Assert triggered incorrectly on variable computed with conditional expression

[Francesco Casella]

Please check ​Buildings.Electrical.AC.OnePhase.Loads.Examples.ParallelLoads. The model fails at runtime with

LOG_SUCCESS       | info    | The initialization finished successfully without homotopy method.
assert            | warning | The following assertion has been violated at time 0.700200
|                 | |       | load_y.y >= 0.0 and load_y.y <= 1.0000000001
assert            | error   | The power load fraction P (input of the model) must be within [0,1]

Now, load.y is computed with the following equation

  y = offset + (if time < startTime then 0 else if time < (startTime +
    duration) then (time - startTime)*height/duration else height);

and the upper limit of the assert is the value 1+eps with eps = 1e-10 defined in Buildings.Electrical.Interfaces.Load. In order to run the simulation successfully, one needs to increase it to 1e-2. What is interesting is that the transient computing at that point result is apparently not exceeding 1 by more than a much, much smaller value.

This raises the obvious question: why is this assert triggered in the first place?

My rough guess is that the assert is not checked on the accepted step value, which would be within the limits with a very tight tolerance, but is somehow being applied to the value of y during the process of finding the zero of the zero-crossing function, incorrectly aborting it.

I would recommend to move the assertion checking downstream of the zero-crossing solution, otherwise this kind of errors could happen in a number of cases.

[Andreas Heuermann]

My rough guess is that the assert is not checked on the accepted step value, which would be within the limits with a very tight tolerance, but is somehow being applied to the value of y during the process of finding the zero of the zero-crossing function, incorrectly aborting it.

This could very well be the case. Should be the first place to check.

Probably also roughly related to #6201.

[Martin Sjölund]

Isn't noEvent needed here? If-expressions cannot be used reliably since they will not switch until an event: ​https://specification.modelica.org/master/equations.html#events-and-synchronization

[Francesco Casella]

Replying to sjoelund.se:

Isn't noEvent needed here? If-expressions cannot be used reliably since they will not switch until an event: ​https://specification.modelica.org/master/equations.html#events-and-synchronization

This would be the case if we had something like y = if x > 0 then sqrt(x) else 0, where the expression in the first branch becomes invalid when x becomes negative, which could happen while the solver is looking for the exact time of the event, when the zero-crossing function vanishes.

Notice that using noEvent has a cost in terms of computational workload, because we are passing the solver a function which is not even C¹, hence all the error estimations assuming a smooth function will not be very reliable. It is a bit of a brute-force solution.

However, this is not the case here. There is nothing wrong in the load going slightly above 1 during the solution process. I think the assert should be applied only on accepted steps.

Seems to me very much related to #6372. @AnHeuermann, what do you think?