Modelica Change Proposal MCP-0027 Units of Literal Constants Authors: Francesco Casella, Martin Sjölund Status: In Development version v3

Size: px

Start display at page:

Download "Modelica Change Proposal MCP-0027 Units of Literal Constants Authors: Francesco Casella, Martin Sjölund Status: In Development version v3"

Lionel Crawford
5 years ago
Views:

1 Modelica Change Proposal MCP-0027 Units of Literal Constants Authors: Francesco Casella, Martin Sjölund Status: In Development version v3 Summary Units of literal Real constants are unspecified in the Modelica 3.4. Some tools interpret this as having unit, which prevents strong unit checking of physical s containing non-dimensional literal constants. The goal of this proposal is to clarify this aspect and make stronger unit checking possible. Revisions Date v3 Oct 19, 2017 v2 May 19, 2017 v1 Dec 11, 2016 Short description of revision Revised at 95 th Design Meeting in Linkoping Revised at 94 th Design Meeting, based on output of discussion at 92 nd Design Meeting Francesco Casella. Prepared with suggestions from Martin Sjolund, for presentation at the 92 nd Design Meeting Contributor License Agreement All authors of this MCP or their organizations have signed the Modelica Contributor License Agreement Table of Contents 1. Rationale Issues with the existing MSL Proposed Changes in Specification Backwards Compatibility Tool Implementation Experience with Prototype... 5

2 MCP 0027 UnitsLiteralConstants In Development v Rationale The Modelica Specification 3.4 does not define what the unit attribute of literal Real constants is. This makes it impossible to perform unit checking of s containing non-dimensional numerical factors. Consider the following example, based on the well-known Torricelli s law: Modelica.SIunits.Velocity v; Modelica.SIunits.Acceleration g = ; Modelica.SIunits.Height h; v = sqrt(2.0*g*h); If the literal constant 2.0 had unit 1, then it would be possible to check that both the left-hand side and right-hand side of the have unit m/s, so that the is dimensionally consistent. Otherwise, no checking is possible. If one writes a dimensionally incorrect such as v = 2.0*g*h; it is only possible to detect the dimensionally inconsistence if 2.0 has dimension 1, otherwise nothing can be said about that, since not all terms in the would have well-specified dimensions. In fact, a modeller is most likely going to write: or v = 2*g*h; v = sqrt(2*g*h); using Integer literal constants. In this case, the same considerations stated above apply, once the Integer constant 2 has been converted to the Real constant 2.0, according to the rules stated in Section With this proposal, one should not write expressions mixing literal and non-literal terms, when the literal term is assumed to have a dimensions other than 1, e.g.: Modelica.SIunits.Voltage v; v = 4*i; which may be considered as a bad modelling style, as the preferred way to write physical s is to first define a physical variable or parameter that has value 4 in SI units and then use it in the instead of the literal constant, e.g.: Modelica.SIunits.Voltage v; parameter Modelica.SIunits.Resistance R = 4; v = R*i;

3 MCP 0027 UnitsLiteralConstants In Development v1 3 However, there are a few cases in which it is not possible to assume that a literal constant has dimention 1, otherwise the result would be unintendedly dimensionally inconsistent. In all these cases, the unit of the literal constant is kept to the default value for the Real type, that is,. a) Equations or assignments in the form <variable> = <expr>; or <variable>:=<expr>;, where <expr> is an expression containing only literal constants, arithmetic operators (excluding operator overloading), and built-in mathematical functions This includes all binding s such as Modelica.SIunits.Voltage v = 3; constant Modelica.SIunits.Acceleration g = ; parameter Modelica.SIunits.Length L = sqrt(2)*14.5; and all s and assignments such as v = 3; a := T := whose straightforward interpretation is that the literals in the expressions have unit=, so that the s and assignment are not dimensionally inconsistent. b) relations Relations in conditions or assertions are often written by indicating the limit value with a literal constant or literal expression, e.g. when F > 100 then... if T > then... assert(1e6 <= p, Pressure too low ); These cases should also obviously not trigger unit checking warning, so the literal constants have unit= here as well. c) the constant is zero If one writes Modelica.SIunits.MassFlowRate mflow[:]; Modelica.SIunits.Current i1, i2, i3; 0 = sum(mflow); i1 + i2 + i3 = 0; then obviously the s are dimensionally consistent no matter what the unit of the non-literal side is. In order to avoid triggering unit checking warnings, one should assume that the literal constant 0.0 has unit=. This is also needed to correctly deal with s such as Boolean on; Modelica.SIunits.Voltage V; Modelica.SIunits.Resistance R; i = if on then v/r else 0;

