Running a simulation#

A run walks your diagram forward through simulated time and hands each block's output to whatever it feeds. This page covers the settings that govern that walk and how to start and stop it.

Starting and stopping#

Press Run. The run advances from the start time to the stop time, filling in any scope as it goes, and stops on its own when it reaches the end. Stopping it early is the Stop control; a stopped run keeps whatever it has already produced, so the scope does not clear.

The settings you actually set#

Everything a run obeys is in the model configuration panel, and the same values can be read from the command window. This is the full set, at the defaults a new model starts with:

$ ICoreBlocks --console "modelConfig"
  startTime                     0
  stopTime                      10
  infiniteSimulation            false
  solverType                    Continuous
  steppingType                  Fixed-step | Runge-Kutta | RK4
  discretizationMethod          Zero-order Hold
  multiRateTolerance            1e-09
  globalSamplingTime            0.1
  maxTimeStep                   0.1
  minTimeStep                   0.001
  initialTimeStep               0.01
  relativeTolerance             0.001
  absoluteTolerance             1e-12

Of those, four are the ones most models need:

Setting	What it decides
`startTime` / `stopTime`	The stretch of simulated time the run covers. These are model seconds, unrelated to how long the run takes on your machine.
`solverType`	`Continuous` or `Discrete` — see below.
`globalSamplingTime`	The rate the model runs at when nothing states its own. At the default `0.1`, a block that inherits its rate produces a sample every 0.1 model seconds.
`stopTime` vs `infiniteSimulation`	Setting `infiniteSimulation` runs until you stop it, and `stopTime` no longer applies.

A setting can also be read or changed from the command window, which is useful when you want to try several values quickly:

$ ICoreBlocks --console "getModelConfig solverType"
Continuous

Where a setting is a choice rather than a number, offering it something else lists what it will take:

$ ICoreBlocks --console "setModelConfig solverType Banana"
setModelConfig solverType: no option matches 'Banana' — available:
  Continuous
  Discrete

Continuous and discrete, and which your model is#

Continuous means the model is written in terms of quantities that change smoothly — an integrator, a transfer function in s, a state-space plant — and the solver advances them with a numerical integration method. The default is fixed-step Runge-Kutta (RK4), and the step-size settings (maxTimeStep, minTimeStep, initialTimeStep) and the two tolerances govern that method.

Discrete means the model is written in terms of samples — a discrete transfer function, a unit delay, a discrete integrator — and the run advances one sample at a time. Here globalSamplingTime is the whole story and the integration settings do not apply.

Most real models are mixed, and that is expected: the solver type says how the continuous parts are advanced, and blocks with their own sample rate keep it regardless.

discretizationMethod (default Zero-order Hold) is how a continuous description is converted when a discrete equivalent is needed — for instance when a continuous plant is run inside a sampled loop.

Sample rate, and the one thing worth checking#

Most blocks carry a Sampling Time (s) parameter set to -1. In the blocks' own words, zero or less inherits the solver's rate; a positive value runs the block at that period. Inheritance runs downwards through the levels — Home takes globalSamplingTime, and a subsystem takes its own rate if it sets one and its parent's otherwise — so it is the enclosing level that decides a block's rate, not whichever block feeds it. Left alone, a whole diagram therefore runs at globalSamplingTime.

Pinning a block to its own rate is how you deliberately run part of a model slower than the rest — a controller sampled at a quarter of the plant's rate, for example. When you do that, the two rates are what you want to check first if the result looks wrong: a signal sampled more slowly than it changes is the most common cause of a response that looks stepped or lags where you did not expect it.

If a run produces nothing, or stops immediately, the diagnostics panel is where the reason is — Reading results — scopes, charts, stored values, and what a run tells you covers what its messages mean.

Real runs#

Every transcript on this page is a real run rather than an illustration. Binary cmake-build-debug/ICoreBlocks.app, built 2026-08-17 01:28 (source at approximately commit c2a229c6); one process per line, HOME=<scratch> QT_QPA_PLATFORM=offscreen ICoreBlocks --console "<line>", with the toolkit's startup noise removed and paths under that scratch home shortened to …. Re-run any line above to check this page against the program.