## 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 `ex_spi_show_zc`

model and launch Solver
Profiler.

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.

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

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

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.

### Block Signal

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.

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