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.

Pause holds the run where it is, and Run resumes it. Debug starts the run stopped, and Step advances it one solver step at a time. To run up to a particular moment and hold there, click the time line at the bottom of the window ahead of the progress mark: an amber mark appears at that time, the run continues normally — every step is still solved, nothing is skipped — and pauses on its first step at or past the mark. In Debug mode the run steps by itself up to the mark and then waits for Step again. Click the mark to remove it; the part of the ruler already simulated is drawn solid and cannot take a mark. A mark set before you press Run applies to that run, and one the stop time no longer reaches is dropped when the run starts, with a line in the diagnostics.

⚠ Two things can stop a run before the solver starts, and both are the licence. A licence that has expired — lapsed, with the licensing service reachable and saying so — refuses with "Simulation is unavailable because this licence has expired." A session with no licence at all — for instance after cancelling the sign-in dialog — refuses with "Simulation is unavailable because no licence has been resolved.", and signing in from Help ▸ Account… lifts it. Either way the model is untouched; every model still opens and still saves. Working offline on a lapsed token is not this: that is grace, it is fully functional for thirty days, and the banner counts them down. See Troubleshooting — the messages you will meet and what to do.

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
  maximumConsecutiveTimeBuffer  10000
  slowPaceStepDelay             0
  solverType                    Continuous
  steppingType                  Fixed-step | Runge-Kutta | RK4
  solverCoupling                Joint | continuous states integrated together
  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
  timeBudgetValidationEnabled   false
  timeBudgetRelativeTolerance   1e-09
  timeBudgetAbsoluteTolerance   1e-12
  unitsInconsistencyMessage     warning
  automaticUnitConversions      true

Of those, four are the ones most models need:

The last two settings are about units. A subsystem's input and output ports can each carry a Unit (m, rad/s, degC), spelled as Simulink spells it. Where a port sets a unit different from the one arriving on its wire, and both measure the same quantity, the value is converted on the way through, as Simulink does by default: a 3 sent out in m reaches a port set to cm as 300. The run says so in the diagnostics, and it warns, without converting, when the two units measure different quantities. automaticUnitConversions false passes every value through unchanged instead, and unitsInconsistencyMessage none silences the warnings.

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), which steps at globalSamplingTime. If a model mixes very fast and very slow dynamics (a stiff model) and the run only stays stable at a tiny step, switch steppingType to one of the two implicit fixed-step methods, BE1 (Backward Euler) or TR2 (Trapezoidal); they keep the same globalSamplingTime and remain exportable. The variable-step methods pick their own step as they go: RK45 and RK23 for ordinary models, TRBDF2 for a stiff one (it is the implicit choice, and the one to try when RK45 crawls or reports the Min Step Size warning). Only for them do the step-size settings (maxTimeStep, minTimeStep, initialTimeStep) and the two tolerances apply. A variable-step run also lands exactly on the moments a source block announces in advance — a Step's step time, a pulse edge, a table breakpoint — so those jumps are sharp in the result rather than smeared over whichever step happened to contain them. Whichever method you choose, the first sample of a run is the model's initial condition and the last sample is stopTime itself.

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. Discrete blocks (a unit delay, a discrete filter) keep their own sample rate under Continuous, fixed or variable step; under Discrete everything runs at globalSamplingTime — the details are on Sample time and loops — how the simulator paces a diagram.

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 build/ICoreBlocks.app, built 2026-09-26 10:51 (source at approximately commit 4d4d8b0d); one process per line, HOME=<scratch> ICoreBlocks --console "<line>", with the startup lines removed. Re-run any line above to check this page against the program.