Using Solver Profiler for analyzing variable step solver performance | Simscape Electrical Modeling Practices for Fast Simulation

Hello, my name is Eva, and I'm an application engineer at MathWorks. And today, I would like to show you how you can use the Solver Profiler to examine solver behavior throughout the simulation and identify potential issues that might contribute to poor simulation performance. The model used in this video was taken from the Simscape electrical examples library.

Open the Solver Profiler app by going to Debug, Performance Advisor, Solver Profiler, and this will open up an interface from where I can start the simulation and at the same time capture solver statistics. So from here, I will enable additional logging settings for continuous states, Simscape states, and zero crossings. This will, after the Run, allow me to look at additional viewers. From here, start the simulation and profiling.

After the run, the solver profiler is displaying a plot of chosen step size against the simulation time. This allows to explore where the solver is taking small time steps. The left pane is displaying some general statistics on the solver settings, time stepping, and different events happening throughout the simulation. For example, it could be of interest to compare the ratio of runtime versus simulation time as changes are being made.

Above the graph, select to highlight additional events, for example check zero crossing in the time step plot. This will mark where zero crossing events are happening. And below the graph, there are tabs which are guiding through the different events and help me to investigate those in more detail.

The first suggestion tab is making some general suggestions. For example, it is reporting here that there are a lot of consecutive solver exceptions being triggered and that I should be looking into blocks that are contributing to those. And it is also telling me that for most of the total simulation time the maximum allowed time step was taken, so increasing that could potentially speed things up.

The remaining tabs guide me through those different events, starting with zero crossing events. When zero crossing detection is turned on, these events are being triggered to accurately simulate discontinuities, for example sudden changes in signals. And by making the time step smaller, the solver will try to precise the time where those are happening. Here, this is pointing me to one specific block which is triggering the majority of zero crossings.

From here, select Highlight block to point to which those are. The report here is pointing to an absolute block where a change in the input signal sign is triggering a zero crossing event. From here, navigate to the Zero Crossings Explorer to display even more detail. This will open up an additional viewer specifically for zero crossing events.

On the left side, the zero crossing events are ordered by number of times they have been triggered during the simulation. On the right-hand side, the corresponding signal is being plotted. So the oscillating input signal is triggering an event whenever it is crossing the zero mark.

So here the solver seems to be recovering quite quickly after that. Based on the requirements for your simulation, you would decide to resolve or include this. For example, you could adapt the zero crossing detection on block or global level or leave the accuracy as is.

The next is the Solver Exceptions tab. Solver exceptions occur when the solver was not able to meet my accuracy requirements, and to solve them additional trials needed to be made. And the events themselves are based on different criteria. These are displayed here in the different columns.

The error control events show which parts of the model are close to exceeding the tolerance limits, and this list showing me which states contributed to being close to exceeding those limits and how often they have triggered this event. The Newton iterations are related to implicit solvers and show where the iterations are not converging after a couple of trials. Similar to error control, these often occur when the system is undergoing rapid changes.

Both of these don't necessarily indicate poor modeling, and the collected statistics are not intended to help you in getting these down to zero. But if they are happening a lot, you should investigate those closer to see if the variable is behaving as expected or if this might point to a modeling issue. This could also be caused by bad variable scaling.

The infinite state and derivatives occur when the magnitude of states or its derivative is approaching infinity. So again, this is where the solver needs to adjust the time steps. Simscape models use DAEs, or Differential Algebraic Equations, and these add complexity. And when that algebraic constraint is changing fast and the iterations are failing, this will trigger solver exceptions to resolve those.

To explore individual variable behavior in more detail, from here the Simscape Results Explorer or the State Explorer can be opened. I am selecting the State Explorer. This opens an additional viewer to look at individual state behavior. It can be ranked by either the exception type that is being investigated or it can be ranked by value. The right-hand side plot is now showing the state behavior, So. Here the values, how they change over time, and the derivative value.

This allows to check if the states are behaving as expected or if some of the behavior is related to noise. Depending on the magnitude of the state values, you could also decide to adjust tolerance, or, for Simscape networks, the variable scaling settings. The Simscape variable scaling tool that helps with that will be covered in a separate video.

The next tab lists the solver resets. This logs events where the solver was forced to reset its parameters. This can be due to different causes. It can be related to the zero crossing events. The discrete signal type is pointing to where a discrete signal is driving a block that has continuous states. This could also happen when this is directly driving a Simscape block.

The zero order hold reset occurs when some block output is not executed during a solver trial or minor time step and block changes, specifically for some blocks that can themselves trigger a server reset, for example an integrator that is set to reinitialize at certain points. Here, this is pointing generically to my overall Simscape network. And the states below Absolute Tolerance tab lists states where their numerical value was below the defined absolute tolerance. This is also where the state viewer can help me to decide again if these are important dynamics or if this is just noise from individual states.