{"id":16659,"date":"2024-07-22T15:10:25","date_gmt":"2024-07-22T19:10:25","guid":{"rendered":"https:\/\/blogs.mathworks.com\/simulink\/?p=16659"},"modified":"2024-08-23T14:21:38","modified_gmt":"2024-08-23T18:21:38","slug":"derivative-of-state-1-in-block-x-y-integrator-at-time-0-55-is-not-finite","status":"publish","type":"post","link":"https:\/\/blogs.mathworks.com\/simulink\/2024\/07\/22\/derivative-of-state-1-in-block-x-y-integrator-at-time-0-55-is-not-finite\/","title":{"rendered":"Derivative of state ‘1’ in block ‘X\/Y\/Integrator’ at time 0.55 is not finite"},"content":{"rendered":"
\"\"<\/img><\/a><\/div>
Let's look at another frequently visited <\/span>MATLAB Answers<\/span><\/a> page:<\/span><\/div>
Derivative of state '1' in block 'X\/Y\/Integrator' at time 0.55 is not finite.<\/span><\/a><\/div>

The Problem<\/span><\/h2>
Here is a simple model similar to the one I have been using recently in multiple posts.<\/span><\/div>
mdl = <\/span>\"suspension\"<\/span>;<\/span><\/span><\/div><\/div>
open_system(mdl);<\/span><\/span><\/div><\/div><\/div>
\"\"<\/img><\/div>
When simulating the model, we get the same error as reported in MATLAB Answers:<\/span><\/div>
in = Simulink.SimulationInput(mdl);<\/span><\/span><\/div><\/div>
in = in.setModelParameter(<\/span>'Stoptime'<\/span>,<\/span>'500'<\/span>);<\/span><\/span><\/div><\/div>
in = in.setModelParameter(<\/span>'CaptureErrors'<\/span>,<\/span>'on'<\/span>);<\/span><\/span><\/div><\/div>
out= sim(in);<\/span><\/span><\/div><\/div>
out.ErrorMessage<\/span><\/span><\/div>
ans = <\/span>'Derivative of state 'dx' in block 'suspension\/Integrator, Second-Order' at time 284.04767405115081 is not finite. The simulation will be stopped. There may be a singularity in the solution. If not, try reducing the step size (either by reducing the fixed step size or by tightening the error tolerances)'<\/div><\/div><\/div><\/div><\/div><\/div>
\"\"<\/img><\/div>
This error can be triggered by multiple reasons. Before diving into the reasons, I would like to highlight the tools that are the most likely to help you diagnose this type of issue.<\/span><\/div>

Debugging Tools<\/span><\/h2>

Solver Profiler<\/span><\/h4>
Try simulating using the <\/span>Solver Profiler<\/span><\/a>, which you can launch from the Debug tab:<\/span><\/div>
\"\"<\/img><\/div>
In the Explore Gallery, launch the States Explorer.<\/span><\/div>
\"\"<\/img><\/div>
This will allow you to quickly scan all the states in the model and identify which states are diverging:<\/span><\/div>
\"\"<\/img><\/div>

Highlight Source<\/span><\/h4>
Another useful tool is to <\/span>Highlight Signal to Source<\/span><\/a> the signal entering the block reported in the error message:<\/span><\/div>
\"\"<\/img><\/div>
Once enabled, use the arrow keys to highlight the upstream blocks feeding the integrator and try understanding the logic making the equations unstable.<\/span><\/div>
\"\"<\/img><\/div>
\"\"<\/img><\/div>

Simulink Debugger<\/span><\/h4>
The <\/span>Simulink Debugger<\/span><\/a> allows you to step block by block during a simulation, which can be useful to diagnose this kind of issue.<\/span><\/div>
First, select the blocks upstream of the block listed in the error message and enable <\/span>Port Value Display<\/span><\/a>.<\/span><\/div>
\"\"<\/img><\/div>
Select the signal entering the problematic block and add a breakpoint. You have the option to break on <\/span>Inf or NaN<\/span>, but I recommend breaking earlier to better observe what happens before the error. <\/span><\/div>
\"\"<\/img><\/div>
Click Run and when the breakpoint is hit, you will be able to step block by block to try identifying the problem with the equations in your model.<\/span><\/div>
\"\"<\/img><\/div>
Let's now look at the most common situations leading to this error.<\/span><\/div>

Reason 1: Unstable System<\/span><\/h2>
The most common reason for this error is that equations in the model are unstable. This usually happens if the algorithm has been implemented incorrectly, or if you are simulating a system that is truly unstable. <\/span><\/div>
It can be useful to plot the state mentioned in the error message to see that it diverges toward infinity:<\/span><\/div>
plot(out.xout.get(<\/span>'dx'<\/span>).Values)<\/span><\/span><\/div><\/div>
<\/div>
<\/div>
<\/div>
<\/div><\/div><\/div><\/div><\/div>
In this simulation, the size of the model makes it easy to identify the problem. Here is an animation where I enabled port value display for all blocks and I am slowly stepping the model forward so we can see the evolution of each signal. Notice how the values are increasing at each time step:<\/span><\/div>
\"StepUnstableModel.gif\"<\/img><\/div>
The implementation mistake here is that signs specified in the Sum block result in a positive feedback loop. To solve the problem and make this simulation behave as the mass-spring-damper it is trying to model, we need to make the signs of the feedback signals entering the Sum block negative.<\/span><\/div>
in = Simulink.SimulationInput(mdl);<\/span><\/span><\/div><\/div>
in = in.setBlockParameter(<\/span>'suspension\/Sum'<\/span>,<\/span>'Inputs'<\/span>,<\/span>'+--'<\/span>);<\/span><\/span><\/div><\/div>
out = sim(in);<\/span><\/span><\/div><\/div>
plot(out.xout.get(<\/span>'dx'<\/span>).Values)<\/span><\/span><\/div><\/div>
<\/div>
<\/div>
<\/div>
<\/div><\/div><\/div><\/div><\/div>

Reason 2: Step size is too large<\/span><\/h2>
As described in the error message, one possible reason for this error is the solver taking too large steps. This typically happens when using fixed-step solver, which is necessary to generate code and deploy to real-time systems.<\/span><\/div>
Here is a slightly different version of the model.<\/span><\/div>
mdl = <\/span>\"suspensionFixedStep\"<\/span>;<\/span><\/span><\/div><\/div>
open_system(mdl);<\/span><\/span><\/div><\/div><\/div>
I fixed the signs of the Sum block to make the equations stable, but I changed the solver to <\/span>ode3<\/span> with a step size of 1 second.<\/span><\/div>
\"\"<\/img><\/div>
I will simulate the model with larger values for <\/span>k <\/span>and<\/span> c<\/span>, making the system dynamic fast and impossible to capture properly with the step sized of 1 seconds.<\/span><\/div>
in = Simulink.SimulationInput(mdl);<\/span><\/span><\/div><\/div>
in = in.setModelParameter(<\/span>'CaptureErrors'<\/span>,<\/span>'on'<\/span>);<\/span><\/span><\/div><\/div>
in = in.setVariable(<\/span>'k'<\/span>,1e5);<\/span><\/span><\/div><\/div>
in = in.setVariable(<\/span>'c'<\/span>,100);<\/span><\/span><\/div><\/div>
out = sim(in);<\/span><\/span><\/div><\/div>
out.ErrorMessage<\/span><\/span><\/div>
ans = <\/span>'Derivative of state 'dx' in block 'suspensionFixedStep\/Integrator, Second-Order' at time 49.5 is not finite. The simulation will be stopped. There may be a singularity in the solution. If not, try reducing the step size (either by reducing the fixed step size or by tightening the error tolerances)'<\/div><\/div><\/div><\/div><\/div><\/div>
There are multiple ways to analyze the system and decide how to deal with this error.<\/span><\/div>

Analysis 1: The Equations<\/span><\/h4>
A first approach is to analyze the equations in the model. This is obviously easier if the model is small. In this example, we have a <\/span>mass-spring-damper system<\/span><\/a>. The natural frequency of this system can be computed analytically using:<\/span><\/div>
omega_n = sqrt(k\/m)<\/span><\/span><\/div>
omega_n = 223.6068<\/div><\/div><\/div><\/div>
This means that the system will oscillate with a period of:<\/span><\/div>
T = 2*pi\/omega_n <\/span>% oscillation period in seconds<\/span><\/span><\/div>
T = 0.0281<\/div><\/div><\/div><\/div>
To capture this oscillation accurately, we need at least a minimum number of points per oscillation. <\/span><\/div>

Analysis 2: Linearization<\/span><\/h4>
Another approach to study the dynamics of the equations in your system is to linearize it using <\/span>Simulink Control Design<\/span><\/a>.<\/span><\/div>
linsys = linearize(mdl);<\/span><\/span><\/div><\/div><\/div>
We can then extract the natural frequency using <\/span>damp<\/span><\/a>. Thanks to <\/span>MATLAB GPT<\/span><\/a> for <\/span>reminding me the existence of damp<\/span><\/a>.<\/span><\/div>
[wn, zeta, p] = damp(linsys);<\/span><\/span><\/div><\/div>
T_lin = 2*pi\/max(wn) <\/span>% oscillation period in seconds<\/span><\/span><\/div>
T_lin = 0.0281<\/div><\/div><\/div><\/div>

Analysis 3: Variable-Step Solver<\/span><\/h4>
When getting this error with a fixed-step solver, one option is simulating the model with a variable-step solver. First, this gives you a good reference in terms of accuracy.<\/span><\/div>
in = Simulink.SimulationInput(mdl);<\/span><\/span><\/div><\/div>
in = in.setModelParameter(<\/span>'SolverType'<\/span>,<\/span>'Variable-step'<\/span>);<\/span><\/span><\/div><\/div>
in = in.setModelParameter(<\/span>'StopTime'<\/span>,<\/span>'0.2'<\/span>);<\/span><\/span><\/div><\/div>
in = in.setVariable(<\/span>'k'<\/span>,1e5);<\/span><\/span><\/div><\/div>
in = in.setVariable(<\/span>'c'<\/span>,100);<\/span><\/span><\/div><\/div>
outVarStep = sim(in);<\/span><\/span><\/div><\/div>
figure<\/span><\/span><\/div><\/div>
plot(outVarStep.xout.get(<\/span>'dx'<\/span>).Values);<\/span><\/span><\/div><\/div>
<\/div>
<\/div>
<\/div>
<\/div><\/div><\/div><\/div><\/div>
Second, seeing what time steps the variable-step solver is taking can be useful to pick a fixed step-size. The <\/span>Solver Profiler<\/span><\/a> has a Step Size plot that can help with that. In this case, we can see that the variable-step solver needs to take steps slightly smaller than 0.01 second. <\/span><\/div>
\"\"<\/img><\/div>
Once you better understand the system dynamic, it's time to look into solutions.<\/span><\/div>

Solution 1: Smaller step-size<\/span><\/h4>
Let's try simulating the model with different fixed-step size and see what the results look like.<\/span><\/div>
ts = [0.0005 0.001 0.002 0.005 0.01];<\/span><\/span><\/div><\/div>
clear <\/span>in<\/span><\/span><\/div><\/div>
in(1:length(ts)) = Simulink.SimulationInput(mdl);<\/span><\/span><\/div><\/div>
for <\/span>i = 1:length(ts)<\/span><\/span><\/div><\/div>
    in(i) = in(i).setModelParameter(<\/span>'FixedStep'<\/span>,num2str(ts(i)));<\/span><\/span><\/div><\/div>
    in(i) = in(i).setModelParameter(<\/span>'StopTime'<\/span>,<\/span>'0.2'<\/span>);<\/span><\/span><\/div><\/div>
    in(i) = in(i).setVariable(<\/span>'k'<\/span>,1e5);<\/span><\/span><\/div><\/div>
    in(i) = in(i).setVariable(<\/span>'c'<\/span>,100);<\/span><\/span><\/div><\/div>
end<\/span><\/span><\/div><\/div>
out = sim(in,<\/span>'ShowProgress'<\/span>,<\/span>'off'<\/span>);<\/span><\/span><\/div><\/div><\/div>
Looking at the results, we can see that they become less and less accurate as the step size increase. If simulated for a larger stop time, the last step size of 0.01 would eventually error out with the infinite derivative error.<\/span><\/div>
figure;hold <\/span>on<\/span><\/span><\/div><\/div>
plot(outVarStep.xout.get(<\/span>'dx'<\/span>).Values,<\/span>'linewidth'<\/span>,2);<\/span><\/span><\/div><\/div>
for <\/span>i = 1:length(ts)<\/span><\/span><\/div><\/div>
    plot(out(i).xout.get(<\/span>'dx'<\/span>).Values)<\/span><\/span><\/div><\/div>
    legendLabel{i} = [<\/span>'Ts = ' <\/span>num2str(ts(i))]; <\/span>%#ok<SAGROW><\/span><\/span><\/div><\/div>
end<\/span><\/span><\/div><\/div>
axis([0 0.2 -2e-3 2e-3])<\/span><\/span><\/div><\/div>
legend([ <\/span>'Variable-Step' <\/span>legendLabel]);<\/span><\/span><\/div><\/div>
<\/div>
<\/div>
<\/div>
<\/div><\/div><\/div><\/div><\/div>

Solution 2: Use a different solver<\/span><\/h4>
The solver being used can also impact the accuracy of the results. The higher the order, the more computationally expensive, but also the more accurate a solver is.<\/span><\/div>
solvers = {<\/span>'ode1'<\/span>,<\/span>'ode3'<\/span>,<\/span>'ode5'<\/span>,<\/span>'ode1be'<\/span>};<\/span><\/span><\/div><\/div>
clear <\/span>in<\/span><\/span><\/div><\/div>
in(1:length(solvers)) = Simulink.SimulationInput(mdl);<\/span><\/span><\/div><\/div>
for <\/span>i = 1:length(solvers)<\/span><\/span><\/div><\/div>
    in(i) = in(i).setModelParameter(<\/span>'FixedStep'<\/span>,<\/span>'0.005'<\/span>);<\/span><\/span><\/div><\/div>
    in(i) = in(i).setModelParameter(<\/span>'StopTime'<\/span>,<\/span>'0.5'<\/span>);<\/span><\/span><\/div><\/div>
    in(i) = in(i).setModelParameter(<\/span>'Solver'<\/span>,solvers{i});<\/span><\/span><\/div><\/div>
    in(i) = in(i).setVariable(<\/span>'k'<\/span>,1e5);<\/span><\/span><\/div><\/div>
    in(i) = in(i).setVariable(<\/span>'c'<\/span>,100);<\/span><\/span><\/div><\/div>
end<\/span><\/span><\/div><\/div>
out = sim(in,<\/span>'ShowProgress'<\/span>,<\/span>'off'<\/span>);<\/span><\/span><\/div><\/div><\/div>
Here we can see that <\/span>ode1<\/span> is unstable while <\/span>ode5<\/span> gives results close to the variable-step solver. <\/span>Ode1be<\/span> is an <\/span>implicit solver<\/span><\/a> that is especially good at remaining stable when solving stiff systems.<\/span><\/div>
figure;hold <\/span>on<\/span><\/span><\/div><\/div>
plot(outVarStep.xout.get(<\/span>'dx'<\/span>).Values,<\/span>'linewidth'<\/span>,2);<\/span><\/span><\/div><\/div>
for <\/span>i = 1:length(solvers)<\/span><\/span><\/div><\/div>
plot(out(i).xout.get(<\/span>'dx'<\/span>).Values)<\/span><\/span><\/div><\/div>
end<\/span><\/span><\/div><\/div>
axis([0 0.2 -2.5e-3 2.5e-3])<\/span><\/span><\/div><\/div>
legend([<\/span>' Variable-Step' <\/span>solvers]);<\/span><\/span><\/div><\/div>
<\/div>
<\/div>
<\/div>
<\/div><\/div><\/div><\/div><\/div>

Solution 3: Modify the system dynamics<\/span><\/h4>
In some cases, real-time constraints can make it impossible to use a larger step-size or a more accurate solver. In such case, the solution is most likely to try simplifying the system equations or to soften the dynamics. <\/span><\/div>
The Simscape documentation has an extensive section on techniques to adapt a model for real-time simulation: <\/span>Real-Time Simulation<\/span><\/a>. Many of those techniques are not Simscape-specific and also apply to any Simulink model.<\/span><\/div>

Division by Zero<\/span><\/h2>
This one might sound obvious, but if the equations in the model return <\/span>Inf<\/span> and this <\/span>Inf<\/span> is passed to an Integrator block, you will get this error. One common reason for that is a <\/span>division by zero<\/span><\/a>.<\/span><\/div>
mdl = <\/span>\"example3\"<\/span>;<\/span><\/span><\/div><\/div>
open_system(mdl);<\/span><\/span><\/div><\/div>
in = Simulink.SimulationInput(mdl);<\/span><\/span><\/div><\/div>
in = in.setModelParameter(<\/span>'CaptureErrors'<\/span>,<\/span>'on'<\/span>);<\/span><\/span><\/div><\/div>
out = sim(in);<\/span><\/span><\/div><\/div>
out.ErrorMessage<\/span><\/span><\/div>
ans = <\/span>'Derivative of state '1' in block 'example3\/Integrator' at time 0.89047195013357083 is not finite. The simulation will be stopped. There may be a singularity in the solution. If not, try reducing the step size (either by reducing the fixed step size or by tightening the error tolerances)'<\/div><\/div><\/div><\/div><\/div><\/div>
To diagnose this, I recommend using the Simulink Debugger. Setting a breakpoint on <\/span>Inf<\/span> or <\/span>NaN<\/span> will stop the simulation at the first block where the Inf is generated.<\/span><\/div>
\"\"<\/img><\/div>
In this case, the solution is to modify the equations to avoid feeding <\/span>Inf<\/span> to Integrator blocks.<\/span><\/div>

Now it's your turn<\/span><\/h2>
Have you run into problems with infinite derivative error? Let us know in the comments below.<\/span><\/div>\r\n
\r\n<\/div>