MCP-0027 Units of Literal Constants

Reported by fcasella on 11 Dec 2016 19:03 UTC
I have added a proposal for the clarification of the units of literal constants, which is currently unspecified in Modelica 3.3r1. I hope there's still time to have it in Modelica 3.4, the proposal is very simple and the evaluation process should be straightforward.

Documents can be accessed directly here: Overview and Specification Changes.

Migrated-From: https://trac.modelica.org/Modelica/ticket/2127

Comment by fcasella on 14 Dec 2016 09:49 UTC
Discussion at the 92nd Design Meeting.

Conclusions

only specify when the unit is "1"

Make sure it works with

if expressions
relations
ideal diode model in MSL
degC to K conversion in MSL

Comment by fcasella on 19 May 2017 14:12 UTC
Updated the MCP text on SVN (r9715) at the 94th Design Meeting in Prague

@bilderbuchi

AFAIK, this list is uncontentious w.r.t. the rejected/accepted outcome of a given example, and probably also w.r.t the given reasoning. It might come in handy during potential future iterations on this MCP's topic.

Thanks @bilderbuchi, it is definitely good for me.

From the various comments here and in the rejected #3266, I had compiled this list of examples/test cases for desired unit checking behaviour involving literals: https://gist.github.com/bilderbuchi/317bc1a2e039f477462a61f5826260ea#file-mcp-0027-test-examples-md AFAIK, this list is uncontentious w.r.t. the rejected/accepted outcome of a given example, and probably also w.r.t the given reasoning. It might come in handy during potential future iterations on this MCP's topic.

One comment regarding the ones with pi and gamma: as is, I agree with the "undecided" status. With that said, I feel the following issue should be resolved and unit="1" should be added to pi, gamma, etc.: modelica/ModelicaStandardLibrary#4046

@dietmarw

One comment regarding the ones with pi and gamma: as is, I agree with the "undecided" status. With that said, I feel the following issue should be resolved and unit="1" should be added to pi, gamma, etc.: modelica/ModelicaStandardLibrary#4046

