check model/simulation fails without helpful error message

[Lennart Ochel]

I created an almost flat model out of the flat Modelica code that Dymola generates (Dymola 2014 is needed, because of impure functions).
OpenModelica seems to be unable to flatten this (already very flat) model. If I press "check model" in OMEdit I get the following message:

"Internal error! Check of: test_1 failed with no error message."

[Lennart Ochel]

I am a bit cofued about the ouput that I get. If I run omc .\test_1.mo +s +d=failtrace +locale=en Modelica then the output of the flat code stops at line 1206 of test_1.mo with the following error message: Execution failed!.
If I run omc .\test_1.mos +d=failtrace +locale=en using the following script than the output of the flat code stops one assignment later at line 1207 of test1_.mo with the following error message:
Error: Internal error SimCode: The model test_1 could not be translated

loadModel(Modelica); getErrorString();
loadFile("test_1.mo"); getErrorString();

simulate(test_1); getErrorString();

1. Can anyone explain why this two commands behave different?
2. Anyway, the error message is not that helpful. Can anyone help me to understand the issue?

[Martin Sjölund]

instantiateModel and without +s works just fine. So it is something in the backend.

[Lennart Ochel]

You are right. It was “check model” and not “instantiate model”.

[Adrian Pop]

I'm running a trace now (will take a while), hopefully I'll find the approximate place where it fails.

[Adrian Pop]

Actually running a script:

loadModel(Modelica); getErrorString();
loadFile("test_1.mo"); getErrorString();
checkModel(test_1); getErrorString();

like this:

./omc +showErrorMessages +d=failtrace test_1.mos > trace.txt 2>&1

gets me this:

- BackendDAECreate.statementOutputs failed for 
  P1_enableOut_cumEnablingProb[1:P1_enableOut_nremTAout] := 
    fill(1.0 / /*Real*/(P1_enableOut_nremTAout), P1_enableOut_nremTAout);

- BackendDAECreate.statementOutputs failed for
  if P1_enableOut_sumEnablingProbTAout > 0.0 then
    P1_enableOut_cumEnablingProb[1] := P1_enableOut_enablingProb[P1_enableOut_remTAout[1]] / P1_enableOut_sumEnablingProbTAout;
    for j in 2:P1_enableOut_nremTAout loop
      P1_enableOut_cumEnablingProb[j] := P1_enableOut_cumEnablingProb[j + -1] + P1_enableOut_enablingProb[P1_enableOut_remTAout[j]] / P1_enableOut_sumEnablingProbTAout;
    end for;
  else
    P1_enableOut_cumEnablingProb[1:P1_enableOut_nremTAout] := 
      fill(1.0 / /*Real*/(P1_enableOut_nremTAout), P1_enableOut_nremTAout);
  end if;

So it seems BackendDAECreate.statementOutputs fails if there is a
slice on the left hand side and a function call on the right hand
side.

Cheers,
Adrian Pop/

[Adrian Pop]

Maybe we should add an internal compiler error instead of a failtrace in this case.

[Martin Sjölund]

We really should. Failtrace is not for fatal errors :)

[Lennart Ochel]

Replying to adrpo:

So it seems BackendDAECreate.statementOutputs fails if there is a
slice on the left hand side and a function call on the right hand
side.

Thanks for this first hint. Actually, there is now function BackendDAECreate.statementOutputs. It was moved to CheckModel.mo. Therefore, I changed the message.

[Lennart Ochel]

I created a much small model that has the same issue:

model test_2
  parameter Integer N = 5;
  parameter Integer M = 2;
  Real x[N];
  Integer n;
algorithm
  n:=M;
  x[1:n]:=fill(0.0, n);
  x[n + 1:N]:=fill(1.0, N - n);
end test_2;

Error processing file: test_2.mo
- Static.canonCref failed, cr: x[1:n]
- Static.canonCref failed, cr: x[1 + n:N]
- ComponentReference.expandCref failed on x[1:n]
- CheckModel.statementOutputs failed for   x[1:n] := fill(0.0, n);

CheckModel fails, because ComponentReference.expandCref needs to evaluate the slice (see trace above). This is not possible for any kind of algorithm. If I evaluate the slices by hand, everything is fine (except the c runtime).

