Error due to bogus dynamic state selection

[Francesco Casella]

Please consider the attached test case. During compilation, OMC generates the following error

Error: Internal error It is not possible to select continues states because Number of equations 203 greater than number of States 197 to select from

The model compiles and runs correctly in Dymola. It has two potential state variables with stateSelect.prefer attribute; one is eliminated by the dummy derivatives method, and the only remaining one, which can definitely be selected statically is pipeToCoolingTower.htilde[1].

• Why is this error generated?
• What does "Number of equations greater than number of states to select from" mean? Which set of equations is the message referring to? Please improve the clarity of the error message. Also note that the correct spelling of "continues" is "continuous"
• More specifically, why trying (and failing) dynamic state selection among 197 potential states, for a model that has a very obvious static state selection?

[Francesco Casella]

Test case

[Francesco Casella]

I have performed some further analyis. The problem is caused by the cooling tower model, that has a stateSelect.prefer on some state variables, but that is optionally reduced to purely algebraic model by setting staticModel = true.

Something like

model M
  Real x(stateSelect = StateSelect.prefer);
  Real u;
  Boolean static = true;
equation
  u = sin(time);
  if static then
    der(x) = -x + u; 
  else
    0 = -x + u;
  end if;
end M;

In this case, there are actually no der() operators at all in the model, but there are some variables with StateSelect.prefer. Apparently, the current state selection algorithm tries hard to select these variables as states, and it obviously fails, because there are not enough differential equations. However, this should not cause an error, because StateSelect.prefer means that the variable should preferably be used as state, but not necessarily; that would be StateSelect.always. As far as I understand, models as the attached one are perfectly legal and well-posed.

The workaround is to set the proper StateSelect attribute based on the static/dynamic mode, as in

model Mfix
  Real x(if static then stateSelect = StateSelect.default else StateSelect.prefer);
  Real u;
  Boolean static = true;
equation
  u = sin(time);
  if static then
    0 = -x + u; 
  else
    der(x) = -x + u;
  end if;
end Mfix;

This modification makes it possible to run the attached model in OpenModelica. However, I think it would be good if the state selection algorithm was able to also handle models like the attached one without the workaround, just in case.

[Francesco Casella]

Milestone moved to 1.13.0 due to 1.12.0 already being released.

[Jens Frenkel]

If a variable is modified with stateSelect=StateSelect.prefer the index reduction consider this variables as potential states. Since it is not possible to decide before index reduction and state selection if a potential state is a state or only an algebraic variable (at least there is no procedure known to the developer how to do it) all potential states lead to differentiation of statements (Pantelides Algorithm).
Then the state selection algorithm have to detect the real states of the system. All other potential states became algebraic variables.
After sorting the statements of the system in BLT form (Tarjan's algorithm) the superfluous statements from differentiation can be removed from the system very simple because all variables of the block are derivatives from differentiation and modified to algebraic variables. In addition those blocks are not used to calculate derivatives or variables for results. This is since a long time the state of the implementation. One difficult issue with this procedure is for example a not differentiable function call in an statement of a pure algebraic loop marked for differentiation from Pantelides Algorithm.

[Francesco Casella]

Rescheduled to 1.14.0 after 1.13.0 releasee

[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