modelica
Wrap if-condition in noEvent within smooth in OpAmp
Making it explicit that this condition should not generate events, similar to the smooth expression in OpAmpDetailed: https://github.com/modelica/ModelicaStandardLibrary/blob/89d5175dea8b668624c90dbd019cca4bd3f1f5bb/Modelica/Electrical/Analog/Basic/OpAmpDetailed.mo#L200
As far as I can tell, this only improves simulations with this component.
The goal with smooth is that tools are able to treat it as noEvent when needed, and as event when that is better. Thus I don't see why we should add this.
Having noEvent inside smooth is sometimes necessary (e.g., smooth(0, noEvent(if x<0 then 0 else sqrt(x))) - but this isn't the case here.
Having noEvent inside smooth is sometimes necessary (e.g.,
smooth(0, noEvent(if x<0 then 0 else sqrt(x))) - but this isn't the case here.
Yes, but this PR is about the particular equation in OpAmp. If OpAmpDetailed can have the noEvent that I find very helpful, why couldn't we have it also for OpAmp? Are you aware of any examples that simulate better with event generation inside this equation? Would Dymola ever interpret smooth(…) as allowing even generation for this model?
Any other tool vendor that would like to share any insights regarding OpAmp event generation?
Having noEvent inside smooth is sometimes necessary (e.g.,
smooth(0, noEvent(if x<0 then 0 else sqrt(x))) - but this isn't the case here.Yes, but this PR is about the particular equation in
OpAmp. IfOpAmpDetailedcan have thenoEventthat I find very helpful, why couldn't we have it also forOpAmp?
The fact that they are both smooth expressions in OpAmps doesn't mean that those expressions should be treated similarly.
They are not even similar expressions, specifically one is a rate-limit for voltage-derivative and the other applies directly to the voltage (where events could lead to chattering at almost steady-state).
Would Dymola ever interpret
smooth(…)as allowing even generation for this model?
Yes, Dymola does for smooth decide whether to generate events or not, depending on settings and the specifics of the crossing function. And if it never was good to generate events for smooth expressions we would just do that, instead of changing all models to add noEvent inside smooth.
Would Dymola ever interpret
smooth(…)as allowing even generation for this model?Yes, Dymola does for smooth decide whether to generate events or not, depending on settings and the specifics of the crossing function. And if it never was good to generate events for smooth expressions we would just do that, instead of changing all models to add noEvent inside smooth.
I understand that each tool has its own heuristics, which is one of the many things explaining why portability between tools isn't as good as it should. However, this PR is not about changing anything in general, it is specifically about whether it might be a good idea to make sure that the OpAmp doesn't generate event in any tool.
When I created the PR, I did that because I saw a possibility of explicit noEvent would improve model portability between tools while not having adverse impact on the simulation with any tool. If it is the case that Dymola happily simulates all models with even generation inside the OpAmp components, then this is the kind of specific input to this discussion that can be used to settle what to do with the PR on OpAmp specifically.
Would Dymola ever interpret
smooth(…)as allowing even generation for this model?Yes, Dymola does for smooth decide whether to generate events or not, depending on settings and the specifics of the crossing function. And if it never was good to generate events for smooth expressions we would just do that, instead of changing all models to add noEvent inside smooth.
I understand that each tool has its own heuristics, which is one of the many things explaining why portability between tools isn't as good as it should. However, this PR is not about changing anything in general, it is specifically about whether it might be a good idea to make sure that the
OpAmpdoesn't generate event in any tool.
And depending on the application and use-case it may be good to have an event or not.
If you are proposing the PR it should be your job to explain why it is good that some other smooth-expression generate events, but not this one.
I understand that each tool has its own heuristics, which is one of the many things explaining why portability between tools isn't as good as it should. However, this PR is not about changing anything in general, it is specifically about whether it might be a good idea to make sure that the
OpAmpdoesn't generate event in any tool.And depending on the application and use-case it may be good to have an event or not.
If you are proposing the PR it should be your job to explain why it is good that some other smooth-expression generate events, but not this one.
I did give the reason already: I don't want this PR to interfere with the general idea that tools should have the freedom to made "good" automatic choices about event-generation inside smooth. What I'm suggesting is that if we're happy with the way that the library developer has taken control over the situation in OpAmpDetailed (for good reasons, I believe), then I don't see why we shouldn't do the same in OpAmp.
Since I don't have access to the event-generation behavior for OpAmp in other tools, I am kindly requesting this information from those with access to other tools, because if it turns out that some tools are successfully using this model with event-generation, then this would be a valid reason to keep the current freedom of tools to decide.