Is this really a Backend thing? Who might be the right person to address this?

[Martin Sjölund]

Replying to lochel:

Is this really a Backend thing? Who might be the right person to address this?

CheckModel is a back-end module. So I guess Jens would have been the guy. Now... It's you or Willi? :)

[Lennart Ochel]

I am not ;-)
Why is the a Backend module in the Frontend folder from the compiler?

[Martin Sjölund]

Ask Jens; he added it there :)

[Lennart Ochel]

I have added Jens and Willi.
Well, Jens why is there a Backend module in the Frontend folder? Probably we all have not the same definition for the frontend.
I guess we should restructure this. Only Frontend modules should be part of the Frontend folder. Same for Backend stuff.
Anyway, this does not help for the primary issue. Any constructive input?

[Jens Frenkel]

CheckModel was introduced to avoid changes in the testsuite when someone do something in the BackendCreate module. Because it does nothing else than count the number of variables and equations I added it to the frontend. It is up to you where it will stay.

[Adrian Pop]

Hm, no idea how this can be handled without doing some sort of
evaluation (or at least replace parameters with values in the
algorithm section for the slices).

One idea might be to just consider the entire array as output when you have an array
with a slice on the left hand side (as anyways it does not matter how the different
slices are split, you still output the entire array). I don't think you can have an
array element being an input an another being an output.

[Adrian Pop]

Added Per as he implemented some parts of the array slicing expansion, so he might have some ideas.

[Per Östlund]

Replying to adrpo:

Added Per as he implemented some parts of the array slicing expansion, so he might have some ideas.

The array slicing expansion is not the issue here, the issue is that it's done on something that's not expandable. I think the solution depends on how the equation counting is supposed to handle algorithms, and the specification seems a bit fuzzy on that topic (someone who knows more about these things should probably submit a ticket about this). But Dymola only seems to count whole arrays, i.e. this is fine in Dymola:

model M
  Real x[4];
algorithm
  x[1] := 1;
end M;

Dymola says this model has 4 unknowns and 4 equations, OMC says it has only 1 equation. I think counting the whole arrays is the only sensible soluation, trying to count only those elements which are used is not possible in the general case I think. If we do that, then we don't need to expand any slices.

[Lennart Ochel]

Replying to perost:

Dymola says this model has 4 unknowns and 4 equations, OMC says it has only 1 equation. I think counting the whole arrays is the only sensible soluation, trying to count only those elements which are used is not possible in the general case I think. If we do that, then we don't need to expand any slices.

This seems also not to be a good idea in each case. Just test this in Dymola:

model test
  parameter Integer N = 5;
  parameter Integer M = 2;
  Real x[N];
  Integer n;
algorithm 
  n:=M;
  x[1:n]:=fill(0.0, n);
algorithm 
  x[n + 1:N]:=fill(1.0, N - n);
end test;

This should be fine, but Dymola counts the equations wrong.
If you remove the second "algorithm" keyword, everything works fine in Dymola.

[Martin Sjölund]

Probably warrants a bug-report in ​m:newticket. Spec only says: "The number of equations defined locally (i.e. not in any model or block component), including binding equations, and equations generated from connect-equations. This includes the proper count for when-clauses (see Section 8.3.5), and algorithms (see Section 11.1)", but those sections do not say how to make a proper count (as far as I can tell).

[Per Östlund]

Replying to lochel:

This should be fine, but Dymola counts the equations wrong.
If you remove the second “algorithm” keyword, everything works fine in Dymola.

Actually, if you define the "output" of an algorithm sections as whole variables, then Dymola is correct. Whether or not Dymola's way of counting equations is correct or not is not for me to say, but it seems consistent at least.

Replying to sjoelund.se:

Probably warrants a bug-report in ​m:newticket. Spec only says: "The number of equations defined locally (i.e. not in any model or block component), including binding equations, and equations generated from connect-equations. This includes the proper count for when-clauses (see Section 8.3.5), and algorithms (see Section 11.1)", but those sections do not say how to make a proper count (as far as I can tell).

The equation counting for algorithms is described in 11.1.2, in the big comment or whatever it's supposed to be.

