In the release announcement of the Modelica language version 3.6 (see Modelica Association Newsletter 2023-01), there is a new syntax Undefined modification:
Undefined modification - this allows making a parameter undefined, e.g., to force users of the model to explicitly set it. https://specification.modelica.org/master/inheritance-modification-and-redeclaration.html#removing-modifiers-break
However, the new syntax, if I understand it correctly, is only to remove the parameter value set the superclass when inheriting a model (with the extends
keyword).
Now seeing this new syntax it just occurred to me that I don't know how to specify that a model parameter shouldn't have a default value in general (i.e. force the user of the model to specify its value).
For example, here is a short model where the value of param
is not set:
model ParameterDefaultValue "A model with one parameter which shouldn't have a default value"
parameter Real param "parameter which shouldn't have a default value";
equation
end ParameterDefaultValue;
Even if the value is not specified, this model does simulate, using a default value of 0.0 (in OpenModelica 1.20), albeit with a Translation warning: [ParameterDefaultValue: 2:3-2:73]: Parameter param has no value, and is fixed during initialization (fixed=true), using available start value (start=0.0) as default value.
More specifically, I wonder if it's possible for the simulation to fail rather than emit a warning. In a sense, it means that the model ParameterDefaultValue wouldn't be directly simulable, only after having been extended or simply composed is a larger model:
model UpperModel
ParameterDefaultValue parameterDefaultValue(param = 1);
equation
end UpperModel;
I see that my question resembles the use case of the partial
keyword (abstract classes in other object oriented languages), except that partial
is:
Also, comparing to an imperative programming languages like Python, the default values of parameters in a function is an optional feature, not a default:
def f(a, b=1):
return a+b
f(2) # OK → returns 3
f() # fails with TypeError: f() missing 1 required positional argument: 'a'
I believe that OpenModelica version may be relying on another item that was changed in Modelica 3.6 (due to https://github.com/modelica/ModelicaSpecification/pull/3226 ).
Specifically the messages says it uses the available start-value 0.0, and that seems to refer to the earlier definition of Real that did have a start-value of 0.0 https://specification.modelica.org/maint/3.5/class-predefined-types-and-declarations.html#real-type
Technically the start-value should only be used as default if there was a modifier, but that was a bit unclear and the Pull Request removed the default 0.0 and clarified the use. (There might be additional changes related to this.)
Added: Basically for parameters we can think of three cases:
parameter Real p;
parameter Real p(start=1);
parameter Real p=1;
The idea is that later ones are "better", but before 3.6 the specification only specified that 2 should give a warning, but didn't really specify anything for 1. I believe that so many relied on the check in Dymola that no-one actually checked whether it was specified.
Note that case 2 was added in 3.3, and updated in https://github.com/modelica/ModelicaSpecification/issues/2136