"strict" parameter in Limiters

[dariomangoni]

In Modelica.Blocks.Nonlinear.Limiter/VariableLimiter/SlewRateLimiter, I noticed that:

• the if strict branch has noEvents wrapping some conditions e.g. noEvent(if u > uMax then ...)
• the else branch does not.

To me it should be exactly the opposite: I assume that the event generation is much stricter in catching any change in the condition.
Is there anyone that can explain me why is the opposite?

Thanks a lot,
Dario

[dietmarw]

I agree that the choice of terminology could have been better. The way to see it is, that in this case "strict" is just a name without an implied meaning of "being strict" but with the result that the noEvent operator is applied on the condition. Maybe @MartinOtter or @AHaumer can shed some light on the historical reason to call that switch "strict" and not something else.

[MartinOtter]

In Modelica.Blocks.Nonlinear.Limiter/VariableLimiter/SlewRateLimiter, I noticed that:
* the if strict branch has noEvents wrapping some conditions e.g. noEvent(if u > uMax then ...)
* the else branch does not.
To me it should be exactly the opposite: I assume that the event generation is much stricter in catching any change in the condition. Is there anyone that can explain me why is the opposite?

The "strict" here means that it is guaranteed that the respective branch is only evaluated, if signaled by the condition.
E.g. if uMax == 1, the then branch in "if u > uMax then ..." is only evaluated if u > 1 (which is guaranteed by "noEvent(..)").
Instead, without a noEvent, it could be that the "then" branch is evaluated, even if u <= 1 (during the iteration to find the event instant within some tolerance).

In this view "strict = true, if strict limits with noEvent(..)" looks fine.

[dariomangoni]

oh, I see... the specifications already tell this (to those that can read them). It's surely correct to have this flag in Advanced folder, as it is right now.
Thanks for the hint