0/0 is handled as 0

[Lennart Ochel]

0/0 is handled as 0 since r14719.

model test
  parameter Real p = -1.0;
  Real a = (p + time * time) / (p + time);
  annotation(experiment(StartTime = 0, StopTime = 2, Tolerance = 1e-006, Interval = 0.004));
end test;

[Lennart Ochel]

fixed in r19667

[Adrian Pop]

Why was this a problem? 0/0 is 0.

[Lennart Ochel]

Replying to adrpo:

Why was this a problem? 0/0 is 0.

No, it is not. It depends on the expression itself and it is not determinable by only knowing the evaluated denominator and devisor. In the example above 0/0 is 2. Because we cannot evaluate limits in our runtime, we have to trigger an error.

[Vitalij Ruge]

Replying to lochel:

in this sense you have to modify
ExpressionSimplify.mo->simplifyBinaryCommutativeWork->
case 0 * a = 0
because there are not checking for "a" != expression/0

I prefer 0/0 = 0 with a warning!!

[Lennart Ochel]

Replying to vitalij:

Replying to lochel:

in this sense you have to modify
ExpressionSimplify.mo->simplifyBinaryCommutativeWork->
case 0 * a = 0
because there are not checking for "a" != expression/0

I prefer 0/0 = 0 with a warning!!

Sorry, I didn't get your point.
It is not possible to evaluate a 0/0 expression in the runtime to zero, even if a warning is issued.
Besides that, feel free to change symbolic transformations in ExpressionSimplify.mo.

[Vitalij Ruge]

In ExpressionSimplify we would simplify 0*(x/0) to 0.
If we don't use the same rules in the runtime ... the results became more nondeterministic depend from style...

[Vitalij Ruge]

consequently if you handling 0/0 as undefined
then you need a case for 0⁰

[Lennart Ochel]

Replying to vitalij:

In ExpressionSimplify we would simplify 0*(x/0) to 0.
If we don't use the same rules in the runtime ... the results became more nondeterministic depend from style...

What rules do you mean? There are no symbolic transformations during runtime.
This ticket is about handling 0/0 during runtime. Because it is indeterminate, an error is issued.
I agree, 0^0 should also issue an error. You can easily fix it.

[Martin Sjölund]

Why should 0⁰ issue an error? It is 1... By far less controversial than 0/0.

[Vitalij Ruge]

Replying to lochel:

What rules do you mean? There are no symbolic transformations during runtime.

we had 0/0 => 0 and now 0/0 => error
It's was not better or right but uniformly with simplify

I agree, 0^0 should also issue an error. You can easily fix it.

I am sure we don't want this rule.

Replying to sjoelund.se:

Why should 0⁰ issue an error?

in scant special case is indeterminate
​http://www.wolframalpha.com/input/?i=0^0

[Martin Sjölund]

Python, C, Matlab, Dymola, OM all give 0⁰ == 1... Also, see ​m:#605 for that discussion. Don't go changing things until that ticket tells you to.

[Adrian Pop]

This change seems to break 3 models in this library:
​https://test.openmodelica.org/hudson/job/OpenHydraulics_Simulation/lastCompletedBuild/testReport/
See those with Age 1, for example:
​https://test.openmodelica.org/hudson/job/OpenHydraulics_Simulation/lastCompletedBuild/testReport/OpenHydraulics/DevelopmentTests/ThrottleValveTest/

[Adrian Pop]

Same for BioChem and ThermoPower, one more failing now:
​https://test.openmodelica.org/hudson/job/BioChem_Simulation/173/testReport/BioChem.Examples/CellDivison/cell/
​https://test.openmodelica.org/hudson/job/ThermoPower_Simulation/201/testReport/junit/ThermoPower.Test/WaterComponents/WaterPumpMech/

[Lennart Ochel]

It seems that the 0/0 issue covered some other problems. I discussed this with Willi, and it is maybe connected to nonlinear solver issues that are not handled immediately.

[Willi Braun]

I've just looked into this 3 OpenHydraulic examples.
For the example OpenHydraulics.DevelopmentTests.ThrottleValveTest I can't reproduce the behaviour, since it just works for me.
For the example OpenHydraulics.DevelopmentTests.ThrottleValveTest2 it's really connected to non-linear solver, that fails to solve a system before and that leads to the division by zero.

But for the example OpenHydraulics.DevelopmentTests.ThrottleValveTest2 it seems to be an initializations issue, since the variable leakage.d_b:

assert            | debug   | division by zero at time 0, (a=0) / (b=0), where divisor b expression is: leakage.d_b

is initialized in Dymola with a non-zero value and the model does not have any non-linear or linear algebraic loop.