Array of component: Too many equations.

[Lennart Ochel]

I need to create an array of PC components, similar to the minimal example below. When doing so, OpenModelica reports 142 equations and 126 variables.

model test
  inner PNlib.Settings settings annotation(Placement(visible = true, transformation(origin = {-30, 30}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
  PNlib.PC P1[2] annotation(Placement(visible = true, transformation(origin = {0, 0}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
  annotation(uses(PNlib(version = "1.4")));
end test;

[Lennart Ochel]

I just added an inner Settings component to the example to get rid of the warnings.

[Lennart Ochel]

It seems that there are some algorithm sections, which have too many output variables. This is the corresponding declaration within model PC:

  Blocks.enablingInCon enableIn(…);
  Blocks.enablingOutCon enableOut(…);

[Lennart Ochel]

The wrongly detected output variables are the following ones, which are declared as protected within the block definition:

P[2].enableOut.cumEnablingProb[1]
P[2].enableOut.cumEnablingProb[2:P[2].enableOut.nremTAout]
P[2].enableOut.TEout[P[2].enableOut.posTE]

P[2].enableIn.cumEnablingProb[1]
P[2].enableIn.cumEnablingProb[2:P[2].enableIn.nremTAin]
P[2].enableIn.TEin[P[2].enableIn.posTE]

P[1].enableOut.cumEnablingProb[1]
P[1].enableOut.cumEnablingProb[2:P[1].enableOut.nremTAout]
P[1].enableOut.TEout[P[1].enableOut.posTE]

P[1].enableIn.cumEnablingProb[1]
P[1].enableIn.cumEnablingProb[2:P[1].enableIn.nremTAin]
P[1].enableIn.TEin[P[1].enableIn.posTE]

[Lennart Ochel]

And this is what the algorithm statements look like, that are used to determine the outputs:

P[2].enableOut.cumEnablingProb[1] := {}[{}[1]] / P[2].enableOut.sumEnablingProbTAout;
P[2].enableOut.cumEnablingProb[2:P[2].enableOut.nremTAout] := {}[-1 + (2:P[2].enableOut.nremTAout)] + {}[{}[2:P[2].enableOut.nremTAout]] / P[2].enableOut.sumEnablingProbTAout;
[…]

[Adrian Pop]

I did a bit more investigation and I know what the problem is, but not yet how to fix it.
The problem is that if we have an array of components the algorithmOutputs function is given DAE.NOT_EXPAND so it does no expansion of the crefs. Because it does no expansion it comes up with 16 outputs instead of 12:

16: // bad outputs
 P[1].enableIn.arcWeightSum,
 P[1].enableIn.nremTAin,
 P[1].enableIn.nTAin,
 P[1].enableIn.sumEnablingProbTAin,
 P[1].enableIn.cumEnablingProb[1],
 P[1].enableIn.cumEnablingProb[2:P[1].enableIn.nremTAin],
 P[1].enableIn.randNum,
 P[1].enableIn.state128,
 P[1].enableIn.endWhile,
 P[1].enableIn.k,
 P[1].enableIn.posTE,
 P[1].enableIn.TEin[P[1].enableIn.posTE],
 P[1].enableIn.state128[1],
 P[1].enableIn.state128[2],
 P[1].enableIn.state128[3],
 P[1].enableIn.state128[4]}

Correct outputs:

12: // correct outputs
{P1.enableIn.arcWeightSum,
 P1.enableIn.nremTAin,
 P1.enableIn.nTAin,
 P1.enableIn.sumEnablingProbTAin,
 P1.enableIn.randNum,
 P1.enableIn.state128[1],
 P1.enableIn.state128[2],
 P1.enableIn.state128[3],
 P1.enableIn.state128[4],
 P1.enableIn.endWhile,
 P1.enableIn.k,
 P1.enableIn.posTE}

It seems the problem appears when one replaces the index in the for loop with the range of the for loop and it does not expand the crefs. However, if the crefs are expanded that is not correct also as you will get 24 instead of 12 outputs, for both P[1] and P[2].

[Martin Sjölund]

Milestone moved to 1.12.0 due to 1.11.0 already being released.

[Francesco Casella]

Milestone moved to 1.13.0 due to 1.12.0 already being released.

[Francesco Casella]

Updated test case to work with PNLib 1.4

model test
  inner PNlib.Components.Settings settings annotation(Placement(visible = true, transformation(origin = {-30, 30}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
  PNlib.Components.PC P1[2] annotation(Placement(visible = true, transformation(origin = {0, 0}, extent = {{-10, -10}, {10, 10}}, rotation = 0)));
  annotation(uses(PNlib(version = "1.4")));
end test;

[Francesco Casella]

With the NF, we now get

[2] 09:39:00 Symbolic Error
The given system is mixed-determined.   [index > 3]
Please checkout the option "--maxMixedDeterminedIndex".

There is probably something wrong in the way the DAE structure is built.

[Per Östlund]

Replying to casella:

With the NF, we now get

[2] 09:39:00 Symbolic Error
The given system is mixed-determined.   [index > 3]
Please checkout the option "--maxMixedDeterminedIndex".

There is probably something wrong in the way the DAE structure is built.

I'm not sure that's the NF's fault. checkModel reports that the model is balanced when using the NF, while it has too many equations when using the OF. So I'm going to assume this is a backend issue unless someone convinces me otherwise.