Main Content

Solver Resets

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.

Note

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.

Zero-Crossing

Some zero crossing events occur at discontinuities in the signal. Consider the example model of a bouncing ball from the Zero-Crossing Events section.

Open the model BouncingBallWithSwitch and open Solver Profiler.

The Solver Profiler records 46 solver resets, 45 of them are caused by Zero Crossing events from the 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.

Discrete Signal

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.

When a discrete input to a Model block connects to the input of a block that has continuous states, the software cannot determine with certainty the appropriate rate at which to reset the solver to ensure simulation accuracy. The software resets the solver each time the discrete signal updates. This solver reset rate ensures that the simulation results are accurate when the discrete signal is the source for the input signal to the block with continuous states. When the discrete signal is not the source for the input signal to the block with continuous states, the software can reset the solver more frequently than necessary, which can affect simulation performance.

ZOH Signal

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 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.

Note

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 NaN.

This is because the driving Fixed-in-Minor-Step Sample Time 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.

Tip

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.

Block Signal

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.

Initial Reset

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.

Internal

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.