Target IP or hostname on which to compile, load, and execute the simulation.

The drop-down box lists every target previously set up in the Target Manager menu.

The button on the right is a shortcut to open the Target Manager and focus on the selected target.

Real-Time Accelerated (RTA) is a type of offline (or non-real-time) simulation that runs as fast as possible, meaning the actual execution time is usually much faster than real-time depending on the PC specifications.

NOTE: All I/Os are not initialized in this mode.

Real-Time runs a standard real-time simulation where all I/Os are available.

NOTE: When the operating system is Windows, real-time performance cannot be guaranteed due to the nature of this OS, but that doesn't mean that doing HIL simulation is impossible. Certain protocols such as C37.118 whose data are time-stamped and the tolerance on latency is relatively high are very favorable to this kind of application. It's up to the user to define the acceptable boundaries of simulation performance when running in real-time with I/Os on Windows.

Non-editable field. It reports the operating system expected on the target simulator.

Size of the discretization used by all equations. The execution is in real-time if the performance factor = 1, faster than real-time if the performance factor < 1, and slower if the performance factor > 1.

simulation.calculationStep

This parameter can be used for optimizing and debugging in real-time mode. It helps to alter the actual execution time by a specified factor and is usually used to slow down the simulation when more time is needed to compute all equations than what the time step allows.

/!\  Real-time is only when performance factor = 1. The other modes are for debugging purposes only.

Step duration = performance factor * simulation time step

For example, a time step of 50 μs with a performance factor of 2 gives the simulation 100 μs to complete calculations (while the size of the discretization remains 50 μs) and exchange I/Os. Since I/Os are only exchanged between two calculations, it also means that their output frequency is slowed down to every 100 μs.

In other words, with a performance factor > 1, the processors have more time, and heavy tasks can be completed before I/Os have to be exchanged again, and thus overruns can be avoided.

To illustrate the behaviour, say a sine wave is observed on a real oscilloscope: its period is equal to the product of the performance factor and the real period. This is like playing a video in slow motion.

simulation.performance

This parameter is set automatically depending on the chosen target.

Before the simulation, HYPERSIM generates C code specific to each network. This parameter is used to define the directory where the code is saved.

If there is no modification to the model, the second execution is faster as HYPERSIM detects the code has already been generated and skips the compilation step.

For debugging purposes, add more information to the simulation log file (*.simout).

NOTE 1: This decreases real-time performance.

NOTE 2: Communication Protocols have their simulation logging mode that can be configured in the IO interface.

simulation.logging

Enable the iterative solver for non-linearities and zero-crossing. It is enabled on a task-by-task basis depending on the following:

• If switches or breakers are present and iteration is enabled, the iteration is done on the entire topology to guarantee the natural commutation (current crossing zero).

• If nonlinear components are present, in addition to the 'Enable iteration' option, the iteration must be enabled for every component individually. This gives flexibility to the user to optimize for precision or computation time.

To activate iteration for all components, check to Apply to all nonlinear elements.

NOTE: if the precision valve parameter is enabled in a switch, it disables the iteration for all components within the same task.

simulation.iteration.activate

Limit the maximum number of iterations for the iterative method at each step. There is a trade-off between precision and computation time.

simulation.iteration.max

Override individual components' iteration parameters and activate iteration for all components.

simulation.iteration.enable_all_comp

This is the sensor file that is loaded when opening a model. The default value is the eponym .csv file next to the .ecf.

More information on the default sensor file can be found in Sensor Management.

Enables or disables the loading of the default sensor file name.

It can be useful to deactivate this option if the model is meant to be run on different hardware which requires different I/O Factors in the sensor configuration.

The nominal frequency of the power system model. For example, this value is used to calculate the load flow and to calculate monitoring values of the Monitor component.

loadflow.frequency

The power base when displaying power in PU.

loadflow.pbase

The load flow convergence tolerance.

loadflow.tolerancePQ

The maximum number of iterations for the load flow algorithm to search for a convergent solution.

loadflow.maxIteration

Usually set to 1 for most cases, this parameter is used only when iteration is necessary to find a solution. Decreasing its value reduces the size of the variation between two iterations.

loadflow.decelerationFactor

If checked, the load flow algorithm is executed and initial conditions are set every time the simulation is started. Otherwise, generators start from a steady-state.

loadflow.steadyStateStart

Opens the Target Manager

Opens a Windows Explorer dialogue to the location of the code directory (if valid).

Opens a file browser to select a different directory. It is not saved and is only valid for the duration of the session.

Resets the default directory.

Deletes the contents of the code directory.

Opens the Task Manager

C Flags are specific to the compiler used. They are used to send extra arguments to the compiler when generating the C code of a model.

For Intel and GCC, the basic flags are -O0, -O1, and -O2 where -O0 = No Optimization -O1 = A bit of Optimization and -O2 = Maximum Optimization.

-O2 is the value by default for Intel and GCC compilers.

Example: Passing defines (-D) :

• -Ddef1, -Ddef2=val2

• or options (-O) : -O2 -O3 to the compiler.

architecture.<ARCH_NAME>.cflags

Used to build generated code in parallel on several cores.

/!\ It is highly recommended that users not modify this parameter.

Localhost default value: %{TOOLS_MSYS}/usr/bin/make -j10

Target default value: /usr/bin/gmake -j10

architecture.<ARCH_NAME>.makecmd

A compiler generates object files from source code. This field chooses what compiler to build with either opgcc or opicc. (Intel compiler requires a license.)

Using gcc builds faster, but using icc gets better performance. 

