Count number of equations correctly when using inner/outer variables in algorithm

[Jan Kokert]

I recently became familiar with the inner/outer statement which is basically a global variable and will prevent your hierarchical models from too many connectors.
But unfortunatally, it seems that OM does not correctly count the number of equations in conjunction with the inner/outer statement in an algorithm.

For consolidation please check the following model.

package TestAlg
  model Top
    inner Real a;    
    Sub1 s1;
    
  initial algorithm
      a := 0;      
    
  algorithm
    when time > 1 then
      a := 1;
    end when;
  end Top;

  
  model Sub1
    outer Real a;    
  algorithm
    when time > 2 then
      a := 2;
    end when;
  end Sub1;

end TestAlg;

It will result in an error message, that there are too many equations defined. To verify that the multiple algorithms ok, you can move lines 19..21 into the top model.

This issue could be related to #4138 (Lookup and Modifiers). I appreciate a feedback if this is really a defect or if it is just not intended by the MSL specification and if you could fix it soon. Thanks!

[Jan Kokert]

Actually, Dymola is complaining in the same manner, that there are too many equations. But how can I then realized the decentralized writing to status signals? And please note, the two when blocks do not contradict each other and are valid when both are in the same model. I would be very grateful for a feedback!

[Adrian Pop]

Seems we don't apply the inner/outer properly inside the when algorithm statements.

adrpo33@ida-0030 MINGW64 /c/home/adrpo33/dev/OMTesting/bugs/4365
$ ~/dev/OpenModelica/build/bin/omc t.mo +i=TestAlg.Top
class TestAlg.Top
  Real a;
initial algorithm
  a := 0.0;
algorithm
  when time > 2.0 then
    s1.a := 2.0;
  end when;
algorithm
  when time > 1.0 then
    a := 1.0;
  end when;
end TestAlg.Top;

It should be a not s1.a in the flattened code.
I will check why this happens.

[Adrian Pop]

Fixed the inner/outer prefixing in algorithms with 935a1c/OMCompiler.
Added test in 3c3326/OpenModelica-testsuite.

However the model does not work as you get separate algorithm sections each containing one when statement. You would need one algorithm section only with two when statements in order for it to make it work in this fashion, but that is not supported by the Modelica standard (yet). I'll open a ticket about this on the Modelica Trac to see what others think about this.

[Adrian Pop]

With a8b251/OMCompiler I added a flag that activates an experimental functionality which merges all algorithm sections in the model into just one (one for initial, one for normal) which makes your model compile.

Activate the experimental feature with -d=mergeAlgSections. Note that I have no idea if this works properly with models that do not need this feature.

[Lennart Ochel]

I think this model has actually more equations than variables and that we should not try to merge algorithm sections.

[Adrian Pop]

@lochel: of course, each algorithm section is seen as a function with inputs / outputs which makes the system unbalanced in this case. I added the merging as an experimental unsupported feature.

It is a bit strange that if you have 2 algorithm sections vs one algorithm section with 2 statements the interpretation is different, even if I understand why is like that.

[Jan Kokert]

Dear developers,

I really appreciate that the issue is fixed now.

For me, it is very intuitive that my code should work. If I got it correctly, for each variable there must be exactly one equation OR at least one algorithm. Two algorithm sections in one model work fine. So why can't we split the code into two models? And as inner/outer is a reference mechanism it should understand that both algorithms actually modify the SAME value.

Merging the algorithm sections is a very straight forward approach. Actually, I can't think of any example, where this will end up in problems. To be on the safe side, the experimental flag seems to be a very good solution.

@adrpo: Is the ticket in Modelica trac open already? Can we vote there?

[anonymous]

Replying to janK:

Actually, Dymola is complaining in the same manner, that there are too many equations. But how can I then realized the decentralized writing to status signals? And please note, the two when blocks do not contradict each other and are valid when both are in the same model. I would be very grateful for a feedback!

To have decentralized monitoring of the program status I suppose you can define a Record of flags to pass to inner models through the inner/outer schema.
Each model writes through a single when to his flag(s) (I think in that case you don't need to do this in an algorithm section, you can do it in an equation section).
Maybe you can add a discrete status variable to that Record, which in a when final() manages to combine the individual flags into a unique indicator.

[Jan Kokert]

Hi, Thank you for your contribution! The idea of packing all flags into one record is a clear way of modeling. I will do that.
However, when I wrap my variable in a record and pass the record via inner/outer to the different models with different algorithm (or equation) sections, I get the same result and the same error message.

What is the meaning of final() - do you mean terminal()? I only know final to basically define a constant.

[anonymous]

Replying to janK:

Hi, Thank you for your contribution! The idea of packing all flags into one record is a clear way of modeling. I will do that.
However, when I wrap my variable in a record and pass the record via inner/outer to the different models with different algorithm (or equation) sections, I get the same result and the same error message.

Ehm... I did not try my suggestion. I hope it is not totally useless.

I was thinking to adrpo's idea of combining all algorithms into one. It seems to me that the drawback of a general adoption of this is because "any algorithm section is treated as a function with n outputs", and "the calling of a function with n output arguments is treated as n implicit equations, where every equation depends on all output and on all input arguments". (from the Modelica association's Modelica tutorial).

If the language had some way of specifying when to combine algorithm sections... but proposing to add a new keyword to the language is, I think, overkill for this problem.

What is the meaning of final() - do you mean terminal()? I only know final to basically define a constant.

Yes, I meant terminal().

[Jan Kokert]

Hi! I'm not perfectly convinced by

any algorithm section is treated as a function with n outputs

from the tutorial.

Shouldn't it be (just my intuition):

any when clause in an algorithm section in a model is treated as a function with n outputs?

(As there are no when clauses in a function allowed)

If that is the case, then merging the algorithms should not be a drawback, right?