issue with unit «knot» / «kn» with Dymola

Question

I'm not sure but when switching to the last dymola version 2024x Refresh 1, I've lost the fact Dymola recognise the unit «kn» or «knot» (nautical mile per hour). The 2024x version used to recognise it.

I basically define the new unit as :

type Velocity_knots = Real (final unit="kn",final quantity="Velocity")

I also run a displayunit.mos script which has the following lines in it:

defineUnitConversion("m/s", "kn", 1/(1852/3600));

when checking with 2024x Refresh 1, I got the warning:

/!\ Could not decode the unit symbol "kn" appearing in the unit string "kn"

I didn't have such an error with the previous 2024x version. Did I miss something that make Dymola fails to recognise my unit ?

----- EDIT:

Following your comments I made further tests. I found the issue is not related to 2024x Refresh 1 nor previous ones, but rather to changes in the code that were made, that I did not notice at first - my mistake, my appologies.

Here are further tests :

package TestPackage
 model ATest
 type NewType = Real (final unit="kn", final quantity="Velocity");
 parameter NewType v_nt=4;
 parameter TestPackage.NewType v_ntp=5;
 end ATest;
 type NewType = Real (final unit="kn", final quantity="Velocity");
end TestPackage;

when checking with Dymola:

• the NewType, defined within the model passes check. This is not the case for the NewType defined within the package which flag a warning. It's not clear to me why.
• the parameter declarations v_nt and v_ntp do flag the warning «Could not decode the unit symbol "kn" appearing in the unit string "kn"» . This independantly from using the displayunit.mos script or not.

One comment about why I found I need to define unit="kn". All my models equations are in SI units. But when it comes to user to enter data in tables, for example maps such as z=f(x,y) using for example MSL CombiTables models, then, I did not find a proper way for non-SIunits to be displayed for entry in the table. Thus I prefer the user to enter data with its own usual nonSI units in the table and then the code uses hard coded converters functions to convert back to SI units. I define the user-nonSI units by using a new Type with unit="kn" for example, for clarity and assurance quality purpose. Has anyone an alternative best practice ?

• Hans Olsson: I cannot reproduce it working in Dymola 2024x, or even back to Dymola 2018. However, ideally the model should use displayUnit="kn" and unit="m/s".
• Markus A.: I cannot reproduce either. Probably you have some custom definition added to the version-specific(!) setup file of Dymola? Try to check "C:\Users\#UserName#\AppData\Roaming\DassaultSystemes\Dymola2024円x\setup.dymx" if there is any entry for kn in 2024x but not for 2024x Refresh 1...
• Markus A.: Having different units in for e.g. columns of an array is not possible in Modelica from what I know. What you can do, is separate scales from values, e.g. for a 1D table have one vector for the independent variable (=input) and a second one for the dependent one (output). Then you can use different units when entering values and combine the vectors to the matrix used in the tables (potentially including a conversion and making sure the vectors have the same length).
• AngeliqueR: For sure. I simply wish this would be part of modelica, i.e. a definition of tables with units as a part of modelica standard, and that it would be managed by the modelica tool either, so as the user would be able to enter its data in nonSI units and that it coud display them in nonSI units, while data is kept in SIunits internally. - I feel the array/matrix object is not adapted to this end.

Answer 1

The simple explanation is the unit for calculation should be "m/s" and you should just use an alternative display unit "kn".

• AngeliqueR: I'm still wondering why. If you look at the definition of degree Fahrenheit in MSL, it uses unit="degF". I'd like to use it for the same purpose, i.e. building proper conversion functions.
• Dag B: Yes, and I would attribute that to earlier MSL design mistakes, and we need legacy code to handle it. Note also there is a special section for Non-SI units. Modern tools are much better at handling display units, for example they will allow you to enter a temperature in degF if the display unit says so, and automatically convert to K.