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

Open
modelica-trac-importer opened this Issue Feb 26, 2017 · 6 comments

Comments

Projects
None yet
7 participants
@modelica-trac-importer

modelica-trac-importer commented Feb 26, 2017

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

This comment has been minimized.

Show comment
Hide comment
@HansOlsson

HansOlsson Jun 29, 2017

Contributor

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.

Contributor

HansOlsson commented Jun 29, 2017

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.

@JJA1594

This comment has been minimized.

Show comment
Hide comment
@JJA1594

JJA1594 commented Oct 28, 2017

NMI

@beutlich beutlich removed the hacktoberfest label Oct 31, 2017

@hubertus65

This comment has been minimized.

Show comment
Hide comment
@hubertus65

hubertus65 May 21, 2018

Contributor

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.

Contributor

hubertus65 commented May 21, 2018

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

This comment has been minimized.

Show comment
Hide comment
@HansOlsson

HansOlsson May 21, 2018

Contributor

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

Contributor

HansOlsson commented May 21, 2018

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

This comment has been minimized.

Show comment
Hide comment
@HansOlsson

HansOlsson May 21, 2018

Contributor

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.

Contributor

HansOlsson commented May 21, 2018

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

This comment has been minimized.

Show comment
Hide comment
@MartinOtter

MartinOtter Jun 5, 2018

Member

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

Member

MartinOtter commented Jun 5, 2018

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment