Default for absoluteValue

[henrikt-ma]

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.

[HansOlsson]

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.

To me the description was made it clear by only stating the effect of absoluteValue = false
"When converting between units (in the user-interface for plotting and entering parameters), the unit offset must be ignored for a variable defined with annotation absoluteValue = false."
That default was also the intent when it was first proposed in 2007 (as a vendor-specific annotation).

However, it would clearly be possible to remove the default and with increased unit inference it makes more sense.

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.

The problem I see is that inferring whether something is an absolute value or not can be more complicated, and either we need to specify it (which will take time) or different tools will behave differently. On the other hand if we have Real t4=t3; it doesn't make sense to specify absoluteValue when we don't even specify the unit.

In many cases I don't see how we can infer if it is an absolute value or not - in particular if we had "t1=t5+t6;" (using t1 as above) we can deduce that one of t5 and t6 is absolute and the other relative, but not which one is which (this differs from unit inference where we conclude that both have unit "K").

Thus, I would consider it important that we state that specifying it is preferable.

[henrikt-ma]

In many cases I don't see how we can infer if it is an absolute value or not - in particular if we had "t1=t5+t6;" (using t1 as above) we can deduce that one of t5 and t6 is absolute and the other relative, but not which one is which (this differs from unit inference where we conclude that both have unit "K").

Yes, but it is actually not completely trivial to extend this example to something realistic where it is still not possible to infer which of them is absolute (especially if removing the requirement that the inference should be supported by some existing Modelica tool).

Thus, I would consider it important that we state that specifying it is preferable.

Well, saying it is preferable even in the cases where it is trivially inferable seems a bit clumsy, so we should aim for something more nuanced. Maybe this could work:

Automatic inference is generally harder for absoluteValue than for units, and the absoluteValue-annotation should be used (typically by means of a type where it has been specified) when it is not expected that tools will be able to infer it.

[henrikt-ma]

More important than giving recommendations for the user however, is probably to give the sensible rule for tools:

If the absoluteValue of a component is neither determined by annotation nor inference, unit conversions that would differ depending on absoluteValue cannot be performed.

Given this, the recommendation could be replaced by a non-normative observation:

For a component where unit conversions involving offsets could be of interest, ensuring that absoluteValue is determined by an annotation (typically by means of using a type where it has been specified) may hence reduce impact of quality-of-implementation in tool ability to infer absoluteValue.

[HansOlsson]

Since we don't have any rules for inference (yet) I would rewrite it as follows:

For a component where unit conversions involving non-zero offset is possible (mainly temperatures) it is recommend to give a value for absoluteValue in annotation either for the component or the type declaration. Tools may infer absoluteValue in other cases, but specifying absoluteValue reduces impact of quality-of-implementation in tool ability to infer absoluteValue.

[henrikt-ma]

OK, then I'll prepare a PR where the discussion can be continued.