To me it doesn't make sense to specify that it is inferred without specifying how it is inferred (which to me requires unit-inferrence as we don't even know which variables require it otherwise).

That's why I suggested:

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.

That still gives the possibility to infer, but without making models too reliant on it.

I believe the fear of over-using the annotation is misplaced. To me it is a matter of using Modelica.Units.SI.Temperature or Modelica.Units.SI.TemperatureDifference.

If we consider parameters of a model I believe it is good style to declare them with a type (that includes unit and absoluteValue-annotation). Similarly for physical connectors. I would also consider it normal to declare other variables in physical models to be declared with a type (including unit and absoluteValue).

The exception I see is when you build blocks interacting with such models (using sensors and sources), where I would see it as unusual to have a unit and absoluteValue (looking more I realize that there are some that have unit="K" - most, but not all implicitly have absoluteValue=true - and the exception I found was wrong in other ways as well - will open an issue).

It is also important that any such inference is restricted to the cases where it makes sense to avoid problems. The ones that are clear are:

• Two-terms: Equality (a=b)
• Three-terms (regardless of written as addition or subtraction a=b-c, b=a+c):
  • The difference between two absolute temperatures is a relative one.
  • Adding/subtracting two relative temperatures give a relative one.

The reason to be restrictive is that if tools add additional incorrect rules there might be a push to update existing good models in bad ways to circumvent those checks. Since such a scenario is not just hypothetical, I don't see how we can add inference as default without specifying the how.

BTW: Such an inference has been test-implemented in Dymola, and correctly handles the sensors for absolute and relative temperature.

It is also important that any such inference is restricted to the cases where it makes sense to avoid problems. The ones that are clear are:

The rules for unit checking are also important. This PR is primarily about restoring the 3.6 situation where the specification did not rule out the possibility of doing some sort of inference, but instead of just going back to the unexplained default in 3.6, this PR goes a little further by also pointing out that tools need to be aware of when their inference isn't conclusive. Similar to unit inference, we need to have faith in tools until we manage agree upon exactly how absoluteValue inference should be done.

It is also important that any such inference is restricted to the cases where it makes sense to avoid problems. The ones that are clear are:

The rules for unit checking are also important. This PR is primarily about restoring the 3.6 situation where the specification did not rule out the possibility of doing some sort of inference, but instead of just going back to the unexplained default in 3.6, this PR goes a little further by also pointing out that tools need to be aware of when their inference isn't conclusive. Similar to unit inference, we need to have faith in tools until we manage agree upon exactly how absoluteValue inference should be done.

But:

• For units we don't tell users that inference is the default, instead we only define explicit unit-attribute in the specification. Why should we do it differently for absoluteValue based on some future work?
• One can neither completely boot-strap unit nor absoluteValue for a model, inference starts from some variables with units and infer units for other variables.
• For many the focus is on checking not inference; and to me that is a valid approach; by stating that inference is the default we demote that.

In practice if we look at MSL:

• In Modelica.Blocks.Examples.Noise.Utilities.Parts.MotorWithCurrentControl (and similar ones) we can infer unit and absoluteValue for const-blocks in smpm.thermalAmbient - a nice to have, but nothing more.
• But in Modelica.Clocked.Examples.Systems.ControlledMixingUnit I don't see how we can infer absoluteValue=true for the different temperatures in the mixing unit. The clearest indicator that it is an absolute value is exp( -weps/T), but that is really stretching it.