The debugger says you get one non-linear system of size 1 unknown (3 torn variables):

f2.u := smooth(0, if add.y > limiter.uMax then limiter.uMax else if add.y < limiter.uMin then limiter.uMin else add.y)
add.u2 := DIVISION(add.y - add.k1 * f1.x_scaled[1], add.k2)
y := (1.0 + -2.0 * f2.a[2]) * f2.x_scaled[1] + 2.0 * f2.u
y + (-f3.a[2]) * f3.x_scaled[1] - add.u2 (residual)

add.y is the unknown in this case. Re-ordering the equations does not work.

Yes. that is right, i have already seen this. but as i said it could be solved as linear system of equations considering limiter equation as a piece-wise linear function. Is there any trick (modeling, modelica flags, ....) to let OM choose linear option instead of nonlinear one?

No, there is no way to make the simulation switch to a different set of equations based on which branch is selected. I also do not agree that it results in a linear equation system even with the knowledge that it is piece-wise linear: you still form an algebraic loop due to being required to check if the boolean conditions changed for the limiter.

I have attached the analytical solution. the nonlinear system of equations can be decoupled to two linear system of equations.

I don't agree that the analytical solution is the same as the problem above. It seems to approximate the stop by setting a derivative to zero. Which means that the value which is supposed to be limited will be slightly larger or smaller than the limit.

sjoelund.se wrote:

I don't agree that the analytical solution is the same as the problem above. It seems to approximate the stop by setting a derivative to zero. Which means that the value which is supposed to be limited will be slightly larger or smaller than the limit.

yes, i agree with you. they are not the same.

Hello,

I found a solution to break the algebraic loop by using FixedDelay block on the feed back loop and setting --delayBreakLoop to true. I originally tested this approach in Dymola and by setting delaytime to 0.001, for integration timestep of 0.01sec using Euler solver, the results were stable and close to the reference (with no delay with algebraic loop) and and the performance is almost twice improved.

but repeating the same scenario in OpenModelica, the results are not stable. i have attached the results comparison as well as the test case.


test.mo

test1.mo

If you are using a delayTime of 0.001, you need to set an integration step of 0.001 or smaller, or the results become totally wrong (stepSize needs to be smaller than the smallest delay). However, our Euler seems to be unstable until you reach a step-size of 0.00001. Use our rungekutta solver instead and you will not get instability as easily.