Derivative of state '1' in block 'X/Y/Integrator' at time 0.55 is not finite.

An error occurred while running the simulation and the simulation was terminated Caused by: Derivative of state '1' in block 'X/Y/Integrator' at time 0.55 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). How to fix this error?

[MASSAMBA]

personnellement j'ai le meme probléme et j'arrive pas à le resoudre , si quelqun à la solution je veux bien.

[MASSAMBA]

Personally I have the same problem and I can't solve it, if someone has the solution I'm willing.

[Sam Chak]

Hi @MASSAMBA

Please post your Simulink model (a snapshot) on a New Question. It allows to use to visually inspect if there is any block that cause the problem.

By the way, most of the time, the true singularity problem cannot be solved by merely reducing the fixed step size or by tightening the error tolerances. Take note!

[Sourabh]

mdl = 'rl_exam'

obsInfo = rlNumericSpec([2 1]);
obsInfo.Name = 'observations';
obsInfo.Description = 'integrated error and error';
actInfo = rlNumericSpec([1 1]);
actInfo.Name = 'PID output';

env = rlSimulinkEnv(mdl,[mdl '/RL Agent'],obsInfo,actInfo)

agentOpts = rlDDPGAgentOptions(...
    'SampleTime',0.01,...
    'TargetSmoothFactor',1e-3,...
    'DiscountFactor',0.99,...
    'ExperienceBufferLength',100000,...
    'MiniBatchSize',64,...
    'NumStepsToLookAhead',2);

agent = rlDDPGAgent(obsInfo,actInfo,agentOpts)

This is the code i am using and i am getting

• Algebraic state in algebraic loop containing 'rl_exam2/calculate reward/Sum1' computed at time 0.30000000000000004 is Inf or NaN. There may be a singularity in the solution. If the model is correct, try reducing the step size (either by reducing the fixed step size or by tightening the error tolerances) or tweak the initial guess of algebraic loop variable values.

as error . i dont know how to attach the simulink file. i am stuck from last 5 days on this, any help would be great.

Answer 1

[Sorelys Sandoval]

Hi, I had the same problem and the next thing worked for me:

Go to model configuration parameters/Solver/Solver Options:

Type: Variable-step

Solver: ode15s (stiff/NDF)

and that's all. Hope it works for you :D

[Maria Angela Agizza]

This answer helped me a lot, thanks

[jinghua sun]

that does help！Thanks！

[Maria Jaramillo]

Funciono!! Muchas gracias

[Abinash Baruah]

but it didn't work for me.can i get any other solution

[Mira Mamdouh]

it didn't work for me did you reach any other solution ? if so please share

[Joel Fernandez]

It works, because it reduced properly the time-step. However, it can significantly retard the whole process.

Using ode15s takes much more time than ode1 (Euler) for example. You should verify your initial parameter values e.g : perform a load-flow (allowing asynchronous machine initialisation) in an electrical power system.

[Charles Collins]

didnt work for me either

[Frank Kulor]

okay

[Jamil Hassan]

Thank you.It worked for me as well

[KNourdine]

No it doesn't work

[Karen Wilches]

No it doesn´t work x2

[Walter Roberson]

Changing solvers will typically not succeed in cases where the model is not initialized properly, or in cases where the model is created incorrectly, or in cases where the dynamics is unstable.

For example if the model effectively has a division by (position minus 10) then it will have problems in any situation where the position reaches 10, and switching to a diffrent solver cannot "solve" that.

[Erika Yulieta]

n error occurred while running the simulation and the simulation was terminated

Caused by:

• Derivative of state '1' in block 'tugasakhir/Battery/Model/Exp/Integrator2' at time 4.1000000000000707 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)

how to fix this error. i had tried to change the solver to ode15s(stiff/NDF) and didnt works. if you know another solution please reply my comment

[Sam Chak]

Hi @Erika Yulieta,

This probably indicates there maybe division-by-zero (the denominator approaches 0) or -like components in the Simulink model. Please check. If true, then the singularity issue can be avoided merely by changing the ode15s solver.

If you still cannot identify the issue, you are advised to post a new question with the Simulink model attached.

[Julio Cesar Guzmán Jasso]

CHIDO MI BRO ERES LA MERA CORNETA

[VIGNESH BALAJI]

It did not work for me and it always stops at zero.

[Sam Chak]

Hi, @VIGNESH BALAJI, have you identified the singularity occurence in your Simulink model? If not, try posting a New Question and attach the Simulink slx file, so that we can investigate.

[VIGNESH BALAJI]

@Sam Chak thanks for your reply. I found the singularity occurrence in my model and rectified it, It was a calculation returning NaN (Improper calculation) that is propogating at the integrator of the system.

[Sam Chak]

@VIGNESH BALAJI, Good to hear that you've fixed the issue!

[Nicolas CRETIN]

I don't have exactly the same error, but the following has helped in my case: I reduced the relative tolerance in the solver parameters:

hope it can help someone!

Answer 2

[Sebastian Castro]

This usually has to do with really large or infinite signals feeding into an Integrator block. Numerical solvers (expectedly) have trouble integrating such large signals and therefore this leads to errors.

Typical causes can be divide by zero (1/0 = inf) or general unstable dynamics that quickly blow up over time. You should check that in your model. It can help to use Port Value Displays as you step through the model to figure out why this happens.

- Sebastian

Answer 3

[Abhiram V. P. Premakumar]

I solved this issue by eliminating the infinite signal, using a switch block, and setting a clock as it's threshold (or a step block with t=1e-3). Denominator of a DIVIDE block being 0 at the beginning of a simulation, was the issue in my case. Using a clock or a step signal starting at t=1e-3s, along with a switch block, can make the divide block in the output of the switch block use a finite value temporarily, until the actual signal becomes finite.

[chuyen hoangcao]

hello Abhiram, I dont know whether your solution affects so much to the simulation model or not? How did you switch block and setting clock

[Abhiram V. P. Premakumar]

My understanding is that it is due to division by zero. You may get around that problem using any method which is plausible.

[KNourdine]

hello Abhiram, could you be prcise more on how using switch block and

clock

[Ndip Cyril]

Hello Abhiram. Could you please explain how exactly you did this?

[Abhiram V. P. Premakumar]

Hi Ndip, The denominator of a divide block should never have 0 coming at the input. There are several ways to achieve that. One example is to use the ‘switch’ block for the denominator signal. Add ‘clock’ to the middle input, no input to the 3rd input, and the denominator signal to the 1st input of the switch block. Output of switch block goes to the denominator of ‘divide’ block.

[Walter Roberson]

If you are not expecting negative values then instead of switch blocks use a max block with the second input being a constant block with value being the value that should be substituted if the denominator is too small.

[SALAH alatai]

@Abhiram V. P. Premakumar what about the clock , what value should I put inside to adjust it ?

[OLUWASEUN ADEKOYA]

@Abhiram V. P. Premakumar It would be great if you could be more elaborate on what specific values you put into what. For example, the clock, the only option I see here is decimation (which ofcourse only permits positive integer values). Is that the threshold value you are referring to?

Also, MATLAB's Simulink signals an error when a port is empty. Should one worry about that?

Finally. did you mean "integrator block" when you refer to "divide block"?

Thanks in anticipation.

[Abhiram V. P. Premakumar]

Denominator of a DIVIDE block being 0 at the beginning of a simulation, was the issue in my case. A clock or a step signal starting at t=1e-3s, can make the divide block use a finite value temporarily until the actual signal becomes finite.

Answer 4

[ahmet akgün]

Adaptive Sliding-Mode Control for Boost DC–DC Converters simulation simulation fails;''Derivative of state '1' in block 'power_BoostConverter_Adaptive_SMC_math/TSMC Controller/Integrator' at time 0.0 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) ''

How to fix this error?

[Himani Modi]

I am facing the same issue.

[Mohammed-Amine MOSSADAK]

Me too.

[Stéphanie Monteiro]

Hello,

Can you solve this error? Can you help me, please?

Thank you!!

[Walter Roberson]

you have a problem with the initial conditions

[Ambe Harrison]

Hello,ahmet akgün. I am presently working on a Back steeping controller. Face thesame problem with the integrator. Please have you solved it.

If possible we may exchange more via email, [e-mail]

[Zakarya Motea]

If your system has multiple chanels Try to tune them one by one. When tuning one chanel let the input for other chanels as zero.

Answer 5

[Pavke]

Hello guys

I am doing a project in simulink and I have a problem. It is about braking an asynchronous motor with direct current, which I made (it works correctly), and it is necessary to connect that system to the distribution network (I use IEEE Bus 13). I connected the braking system of the asynchronous motor to the distribution network, and the system starts to work, it goes down from 1800 reversions and comes to 1480, and by the end of the simulation it stands at 1480, the engine will not brake and the simulation does not finish to the end and the following error occurs :

An error occurred while running the simulation and the simulation was terminated Caused by: Derivative of state '1' in block 'distributivnamrezamodel/Transfer Fcn' at time 0.991475799999991 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).

How to fix this problems?

Thank you

[GEORGIOS]

hey , did you find a solution on this ?

[Daniel Joseph]

Try to figure out why is your signal really large/infinite. Is divide by zero correct in this case? maybe you can substitute a very small value like 1e-6 instead of zero, using the switch example shown above by @Abhiram V. P. Premakumar, such that the solver does not get bogged down at very small /large values.

Answer 6

[Anton]

Hello, I have the same error. Please help me figure out what's wrong.

K1 = 2000;
K2 = 1;
Kk1 = 0.0012;
T1 = 0.2;
T2 = 0.005;
Tk1 = 0.0001;
T3 = 0.1;
Kt = 0.5;
tp = 0.280;

[Sam Chak]

Hi @Anton

Can you post your problem on a New Question?

If there is no obvious division-by-zero issue, then your system must be inherently unstable.

[Saleh Altbawi]

Hi, try to change the different options of the solver selection.

[Sam Chak]

Hi @Saleh Altbawi, it is definitely not the solver. When a system is unstable, it doesn't matter what solver is chose. Here is a simple example of an unstable transfer function, with a positive pole.

[Saleh Altbawi]

Hi. The system is not stable at specific time does not mean division on zero. If that true it should not work from the beginning. That mean solver at specific time could not convergence the transfer function. So try to use different kinds of solver. If does not work then try to update your system's parameters.

Answer 7

[Yingxin Zhang]

hey i have the same problem, can you help me?

[OLUWASEUN ADEKOYA]

Any luck on this yet?

I'm currently experiencing some similar issues with this as well. Thanks.

Answer 8

[Camila]

Im having the same problem

Answer 9

[Guy Rouleau]

I describe the most common reasons for this error in this blog post:

Derivative of state ‘1’ in block ‘X/Y/Integrator’ at time 0.55 is not finite » Guy on Simulink - MATLAB & Simulink (mathworks.com)

The most common causes are:

• A modeling error making the equations diverging
• Too large step size
• Division by zero