Avoid StateSelect.never in FreeBodiesEnforceStates

[sjoelund]

ModelicaTest.MultiBody.Parts.FreeBodiesEnforceStatesFalse sets stateSelect=StateSelect.never on pointMass, but its r_0 and v_0 are the only possible states. The specification defines never as "Do not use as state at all", so a tool that respects it cannot translate the model; OpenModelica reports an error since it started enforcing this (OpenModelica/OpenModelica#2584).

Use StateSelect.avoid instead. It still gives a wrong indication, as the test intends, without making the model invalid. Dymola already ignored the hint, so its results are unchanged.

Assisted-by: Claude Opus 5.5

[henrikt-ma]

In System Modeler we also take StateSelect.never with a grain of salt. From my point of view, we could also consider reformulating the specification to say a tool may give a diagnostic when a variable with StateSelect.never is used as state.

[sjoelund]

Having examples in MSL be of the kind that are not supposed to be able to run seems a bit odd. The compliance suite does have these and checks that a tool does not allow specifically this kind of model. So an alternative could be that this model should be removed from ModelicaTest as well. Or that ModelicaTest should contain these kinds of models, but use a different icon and annotation to mark them as expected to fail.

[sjoelund]

In System Modeler we also take StateSelect.never with a grain of salt. From my point of view, we could also consider reformulating the specification to say a tool may give a diagnostic when a variable with StateSelect.never is used as state.

Yes, that could also be an option. But then what's the difference from StateSelect.avoid? Just a slightly more negative weight?

[henrikt-ma]

Yes, that could also be an option. But then what's the difference from StateSelect.avoid? Just a slightly more negative weight?

I'd give them equal weight, with the only difference that the specification allows/recommends giving a diagnostic in the case of never.

(While I understand the real use case of always for those working with state-space methods, my guess is that never was added to the language for the sake of symmetry rather than being motivated by relevant use cases.)

[HansOlsson]

The change itself is good, but it makes the documentation inconsistent.

Currently it seems as if the model was intended to fail.

Test whether enforceStates=false give any undesired output

Information
This test case is made with the intent of verifying what choices are made by the compiler in terms of state selection when wrong indications are given, here all the bodies have the flag enforceStates=false but the bodies positions and velocities are the only possible states.

Dymola ignores the flag and uses bodies variables as states.

I'll see if I can provide more detailed suggestions.

[HansOlsson]

LGTM