New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
State selection in Modelica.Blocks.Examples.NoiseExamples.ActuatorWithNoise #2189
Comments
I believe this change should be analyzed more. The model is similar to The only reason we don't get the issue in the original SMPM_CurrentSource example is that the input is constant and thus the state is removed. |
Why does this need more analysis? If the stateSelect.always would be set in a Library model, I can see that more analysis may be the right thing since it can affect other things, but not in an example. By principle, we'd like to reduce potential ambiguity as much as possible in any ready-to-run model, otherwise, we unnecessarily create problems for running with the same result in multiple tools. |
The reason for further analysis is that Examples are not only ready-to-run examples, but also examples of how to use the library. When we add counter-intuitive modifiers in example models we indicate that the library isn't easy-to-use - and it would be better if we corrected the underlying issue. Note that state-selection isn't really an ambiguity (as for start-values), since different states (including dynamic ones) give the same simulation results (except for numerical accuracy and reinit-cases but they are specified). |
The above was the reason that I mentioned modifying Modelica.Electrical.Machines.Examples.SynchronousInductionMachines.SMPM_CurrentSource If we add a FirstOrder after the "iq" component we do (in Dymola) get dynamic state-selection between firstOrder.y and smpm.idq_sr[] (for one state). Assuming there is nothing weird then firstOrder.y is a good state, and the motor-model might ideally redesigned so that smpm.idq_sr[] isn't a preferred state. To me using an integrated signal as input to the controller seems perfectly normal. Obviously we can argue that dynamic state-selection is good enough, and we shouldn't change the library - but then we shouldn't change the example either. |
I changed label "bug" to "enhancement", because the model seems to be correct. The enhancement is to improve efficiency by selecting StateSelect.always. |
Reported by agnes.ramle on 23 Feb 2017 13:02 UTC
In
Modelica.Blocks.Examples.NoiseExamples.ActuatorWithNoise
JModelica has a dynamic state selection betweenwhere these variables have stateSelect=StateSelect.prefer. A better choice would be
controller.busdelay.y
which doesn't have a stateSelect attribute. Therefore we suggest to set stateSelect=StateSelect.always oncontroller.busdelay.y
. In that way the dynamic state selection would be removed.The text was updated successfully, but these errors were encountered: