id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc
6195	Assert triggered incorrectly on variable computed with conditional expression	Francesco Casella	Andreas Heuermann	"Please check [https://libraries.openmodelica.org/branches/master/Buildings_7.0.0/files/Buildings_7.0.0_Buildings.Electrical.AC.OnePhase.Loads.Examples.ParallelLoads.sim 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."	defect	closed	critical	1.19.0	Run-time		fixed		Michael Wetter