Add annotation "unbounded" to 1D mechanical sources

[markusandres3DS]

I did some investigation on the unbounded annotation in Dymola and found that it would likely be a good addition for some MSL components.

The tests were carried out using Modelica.Mechanics.Rotational.Sources.Speed, with focus on the behavior when angles get relatively big (but still reasonable). This results in numerical issues pretty quickly, as shown below:

There are three variables plotted:

• unbounded=false: based on Modelica.Mechanics.Rotational.Sources.Speed
• unbounded=true: based on a modified version on Modelica.Mechanics.Rotational.Sources.Speed setting a unbounded = true
• Reference (hidden behind the curve for unbounded=true): based on the orignal version Modelica.Mechanics.Rotational.Sources.Speed, but the offset in the angle is added by a block after the actual integration instead of an initial value. This makes the state itself have small values.

Due to the above observations, I think it would be good to add the annotation to the MSL. Of the top of my head, I think this should be done for a couple of elements in the MSL:

• Modelica.Mechanics.Rotational.Sources.Position
• Modelica.Mechanics.Rotational.Sources.Speed
• Modelica.Mechanics.Translational.Sources.Position
• Modelica.Mechanics.Translational.Sources.Speed
• ...

The results can be reproduced using Dymola 2021 with this package. A quick test done with MSL 4.0.0 shows that there is no change regarding this property.

[beutlich]

Duplicate of #3545 and also mentioned in #2946.

[markusandres3DS]

@beutlich seems my search wasn't very successful. So this basically adds an example to #3545.

[MartinOtter]

unbounded=true means to switch relative error control off. This is meaningful, if the variable is a state variable and grows forever, or in other words, if it is not possible to define a meaningful nominal value.

Whether or not this is the case, depends heavily on the application: If in a library component unbounded=true is set, then it is highly likely that there are usages of the component, where unbounded=false yields better simulation results. Note, the same holds for nominal, where it seems also not possible to provide a meaningful value for all applications in a library component.

So to summarize, nominal and unbounded should be set by the user of a library component and should not be defined in the library component.

[markusandres3DS]

@MartinOtter I fully agree.

Therefore, the question to me is: Would it make sense to have parameters for both unbounded and nominal, probably in an "Advanced" tab? Currently they can only be set manually using modifiers for the components from the Standard Library, which is not very comfortable...