You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In Modelica 3.6, it was not a clear definition of default behavior for the absoluteValue-annotation. We also observed that there are examples of both absoluteValue = false and absoluteValue = true in existing libraries, which corroborated the theory that there was no fixed default.
In System Modeler, we have taken advantage of this by allowing inference for absoluteValue, similar to how the unit of a variable may be inferred. For example, we do the "correct" display value conversion for t2 and t4 here:
Real t1(unit = "K", displayUnit = "degC") = 293.15 annotation(absoluteValue = true); // Displays as 20°C.
Real t2(displayUnit = "degC") = t1; // Should display the same way as t1.
Real t3(unit = "K", displayUnit = "degC") = 293.15 annotation(absoluteValue = false); // Displays as 293.15°C.
Real t4(displayUnit = "degC") = t3; // Should display the same way as t3.
(In more realistic examples, t2 and t4 would not have a displayUnit-attribute, but the tool would infer that the unit is "K", and based on this allow the user to select "degC" when plotting the result.)
Based on this, I am proposing to spell out that the default for the absoluteValue-annotation is that we use a similar formulation as for unit and displayUnit:
By default, the absoluteValue status is inferred by the tool.
I am aware that this leaves the question of exactly how to do this inference, but this is a problem closely related to how inference should be done for units, and I propose that we don't try to resolve this part before we have solved problem for units. For now, my main priority is just that the specification doesn't close the door for allowing inference which was still open in the 3.6 release.
The text was updated successfully, but these errors were encountered:
In Modelica 3.6, it was not a clear definition of default behavior for the
absoluteValue
-annotation. We also observed that there are examples of bothabsoluteValue = false
andabsoluteValue = true
in existing libraries, which corroborated the theory that there was no fixed default.In System Modeler, we have taken advantage of this by allowing inference for
absoluteValue
, similar to how the unit of a variable may be inferred. For example, we do the "correct" display value conversion fort2
andt4
here:(In more realistic examples,
t2
andt4
would not have adisplayUnit
-attribute, but the tool would infer that the unit is"K"
, and based on this allow the user to select"degC"
when plotting the result.)Based on this, I am proposing to spell out that the default for the
absoluteValue
-annotation is that we use a similar formulation as forunit
anddisplayUnit
:I am aware that this leaves the question of exactly how to do this inference, but this is a problem closely related to how inference should be done for units, and I propose that we don't try to resolve this part before we have solved problem for units. For now, my main priority is just that the specification doesn't close the door for allowing inference which was still open in the 3.6 release.
The text was updated successfully, but these errors were encountered: