Global solvers, per-rate subsystems
Six integration methods, two solver types, and subsystems that keep their own rate.
The solver types
A model is Continuous or Discrete. The type says how the model advances, not what is in it: most real models are mixed, with continuous dynamics and discrete logic in the same diagram, and that is expected rather than a compromise.
The six methods
| Stepping | Method | Order |
|---|---|---|
| Fixed-step | Euler | RK1 |
| Fixed-step | Improved Euler (Heun) | RK2 |
| Fixed-step | Bogacki–Shampine | RK3 |
| Fixed-step | Runge–Kutta | RK4 |
| Variable-step | Dormand–Prince | RK45 |
| Variable-step | Bogacki–Shampine | RK23 |
Fixed-step methods are also what code export requires, because a generated core advances by a known step. Variable-step methods are for studying the model in the app, where the solver may take the step the dynamics deserve.
getModelConfig and setModelConfig.Subsystems at their own rate
A subsystem can run at a sampling rate of its own — a controller at 1 kHz inside a plant model stepped far finer, say. Rates are reconciled against a multi-rate tolerance you can set, so two rates that are equal to floating-point noise are treated as equal rather than as a rate change.
Setting it
Everything above is in Model Configuration, and every field has a console equivalent —
getModelConfig and setModelConfig — so a study that sweeps solver
settings is a script, not an afternoon of clicking. Naming an option that does not exist prints
the ones that do.
See also: Multi-target, multi-rate deploy · Code export
See it run on your own model.
Download the application from the customer portal, or read the documentation first — the manual, every block with its measured response, and the full command reference are public.