Is pre(c) for a constant a variable of the initialization problem?

[henrikt-ma]

This model looks crazy to me, but I can't find support in the specification for rejecting it:

model ConstantPre
  constant Real c = 1.0;
initial equation
  pre(c) = 2.0;
end ConstantPre;

Maybe we should deprecate this kind of craziness?

What about the parameter case?

model ParameterPre
  parameter Real p = 1.0;
initial equation
  pre(p) = 2.0;
end ParameterPre;

Outside of initial sections, it seems straight-forward to just apply the simplification pre(c) → c, which would also be safe for a parameter, right?

[henrikt-ma]

Could it be the case that the intended restriction for pre(y) in https://specification.modelica.org/master/operators-and-expressions.html#modelica:pre is that y is a discrete-time variable (https://specification.modelica.org/master/class-predefined-types-and-declarations.html#component-variability) rather than a discrete-time expression (https://specification.modelica.org/master/operators-and-expressions.html#discrete-time-expressions)?

[HansOlsson]

Could it be the case that the intended restriction for pre(y) in https://specification.modelica.org/master/operators-and-expressions.html#modelica:pre is that y is a discrete-time variable (https://specification.modelica.org/master/class-predefined-types-and-declarations.html#component-variability) rather than a discrete-time expression (https://specification.modelica.org/master/operators-and-expressions.html#discrete-time-expressions)?

No, there is already an explanation for why that isn't the case:

This can be applied to continuous-time variables in when-clauses, see section 3.8.5 for the definition of discrete-time expression

[HansOlsson]

Yes, since a parameter or constant does not change value I believe it would make sense to explicitly state that pre(c)=c. Using the pre-value during initialization for some good purpose seems pretty odd.

[eshmoylova]

For constants we have in Section 4.5

A variable vc declared with constant prefix does not change during simulation, with a value that is unaffected even by the initialization problem (i.e., determined during translation). This is called a constant, or constant variable. For further details, see 4.5.1.

And if we assume pre(c) = c for a constant, the initial equation in ConstantPre should reduce to:

  1.0 = 2.0;

(This is what I get in MapleSim.) It should raise an error that the equation is inconsistent.

BUT: you could also assume that pre(c) is equivalent to c.start. The start attribute is a parameter in Real. We have a rule for variability of structured entities, but nothing is mention about built-in types. So, as it stands, it is reasonable to assume that c.start is a parameter even though c is a constant. In that case you can set it in an initial equation and there is no inconsistency between c = 1.0 and c.start = 2.0. You cannot write c.start in an equation, so writing it as pre(c) is the only possibility.

Does this model simulate in any tool?

[henrikt-ma]

BUT: you could also assume that pre(c) is equivalent to c.start. The start attribute is a parameter in Real. We have a rule for variability of structured entities, but nothing is mention about built-in types. So, as it stands, it is reasonable to assume that c.start is a parameter even though c is a constant. In that case you can set it in an initial equation and there is no inconsistency between c = 1.0 and c.start = 2.0. You cannot write c.start in an equation, so writing it as pre(c) is the only possibility.

No, we don't have pre(c) = c.start for a parameter/constant variable. From https://specification.modelica.org/master/equations.html#initialization-initial-equation-and-initial-algorithm:

For a variable declared as constant or parameter, no equation is added to the initialization equations.

Thus, pre(c) is currently a free and mysterious variable of the initialization problem.

The model does not build in System Modeler, and I'd be happy to reject it with support in the specification rather than try to make it work.

I see two ways we could reject it in the specification:

1. @HansOlsson's suggestion to add the equation pre(c) = c for parameter/constant variables.
2. Forbid pre(c) for parameter/constant variables.

(1) has the advantage of a more symmetric treatment of variables of all variabilities. It has the disadvantage that we sustain some of the mystery by speaking of the useless pre(c) for parameter/constant variables.

(2) has the advantage of making it much easier to reject the model with a message that will be easy for users to understand and help them correct the problem.

[henrikt-ma]

Note that another weirdness of the current situation is that this model suffers from underdetermined initialization:

model UndeterminedConstantPre
  constant Real c = 1.0;
  parameter Real p(fixed = false);
initial equation
  p = pre(c); /* Only one equation, but two unknowns! */
end UndeterminedConstantPre;

[HansOlsson]

An argument for having pre(c) return c for a constant or parameter c is that we have defined previous in that way https://specification.modelica.org/master/synchronous-language-elements.html#clocked-state-variables

In both cases the use-case is writing cases like:

when ... then
   a=0.5*previous(a)+previous(u)+...;
end when;

(and similarly with pre) as a style, and ignoring whether u is a parameter or not.
I believe that consistency is quite useful.

[HansOlsson]

Should explicitly state that pre(c) is the same as c - even during initialization.