Opened 8 years ago

Closed 8 years ago

#4306 closed defect (fixed)

Unit propagation issue

Reported by: massimo ceraolo Owned by: Lennart Ochel
Priority: normal Milestone: 1.12.0
Component: Frontend Version:
Keywords: Cc:

Description

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.

Attachments (3)

PowerUnit.mo (2.5 KB ) - added by massimo ceraolo 8 years ago.
ProductUnit.mo (473 bytes ) - added by massimo ceraolo 8 years ago.
testUnitNew.mo (2.0 KB ) - added by massimo ceraolo 8 years ago.

Download all attachments as: .zip

Change History (25)

comment:1 by Lennart Ochel, 8 years ago

Component: OMEditFrontend
Owner: changed from Adeel Asghar to somebody

comment:2 by massimo ceraolo, 8 years ago

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 in the new f.e.?

Last edited 8 years ago by massimo ceraolo (previous) (diff)

comment:3 by Lennart Ochel, 8 years ago

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.

comment:4 by Lennart Ochel, 8 years ago

Owner: changed from somebody to Lennart Ochel
Status: newaccepted

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

comment:5 by Lennart Ochel, 8 years ago

For more information, see also OMCompiler#1543.

in reply to:  4 ; comment:6 by massimo ceraolo, 8 years ago

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"

by massimo ceraolo, 8 years ago

Attachment: PowerUnit.mo added

by massimo ceraolo, 8 years ago

Attachment: ProductUnit.mo added

in reply to:  6 comment:7 by Lennart Ochel, 8 years ago

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.

comment:8 by Lennart Ochel, 8 years ago

Milestone: Future1.12.0

comment:9 by massimo ceraolo, 8 years ago

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.

in reply to:  9 comment:10 by Lennart Ochel, 8 years ago

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.

comment:11 by massimo ceraolo, 8 years ago

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)

in reply to:  11 comment:12 by Lennart Ochel, 8 years ago

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).

comment:13 by Lennart Ochel, 8 years ago

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"

comment:14 by massimo ceraolo, 8 years ago

I've added --preOptModules+=unitChecking to OMC flags in OMEdit.
I've verified that that flac is accepted, looking ath 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

Version 0, edited 8 years ago by massimo ceraolo (next)

in reply to:  14 comment:15 by Lennart Ochel, 8 years ago

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.)

comment:16 by Lennart Ochel, 8 years ago

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

comment:17 by Lennart Ochel, 8 years ago

This should be fixed once OMCompiler#1551 is merged.

comment:18 by Lennart Ochel, 8 years ago

Resolution: fixed
Status: acceptedclosed

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

comment:19 by massimo ceraolo, 8 years ago

Resolution: fixed
Status: closedreopened

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.

by massimo ceraolo, 8 years ago

Attachment: testUnitNew.mo added

comment:20 by Lennart Ochel, 8 years ago

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.

comment:21 by massimo ceraolo, 8 years ago

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.

Last edited 8 years ago by massimo ceraolo (previous) (diff)

comment:22 by massimo ceraolo, 8 years ago

Resolution: fixed
Status: reopenedclosed
Note: See TracTickets for help on using tickets.