A few months ago I introducedmy favorite command to analyze the performance of a variable-step solver.

This week, I will introduce how theSimulink Debuggercan be used for a deeper analysis of variable-step solvers performance. For this, we will use thedebugger command-line interface.

Launching the debugger

For this example, let's use the demo modelvdp.mdl. I start the debugger usingsldebugand enable tracing of the solver information usingstrace 1. For this example, I want to run just a small part of the simulation, so I will set a breakpoint after 5 seconds usingtbreak 5.

After using thecontinuecommand (or the one-character shortcutc), a lot of information is displayed.

Solver Information

Let's look at a successful step where we moved from 0.284s to 0.54s.

(click to view full size)

In the above screen capture, you can identify:

• TM:We take a major step at 0.284s


• Tm - Hm:We start a minor step at 0.284s. Based on the evolution of the states during the previous step, the solver thinks this minor step should advance by 0.256 seconds.


• Tm - H:Nothing is blocking us from trying this step, we begin the integration from 0.284s and advance by 0.256s


• Ts - Hs:The minor step was successful, we move forward by 0.256s without exceeding solver tolerance


• Err - Ix:Among all the states in the model, the one closest to the maximum tolerance was state 1 and it's normalized error was 8.2045e-2. The normalization is made relative to the maximum tolerance. An error above 1 exceeds the tolerance and below one passes.

For more details on how to interpret the solver trace information, you can look at the documentation forstrace.

To determine which state had the maximum error, use thestatescommand:

For this step, the state closest to the maximum tolerance (Ix=1) is from the Integrator blockx2.

Step limited by maximum step size

Now let's look at a different type of output. If we move forward to 4.651s, we notice a step where the step size is limited by the solvermaximum step size:

(click to view full size)

If you see many of those in your model, this probably means you could increase the maximum step size in the solver configuration.

Failed step

的有限公司urse, not all steps move forward smoothly. Sometimes the solver needs to take steps back to respect tolerances. If we continue to step forward, at t=13.21s we notice that it took 2 attempts before respecting the tolerance.

(click to view full size)

If this happens often in your model, you might want to try other solvers, like stiff solvers. If this does not help, you might want to look at your equations and the block with the maximum error.

Conclusion

The examples I have given show how the Simulink debugger can be useful to understand why a variable-step solver takes steps of a certain size. Those examples are mainly focused on states, but you can follow the same principle for zero-crossings by using functions likezcbreakandzclist.

I need to stop here because this post is already long enough, but I want to mention that those examples are only the tip of the iceberg. With the Simulink debugger, it is possible to see finer details of the integration done during minor steps and display data for any signal or block.

Now it's your turn

Take the time to go through the list ofSimulink debugger Commandsand let us know if you find something you will use by leaving acomment here