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

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