Skip to content
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

MultiBody models have a problem with StateSelect.always/never #2482

Open
sjoelund opened this issue Mar 5, 2018 · 2 comments
Open

MultiBody models have a problem with StateSelect.always/never #2482

sjoelund opened this issue Mar 5, 2018 · 2 comments
Assignees
Labels
bug Critical/severe issue L: Mechanics.MultiBody Issue addresses Modelica.Mechanics.MultiBody

Comments

@sjoelund
Copy link
Member

sjoelund commented Mar 5, 2018

When trying to implement a check in OpenModelica for variables chosen as states despite StateSelect.never and variables not selected as states despite having StateSelect.always, I discovered that Joints.Revolute and Parts.RollingWheel have this problem. For both models, the problem is that you set these models using a single stateSelect parameter.

For Joints.Revolute, the stateSelect parameter is used for both phi and w where w = der(phi) and a = der(w) which means these might reasonably be chosen as states in some models (depending on optimizations); so StateSelect.never is probably not a good value. Modelica.Mechanics.MultiBody.Examples.Constraints.RevoluteConstraint does set StateSelect.never and the question is if there should be an assertion checking that StateSelect.never was used, if this should trigger a warning in the tool and the example be changed, or if the model should simply use SI.Angle phi(start=0, final stateSelect=max(stateSelect, StateSelect.avoid)).

For Parts.RollingWheel we have the opposite problem: at least OpenModelica gets for Elementary.RollingWheel wheel1.der_angles[1] and wheel1.der_angles[2] as non-state variables with stateSelect=StateSelect.always (regardless of index reduction method used). And it stands to reason that if the acceleration of these variables is not used, StateSelect.always is a bad value; but it might be fine for the other variables in the model (and indeed setting StateSelect.prefer in Elementary.RollingWheel is problematic for OpenModelica). So again the question is if we should guard der_angles in Parts.mo with each stateSelect=min(StateSelect.prefer, stateSelect) or if we should fix the RollingWheel example by for example setting stateSelect=StateSelect.always and manually overriding only der_angles (but this seems like an awkward thing to do).

@sjoelund sjoelund added bug Critical/severe issue L: Mechanics.MultiBody Issue addresses Modelica.Mechanics.MultiBody labels Mar 5, 2018
@sjoelund sjoelund added this to the MSL3.2.3 milestone Mar 5, 2018
@tobolar
Copy link
Contributor

tobolar commented Mar 5, 2018

See also #1810.

@HansOlsson
Copy link
Contributor

Modelica.Mechanics.MultiBody.Examples.Constraints.RevoluteConstraint does set StateSelect.never and the question

I agree that there is a problem here, and will discuss that in #1810

For Parts.RollingWheel we have the opposite problem: at least OpenModelica gets for Elementary.RollingWheel wheel1.der_angles[1] and wheel1.der_angles[2] as non-state variables with stateSelect=StateSelect.always (regardless of index reduction method used).

I cannot see any problem with this model in Dymola, where wheel1.der_angles become state-variables.

@tobolar tobolar modified the milestones: MSL3.2.3, MSL_next-MINOR-version May 29, 2018
@beutlich beutlich modified the milestones: MSL_next-MINOR-version, MSL_next-MAJOR-version Jun 24, 2018
@MartinOtter MartinOtter removed their assignment Jan 9, 2020
@tobolar tobolar modified the milestones: MSL4.0.0, never Jan 28, 2020
@beutlich beutlich removed this from the never milestone Feb 12, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Critical/severe issue L: Mechanics.MultiBody Issue addresses Modelica.Mechanics.MultiBody
Projects
None yet
Development

No branches or pull requests

5 participants