0/0 = ?

[Volker Waurich]

Hi,

Of course, the answer is that the solution of 0/0 is not defined and it should result in NaN or something.

There are some models that fail due to division by zero (e.g. ThermoSysPro.Examples.SimpleExamples.TestCentrifugalPump1.mo) where its not just a/0 but 0/0.

Consider this example:

model test_DivZero
   Real x,a,b;
equation
   a = 1-time^2;
   b = 2-2*time;
   b = a*x;
end test_DivZero;

Dymola handles this (it holds the value at time=1.0), OMC not (div by zero).
My question is, do we want to cover as many models as Dymola does or do we want to handle this as div by zero?
Another option would be to calculate the limit at this time step, which is imo (more) correct than holding the value.

[Martin Sjölund]

Well. Anything returning NaN (or inf, or -inf) should trigger an assertion.

[Martin Sjölund]

Note that omc returns successfully for that model. Probably because it changes the time step to something that is not ==1.0 and avoids any problem.

[Volker Waurich]

Ok. But in the ThermoSysPro model I mentioned, the solver step is not changed and the exe crashes (at least on my machine). Should we fix this or is it ok as it is? Instead of returning a NaN we could catch these cases and do something different (hold value, compute limit).

[Lennart Ochel]

see also #2633

[Volker Waurich]

Replying to lochel:

see also #2633

Thanks for the hint. But what was the outcome of that ticket?

[Lennart Ochel]

Replying to vwaurich:

Replying to lochel:

see also #2633

Thanks for the hint. But what was the outcome of that ticket?

I am not sure. I guess the outcome was to handle it as a div. by zero exception. The solver could than try to slightly change the step size to avoid this issue.

[Volker Waurich]

The term 0/0 is avoided by applying a common sub expression replacement. The numerator and denominator are alias variables. Therefore, the term can be removed already in the backend. Since the model simulates now, I will close this ticket.

[Dietmar Winkler]

It doesn't make sense to keep closed ticket in the "Future" milestone that were simply forgotten to assign to the correct milestone in the past.

[Martin Sjölund]

Removing the pre1.9.4 milestone in favor of 1.9.4.