Documentation Home Page ◇ HYPERSIM Home Page
Pour la documentation en FRANÇAIS, utilisez l'outil de traduction de votre navigateur Chrome, Edge ou Safari. Voir un exemple.
Simulation Settings
Simulation Settings can be accessed through the HYPERSIM ribbon.
General
Through the Simulation Settings window, users can specify the following parameters:
Target Configuration | |
---|---|
Target | 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. |
Simulation mode | 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. |
Architecture | Non-editable field. It reports the operating system expected on the target simulator. |
Simulation | |
Time-step (s) | 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. |
Performance factor | 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. |
Code directory | 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. |
Enable simulation logging | 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. |
Nonlinear elements iterative method | |
Activate iterative method | Enable the iterative solver for non-linearities and zero-crossing. It is enabled on a task-by-task basis depending on the following:
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. |
Maximum iterations | Limit the maximum number of iterations for the iterative method at each step. There is a trade-off between precision and computation time. |
Apply to all nonlinear elements | Override individual components' iteration parameters and activate iteration for all components. |
Model sensors | |
Default sensor file name | 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. |
Automatically open sensor file with design | 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. |
Load flow | |
Frequency (Hz) | 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. |
Power base (MVA) | The power base when displaying power in PU. |
PQ tolerance (MVA) | The load flow convergence tolerance. |
Max iterations | The maximum number of iterations for the load flow algorithm to search for a convergent solution. |
Deceleration factor | 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. |
Perform load flow | 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. |
Feature Quick Access Buttons
Several other interface buttons provide quick access to other features:
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 |
Target
%{TOOLS_MSYS} and %{TOOLS_MINGW} is replaced by the absolute path in the UI.
This tab allows overriding the target's general advanced settings related to compilation and task mapping.
It does not overwrite the values in the Target Manager and therefore is specific to this model only.
Compilation | |
---|---|
Cflags | 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) :
|
Make command | 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 |
Compiler | 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. |
Linker | 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. |
Server | 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" |
Task Mapping | |
Communication overhead | 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 |
I/O overhead | 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 |
Processor performance | This parameter has two functions:
Processor performance * Time Step = Microseconds available per core This value is then compared to the minimum time step enumerated previously.
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 |
Advanced
This tab allows overwriting the target's general advanced settings related to Acquisition, Code generation, Simulation Server, and Topology
Acquisition | |
---|---|
Point-on-wave detection timeout | This timeout is applied when the trig signal is not received by ScopeView. |
Code Generation | |
Number of CPU for code generation | 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. |
Solve control inputs before solving power | 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 Server | |
Start/stop timeout | 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. |
External simulation start | Indicates that this simulation’s start is synchronized with an another external simulation’s start using a synchronization signal. To configure the signal, see the following section https://opal-rt.atlassian.net/wiki/spaces/PDOCHS/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). |
Number of steps before enabling I/Os | 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. |
Topology | |
Auto-transceiver |
NOTE: Transceivers are used to decouple control tasks into different tasks. |
Convert signal type mismatch | Automatically convert the signal from FLOAT to INT or INT to FLOAT. This option replaces the use of conversion control components. |
Enable transceiver validation | Check if more than one output signal is connected to the transceiver. |
EXata CPS (EXata CPS)
This tab allows the configuration of EXata with HYPERSIM
EXata CPS configuration | ||
---|---|---|
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. |
EXata CPS Executable | String | path to EXata executable |
From json | String | Not editable, path to the auto-generated configuration file, located in |
From config | String | Path to EXata configuration file. |
Browse for file | ||
open EXata GUI with the selected configuration file |
OPAL-RT TECHNOLOGIES, Inc. | 1751, rue Richardson, bureau 1060 | Montréal, Québec Canada H3K 1G6 | opal-rt.com | +1 514-935-2323
Follow OPAL-RT: LinkedIn | Facebook | YouTube | X/Twitter