4 MCP 0027 UnitsLiteralConstants In Development v Issues with the existing MSL. The Modelica.Electrical.Analog.Ideal.IdealNode contains the following code: Boolean off(start=true) "Switching state"; protected Real s(start=0, final unit="1") "Auxiliary variable for actual position on the ideal diode characteristic"; /* s = 0: knee point s < 0: below knee point, conducting s > 0: above knee point, locking */ constant Modelica.SIunits.Voltage unitvoltage=1; constant Modelica.SIunits.Current unitcurrent=1; v = (s*unitcurrent)*(if off then 1 else Ron) + Vknee; i = (s*unitvoltage)*(if off then Goff else 1) + Goff*Vknee; LossPower = v*i; The current proposal would lead to the assumption that 1 has unit 1 in the conditional expressions, leading to dimensionally inconsistent s. On the other hand one could argue that writing those s as: constant Modelica.SIunits.Resistance unitresistance = 1; constant Modelica.SIunits.Resistance unitconductance = 1; V = (s*unitcurrent)*(if off then unitresistance else Ron) + Vknee; i = (s*unitvoltage)*(if off then Goff else unitconductance) + Goff*Vknee; would actually be more elegant and correct. This formulation would be dimensionally consistent according to the current proposal. We think this small update in the MSL is worth carrying out. 3. Proposed Changes in Specification The precise text of the proposed changes with respect to Modelica Specification 3.4 is found in the accompanying document MCP_0027_UnitsLiteralConstants_SpecChanges.pdf. 4. Backwards Compatibility The proposed MCP only clarifies a currently ambiguous point, i.e., what is the unit of literal Real constants. Some Modelica tools may take some implicit assumptions on this, but that is not standardized, and in the opinion of the authors of this MCP too lax, also. As unit checking typically only gives a warning in Modelica tools, there should be no serious problems of backwards compatibility. The proposal is 100% backwards compatible, in thee sense that the validity of a Modelica model is not formally constrained or restricted by unit consistency. Anyway, this proposal requires as few as possible modifications to the existing code bases (in particular the MSL) to ensure that unit checking is only affected positively, i.e., reducing the likelihood that a dimensionally incorrect model passes unit checking, whithout at the same time increasing the likelihood that existing correct models get diagnosed as not dimensionally consistent by unit checking. In particular, there are just a few places in the MSL where literal constants have been used in expressions, meaning a quantity with dimensions, e.g., if off then 1 else Ron, where 1 means

5 MCP 0027 UnitsLiteralConstants In Development v1 5 1 Ohm. These cases can be spotted easily because they will generate an additional warning when the new rules are used, and should be corrected as suggested at the end of Section Tool Implementation 5.1 Experience with Prototype As of today, there are no test implementations yet. However, the proposal could be implemented and tested in OpenModelica very quickly, as it is only a minor addition to the existing type checking mechanism. It will then be possible to automatically check the impact of this MCP on the MSL and on a large number of open source Modelica libraries for which OpenModelica coverage is ran on a nightly basis.

Programming Languages Third Edition

Programming Languages Third Edition Chapter 12 Formal Semantics Objectives Become familiar with a sample small language for the purpose of semantic specification Understand operational semantics Understand