Localhost default value: %{TOOLS_MINGW}/bin/gcc

NOTE 1: For localhost, only gcc is compatible.

Target default value: opicc (wrapper of icc)

NOTE 2: if you use icc as Compiler for example, you must use icc as Linker.

architecture.<ARCH_NAME>.compiler

A linker combines these object code files into an executable. This field chooses what linker to use. Either gcc or icc.

Localhost default value: %{TOOLS_MINGW}/bin/gcc

Target default value: opicc (wrapper of icc)

NOTE: if you use gcc as Compiler for example, you must use gcc as Linker.

architecture.<ARCH_NAME>.linker

It indicates what server is used for compilation.

/!\ This value must not be modified.

Localhost default value: localhost

Target default value: "IP address" or "Target Name"

Delay allocated for communication between processors.

For example, when doing a task mapping, the minimum time step required to run the simulation is calculated as follows:

Minimum Time Step per core = (Estimated execution time per task assigned to a core / Processor Performance) + Communication overhead + I/O overhead

Where the Exec Time is the maximum execution time needed by the biggest task.

Localhost default value: 1.0e-9

Target default value: 4.0e-6

architecture.<ARCH_NAME>.overheadcomm

It's the delay allocated to I/Os to communicate.

For example, when doing a task mapping, the minimum time step required to run the simulation is calculated as follows:

Minimum Time Step per core = (Estimated execution time per task assigned to a core / Processor Performance) + Communication overhead + I/O overhead

Where the Exec Time is the maximum execution time needed by the biggest task.

Note that I/O overhead is considered by the core only if this core has I/Os. So if you don't use any I/O, the minimum time step becomes:

Time step = (Estimated execution time per task assigned to a core / Processor Performance) + Communication overhead

Localhost default value: 1.0e-9

Target default value: 2.0e-6

architecture.<ARCH_NAME>.overheadio

This parameter has two functions:

• During task assignment, used to artificially increase or decrease the computation capacity of cores.

Processor performance * Time Step = Microseconds available per core

This value is then compared to the minimum time step enumerated previously.

• During a real-time simulation, Execution time = Time step * Performance factor

For example, if the user observes a sine wave on a real oscilloscope, its period will be Processor performance * Time step.

With Processor performance > 1, the time allocated for each time-step will be (Processor performance * Time step), the CPUs have therefore more time and more tasks will be packed in each CPU.

Localhost default value: 8.5

Target default value: 20

architecture.<ARCH_NAME>.procperf

This timeout is applied when the trig signal is not received by ScopeView.

acq.powTimeoutDelay

Set the number of CPU for code generation

-1: use as many CPU as the system can carry

0: disable the feature

from 1: use the number of CPUs specified by the user. if this value is higher than the number of CPUs available, it uses as many CPUs as the system can carry.

simulation.numThreadCodeGen

When a control component is connected to the input of a network component, the control can be solved after the network in the task. It means that there is a calculation step delay on values measured by network components connected to the control.

When this option is enabled, control components connected to the input of network components are solved before in the task and the calculation step delay disappears.

This option is enabled by default. If you want to disable the feature, it needs to be specified before generating the code for the simulation to take it into account allowing the power blocks to initialize correctly.

simulation.preVNodePowerInputControls

This timeout applies to the initialization (such as creating I/O connections, connecting to external hardware...) and stopping the sequence of the simulation. Increasing its value may be necessary when working with a high number of I/O connections.

NOTE: Increasing its value also causes a longer waiting time when other issues prevent the simulation from correctly starting/stopping.

Should this happen, contact technical support.

simulation.rpcCallTimeout

Indicates that this simulation’s start is synchronized with another external simulation’s start using a synchronization signal. To configure the signal, see the following section https://opal-rt.atlassian.net/wiki/spaces/DOCHS/pages/20166359/OPAL-RT+Board#General-Configuration, Use external synchronization source/Type of generated synchronization signal/Operate as hardware synchronization source.

NOTE: Synchronization is carried out by a driver (Opal-Board) and is therefore always performed after a waiting period to stabilize the model (see next line).

simulation.extSimStartEnable

Specify the number of steps to wait before enabling I/O operations and starting to monitor simulation performance. This delay allows the CPU to stabilize its performance, ensuring accurate monitoring and optimal system behavior. A large value might negatively impact numeric stability when using I/Os. A small value might result in overruns for the first few steps. The correct number depends on the model and its I/Os.

simulation.fullSpeedCount

• If checked, a transceiver component is automatically added in all locations where it is needed to succeed in mapping tasks.

• If unchecked and a transceiver is needed, an error message during the task mapping step specifying the location where it is needed is displayed.

NOTE: Transceivers are used to decouple control tasks into different tasks.

simulation.autoAddTransceiver

Automatically convert the signal from FLOAT to INT or INT to FLOAT. This option replaces the use of conversion control components.

simulation.autoAddFtoIItoF

Check if more than one output signal is connected to the transceiver.

simulation.transceiverValidation

Auto-run Exata CPS simulation

True/False

If the condition is set to True, the designated EXata CPS Executable will automatically launch at the initiation of the simulation, utilizing the specified configuration file format (JSON or config)

Close Exata CPS GUI on stop simulation

True/False

if the condition is set to true, stopping the simulation will automatically close Exata opened earlier.
This can only be true if Auto-run is set to true,

EXata CPS Executable

String

path to EXata executable

From json

String

Not editable, path to the auto-generated configuration file, located in hyp_folder/exata/exata_opalrt_configfile.json

From config

String

Path to EXata configuration file.

 Browse for file

 open EXata GUI with the selected configuration file