Opened 4 years ago
Last modified 3 years ago
#6345 reopened defect
displayUnit of inverse time "d-1", "h-1", ''min-1" not working
Reported by: | Owned by: | Martin Sjölund | |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | OMEdit | Version: | 1.16.2 |
Keywords: | Cc: |
Description
Dear OM devs,
With OM 1.16.2, I can't get variables representing a rate in per second ("s-1") to display as per day, per hour or per minute (i.e. unit="s-1"
and displayUnit="d-1"
or "h-1", "min-1"). See example model attached.
I've checked that the displayUnit="d"
for a time works. For a rate, displayUnit="ks-1"
(per 1000 seconds) also works fine, i.e. displays the value multiplied by 1000. So the problem does not concerns the conversion of all units with a -1 exponent.
I've found the implementation of the "day" unit was discussed in issue #2250 (https://trac.openmodelica.org/OpenModelica/ticket/2250#comment:27) and is visible in the code at https://github.com/OpenModelica/OpenModelica/blob/master/OMCompiler/Compiler/runtime/unitparser.cpp#L1152.
About the application: I gave students a modeling project about SIR epidemy models. Quite fashionable these days! I think infection rates are often given per day.
Best,
Pierre
Attachments (1)
Change History (13)
by , 4 years ago
Attachment: | timeUnitDay.mo added |
---|
comment:1 by , 4 years ago
Further digging into the problem: displayUnit="1/d"
does work ("1/ks" as well). So there is some specific interaction between the day/hour/minute unit and the "-1" unit exponent.
comment:2 by , 4 years ago
>>> convertUnits("s-1", "d-1") (false,86400.0,0.0) >>> convertUnits("s-1", "1/d") (true,1.157407407407407e-05,0.0) >>> getDerivedUnits("1/s") {"Bq","Hz","rpm"} >>> getDerivedUnits("1/d") {"Bq","Hz","rpm"}
So there is indeed something fishy going on with that conversion...
comment:3 by , 4 years ago
Component: | *unknown* → OMEdit |
---|---|
Owner: | changed from | to
Status: | new → assigned |
I'll assign this to @adeas31
Adeel, feel free to reassing it if there is a dependency of OMEdit on some other module that you cannot fix.
comment:4 by , 4 years ago
s-1 has unit s-1 d-1 has unit s s has unit s d has unit s
This seems... wrong
comment:5 by , 4 years ago
So, the error is that Unit::pow gives an error if the scale factor is not 1 when you try to add an exponent. And this is silently ignored.
The actual thing that should happen is that the scale factor should also be affected by this operation as far as I can tell.
This seems to only be supported for prefixExpo (Exponent value for the prefix. E.g. if [mm] is defined, it is 10^-3*[m], e.g. prefixExpo = -3
), but not (Scalar factor including both SI prefix and unit scalar factors (e.g. feet -> meter)
).
follow-up: 7 comment:6 by , 4 years ago
So... The problem is this is all using rational factors, and pow was never implemented. They even added an error code for this, instead of fixing the problem :)
comment:7 by , 4 years ago
Replying to sjoelund.se:
They even added an error code for this, instead of fixing the problem :)
Who was "they"?
comment:8 by , 4 years ago
Owner: | changed from | to
---|
comment:9 by , 4 years ago
Milestone: | NeedsInput → 1.17.0 |
---|---|
Resolution: | → fixed |
Status: | assigned → closed |
comment:10 by , 4 years ago
Resolution: | fixed |
---|---|
Status: | closed → reopened |
@sjoelund.se, PR 7132 is already on 1.18.0-dev, would you mind pushing it also to 1.17.0 maintenance?
comment:11 by , 4 years ago
Milestone: | 1.17.0 → 1.18.0 |
---|
Retargeted to 1.18.0 because of 1.17.0 timed release.
model to test displayUnit="d-1"