Variability of expressions inside `initial` sections.

[qlambert-pro]

In section 3.8.3, the variability of expressions inside initial algorithm and initial equation are defined to be discrete-time. Shouldn't they rather be parametric? Since this reduces the level of checking, making the change should not create any backward compatibilities.

[gwr-de]

One might also add when initial() as Section 3.8.3 includes

Expressions in the body of a when-clause

as being discrete-time.

This seems to be handled rather inconsistently in Modelica tools?

The following code should clearly be in violation of Section 3.8.3 as far as I understand the specs:

model ParameterModel
  Real x(start = 1.0, fixed = true);
  parameter Real k(fixed = false);
initial equation
  k = 2*x;
equation
  x = -k*der(x);  
end ParameterModel;

[henrikt-ma]

Since this reduces the level of checking, making the change should not create any backward compatibilities.

The problems wouldn't come in the from of backwards incompatibility, but in the form of opening up for unhandled cases of equations taking advantage of the more permissive variability rules. Still, I agree that the specification should be better at explaining why the expressions are discrete-time rather than parameter. If there is no good reason for it, I suppose the sensible thing to do would be to actually change them to be parameter.

[henrikt-ma]

The following code should clearly be in violation of Section 3.8.3 as far as I understand the specs:

Are you referring to the master branch of the specification, or the 3.4 release? In 3.4, I don't think there is any variability requirements on your initial equation. On master, on the other hand, I think we are missing this case of an initial equation, as your equation wouldn't be considered contributing to the solution of k. This, however, looks like exactly the kind of problem that this issue is all about — it would be resolved elegantly if the variability of x was parameter in the initial equation.

[henrikt-ma]

One might also add when initial() as Section 3.8.3 includes

Expressions in the body of a when-clause

as being discrete-time.

I think this one isn't that clear, since initial() isn't in general the only condition triggering a when-clause, but reducing everything to parameter would only make sense for the clause when used during initialization. To me, it would seem better to keep the discrete-time variability for all when-clauses instead of making an exception for the ones triggered by initial() alone.

[gwr-de]

I believe I looked atthe lonked master version given as html.

The problem I am facing is solving for some initial value that needs to be passed as an initialValue parameter for a component (where it sets the start attribute). How to do that with discrete-time variability then?

[henrikt-ma]

The problem I am facing is solving for some initial value that needs to be passed as an initialValue parameter for a component (where it sets the start attribute). How to do that with discrete-time variability then?

I'm afraid there is no good answer to that, but I invide others to prove me wrong. I think you present a good use case that should increase the interest in finding a good resolution to this issue.

[HansOlsson]

Let's get back to the issue.

In section 3.8.3, the variability of expressions inside initial algorithm and initial equation are defined to be discrete-time. Shouldn't they rather be parametric? Since this reduces the level of checking, making the change should not create any backward compatibilities.

I'm unsure what change it would actually cause, can you explain that in more detail?
Is this issue based on some specific problem?

I can understand the historic reasons for making them discrete-time - I believe "initial equation" started out as "when initial()".
Thinking more I can see one additional reason: we generally don't have systems of equations for parameters:
Thus parameter-bindings must acyclical ( https://specification.modelica.org/master/class-predefined-types-and-declarations.html#acyclic-bindings-of-constants-and-parameters ), whereas initial equations can include cyclical equations.
I know it's not a strong argument.

On the other hand I can see some weirdness related to parameters with fixed=false, but I'm not sure this change would be the best solution.

[qlambert-pro]

The specific problem is the one that Guido presented. The change would be to give any expression inside of the body of an initial section variability parametric. It wouldn't pause a problem as far as variability checking goes but as Henrik pointed out, if it did create problems they would be created at initialization.

[gwr-de]

@HansOlsson Is the nature of solving for initial values parametric or discrete-time? I am probably in over my head, but I see at least some significant subset of such problems that I would consider rather parametric. How to declare that?

[HansOlsson]

@HansOlsson Is the nature of solving for initial values parametric or discrete-time? I am probably in over my head, but I see at least some significant subset of such problems that I would consider rather parametric. How to declare that?

Do you mean something like:

  parameter Real p(fixed=false);
  Real x(start=p);                         
initial equation
  p+p^3=9;

I can see a problem here, but to me this seems different than variability and thus I'm not sure that just changing variability will solve that. I recall that we do something extra for cases related to this - but I will have to investigate more.

[sjoelund]

OpenModelica does not do anything special for that case from what I can see. It's just an equation system containing a parameter as unknown.

[qlambert-pro]

I think there seems to be a good rule of thumb between when an expression can be evaluated and its variability, constant expressions are evaluated around flattening, parameter expressions are evaluated at initialization, discrete-time expressions are evaluated at event and the rest are continuous-time. As a result, and although I understand the historic argument, it feels weird that, initial section expressions would be discrete-time rather than parametric.

[henrikt-ma]

OpenModelica does not do anything special for that case from what I can see. It's just an equation system containing a parameter as unknown.

I agree. There is nothing strange about solving for p in that initial equation, as it has the maximum variability in its equation. Then, using it for x.start doesn't seem problematic in any way.

I can see a problem here, but to me this seems different than variability and thus I'm not sure that just changing variability will solve that. I recall that we do something extra for cases related to this - but I will have to investigate more.

Right, we also treat the initialization of x a bit different in this case compared to more simple cases. However, I'd consider the more simple cases just optimized variants of the general case seen here.

[henrikt-ma]

Thinking more I can see one additional reason: we generally don't have systems of equations for parameters:
Thus parameter-bindings must acyclical

As I see it, this is a special feature that comes with using a declaration equation for a parameter. For parameters without a declaration equation I have no expectation of them not ending up in a system of equations.

[HansOlsson]

Well, if you want something more complicated consider:

  parameter Real p3=4;
  parameter Real p2(fixed=false, start=p3);
  parameter Real p(fixed=false, start=p2);
  Real x(start=p, fixed=true);
initial equation 
  p2+p2^3=7+x;
  p+p^3=9+x;
equation 
  der(x)=-x;

In this case Dymola first solve for p, x so that x.start=p ignoring the start-value for p, and then for p2 (using x).

Note: Added fixed=true for x. And the logic is that if a guess-value cannot be computed we ignore it, instead of having a system of equations just for a guess-value.