-
Notifications
You must be signed in to change notification settings - Fork 194
"strict" parameter in Limiters #3968
In Modelica.Blocks.Nonlinear.Limiter/VariableLimiter/SlewRateLimiter, I noticed that:
- the
if strictbranch hasnoEventswrapping some conditions e.g.noEvent(if u > uMax then ...) - the
elsebranch 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
All reactions
In
Modelica.Blocks.Nonlinear.Limiter/VariableLimiter/SlewRateLimiter, I noticed that:
* theif strictbranch hasnoEventswrapping some conditions e.g.noEvent(if u > uMax then ...)
* theelsebranch does not.
To me it should be exactly the opposite: I assume that the event generation is muchstricter 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...
Replies: 2 comments 1 reply
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.
All reactions
In
Modelica.Blocks.Nonlinear.Limiter/VariableLimiter/SlewRateLimiter, I noticed that:
* theif strictbranch hasnoEventswrapping some conditions e.g.noEvent(if u > uMax then ...)
* theelsebranch does not.
To me it should be exactly the opposite: I assume that the event generation is muchstricter 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.
All reactions
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