model Buildings.Templates.Plants.Controls.HeatRecoveryChillers.Validation.EnableAndModeControl fails verification (threshold issue)

[AndreaBartolini]

The following variables of the model Buildings.Templates.Plants.Controls.HeatRecoveryChillers.Validation.EnableAndModeControl fails the verification vs the Dymola reference file:

• ena.y1
• ena.u1Hea

both of them depend on the output of the threshold u1Hea:

that is supplied by the table ratV_flow thorough the gain VHeaWat_flow.

The threshold is implemented by the following modelica code:

block GreaterNoHysteresis
  "Greater block without hysteresis"
  parameter Real t=0  "Threshold for comparison";
  Buildings.Controls.OBC.CDL.Interfaces.RealInput u "Input u"  annotation (...);
  Buildings.Controls.OBC.CDL.Interfaces.BooleanOutput y "Output y"  annotation (...);

equation
  y=u > t;
end GreaterNoHysteresis;

that in the transformational debugger becomes: 277 (assign) $whenCondition11 := VHeaWat_flow.y > u1Hea.greNoHys.t

herebelow the output of the $whenCondition11:

and herebelow the same in csv form (only the key points, the complete csv file is attached):

Time,VHeaWat_flow.y,u1Hea.greNoHys.t,$whenCondition11
...
18000,0,0,0
18000,1.5000515e-11,0,0
18000,3.052451e-11,0,0
18000,3.052451e-11,0,0
18000,1.0000121e-10,0,0
18000,1.0000121e-10,0,1
18144,0.001199828,0,1
...
53568,0.00039994266,0,1
53740.8,0.0002399656,0,1
53913.6,7.998853e-05,0,1
54000,0,0,1
54000,0,0,1
54086.4,0,0,1
...

the $whenCondition11 becomes true when the input rises over zero but it remains true when the input come back to zero, and the zero-value seems to be well defined in this case, so it should not be a problem related to the numerical noise of the solver.

The following MWE reproduces the issue:

model TestThreshold
  parameter Real t=0;
  Real u;
  Boolean y;

equation
  u = if time < 0.2 then 0 elseif time < 0.6 then 1 else 0;
  y = u>t;

end TestThreshold;

OpenModelica v1.24.0-dev-194-g6379009a4e (64-bit) Dymola Version 2024x Refresh 1, 2024-04-12 (64-bit) Win 11 Pro (64-bit)

whenCondition11.zip

[casella]

This is a borderline case; we could try to fix it, but I think robust application models shouldn't rely on this kind of mechanism.

The event detection mechanism is based on zero-crossing functions. In this case, the zero is not really crossed 😄

What I mean is, model that rely on the fact that v >= 0 should produce different results than v > 0 are doomed to give rise to problems, because equality among Reals is not a well defined concept when finite-precision arithmetics is used. This is a basic fact of life that shouldn't be ignored.

IMHO, one should try to implement some logic that does not depend on the solver reacting to reals being equal to any value, including zero.

@mwetter what do you think?