Unit propagation issue

[massimo ceraolo]

Sorry for possible ticket duplication; I searched the trac, and (surprisingly) could not find any ticket about the topic of this one.

Although I could not find the exact position in Modelica specification, I think that units of measure should be propagated, whenever possible.

In the PowerUnit example the unit of the output of pMeas is correctly displayed as "W"; but input and output of meanP are shown unit-less.

I suppose this is not the expected behaviour.

[massimo ceraolo]

Now I see in #4138 that unit checking is already implemented in the new front-end. Maybe the issue is already solved there? Otherwise, since it has low priority can it addressed directly I'm the new f.e.?

[Lennart Ochel]

The implementation for the new front end is more or less the same than for the old one. So I don't think that it behaves differently.

[Lennart Ochel]

I fixed some missing cases and now the unit information of meanP.y is calculate as "W". What else is missing?

[Lennart Ochel]

For more information, see also ​OMCompiler#1543.

[massimo ceraolo]

Replying to lochel:

I fixed some missing cases and now the unit information of meanP.y is calculate as "W". What else is missing?

two more cases:

• integrator.y (in the new PowerUnit.mo) should have "J"
• pr (in ProductUnit) should have "W"

[Lennart Ochel]

Replying to ceraolo:

• integrator.y (in the new PowerUnit.mo) should have "J"

This works with ​OMCompiler#1543.

• pr (in ProductUnit) should have "W"

It seems that this has also worked before.

[massimo ceraolo]

Sorry, last night I posted results made with an OM version dated a couple of weeks ago.
As soon as a nightly build including #1543 is available I will make new tests.

[Lennart Ochel]

Replying to ceraolo:

As soon as a nightly build including #1543 is available I will make new tests.

I've pushed the changes now, so they should be included in the next nightly build.

[massimo ceraolo]

Using Todays's night build and running from OMEdit, I still cannot see the unit of measure of meanP.u, meanP.y, integrator.y, as well as pr in ProductUnit.

OMEdit v1.12.0-dev-229-g44b8b42 (64-bit)
Connected to v1.12.0-dev-293-gec908e4 (64-bit)

[Lennart Ochel]

Replying to ceraolo:

Using Todays's night build and running from OMEdit, I still cannot see the unit of measure of meanP.u, meanP.y, integrator.y, as well as pr in ProductUnit.

I just double checked it and now all the variables do have the correct unit information. However, this requires to enable the unit checking module (flag for compilation: --preOptModules+=unitChecking).

[Lennart Ochel]

Propagated unit information for PowerUnit.mo

"integrator.y" has the Unit "J"
"integrator.u" has the Unit "W"
"sineVoltage.signalSource.y" has the Unit "V"
"pMeas.product.y" has the Unit "W"
"pMeas.product.u2" has the Unit "A"
"pMeas.product.u1" has the Unit "V"
"meanP.x" has the Unit "J"
"meanP.y" has the Unit "W"
"meanP.u" has the Unit "W"
"sineVoltage.signalSource.offset" has the Unit "V"
"sineVoltage.signalSource.amplitude" has the Unit "V"

Propagated unit information for ProductUnit.mo

"pr" has the Unit "W"
"pc.im" has the Unit "W"
"pc.re" has the Unit "W"

[massimo ceraolo]

I've added --preOptModules+=unitChecking to OMC flags in OMEdit.
I've verified that that flag is accepted, looking at the Compiler CLI:

setCommandLineOptions("--removeSimpleEquations=none --preOptModules+=unitChecking")

The result (as it appears in OMEdit variables Browser) is as follows:

"integrator.y" has noUnit
"integrator.u" has no Unit
"sineVoltage.signalSource.y" has the Unit "V"
"pMeas.product.y" has no Unit
"pMeas.product.u2" has no Unit
"pMeas.product.u1" has no Unit
"meanP.x0" has no Unit
"meanP.y" has no Unit
"meanP.u" has no Unit
"sineVoltage.signalSource.offset" has no Unit
"sineVoltage.signalSource.amplitude" has no Unit

Propagated unit information for ProductUnit.mo
"pr" has the Unit "W"
"pc.im" has the Unit "W"
"pc.re" has the Unit "W"

So, setting --preOptModules+=unitChecking has solved the issues from file ProductUnit.mo, but not from PowerUnit.mo.

Now I see two issues:
1) even when --preOptModules+=unitChecking, some units are not displayed by OMEdit in some cases
2) unit checking and propagation, IMO, should be ON by default. I suppose it is still OFF because the feature is experimental; however, if it works as reported in comment13, I think it is already too useful to leave it OFF by default

[Lennart Ochel]

Replying to ceraolo:

Now I see two issues:
1) even when --preOptModules+=unitChecking, some units are not displayed by OMEdit in some cases

I have to investigate this a bit more. Right now I cannot reproduce your results. However, I will test it with OMEdit and see what’s going on there...

2) unit checking and propagation, IMO, should be ON by default. I suppose it is still OFF because the feature is experimental; however, if it works as reported in comment13, I think it is already too useful to leave it OFF by default

The unit checking is still disabled, because it produces in some cases wrong results due to previously (frontend) simplified expressions. This will be solved once the new front end is in place. (Therefore, the unit checking has already been ported to the new front end.)

[Lennart Ochel]

I found the issue. The unit checking module fails for PowerUnit.mo and thus the calculated unit information get not propagated properly.

[Lennart Ochel]

This should be fixed once ​OMCompiler#1551 is merged.

[Lennart Ochel]

It should work with the next nightly build. Otherwise, please reopen this ticket.

[massimo ceraolo]

All the already supplied examples work well now!

There is a single case missing, IMO. I don't see the unit on measP.flange_a.der(s) of the enclosed testUnitNew.

[Lennart Ochel]

Hmm... measP.flange_a.s has unit "m". But it is an alias variable of type DUMMY_STATE and therefore we do not have measP.flange_a.der(s) in the *_init.xml file that is used by OMEdit to display the unit information ... I'm not yet sure how to solve this.

[massimo ceraolo]

I wrote wrong. Indeed it is flange_b.der(s) that lacks unit.
I also failed to note that the definition of Mechanics.Rotational.Interfaces.Flange_* does not contain any der(s), which is added later by the tool.
For comparison, Dymola does not even show any der(s) among mass's flanges.
So, IMO there is no need to keep this ticket open anymore.