[Martin Sjölund]

Replying to perost:

The equation counting for algorithms is described in 11.1.2, in the big comment or whatever it's supposed to be.

Nowhere does it say known array bounds are treated as the whole variable. So... Yeah :( Legal or not?

algorithm
  x[1] := time;
algorithm
  x[2] := time;

[Lennart Ochel]

Replying to perost:

Replying to lochel:

This should be fine, but Dymola counts the equations wrong.
If you remove the second “algorithm” keyword, everything works fine in Dymola.

Actually, if you define the "output" of an algorithm sections as whole variables, then Dymola is correct. Whether or not Dymola's way of counting equations is correct or not is not for me to say, but it seems consistent at least.

Spec33, section 11.1.2:

[…] Conceptually the algorithm can be viewed as 
(lhs1, lhs2, …) = someFunction(nonLhs1, nonLhs2, …), where lhs are the 
variables assigned and nonLhs are other appearing variables. […]

Therefore, the first algorithms should be treated as (n, x[1:n]) = algorithm1() and the second algorithm should be treated as (x[n+1:N]) = algorithm2(n). I guess there is nothing wrong in the model test above. But Dymola can’t simulate this due to the equation counting.
Anyway, it is not that important how Dymola does the equation counting. But we should get this running as soon as possible (in the case that I did no mistake).

[Martin Sjölund]

Well. We also have the task of making the compliance suite. This seems like a good thing to test to make sure all tools behave the same ;)

[Per Östlund]

Replying to lochel:

Replying to perost:

Replying to lochel:

This should be fine, but Dymola counts the equations wrong.
If you remove the second “algorithm” keyword, everything works fine in Dymola.

Actually, if you define the "output" of an algorithm sections as whole variables, then Dymola is correct. Whether or not Dymola's way of counting equations is correct or not is not for me to say, but it seems consistent at least.

Spec33, section 11.1.2:

[…] Conceptually the algorithm can be viewed as 
(lhs1, lhs2, …) = someFunction(nonLhs1, nonLhs2, …), where lhs are the 
variables assigned and nonLhs are other appearing variables. […]

Therefore, the first algorithms should be treated as (n, x[1:n]) = algorithm1() and the second algorithm should be treated as (x[n+1:N]) = algorithm2(n).

That depends on your definition of "variable". My interpretation would be that variable refers to the whole variable in case of array variables, and not to individual array elements.

[Lennart Ochel]

Well, that's right. My Interpretation is different (but probably wrong...). I have created also this ticket (​https://trac.modelica.org/Modelica/ticket/1190) to get more input for that issue.

[Martin Sjölund]

Replying to perost:

That depends on your definition of "variable". My interpretation would be that variable refers to the whole variable in case of array variables, and not to individual array elements.

And things like... x[1].y[2] become even harder to decide what outputs they define :)

[Lennart Ochel]

I changed the handling of arrays as lhs (locally). This solves my problem but breaks the following models:

Modelica.Electrical.Digital.Examples.DFFREG
Modelica.Electrical.Digital.Examples.DFFREGL
Modelica.Electrical.Digital.Examples.DFFREGSRH
Modelica.Electrical.Digital.Examples.DFFREGSRL
Modelica.Electrical.Digital.Examples.DLATREG
Modelica.Electrical.Digital.Examples.DLATREGL
Modelica.Electrical.Digital.Examples.DLATREGSRH
Modelica.Electrical.Digital.Examples.DLATREGSRL

Probably the MSL needs to be changed a bit (or it's just me...). Unfortunately, I have no precise hint to the corresponding algorithm. But I get two too much equations.

[Lennart Ochel]

Replying to lochel:

Probably the MSL needs to be changed a bit (or it's just me...). Unfortunately, I have no precise hint to the corresponding algorithm. But I get two too much equations.

It is not a MSL issue.
The issue is that the semantic interpretation of algorithms match no longer the “remove simple equations” implementation. If I disable this module, everything works fine (at least for the models that are mentioned above).

[Lennart Ochel]

The error message is still not very helpful. Anyway, it does not occur anymore (for this example), because I fixed the handling of algorithms in r16626.