NF leads to mixed-determined initialization system

[Francesco Casella]

Please check the ​ScalableTestSuite.Electrical.BreakerCircuits.Verification.BreakerNetworkDelayed_3_Array. The compilation with the NF fails with this error message:

Error: The given system is mixed-determined.   [index > 3]
Please checkout the option "--maxMixedDeterminedIndex".
Error: No system for the symbolic initialization was generated

I compared the flattened models with the old FE and with the NF. The equations are all equivalent; the only differences I could spot are the issue already reported in #4858 (but this model breaks earlier than that), and the fact that the when clause

  when pre(open) then
    G = Gopen;
    Modelica.Utilities.Streams.print("Breaker " + name + " opens at time = "+String(time));
  end when;

is flattened as

  when pre(B[1].open) then
    B[1].G = B[1].Gopen;
    Modelica.Utilities.Streams.print("Breaker " + B[1].name + " opens at time = " + String(time, 0, true, 6), "");
  end when;

by thee old FE and as

  when pre(B[1].open) then
    Modelica.Utilities.Streams.print("Breaker " + B[1].name + " opens at time = " + String(time, 6, 0, true), "");
    B[1].G = B[1].Gopen;
  end when;

by the NF. Note in particular that String(time) is rendered as String(time, 0, true, 6) by the old FE and as String(time, 6, 0, true) by the NF. I'm not sure why this transformation is performed at all, and wheether this is relevant for the reported error, but I couldn't find any other difference.

I also compared the dumpdaelow output in the two cases, but I couldn't find any additional difference either.

I read in #4451 that " Mixed-determined means that the initialization problem is under- and over-determined at the same time". This system has one continuous state, several discrete Real and Boolean states, and three fixed = false parameters, which are all initialized either by setting fixed = true or by simple assignment-like initial equations, which look exactly the same in the two dumpdaelow's, so I can't really understand where the problem could be.

[Per Östlund]

Replying to casella:

Note in particular that String(time) is rendered as String(time, 0, true, 6) by the old FE and as String(time, 6, 0, true) by the NF. I'm not sure why this transformation is performed at all, and wheether this is relevant for the reported error, but I couldn't find any other difference.

The reason for the transformation is that String of Real is defined in the specification as either String(r, significantDigits = 6, <options>) (with the options being minimumLength = 0 and leftJustified = true) or String(r, format = s), where the default values of both are chosen such that they both produce the same result no matter which one is chosen for String(r).

We select the String(r, significantDigits = 6, <options>) form when only one argument is given. In this case it looks like the old frontend is actually wrong, since it has switched the order of significantDigits and <options> for some reason. The order of the parameters looks correct in Static.elabBuiltinString, so I will have to investigate why it gets messed up like that.

[Francesco Casella]

In fact, I did search for the "String(" string in the specification but missed the definition of the predefined function. Now I get it, page 20 :)

[Per Östlund]

The String issue in the old frontend is fixed in 7dd0320a, so that everything including code generation uses the same argument order as the new frontend. As expected that didn't solve the mixed-determined issue, but it would have resulted in compilation errors or the wrong result from String if the model got that far.

[Per Östlund]

The mixed-determined issue is most likely caused by some start values and bindings not being prefixes correctly, e.g. G[1].T gets the binding G.T_ref instead of G[1].T_ref. This is basically the same issue as the start value type mismatch problem that plagues a lot of models, even though it might not look like it.

The way we currently handle bindings is by keeping track of which instance level they come from, but this works poorly for component modifiers, worse for class modifiers and completely breaks down when the binding is used as an expression (for example as a dimension). I've been thinking a lot about how to solve this lately since it's the cause of a lot of different issues, and will make it my priority for the next week.

[Francesco Casella]

Replying to perost:

The mixed-determined issue is most likely caused by some start values and bindings not being prefixes correctly, e.g. G[1].T gets the binding G.T_ref instead of G[1].T_ref. This is basically the same issue as the start value type mismatch problem that plagues a lot of models, even though it might not look like it.

I guess #4866 may also be relevant then.

[Per Östlund]

Replying to casella:

Replying to perost:

The mixed-determined issue is most likely caused by some start values and bindings not being prefixes correctly, e.g. G[1].T gets the binding G.T_ref instead of G[1].T_ref. This is basically the same issue as the start value type mismatch problem that plagues a lot of models, even though it might not look like it.

I guess #4866 may also be relevant then.

Or rather #4815, since #4866 was a duplicate of it.

[Francesco Casella]

The model now fails because of

Error: Too many equations, over-determined system. 
The model has 89 equation(s) and 77 variable(s).

the root cause is probably the same as #4874

[Per Östlund]

Replying to casella:

The model now fails because of

Error: Too many equations, over-determined system. 
The model has 89 equation(s) and 77 variable(s).

the root cause is probably the same as #4874

No, the issue is still the same as before, e.g. G[1].T gets the binding G.T_ref instead of G[1].T_ref. I don't know why the model is unbalanced though, since G[1].T is a parameter, but it's not due to #4874 since the model contains neither records nor function calls. So this is a separate issue as far as I can see.

[Francesco Casella]

Aha, sorry, I did not actually flatten the model to double-check.

I guess there is anyway something fishy in the binding G[1].T = G.T_ref, since the left-hand side is Real and the right-hand side is Real[4].

It seems like the back-end is somehow expanding these bogus bindings by assigning to the left-hand-side variable each scalar value of the right-hand-side in a separate equation.
In fact, if you consider that there are four such bindings, and each involves four parameters instead of one, you have 4 X 3 = 12 equations in excess, which is precisely the difference between 89 equations and 77 variables reported by the compiler.

Of course it is necessary to fix the binding in the front-end, but I guess getting some proper type error from the back-end instead of an overdetermined system of equations would also be nice.

[Per Östlund]

Fixed in 598e515, the model now simulates successfully.