State select in Modelica.Mechanics.MultiBody.Examples.Constraints models

[modelica-trac-importer]

Reported by jsten on 28 Oct 2015 13:48 UTC
There seems to be some contradictions in the state selection in Modelica.Mechanics.MultiBody.Examples.Constraints.RevoluteConstraint. The model requires dynamic state selection. One valid solution, according to the reference files uploaded on the Modelica ftp server(modelica.org:20022/files/RegressionTesting/ReferenceResults/MSL/trunk/Modelica/Mechanics/MultiBody/Examples/Constraints/RevoluteConstraint/translate_passed.log, is:

From set 1 there is 1 state to be selected from:
  freeMotionScalarInit.initAngle.angle[1]
  freeMotionScalarInit.initAngle.angle[2]
  freeMotionScalarInit.initAngle.angle[3]

Which seems to be fine by itself, however due to the following connect equations (aliases) and the state selection (never) on the freeMotionScalarInit.angle_X variables, it seems to be incorrect.

//Modelica.Mechanics.MultiBody.Joints.FreeMotionScalarInit
connect(initAngle.angle[1], angle_1);
connect(initAngle.angle[2], angle_2);
connect(initAngle.angle[3], angle_3);

So it boils down to the question if a Modelica tool should include variables with state select never in dynamic state sets, in my opinion it shouldn't!

I suggest that the state selection should be changed in the model for the freeMotionScalarInit.angle_X variables.

There seems to be similar problems in the other constraint models.

---

Migrated-From: https://trac.modelica.org/Modelica/ticket/1810

[modelica-trac-importer]

Comment by hansolsson on 29 Oct 2015 09:10 UTC
The reported defect here seems to be based on a misunderstanding of aliases and stateSelect. If a is equal to b and we don't want 'a' as state it doesn't mean that 'b' is unsuitable as state.

As an example consider a sensor - we might add StateSelect.never to avoid states in the sensor, the intent in that case is that the sensor shouldn't influence state-selection, and it certainly doesn't mean that the sensor should forbid states outside of the sensor just because they are identical to the measured quantities.

However, if the FreeMotionScalarInit is intended to not have states at all it should set StateSelect.never for 'initAngle' as well.

[modelica-trac-importer]

Comment by jsten on 29 Oct 2015 12:06 UTC
Thank you for the response Hans. That makes sense. In other words, when calculating the state selection for an alias set one may "choose" what ever fits the situation? I.e. in this situation it would be better to consider the state selection from the angle variables in freeMotionScalarInit.initAngle.

It would be convenient if these heuristics were documented in order to reduce tool specific heuristics.

[modelica-trac-importer]

Comment by hubertus on 22 Mar 2016 21:24 UTC
I had a brief look at this and agree with Jon. Hans argument does not hold in this case: this is not about sensors in this case. From the point of view of understandability and readability of models, variables that are marked as stateSelect.never, but have to be states anyways are simply awful, and clearly against the "design intent" of the state selection attribute. If I take the view of Joe Engineer, with some Modelica knowledge, the actual state selection compared to the state select attribute setting, are completely mysterious. I would consider this either bug or at least a bad example that should be improved. If it is a bug, I hope it is a bug in a state selection algorithm, and not in the specification.

[modelica-trac-importer]

Comment by hubertus on 22 Mar 2016 21:25 UTC
I meant I agree with Jon's original filing of the ticket, that is.

[modelica-trac-importer]

Modified by hubertus on 25 Mar 2016 03:48 UTC

[tobolar]

I have analysed that example and it seems to me that besides necessary improvement of StateSelect handling in the Modelica.Mechanics.MultiBody.Joints.FreeMotionScalarInit, there is also another issue.
A question arises how to handle cases where there are no variables enabled to be states. In the abovementioned constraint's example, this is the case for both the kinematic branch with constraint and that one with joint. Here, neither freeMotionScalarInit nor joint nor one of the bodies enables state selection.
Nontheless, Dymola (v2018) - for example - tries to find state variables anyway, which in my opinion is not correct. Instead, a warning/error message should be triggered.

[HansOlsson]

Looking more this made me realize that there is another fundamental problem with these examples:
Specifically what is the reason for state-selection for the joints?

The first two (Revolute and Prismatic) state that they don't want states in the joints, and that causes problems. The last two (Spherical and Universal) state that they want states in the joints and that works for the spherical and sort of works for the Universal. That does not seem consistent - and I couldn't see an explanation for why this differs.

If we assume that the examples are intended to demonstrate that the constraint-joint and the normal joint work the same way I don't see any reason to prohibit state-selection in the joints; and thus the RevoluteConstraint and PrismaticConstraint examples should be updated to remove the stateSelection.never from the joints.

If the intent were to demonstrate that you could generate the same result from normal joints then they should all have StateSelection.never, but that seems like a very complicated use of the normal joint models - and would likely need a longer explanation.

Clearly the FreeMotionScalarInit should have stateSelect.never.

[tobolar]

No idea about the original idea.
The constraints have been added in 8ea6db2 by @MartinOtter. Maybe he can add some more explanation about it?

[MartinOtter]

The goal was to check that the joints in package Constraints give the same results as when the standard joints are used. It is fine to remove StateSelect.never from the Revolute and Prismatic joints.

[tobolar]

OK I will care about it.

Still undecided is how to handle cases where there are no variables enabled to be states - as I mentioned in my comment above.

[HansOlsson]

Still undecided is how to handle cases where there are no variables enabled to be states - as I mentioned in my comment above.

Hopefully we will add such diagnosis in a future version of Dymola.

But first I wanted to know why there are no suitable state candidates in these models (for the upper part - joint.phi is a good state).

If we remove freeMotionScalarInit then bodyOfConstraint.body.frame_a.R is a root and bodyOfConstraint.body.Q and bodyOfConstraint.body.w_a can be part of dynamic state selection.

However, when we introduce freeMotionScalarInit it also introduces a non-breakable connection to bodyOfConstraint.body.frame_a and thus it is no longer a potential root and therefore bodyOfConstraint.body.Q is ignored and not differentiated. (There is also another root in the sensor - ignore that.)

Thus the underlying problem is the design (and use) of Modelica.Mechanics.MultiBody.Joints.FreeMotionScalarInit.

It is seen as an initialization helper, but it also influences the dynamic simulation as a normal freemotion-joint with enforceStates=true (if initializing angles) - and thus in this case switches to Euler-angles for the actual problem. It seems clear that this wasn't the intended design.

I tried to correct this by replacing its internal InitAngle (and its derivative) by the corresponding sensor components, and that variant seemed to work without strange state-selection - for this example (and could turn that into a pull request).

But FreeMotionScalarInit also have the possibility to select stateSelect for its angles - and that no longer works - since some functions lack derivatives.