Number of equations are not determined correctly

[Christian Kral <dr.christian.kral@…>]

I ran into troubles with my students simulating a short circuit test of quasi static transformer. Please consider the attached package Transformers. It includes two examples, SC1 and SC2. The only difference between the two examples is one connect statement:

SC1:

  connect(currentSensor1.pin_p, voltageSensor1.pin_n);

SC2:

  connect(currentSensor1.pin_p, ground2.pin);

Those two connects shall be treated equally, since in SC1 the negative pin of the voltage sensor is also connected to ground2 (same potential). Consequently, the (number of) equations in SC1 are not determined correctly.

However, the check of SC1 leads to the following message:

Check of Transformer.SC1 completed successfully.
Class Transformer.SC1 has 293 equation(s) and 292 variable(s).
183 of these are trivial equation(s).

SC1 cannot be simulated and returns an error message:

[1] 10:02:20 Translation Error
Internal error Circular Equalities Detected for Variables:
powerSensor1.currentP.reference.gamma
powerSensor1.currentN.reference.gamma
----------------------------------
currentSensor1.pin_n.reference.gamma
powerSensor1.currentN.reference.gamma
----------------------------------
currentSensor1.pin_p.reference.gamma
currentSensor1.pin_n.reference.gamma
----------------------------------
currentSensor1.pin_p.reference.gamma
powerSensor1.voltageN.reference.gamma
----------------------------------
powerSensor1.voltageP.reference.gamma
powerSensor1.voltageN.reference.gamma
----------------------------------
powerSensor1.currentP.reference.gamma
powerSensor1.voltageP.reference.gamma
----------------------------------


[2] 10:02:20 Symbolic Error
Too many equations, over-determined system. The model has 293 equation(s) and 292 variable(s).

[3] 10:02:20 Translation Error
Internal error Transformation Module PFPlusExt index Reduction Method Pantelides failed!

SC2 compiles with no complaints; the model check results are:

Check of Transformer.SC2 completed successfully.
Class Transformer.SC2 has 292 equation(s) and 292 variable(s).
182 of these are trivial equation(s).

This issue occurs under Windows and Linux with version OpenModelica 1.9.4~dev-675-gb524b08.

[Christian Kral <dr.christian.kral@…>]

Demonstration examples SC1 and SC2

[Adrian Pop]

I think this is an issue with the overconstrained connection graph. I guess we treat the graph differently depending on the different connects. I'll have a look.

[Martin Sjölund]

Milestone pushed to 1.9.5

[Martin Sjölund]

Milestone renamed

[Adrian Pop]

Overconstrained connection graph handling for Transformer.SC1 model

[Adrian Pop]

Overconstrained connection graph handling for Transformer.SC2 model

[Adrian Pop]

The overconstrained connection graph is broken differently for the too models, see the attached SVGs. I created a ticket on the Modelica Trac about heuristics to break the overconstrained connection graph and it generated no discussion: ​https://trac.modelica.org/Modelica/ticket/432
and it was closed recently.

I created the svgs via Transformer.mos script:

loadModel(Modelica); getErrorString();
loadFile("Transformer.mo"); getErrorString();
checkModel(Transformer.SC1); getErrorString();
checkModel(Transformer.SC2); getErrorString();

using omc from command line:

omc +locale=C +d=cgraphGraphVizFile Transformer.mos

This generates .gv files (GraphView) that you can then translate to SVG via:

dot -Tsvg Transformer.SC1.gv -o Transformer.SC1.svg

@Christian, can you check the two graphs to see if we have any obvious errors in the overconstrined connection graph handling?

As far as I can tell the problem is that in the first model SC1 we break the connection graph for two edges of ground2.pin.reference and in the SC2 only for one edge!

[Adrian Pop]

Basically the two models generate the same DAE but with some differences:

.txt

@@ -101 +101 @@
   output ComplexVoltage res;
 end Modelica.SIunits.ComplexVoltage;
 
