# Simulink Debugger: Monitoring Variable Step Solver Performance 2

Posted by **Guy Rouleau**,

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

This week, I will introduce how the Simulink Debugger can be used for a deeper analysis of variable-step solvers performance. For this, we will use the debugger command-line interface.

**Launching the debugger**

For this example, let's use the demo model `vdp.mdl`. I start the debugger using `sldebug` and enable tracing of the solver information using `strace 1`. For this example, I want to run just a small part of the simulation, so I will set a breakpoint after 5 seconds using `tbreak 5`.

After using the `continue` command (or the one-character shortcut `c`), a lot of information is displayed.

**Solver Information**

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

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

To determine which state had the maximum error, use the states command:

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

**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 solver maximum step 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**

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 like zcbreak and zclist.

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 of Simulink debugger Commands and let us know if you find something you will use by leaving a comment here

**Category:**- Debugging,
- Numerics,
- ODEs

## 2 CommentsOldest to Newest

**1**of 2

Dear Mr. Guy

How are you doing ? i was just trying to work out on a project for my masters using simulink . In my model i have 2 blocks which i need to run one after the other and how can i control the timings of each block. If possible i can attach you the model and let me know if you can help.

Thank you for your reply in advance.

Regards

Amith

**2**of 2

@Amith: Simulink determine the order of block execution based on data dependency. If block B needs the output of block A to execute, then block A will run first.

If there is no data dependency between two blocks, then you can set block priority:

http://www.mathworks.com/help/simulink/ug/controlling-and-displaying-the-sorted-order.html#f13-91958

## Recent Comments