Opened 8 years ago
Last modified 5 years ago
#4050 new defect
Array of component: Too many equations.
Reported by: | lochel | Owned by: | lochel |
---|---|---|---|
Priority: | critical | Milestone: | 2.0.0 |
Component: | Backend | Version: | |
Keywords: | PNlib | Cc: | adrpo, sjoelund.se, perost, mahge930 |
Description (last modified by lochel)
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;
Change History (10)
comment:1 Changed 8 years ago by lochel
- Description modified (diff)
comment:2 Changed 8 years ago by lochel
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(…);
comment:3 Changed 8 years ago by lochel
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]
comment:4 Changed 8 years ago by lochel
- Cc mahge930 added
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; […]
comment:5 Changed 8 years ago by adrpo
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].
comment:6 Changed 7 years ago by sjoelund.se
- Milestone changed from 1.11.0 to 1.12.0
Milestone moved to 1.12.0 due to 1.11.0 already being released.
comment:7 Changed 6 years ago by casella
- Milestone changed from 1.12.0 to 1.13.0
Milestone moved to 1.13.0 due to 1.12.0 already being released.
comment:8 Changed 5 years ago by 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;
comment:9 follow-up: ↓ 10 Changed 5 years ago by casella
- Component changed from Frontend to New Instantiation
- Milestone changed from 1.13.0 to 2.0.0
- Owner changed from somebody to perost
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.
comment:10 in reply to: ↑ 9 Changed 5 years ago by perost
- Component changed from New Instantiation to Backend
- Owner changed from perost to lochel
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.
I just added an inner Settings component to the example to get rid of the warnings.