Main Content

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.

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

The Solver Profiler records `67`

solver resets caused by zero
crossings from the Switch block in the model. 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 *t _{s}* = 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.

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

Sometimes, the block can be configured to reset the solver when certain conditions
are satisfied during its execution. Consider the
`sldemo_bounce`

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