Running a simulation

"Getting started" ran a model offline, as fast as the engine can go, with no relationship to wall-clock time. That's the right default for most runs, but not the only mode: this page covers online/paced execution, pausing mid-run, reading back how the engine actually executed and extending a finished run instead of starting it over. All of it on the bundled "Thermal Management" example again.

Offline vs. online

The run dialog's Online simulation toggle switches between the two modes.

Offline runs at maximum speed with no synchronization at all, the right choice for "just show me the result." Online paces the simulation against wall-clock time instead, at a rate set by Online pacing (real time, or a custom ratio). That trade only matters once something on the other end is watching or steering the run live: a plotted value updating as it happens, or a Live parameter (mentioned in "The graph canvas") adjusted mid-run and felt immediately, rather than only after the fact in a completed result.

While it's running

An online run can be paused and resumed at its synchronization boundaries, without losing any state.

The status bar names exactly where you are: "Running" while it's live, "Paused" once you've stopped it and eventually "Model locked" once it's done. The model stays read-only for as long as a result exists, whether that result finished instantly (offline) or took several real seconds to pace through (online).

How it actually ran

Once a run completes, an execution summary is available describing how the engine actually executed it: serial, thread-pooled or partitioned across workers, chosen automatically based on the model's size.

For a model too small to benefit from it, that's a one-line explanation. A larger, partitioned run reports the actual partitioning strategy and the communication cost it produced. That's useful when a model's execution time stops matching expectations and the question becomes "where did that time actually go."

Choosing an execution backend manually

The execution summary above is a report on a decision already made. The gear icon beside Run opens the same settings before a run starts.

Global timestep and output interval live here rather than in the per-run dialog, since they belong to the configuration, not to any one run. Backend offers the same four choices Automatic picks between on its own; setting one explicitly is useful for measuring a model's behavior under a specific backend rather than whatever Automatic would have chosen. Worker limit caps how many workers any backend but Serial is allowed to use.

Advanced execution is mostly about Partitioned specifically: which partitioner to use, how many partitions to target and how strongly to weigh communication cost against balance. The last two fields matter even under Automatic, since they're what it checks before deciding to partition at all: Parallel work threshold is the estimated-work floor below which a model just runs serially, and Maximum automatic cut fraction is the inter-node communication cost above which Automatic falls back to a shared thread pool instead of partitioning.

Extending instead of restarting

A completed run doesn't have to be thrown away to see further: Extend simulation continues from the exact final checkpoint rather than recomputing everything from the start.

It reopens the same run dialog, pre-filled with the previous run's settings (online/offline, pacing) and a target time to raise. Starting it appends new results onto the existing timeline instead of replacing it.

Where to go from here

Everything here has been about producing a result. Next up: reading a result back in more depth than a single node's live value, scrubbing the full timeline, comparing signals and branching a result into an alternative continuation.