-class Transformer.SC1
+class Transformer.SC2
   Real powerSensor2.currentP.v.re(quantity = \"ElectricPotential\", unit = \"V\");
   Real powerSensor2.currentP.v.im(quantity = \"ElectricPotential\", unit = \"V\");
   Real powerSensor2.currentP.i.re(quantity = \"ElectricCurrent\", unit = \"A\");
@@ -432 +432 @@
 equation
   {} = Modelica.Electrical.QuasiStationary.Types.Reference.equalityConstraint(singlePhaseTransformerQS1.conductor.pin_p.reference, singlePhaseTransformerQS1.inductorh.pin_p.reference) \" equation generated by overconstrained connection graph breaking\";
   {} = Modelica.Electrical.QuasiStationary.Types.Reference.equalityConstraint(singlePhaseTransformerQS1.inductor1.pin_n.reference, singlePhaseTransformerQS1.idealTransformer.pin_p1.reference) \" equation generated by overconstrained connection graph breaking\";
+  {} = Modelica.Electrical.QuasiStationary.Types.Reference.equalityConstraint(powerSensor1.currentN.reference, currentSensor1.pin_n.reference) \" equation generated by overconstrained connection graph breaking\";
   {} = Modelica.Electrical.QuasiStationary.Types.Reference.equalityConstraint(powerSensor1.currentP.reference, powerSensor1.voltageP.reference) \" equation generated by overconstrained connection graph breaking\";
-  {} = Modelica.Electrical.QuasiStationary.Types.Reference.equalityConstraint(voltageSensor1.pin_n.reference, ground2.pin.reference) \" equation generated by overconstrained connection graph breaking\";
   {} = Modelica.Electrical.QuasiStationary.Types.Reference.equalityConstraint(currentSensor1.pin_p.reference, voltageSensor1.pin_p.reference) \" equation generated by overconstrained connection graph breaking\";
   {} = Modelica.Electrical.QuasiStationary.Types.Reference.equalityConstraint(singlePhaseTransformerQS1.pin_n2.reference, ground2.pin.reference) \" equation generated by overconstrained connection graph breaking\";
   {} = Modelica.Electrical.QuasiStationary.Types.Reference.equalityConstraint(voltageSensor2.pin_p.reference, powerSensor2.currentN.reference) \" equation generated by overconstrained connection graph breaking\";
@@ -680 +680 @@
   powerSensor1.currentP.v.re = singlePhaseTransformerQS1.pin_p2.v.re;
   powerSensor1.currentP.v.im = powerSensor1.voltageP.v.im;
   powerSensor1.currentP.v.im = singlePhaseTransformerQS1.pin_p2.v.im;
-  currentSensor1.pin_n.reference.gamma = powerSensor1.currentN.reference.gamma;
   currentSensor1.pin_n.v.re = powerSensor1.currentN.v.re;
   currentSensor1.pin_n.v.im = powerSensor1.currentN.v.im;
   powerSensor2.currentN.v.re = singlePhaseTransformerQS1.pin_p1.v.re;
@@ -694 +693 @@
   currentSensor2.pin_p.v.im = powerSensor2.voltageP.v.im;
   currentSensor2.pin_n.v.re = voltageSource1.pin_p.v.re;
   currentSensor2.pin_n.v.im = voltageSource1.pin_p.v.im;
-end Transformer.SC1;
+end Transformer.SC2;
 "
 ""

[Adrian Pop]

The difference is that we generate the equation:

currentSensor1.pin_n.reference.gamma = powerSensor1.currentN.reference.gamma;

in plus for SC1 which is actually a broken connect in SC2.
We should however have removed another equation instead which doesn't seem to happen.
I'll check which one we fail to remove.

[Adrian Pop]

Hm, for each broken connect we add an equalityConstraint equation. The only difference is that in the case of SC1 we have two equalityConstraint for the same variable, ground2.pin.reference :

  {} = Modelica.Electrical.QuasiStationary.Types.Reference.equalityConstraint(voltageSensor1.pin_n.reference, ground2.pin.reference) \" equation generated by overconstrained connection graph breaking\";
  {} = Modelica.Electrical.QuasiStationary.Types.Reference.equalityConstraint(singlePhaseTransformerQS1.pin_n2.reference, ground2.pin.reference) \" equation generated by overconstrained connection graph breaking\";

I'll check the specification again regarding the overconstrained connection graph, maybe I missed something.

[Adrian Pop]

Hm, I think I found the bug, we get for SC1 equation:

currentSensor1.pin_p.reference.gamma = ground2.pin.reference.gamma;

but there is no connect equation:

connect(currentSensor1.pin_p, ground2.pin);

in the SC1 model!
I'll do some debugging to find where this equation comes from.

[Adrian Pop]

Fixed in e74ce8c4fab3beeda583e7e5d82adad4c8e49cc7/OMCompiler.
The problem was that I removed the component references form the connection set for the broken connects but in some special cases one needs to split the connection set otherwise you get extra equations that should not be there.

[Adrian Pop]

Added the attached model as a test in:
6a1618d0ba481218af26c8a07a72a6f608683c3d/OpenModelica-testsuite.

[Martin Sjölund]

Milestone deleted