Provide support for start-value selection according to the Modelica Specification

[Francesco Casella]

The Modelica Specification, section 8.6.2, provides a non-normative procedure to select start values in case of alias variables. This requires the front-end to produce a confidence number based on the level at which the start value is set or modified.

I understand from @ptauber that this number is not available in the back-end, so the selection is based on the cref depth instead.

It would be nice if this information was computed by the new front end, so it could be used by the back-end.

[Per Östlund]

The new frontend already keeps track of how many components a modifier has been propagated through, in order to be able to handle arrays without expanding them. We can also calculate the level a component is on by simply going up the instance tree, so we already have the means to calculate this confidence number if we want. It's a bit unclear how to handle a start value that comes from a type declaration though.

Note to self: It's probably more efficient to let each modifier and component keep track of its level, and calculate the difference when we need it for array handling. Then we don't need to update the modifiers for each level like we do now.

[Francesco Casella]

Replying to perost:

The new frontend already keeps track of how many components a modifier has been propagated through, in order to be able to handle arrays without expanding them. We can also calculate the level a component is on by simply going up the instance tree, so we already have the means to calculate this confidence number if we want.

Please go ahead then. When the new front-end goes mainstream, @ptaeuber can use it in the back-end.

It's a bit unclear how to handle a start value that comes from a type declaration though.

In fact, that was also my question when I re-read the specification. From an end-user perspective, start values coming from type declarations should have lower confidence than those coming from applying modifiers, because type declarations normally contain general-purpose defaults, which are then overridden by applying more or less local modifications. You could give them a high value, say 100.

And, if this is shown to work fine, we could improve the Modelica specification for the next release. If I recall correctly, the current text was proposed by Sven Erik Mattsson and used as a base for Dymola's implementation, but it may be incomplete from this point of view.

Note to self: It's probably more efficient to let each modifier and component keep track of its level, and calculate the difference when we need it for array handling. Then we don't need to update the modifiers for each level like we do now.

[Patrick Täuber]

To determine a confidence number in the Backend, currently the minimum between the cref depth of the variable itself and the cref depth of the start value (if it is a cref) is taken.
Another point is, that the value of the selected alias variable (the variable, that is selected to remain in the system) is always preferred, even if other alias variables have a less depth. I am not sure why this is done, because this prevents e.g. the following model Test from being handled as expected:

model squared
  Real x (start=3);
  Real y (start=3);
equation
  x*y = 9;
  x = y;
end squared;

model Test
  squared S (y(start=p));
  parameter Real p=-3;
equation
end Test;

Here the start value x=y=3 is chosen, instead of -3.
I think, removing this rule should fix it, so that this criteria is good enough until the new Frontend is finished.

[Francesco Casella]

Lennart, Karim, Andreas, this is a potentially critical issue for many libraries with difficult initialization problems. I understand there may be some need of further improvements also on the Modelica specification (I get many unexpected warnings of conflicting start attributes in Dymola, where I would expect none), but it would be nice to start implementing what is written there.

Could you please at least have a look and report?

Thanks!

[Francesco Casella]

Releasing 1.14.0 which is stable and has many improvements w.r.t. 1.13.2. This issue is rescheduled to 1.16.0

[Francesco Casella]

Retargeted to 1.17.0 after 1.16.0 release

[Francesco Casella]

Retargeted to 1.18.0 because of 1.17.0 timed release.

[Francesco Casella]

Ticket retargeted after milestone closed