The Solver Profiler logs events that cause the solver to reset its parameters because solver resets do incur computational cost. In addition to the total number of resets, you can also see a breakdown by type of reset event.
A solver reset event can have multiple causes. As a result, the number of Total solver reset events in the Statistics pane may be less than the sum of the solver resets of each type.
Some zero crossing events occur at discontinuities in the signal. Consider the example model of a bouncing ball from the Zero-Crossing Events section.
ex_spi_show_zc model and launch Solver
The Solver Profiler records
46 solver resets,
45 of them
are caused by Zero Crossing events from the
ex_spi_show_zc/Switch block. The solver resets
are displayed on the Step Size plot as green dots. Compare the step-size and
the Solver Reset highlighting with the output
x of the Second-Order Integrator
block, which is the height of the ball from the ground. Observe that the
solver resets occur when the ball bounces off the ground.
Solver resets also occur when your model has a discrete signal driving a block with continuous states, as seen in this example model.
The discrete Sine Wave block outputs a 1 rad/s sine wave with a discrete sample time ts = 2.
The Solver Profiler report shows that four solver resets occur due to discrete signals driving a continuous block. These resets occur at every execution of the Sine Wave block.
This type of solver reset occurs when a block output is not executed during a trial or minor time step and gets updated only during the integration or major time step. As a result, the block output changes discontinuously from one major time step to the other. As a result the solver resets. See Fixed-in-Minor-Step sample time.
This example model shows a simple plant and controller that tracks a sinusoidal reference signal. The source of this signal is a Sine Wave block whose sample time is specified to be fixed-in-minor-step.
Observe from the results of the profiling session that there are
80 ZOH Signal solver resets in the simulation.
When you select Continuous States for logging or enable the
SaveStates parameter, the derivative of a continuous block driven by a Fixed-in-Minor-Step signal is
This is because the driving Fixed-in-Minor-Step block updates its value only at every major time step. The signal driven to the continuous block is therefore discontinuous and the state is non differentiable.
The plot shows the outputs of the Sine Wave and Integrator blocks in the example model.
Solver resets caused due to ZOH signals are serious compared to solver reset events caused by discrete signals and can significantly slow down the simulation. This is because ZOH signal reset events occur at every major step of the solver. Reconfigure your simulation to avoid these resets, if needed.
Sometimes, the block can be configured to reset the solver when certain conditions are satisfied during its execution. Consider the
sldemo_bouncemodel of a bouncing ball which can be found in the Capture the Velocity of a Bouncing Ball with the Memory Block example.
Observe from the profiling results that there are
130 solver resets triggered by a block. A solver reset event can have multiple causes. In this case, zero crossings and block changes cause a solver reset event.
One setting that causes the Block Change solver reset event is the Reinitialize dx/dt when x reaches saturation parameter. This setting is necessary to properly simulate the dynamics of a bouncing ball.
When you run a simulation, the solver needs to reset its parameters for the first time. This event is shown as the Initial Reset event in the Solver Profiler report. It occurs once at the start of the simulation.
There are some reset events that are internal to the Simulink® engine. These reset events are necessary for the engine to correctly configure itself for accurate simulation.