I absolutely agree with that. But I understand this may also be a subject of debate. I once added unit = "1" to the definition of pi to one of the libraries I am developing (can't remember which one) and I remember some comments from @dietmarw that pointed out some possible drawbacks. @dietmarw, maybe he can give some advice to modelica/ModelicaStandardLibrary#4046 as well.

I am confused: Aren't rad the unit of pi? :)

I am confused: Aren't rad the unit of pi? :)

Yes, and no.

One of the underlying issues with the unit-system is that "rad" and "1" are sort of the same. Having "rad" would imply that A=pi*r^2 should have unit "rad.m2"; which is more confusing - so having "1" is preferable.
The reason for selecting radians is exactly that it is possible to treat it as unit "1".

I know there are people that claim that they can differentiate between them, but those tricks normally makes everything more confusing.

I am confused: Aren't rad the unit of pi? :)

Yes, and no.

One of the underlying issues with the unit-system is that "rad" and "1" are sort of the same. Having "rad" would imply that A=pi*r^2 should have unit "rad.m2"; which is more confusing - so having "1" is preferable. The reason for selecting radians is exactly that it is possible to treat it as unit "1".

I know there are people that claim that they can differentiate between them, but those tricks normally makes everything more confusing.

D'accord and I would be really interested in any reason to not let pi have final unit = "1".

As a side note, I've been participating to Modelica Design Meetings for 20 years, and I sometimes thought our discussions had something in common with the scholarly debates of medieval theologians about how many angels would fit on a pin. Though I was impressed by the progress we made over the years, contrary to the motto that "a language should be designed by a person, not by a committee". At least, Modelica came out way better than Ada 😃 .

I guess the discussion on units is particularly fit for this scenario 😅

D'accord and I would be really interested in any reason to not let pi have final unit = "1".

@gwr69 on this topic please also check my comment above, specifically on the difference between unit checking and dimensional consistency checking.

My feeling is that dimensional consistency is what we should try to check, and from that point of view "rad" or "1" make no difference, because they are both dimensionless. Proper unit checking and unit inference are a lot more demanding, and I have a strong feeling that they require some understanding of the equations, as the examples in my comment above demonstrate. Maybe we should eventually have our models checked by LLMs? 😅

Issues that we need to consider and decide on (the list may be incomplete):

The handling of literal constants (in general - but see additional issues below); according to Added "four-line" proposal for units of literals #3266 (comment) one possibility is to state that literal constants that are multiplied/divided are assumed to have unit="1"; whereas in addition/subtraction/relations and assignments they are assumed to have a suitable unit
Aiming for dimensional consistency or unit-checking; the conclusion from MCP-0027 Units of Literal Constants #2127 (comment) seems to be that we "only" want dimensional consistency
- One part is separating rad vs. 1.
- Another part is allowing prefixes, like 4 mm (as unit); historically the goal was to only have it in displayUnit
Only checking or full inference? It seems fairly clear we want inference
- Possibly with some exception for inferencing some constants(?) from equations.
Fractional powers; Support non-integer exponents to handle the result of square root #3439
- The idea is that sqrt should work even if the input doesn't have a squared unit. (I think we agreed on that.)
- Should it also be possible to specify m^0.5 as unit in some way? Note that m0.5 doesn't seem to work in terms of syntax. I don't know if we need rational powers in general (we cannot write m^(1/3) using decimal numbers) - or just repeated sqrt.
How to enable/disable the checking feature; and at what level (equation, model, top-level package). Note that even if one model has disabled the feature we want to combine that with other models without compromising them. (Hans: I want the ability for equations, and to me that mindset works better for combinations.)
- One case are correlations with literal numbers see Unit error in Modelica.Clocked.Examples.Systems.Utilities.ComponentsThrottleControl.IntakeManifold ModelicaStandardLibrary#4097
- Another case are simple test-cases; like p=1000000+1000*time
- Non-SI units; should we have some clear way to indicate in the unit that they are non-SI for input/output, make it clearer that it isn't allowed, or have some other way of disabling the restriction.
- Note that it was changed from "disable" to "enable/disable". Viewing it as "disable" would imply that the default is the most strict checking - that may not be good; so this should be considered as well.
Do we need a way specifying a value in a unit like Real(value=2, unit="m") or should we rely on named constants/parameters? (An intermediate variant would be to add it, but not recommend it.) Note that for constants/parameters one can use a different displayUnit - that is handled by the parameter dialog showing the value in the displayUnit.
Non-technical units like currencies, The Mole Day Proposal: Modelica should better accommodate the modeling needs of non-technical domains #3425
Check how this works in practice (there are still hundred of issues in MSL when enabling such a check.)

To discuss:

Are some issues missed in that list?

Are some issues missed in that list?

Unit semantics of all built-in operators and functions.
Unit semantics of calls to user-defined functions.
Generalizing discussion about literal constants to entire subexpressions that are free of units.
An overall strategy designed with gradual deprecation in mind, so that we don't need to deprecate all inconsistent uses of units at once, but can put some inconsistent uses on a roadmap of things planned for deprecation in future versions.

After thinking more I think the current unit proposals are a bit over-designed.
What we need are the unit-consistency rules, and tools can then implement unit inference based on that.

Specifically for the basics I only see that we need:

Each scalar variable and array element may only have one unit during the simulation
- Arrays may have heterogenous units.
- This is for each instance of the variable, so different component instances and function calls may have different units
- This applies after evaluating evaluable parameters
- For s-parametrization this requires special work-arounds.
Expressions (including equations, binding equations, and start values) must be unit consistent, except for the listed exceptions, and can be used to infer units.
The unit consistency rules for different operations are as listed in appendix A of https://ecp.ep.liu.se/index.php/modelica/article/view/1287/1101 (can copy paste into the specification) clarified below for literals:
- As default: literals without unit and zeros() are treated as empty unit except in multiplicative context (multiplication and division operators) where it has multiplicative-unit with the following rules:
  - If both operands have multiplicative-unit the result has multiplicative-unit
  - If one operand has multiplicative-unit and the other not, the multiplicative-unit decays to unit "1"
If a constant is declared without unit, and with a binding equation that lacks units (even after inference) the constant is treated as empty unit. (This is primarily for package constants, where we don't want to infer a unit for pi and use it at unrelated places; but that also applies in models.)

An expression having empty unit will match any constraint, and inference will not give it a unit.
Variables declared without unit have unspecified unit, which may be inferred if there is a unique unit that makes the expressions unit consistent.

Note:

These are constraint for the models.
I have thus not specified how to infer units - so the traditional unit inference in Dymola (Mattsson&Elmqvist https://modelica.org/events/conference2008/sessions/session1a2.pdf ), Hindley-Milner for scalars (Applying Hindley-Milner to unit-checking #3491 ), and the advanced combination(s) thereof in https://ecp.ep.liu.se/index.php/modelica/article/view/1287/1101 are all valid in terms of quality-of-implementation, but we could recommend a minimum for tools.
The "As default: literals", is intended to allow stricter or less strict variants, e.g., as described in Configurable unit-handling #3690
The "except for the listed exceptions" is additionally intended to allow exceptions for specific equations as described in Configurable unit-handling #3690 (comment)
Originally I used some other term for literals, but changed to "empty unit" to be consistent with Applying Hindley-Milner to unit-checking #3491 - but I notice that the rules may differ.
The rule for multiplicative-unit may seem a bit odd, it is to handle cases like foo(2*3). The logic is the same in Applying Hindley-Milner to unit-checking #3491 (where one operand gets unit "1" and the other gives the unit) but written in more detail - and in particular to handle division as well.

The reason for treatment of zeros() is that it is similar to a generalized 0-literal, and can be used in the following ways:

a.f+b.f=zeros(3);
a.f=zeros(3)*fNominal;

So, in the first equation it is treated as unknown unit (which makes zero-sum equations work in the expected way without any tricks) and in the second as having unit 1 (the only reason to multiply zeros by some scalar would be to get type or unit from the other operand).

The first case is important, the latter less so, but since it follows from treating them as literals it just makes sense.

Navigation Menu

Repository navigation

MCP-0027 Units of Literal Constants #2127

78 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

MCP-0027 Units of Literal Constants #2127

Description

Activity

modelica-trac-importer commented on Nov 4, 2018

modelica-trac-importer commented on Nov 4, 2018

78 remaining items

casella commented on Jun 12, 2023

mestinso commented on Jun 12, 2023

casella commented on Jun 13, 2023

gwr-de commented on Jun 13, 2023

HansOlsson commented on Jun 13, 2023

gwr-de commented on Jun 13, 2023

casella commented on Jun 13, 2023

casella commented on Jun 13, 2023

HansOlsson commented on Oct 22, 2023

HansOlsson commented on Nov 24, 2023

henrikt-ma commented on Nov 27, 2023

HansOlsson commented on Nov 5, 2025

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions