I am using HYPERSIM to do simulation. And I pushed the button of Analyze, Map Tasks, and Generate Code before running simulation. Why HYPERSIM needs to do Analyze, Map Tasks, and Generate Code before running simulation?
Good question, this trips up a lot of new users. Here’s what each step actually does and why all three are necessary.
The short answer
HYPERSIM is a code-generation-based real-time simulator. It doesn’t interpret your schematic at runtime; it compiles it into an optimized binary that runs on the target hardware within a strict time budget. The three steps are the pipeline that makes this possible.
- Analyze
Scans your entire network topology — reads all component connections, node names, bus assignments, signal paths, and I/O configurations — and assigns them to internal data structures.
Without this step, HYPERSIM has no knowledge of what your circuit contains. All downstream steps (task mapping, load flow, code generation, I/O binding) depend on a completed analysis. It also catches topology errors early — disconnected nodes, missing parameters, unsupported configurations — before you invest time in compilation.
Run Analyze again after any major circuit modification.
- Map Tasks
Distributes the computational work across the available processor cores on your simulation target.
Real-time simulation has a hard deadline: every calculation must complete within one time step (e.g., 50 µs). HYPERSIM identifies which parts of the network can be computed in parallel — typically exploiting transmission line delays to decouple subsystems — and assigns them to separate cores. The Task Manager estimates execution time per task and balances the load. If any task’s estimated time exceeds the time step, you’ll see a warning before compilation even starts.
For IEC 61850 models specifically, this step also determines which cores handle the GOOSE and SV driver threads.
- Generate Code
Converts the analyzed, task-mapped model into C source code, then compiles it into an executable binary for your target (e.g., OP5650XG running OPAL-RTLinux).
The simulator hardware does not run a HYPERSIM schematic — it runs a compiled binary. The generated C code encodes the discretized electrical equations (trapezoidal integration method), task scheduling, I/O driver bindings, and inter-task communication. Compilation flags (e.g., -O2 optimization) are applied here and directly affect real-time performance.
Smart caching: If you run the simulation again without changing the model, HYPERSIM detects the code is already up to date and skips recompilation — which is why subsequent starts are much faster.
Think of it as a three-stage compiler pipeline:
Schematic (.ecf)
↓
[Analyze] → Parse topology, validate connections, assign node names
↓
[Map Tasks] → Distribute equations across cores, estimate timing
↓
[Generate Code] → Compile C code into a binary for the target
↓
Simulation running on target in real-time
This is why HYPERSIM can achieve microsecond time steps on large power system models — the heavy mathematical work is done at compile time, not at runtime.
Practical tip
When you click Start directly, HYPERSIM will automatically re-run whichever steps are needed based on whether the model has changed. But running them manually first lets you:
Review task mapping and catch overrun risks before committing to a full compilation
Check the log window for I/O sensor or driver warnings (especially useful for IEC 61850 configurations)
Adjust task assignments or compilation settings before the binary is built
Hope that helps clarify the workflow!
@Parija Thank you for your help.