Add starting point for figures in Mechanics.Translational.

[maltelenz]

These originate from figures created for Wolfram System Modeler, and are likely to need cleanup and improvement.

Our one existing figure in MSL is probably a good style to follow:

ModelicaStandardLibrary/Modelica/Blocks/package.mo

Lines 159 to 180 in 3f72865

	figures = {
	Figure(
	title = "Anti-windup compensation",
	identifier = "anti-windup",
	preferred = true,
	plots = {
	Plot(
	title = "Reference tracking",
	identifier = "tracking",
	curves = {
	Curve(y = integrator.y, legend = "Reference speed"),
	Curve(y = inertia1.w, legend = "Actual speed")}),
	Plot(
	title = "Anti-windup limiter",
	identifier = "limiter",
	curves = {
	Curve(y = PI.limiter.u, legend = "Input to the anti-windup limiter"),
	Curve(y = PI.y, legend = "Controller output")})},
	caption = "%(plot:tracking) Reference speed (%(variable:integrator.y)) and the actual speed (%(variable:inertia1.w)). The system initializes in steady state, since no transients are present. The inertia follows the reference speed quite good until the end of the constant speed phase. Then there is a deviation.
	%(plot:limiter) Here the reason for the deviation can be seen: The output of the controller (%(variable:PI.y)) is in its limits. The anti-windup compensation works reasonably, since the input to the limiter (%(variable:PI.limiter.u)) is forced back to its limit after a transient phase.
	")}));

Creating as Draft to indicate that library officer(s) probably want/should improve them before merging.

[AHaumer]

just adding starting point for figures - thx @maltelenz - fine with me!

[christiankral]

See also #4674: Many models work fine. Yet there are some models which fail in Dymola2025x under Linux. The failing models are:

• Modelica.Mechanics.Translational.Examples.Brake
• Modelica.Mechanics.Translational.Examples.Friction
• Modelica.Mechanics.Translational.Examples.HeatLosses

Example error message caused by Dymola2025x:

Compilation of [Modelica.Mechanics.Translational.Examples.Brake](modelica://Modelica.Mechanics.Translational.Examples.Brake) failed.

Note: There were translation errors that might explain the problem.

Compiler message:
Using CC=cc -Wl,--no-as-needed
dsmodel.c: In function ‘Modelica_Blocks_Types_ExternalCombiTable1D_M’:
dsmodel.c:181:9: error: ‘ModelicaStandardTables_CombiTable1D_init3’ undeclared (first use in this function); did you mean ‘ModelicaStandardTables_CombiTable1D_init2’?
181 | ModelicaStandardTables_CombiTable1D_init3)(fileName0_0, tableName0_0,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| ModelicaStandardTables_CombiTable1D_init2
dsmodel.c:181:9: note: each undeclared identifier is reported only once for each function it appears in

This somehow seems to be a table issue.

[tobolar]

Yet there are some models which fail in Dymola2025x under Linux.

Shall this not be an another issue?

[christiankral]

Yet there are some models which fail in Dymola2025x under Linux.

Shall this not be an another issue?

I will create a different ticket for this issue. For now it "just" prevents me from testing.

[christiankral]

On more thing, that I consider more relevant, is:

The three physical quantities in this graph have all different SI units. But no units are displayed at all.

@maltelenz How do other tools hande such figures?

I suspect this is a Dymola related issue as units shall be added automatically in the legend by the tool. The Figure specification does not indicate any display unit.

          plots = {
            Plot(
              curves = {
                Curve(y = mass.a, legend = "Accelleration of mass"),
                Curve(y = mass.s, legend = "Position of mass"),
                Curve(y = mass.v, legend = "Velocity of mass")
              }
            )
          }

If the DisplayUnit is unspecifed, the tool is free pick the unit.

[HansOlsson]

See also #4674: Many models work fine. Yet there are some models which fail in Dymola2025x under Linux. The failing models are:

• Modelica.Mechanics.Translational.Examples.Brake
• Modelica.Mechanics.Translational.Examples.Friction
• Modelica.Mechanics.Translational.Examples.HeatLosses

Example error message caused by Dymola2025x:

Compilation of [Modelica.Mechanics.Translational.Examples.Brake](modelica://Modelica.Mechanics.Translational.Examples.Brake) failed.

Note: There were translation errors that might explain the problem.

Compiler message:
Using CC=cc -Wl,--no-as-needed
dsmodel.c: In function ‘Modelica_Blocks_Types_ExternalCombiTable1D_M’:
dsmodel.c:181:9: error: ‘ModelicaStandardTables_CombiTable1D_init3’ undeclared (first use in this function); did you mean ‘ModelicaStandardTables_CombiTable1D_init2’?
181 | ModelicaStandardTables_CombiTable1D_init3)(fileName0_0, tableName0_0,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| ModelicaStandardTables_CombiTable1D_init2
dsmodel.c:181:9: note: each undeclared identifier is reported only once for each function it appears in

This somehow seems to be a table issue.

I assume that either the table-functions library wasn't recompiled for MSL 4.1.0 on Linux, or the new library wasn't used (the Advanced.Translation.PlaceDymolaSourceFirst setting).
Dymola 2025x Refresh 1 should have reduced the second issue, and it will work without any problems on Dymola 2026x

[HansOlsson]

On more thing, that I consider more relevant, is:

The three physical quantities in this graph have all different SI units. But no units are displayed at all.

@maltelenz How do other tools hande such figures?

I suspect this is a Dymola related issue as units shall be added automatically in the legend by the tool. The Figure specification does not indicate any display unit.

          plots = {
            Plot(
              curves = {
                Curve(y = mass.a, legend = "Accelleration of mass"),
                Curve(y = mass.s, legend = "Position of mass"),
                Curve(y = mass.v, legend = "Velocity of mass")
              }
            )
          }

If the DisplayUnit is unspecifed, the tool is free pick the unit.

Yes, adding the unit in the legend seems like the usual approach here.
The plot is somewhat unusual in that they all have comparable values even if the units differ - one shouldn't assume that it is the case in general.

[henrikt-ma]

The plot is somewhat unusual in that they all have comparable values even if the units differ - one shouldn't assume that it is the case in general.

The plot is older than the strong support for units in System Modeler; I don't think anyone would have created the plot this way today.

This could be an indication that some sort of style guide for figures in the MSL would be handy. I think it could help us arrive faster at first collection of nice figures which will then also serve as good examples when more figures are added in the future.

Some ideas for initial content of a figure style guide for the MSL:

• Don't mix variables with incompatible units in the same plot. (The use of a second y-axis can be a nice way to relax this requirement, but this feature is not in the standard.)
• Each figure shall have a caption.
• Some style to be used when describing the different plots in the caption of a multi-plot figure.

I am hesitant to add a recommendation that a multi-plot figure's caption should mention each of the plots, as this can degrade a good caption by inclusion of too many obvious sentences.

[christiankral]

See also #4674: Many models work fine. Yet there are some models which fail in Dymola2025x under Linux. The failing models are:

• Modelica.Mechanics.Translational.Examples.Brake
• Modelica.Mechanics.Translational.Examples.Friction
• Modelica.Mechanics.Translational.Examples.HeatLosses

Example error message caused by Dymola2025x:

Compilation of [Modelica.Mechanics.Translational.Examples.Brake](modelica://Modelica.Mechanics.Translational.Examples.Brake) failed.

Note: There were translation errors that might explain the problem.

Compiler message:
Using CC=cc -Wl,--no-as-needed
dsmodel.c: In function ‘Modelica_Blocks_Types_ExternalCombiTable1D_M’:
dsmodel.c:181:9: error: ‘ModelicaStandardTables_CombiTable1D_init3’ undeclared (first use in this function); did you mean ‘ModelicaStandardTables_CombiTable1D_init2’?
181 | ModelicaStandardTables_CombiTable1D_init3)(fileName0_0, tableName0_0,
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| ModelicaStandardTables_CombiTable1D_init2
dsmodel.c:181:9: note: each undeclared identifier is reported only once for each function it appears in

This somehow seems to be a table issue.

I assume that either the table-functions library wasn't recompiled for MSL 4.1.0 on Linux, or the new library wasn't used (the Advanced.Translation.PlaceDymolaSourceFirst setting). Dymola 2025x Refresh 1 should have reduced the second issue, and it will work without any problems on Dymola 2026x

I created #4696 for handling this Linux specific issue

[christiankral]

Some ideas for initial content of a figure style guide for the MSL:

• Don't mix variables with incompatible units in the same plot. (The use of a second y-axis can be a nice way to relax this requirement, but this feature is not in the standard.)
• Each figure shall have a caption.
• Some style to be used when describing the different plots in the caption of a multi-plot figure.

I think we shall not manually add units to the curve legend, as the tools are free to chose for example MJ (Megajoule) instead of 1E6 in scaling. The unit shall be added by the tool automatically. So not mixing variables makes a lot more sense to me.

[maltelenz]

The three physical quantities in this graph have all different SI units. But no units are displayed at all.

@maltelenz How do other tools hande such figures?

For cases where an explicit legend is specified (like in this case) System Modeler does the same thing (don't show units in the legend). You can see the unit in tooltips and in the measurement view:

As others before me have said, mixing units in a single plot like this is probably a bad idea in general. If the curves are split, the units appear in the y axis label:

[christiankral]

One case where units are yet not derived correctly in Dymola2025x is described in #4676 (comment) referring to example Modelica.Electrical.PowerConverters.Examples.DCAC.PolyphaseTwoLevel.PolyphaseTwoLevel_RL:

I tested this case in Dymola2025x. For some reason the unit of the rms current and voltage are not determine correctly in Modelica.Blocks.Math.Harmonic. Even though the units match in the plots, the units are not displayed.

[maltelenz]

I tested this case in Dymola2025x. For some reason the unit of the rms current and voltage are not determine correctly in Modelica.Blocks.Math.Harmonic. Even though the units match in the plots, the units are not displayed.

@christiankral System Modeler also fails to propagate the unit information to the output of the Harmonic block in this case. It is unclear to me (without spending more time looking much closer at the model) if unit inference should be able to infer the unit with the available information in the model. You can make it work easily by explicitly annotating the example model with the unit:

  Modelica.Blocks.Math.Harmonic fundamentalWaveCurrent[m](
...
   each y_rms.unit = "A")

At least in System Modeler, this will make the unit appear in the plot as expected.

[AHaumer]

I assume that either the table-functions library wasn't recompiled for MSL 4.1.0 on Linux, or the new library wasn't used (the Advanced.Translation.PlaceDymolaSourceFirst setting). Dymola 2025x Refresh 1 should have reduced the second issue, and it will work without any problems on Dymola 2026x

Same issue with Dymola 2025x Refresh 1 under Windows 11 24H2:
Compiling and linking the model (Visual C++).
dsmodel.c
LINK : fatal error LNK1181: Eingabedatei "ModelicaIO.lib" kann nicht geffnet werden.
Error generating Dymosim.