State selection in Modelica.Blocks.Examples.NoiseExamples.ActuatorWithNoise

[modelica-trac-importer]

Reported by agnes.ramle on 23 Feb 2017 13:02 UTC
In Modelica.Blocks.Examples.NoiseExamples.ActuatorWithNoise JModelica has a dynamic state selection between

motor.smpm.idq_sr[1]
motor.smpm.idq_sr[2]

where 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 on controller.busdelay.y. In that way the dynamic state selection would be removed.

[HansOlsson]

I believe this change should be analyzed more.

The model is similar to
Modelica.Electrical.Machines.Examples.SynchronousInductionMachines.SMPM_CurrentSource
and if we in that example put a FirstOrder component between the iq-input and currentController we get the same issue - even if it seems obvious that the FirstOrder component have a good state.

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.

[hubertus65]

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.

[HansOlsson]

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).

[HansOlsson]

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.

[MartinOtter]

I changed label "bug" to "enhancement", because the model seems to be correct. The enhancement is to improve efficiency by selecting StateSelect.always.
I assigned also @AHaumer, because he should analyze the motor model whether it could be improved.
I am a bit reluctant to use the suggested solution of StateSelect.always, because it is not completely obvious for me that the suggested state will work in the all situations (it might result in a devision by zero in some situations).