Equations involving semiLinear are not solved correctly for tearing

[Francesco Casella]

Please check ​Modelica.Electrical.Machines.Examples.DCMachines.DCPM_Cooling. This model stopped working after ​PR 256, but I understand this PR is not the root cause, it simply revealed an existing problem.

The simulation fails because of a division by zero in torn equation 53. If you look at it in the debugger, you can see that equation

-outlet.flowPort.H_flow = semiLinear(-cooling.flowPort_a.m_flow, cooling.flowPort_b.h, cooling.h)

which comes from this original equation

flowPort_b.H_flow = semiLinear(flowPort_b.m_flow,flowPort_b.h,h);

was solved into

cooling.flowPort_b.h = (-((if (-cooling.flowPort_a.m_flow) >= 0.0 then 0.0 else (-cooling.flowPort_a.m_flow) * cooling.h) + outlet.flowPort.H_flow)) / (if (-cooling.flowPort_a.m_flow) >= 0.0 then -cooling.flowPort_a.m_flow else -0.0)

This looks weird to me. The definition of semiLinear(x, a, b) is

semiLinear(x,a,b) = if x > 0 then a*x else b*x

what the BE did was tantamount to trying to solve this equation for a. Obviously this only works if x > 0, otherwise it makes no sense.

This should be definitely fixed, equations involving semiLinear can be solved w.r.t the first argument of semiLinear, but not w.r.t. the other two.

BTW, we are not implementing the optimizations in Section 3.7.2.5. This doesn't have very high priority, since semiLinear was first conceived for fluid modelling, but later abandoned in favour of stream connectors, and is currently only used in the Modelica.Thermal.FluidHeatFlow library, where normally the flows are positive, so the case x = 0 is quite rare.

In any case, the current solution found by the BE seems incorrect to me, regardless of the missing optimization, and should be fixed with high priority.

[Karim Adbdelhak]

I started working on this and got to following problem:
The matching is unique, if and only if, there are no algebraic loops in the system. This is also true for each subsets of equations, so if the solver can decide to solve equation

flowPort_b.H_flow = semiLinear(flowPort_b.m_flow,flowPort_b.h,h);

for the variables flowPort_b.H_flow or flowPort_b.h (after traversing all options) it means that the matching is not unique, therefore this equation has to be inside an algebraic loop. Otherwise this would not be solvable in the first place, because we have to solve it implicitly for flowPort_b.h, which is not always possible.

If this equation is inside an algebraic loop the matching should not matter at all, because all get solved at the same time. Only tearing could somehow try to causalize and use this equation as an inner equation to be solved for flowPort_b.h. This might be a deep dive into that module so before i put too much effort in it i wanted to check if you would come to the same conclusion @Francesco.

Note: The proposed model runs fine under --tearingMethod=minimalTearing.

[Francesco Casella]

Releasing 1.14.0 which is stable and has many improvements w.r.t. 1.13.2.

This issue, previously marked as blocker for 1.14.0, is rescheduled to 1.15.0

[Francesco Casella]

Replying to Karim.Abdelhak:

I started working on this and got to following problem:
The matching is unique, if and only if, there are no algebraic loops in the system. This is also true for each subsets of equations, so if the solver can decide to solve equation

flowPort_b.H_flow = semiLinear(flowPort_b.m_flow,flowPort_b.h,h);

for the variables flowPort_b.H_flow or flowPort_b.h (after traversing all options) it means that the matching is not unique, therefore this equation has to be inside an algebraic loop. Otherwise this would not be solvable in the first place, because we have to solve it implicitly for flowPort_b.h, which is not always possible.

If this equation is inside an algebraic loop the matching should not matter at all, because all get solved at the same time. Only tearing could somehow try to causalize and use this equation as an inner equation to be solved for flowPort_b.h. This might be a deep dive into that module so before i put too much effort in it i wanted to check if you would come to the same conclusion @Francesco.

Absolutely.

My point is that the tearing module should never try to solve for the second and third arguments of semiLinear. This shouldn't be hard to implement, just get to the point where semiLinear is handled and forbid that option.

Note: The proposed model runs fine under --tearingMethod=minimalTearing.

Of course if there is no wrong tearing (and all start values are good enough) things are going to go well.

[Karim Adbdelhak]

Fixed with ​PR658.

I prevented the differentiation module from differentiating semiLinear(x,a,b) w.r.t. a cref contained in a or b. That results in unsolvability for tearing.

Feel free to close this ticket if the nightly tests run fine.

[Francesco Casella]

Will do, thanks!

[Francesco Casella]

The ​Jenkins report shows 6 improvement on related models, including the one mentioned in this ticket. There are some random regressions that come and go at each commit (no idea why that happens). The only possibly related regression is the SoftStarter model, but I flattened it and it has no semiLinear operator inside it, so I guess that's just a glitch.

I understand the fix is currently only in master. Could you please add it to 1.15.0 maintenance as well and then close the ticket?

Thank you!

[Karim Adbdelhak]

The tests run fine on the master branch but produce errors on maintenance 1.15.0. ​report. I don't think the problem originates from my branch but from a difference in library versions.

I talked to some other devs and we are not quite sure if we should still back port something because that would delay the release.

[Francesco Casella]

Never mind that.