Unit string lost in Modelica.Media inheritance chain

[Francesco Casella]

Please open the attached test package in OMEdit. Open M2 and double-click on m to set parameters.

p1 and p2 have the correct display unit. p3 doesn't show any unit information.

Now, p3 is of type Modelica.Media.Water.StandardWater.AbsolutePressure, which inherits from Modelica.SIunits.AbsolutePressure, that has unit="Pa" and displayUnit = "bar". This information is somhow lost in the inheritance chain.

Please make sure this information is passed correctly to the new API that will be rolled out in 1.13.0 and uses the new front end.

[Per Östlund]

This works correctly in both the old and the new frontend as far as I can see.

[Francesco Casella]

Indeed. However, OMEdit still doesn't show any display unit for p3 when editing the parameters of m.

@adrpo, can you please check that the new API works correctly in this case, and if so, can you please close this ticke?

[Francesco Casella]

Rescheduled to 1.14.0

[Francesco Casella]

I did some more analysis on omcommunication.log, using -d=newInst,nfAPI. An excerpt of it follows:

getComponents(TestParameterUnits.M2, useQuotes = true) 13:04:00:967
{{"TestParameterUnits.M1","m","", "public", "false", "false", "false", "false", "unspecified", "none", "unspecified","{}"}
} 13:04:00:967

getComponents(TestParameterUnits.M1, useQuotes = true) 13:04:00:976
{{"Modelica.SIunits.Pressure","p1","", "public", "false", "false", "false", "false", "parameter", "none", "unspecified","{}"},
 {"Modelica.SIunits.AbsolutePressure","p2","", "public", "false", "false", "false", "false", "parameter", "none", "unspecified","{}"},
 {"TestParameterUnits.M1.Medium.AbsolutePressure","p3","", "public", "false", "false", "false", "false", "parameter", "none", "unspecified","{}"}
} 13:04:01:351

Here, the three types of p1, p2, and p3 are listed correctly.

Later on, OMC is inquired about the displayUnit modifiers of the first two classes:

getDerivedClassModifierValue(Modelica.SIunits.Pressure,displayUnit) 13:10:25:884
""bar"" 13:10:25:884
getDerivedClassModifierValue(Modelica.SIunits.AbsolutePressure,displayUnit) 13:10:25:885
"" 13:10:25:885

the first result is correct, the second is not, but then somehow (how?) OMEdit figures out that p2.displayUnit="bar" and shows it in the dialog. For some reason (which one?), the displayUnit of the type of p3 is not even inquired.

I guess there are issues here both with OMEdit and with getDerivedClassModifierValue. @adeas31, can you please check the OMEdit issue, and then hand this over to @adrpo for the nfAPI part?

Thanks!

[Adeel Asghar]

The new API fails to list the components if the component class is not found. This is rather bad for OMEdit. OMEdit can handle undefined classes and shows a red cross box for them. Once they are loaded then OMEdit automatically updates them.

I strongly recommend to consider this for new API. Just list the components of the class even if they are undefined.

[Adeel Asghar]

Replying to casella:

I did some more analysis on omcommunication.log, using -d=newInst,nfAPI. An excerpt of it follows:

getComponents(TestParameterUnits.M2, useQuotes = true) 13:04:00:967
{{"TestParameterUnits.M1","m","", "public", "false", "false", "false", "false", "unspecified", "none", "unspecified","{}"}
} 13:04:00:967

getComponents(TestParameterUnits.M1, useQuotes = true) 13:04:00:976
{{"Modelica.SIunits.Pressure","p1","", "public", "false", "false", "false", "false", "parameter", "none", "unspecified","{}"},
 {"Modelica.SIunits.AbsolutePressure","p2","", "public", "false", "false", "false", "false", "parameter", "none", "unspecified","{}"},
 {"TestParameterUnits.M1.Medium.AbsolutePressure","p3","", "public", "false", "false", "false", "false", "parameter", "none", "unspecified","{}"}
} 13:04:01:351

Here, the three types of p1, p2, and p3 are listed correctly.

Later on, OMC is inquired about the displayUnit modifiers of the first two classes:

getDerivedClassModifierValue(Modelica.SIunits.Pressure,displayUnit) 13:10:25:884
""bar"" 13:10:25:884
getDerivedClassModifierValue(Modelica.SIunits.AbsolutePressure,displayUnit) 13:10:25:885
"" 13:10:25:885

the first result is correct, the second is not, but then somehow (how?) OMEdit figures out that p2.displayUnit="bar" and shows it in the dialog. For some reason (which one?), the displayUnit of the type of p3 is not even inquired.

The second result is also true since Modelica.SIunits.AbsolutePressure doesn't have any displayUnit so in that case OMEdit tries to find it from the base class i.e., Modelica.SIunits.Pressure. For p3 we should also get bar but getInheritedClasses(TestParameterUnits.M1.Medium.AbsolutePressure) fails. If you look further below in the log you will see that p3 is inquired.

I guess there are issues here both with OMEdit and with getDerivedClassModifierValue. @adeas31, can you please check the OMEdit issue, and then hand this over to @adrpo for the nfAPI part?

Thanks!

[Adrian Pop]

With PR: ​https://github.com/OpenModelica/OpenModelica/pull/298
we will get the components even if the types of the classes are not found.

getInheritedClasses(TestParameterUnits.M1.Medium.AbsolutePressure) is not using the NF yet, also it tries to search in the AST for class TestParameterUnits.M1.Medium.AbsolutePressure which of course will never be found. You would need to do proper lookup to find out that Medium is set to StandardWater and that StandardWater is actually a short class definition of WaterIF97_ph, fetch inherited classes of that one to reach Types where AbsolutePressure is defined and then fetch its modifier. I have to think about a solution for this one.

[Adeel Asghar]

So we just need to fix getInheritedClasses and then we get the expected results in OMEdit.

[Francesco Casella]

Releasing 1.14.0 which is stable and has many improvements w.r.t. 1.13.2.

This issue, previously marked as blocker for 1.14.0, is rescheduled to 1.15.0

[Francesco Casella]

Release 1.15.0 was scrapped, because replaceable support eventually turned out to be more easily implemented in 1.16.0. Hence, all 1.15.0 tickets are rescheduled to 1.16.0

[Francesco Casella]

Retargeted to 1.17.0 after 1.16.0 release

[Francesco Casella]

Rescheduled to 1.18.0

[Francesco Casella]

Ticket retargeted after milestone closed

[Francesco Casella]

1.18.0 blocker tickets moved to 1.19.0