Knowledge Base

Welcome to OPAL-RT’s Knowledge Base

OPAL-RT offers a repository of support information for optimal use of its technology.

Please note that OPAL-RT knowledge base is not fully optimized for mobile platforms.

For optimal experience, use a desktop computer.

Reference Number: AA-02057 // Views: 76 // Created: 2022-01-10 23:21:29 // Last Updated: 2022-01-10 23:36:49
General Article
HYPERSIM: 7 Ideas to Get Rid of Stretched Steps (Overruns)

HYPERSIM: 7 Ideas to Get Rid of Stretched Steps (Overruns)


The Real-Time tab in HyperView allows the user to keep track of the simulation performance. One of the key parameters is the 'Stretched Step'.

First, what is a Stretched Step?

Stretched Step

The number of steps where execution delays could not be compensated in the following step, since simulation start or last reset.

It is equivalent to 'overruns' in RT-LAB.

In other words, if the number of stretched step keep increasing throughout the simulation, it means that the simulation is running slower than the time in real life.

This article covers general ideas to get rid of stretched step in HYPERSIM.

Idea 1: Increase the time step

The most straight forward idea: take a look at the Exec and Exec Max in HyperView, if they are almost equal to Ts, or not much bigger, increasing the time step can be an easy solution.

To do so, simply stop the simulation and go to Settings:

The main disadvantage of this first idea is that, the bigger the time step, the bigger the granularity. In other words, the accuracy of the model compared to real life might be lower. It is up to designer to decide if it is acceptable to increase the time step or not.

Idea 2: Use more cores of the simulator / adjust the estimated execution time (Task Manager)

NOTE: To know the number of cores available on the simulator, check the Target Manager:

1- For the physical cores available.

2- For the license.

HYPERSIM automatically assign the tasks on different cores based on estimated execution time. Sometimes, HYPERSIM can be wrong in the estimation and thus using less cores than what it should.

For this, one approach is to reduce the processor load level. HYPERSIM will think the cores are "less powerful" therefore will distribute the tasks on more cores.

NOTE: the processor load level is ONLY for assigning the tasks to different cores. It does not limit the capability of the cores.

A second approach is to manually edit the field in the Task Manager.

It is not obvious, but the input fields are editable:

Note: The edited times will appear in orange.

This is especially useful for custom code (such as UCM), where HYPERSIM often estimates zero second of execution time required.

Idea 3: Try a different compiler

The Intel compiler is known to have more optimization tricks compared to GCC. To change compiler, simply follow this KB: HYPERSIM 6.0+: How to switch / change to GCC compiler instead of Intel compiler?

NOTE: Please make sure that the Intel compiler was purchased. This information can be found in the purchase order.

Idea 4: Adding decoupling elements

Similar to idea 2, if there is one task that is too big, it might cause overruns.

An idea is to help HYPERSIM by adding a decoupling element in the model, so that it can split one big task in smaller tasks.

For more information about the decoupling element, consult this KB: HYPERSIM: More Information About Decoupling Elements.

NOTE: HYPERSIM automatically decouples using transmission lines that are long enough. If there are some 'constant param' lines in the model, increasing their length might help for decoupling.

Idea 5: Removing extra switches

This one is pretty straight forward too: the more switches there are, the bigger the number of possible combinations there will be (exponential). Removing unused switches should help reduce the execution time.

Idea 6: Include / exclude part of the model / Simplify the model

If the maximum number of cores is reached or the model is too big, it is time to ask: what is the level of detail required for that model?

For instance, is it mandatory to use dynamic load at each bus or and R-L-C equivalent could do the job too?

Idea 7: (If there are communication protocols):

The stretched step could be due to too many communication protocols on core 0. Try to use the option 'Use an RT core for asynchronous computation' to reduce the charge on core 0.

If, after all those ideas, your model is still having stretched step, do not hesitate to contact Technical Support via: