Problem with PFPlusExt Pantelides algorithm

[Francesco Casella]

The model ThermoPower.Examples.HRB.Simulators.OpenLoopSimulator in the testsuite generates the following errors

Error: Model is structurally singular, error found sorting equations
<...>
Error: Internal error Transformation Module PFPlusExt index Reduction Method Pantelides failed!

The model works fine in Dymola. There are other 10 models in the library that lead to the same error, so probably solving this one would also solve the other ones.

Also, how can I try compiling the code with other matching algorithms, either from OMEdit or from the command line?

[Adrian Pop]

Running omc without parameters or with +help gives you:

      +matchingAlgorithm     Sets the matching algorithm to use. See 
                              +help=optmodules for more info.
                               Valid options:
                                * BFSB
                                * DFSB
                                * MC21A
                                * PF
                                * PFPlus
                                * HK
                                * HKDW
                                * ABMP
                                * PR
                                * DFSBExt
                                * BFSBExt
                                * MC21AExt
                                * PFExt
                                * PFPlusExt
                                * HKExt
                                * HKDWExt
                                * ABMPExt
                                * PRExt

[Francesco Casella]

Replying to adrpo:

Running omc without parameters or with +help gives you:

      +matchingAlgorithm     Sets the matching algorithm to use. See 
                              +help=optmodules for more info.
                               Valid options:
                                * BFSB
                                * DFSB
                                * MC21A
                                * PF
                                * PFPlus
                                * HK
                                * HKDW
                                * ABMP
                                * PR
                                * DFSBExt
                                * BFSBExt
                                * MC21AExt
                                * PFExt
                                * PFPlusExt
                                * HKExt
                                * HKDWExt
                                * ABMPExt
                                * PRExt

OK. But I have been warned that the optmodules "should be applied in the correct order" and I am bit clueless about that

[Lennart Ochel]

Changing the matching algorithm does not affect the opt-module at all. So you can just try it out as Adrian proposed. Anyway, I will have a look too.

[Francesco Casella]

Save Total file with complete definition of reduced-order model

[Francesco Casella]

I have tried many different matching algorithms, but they all fail because of Pantelides. Unfortunately the diagnostic message is not very informative, as it just tells me that a big bunch of equations is singular, but doesn't point to any possible root cause.

I have prepared a reduced-order version of the model for easier analysis, you can get it by loading the attached file.

Please:

• have a look at the problem
• if possible improve the diagnostic message with more useful information for the modeller to help fix the problem

[Francesco Casella]

You may start your analysis from this other model:

ThermoPower.Test.DistributedParameterComponents.TestGasFlow1DFV_A

which gives this much simpler error message:

Error: Model is structurally singular, error found sorting equations 
 1: hex.dddX[1] = 0.0;
 for variables 
 hex.dddX[1,1](1)}}
Error: Internal error Transformation Module PFPlusExt index Reduction
Method Pantelides failed!

I cannot really see what's wrong with that equation.

[Martin Sjölund]

hex.dddx[1] does not exist. It seems the flattened equation: hex.dddX[1,:] = ThermoPower.Gas.Flow1DFV.Medium.density_derX(hex.gas[1].state); loses the second index when the back-end performs some transformation. I guess Lennart can pinpoint and fix it ;)

[Lennart Ochel]

This is a problem of the pre-optimization module >>inlineArrayEqn<<.

[Lennart Ochel]

The pre-opt module transforms the following equations (left) into the right ones:

hex.dddX[2,:] = {0.0} -> hex.dddX[1] = 0.0
hex.dddX[3,:] = {0.0} -> hex.dddX[1] = 0.0
hex.dddX[4,:] = {0.0} -> hex.dddX[1] = 0.0
...

Hence, the system becomes singular.

[Francesco Casella]

I tried the following test case, which should capture all the features of the example, but it works just fine:

model TestArray
  parameter Integer N = 3;
  parameter Integer nX = 4;
  Real dddx[N, nX];
equation
  for j in 1:N loop
    dddx[j, :] = zeros(nX);
  end for;
end TestArray;

[Lennart Ochel]

I found a fix for the ThermoPower example, which breaks none of the test cases from the test suite. Anyway, I am not sure if it is a bad hack or a proper fix.

[Francesco Casella]

Replying to lochel:

I found a fix for the ThermoPower example, which breaks none of the test cases from the test suite. Anyway, I am not sure if it is a bad hack or a proper fix.

Volker, can you please have a look at that?

[Martin Sjölund]

Replying to casella:

I tried the following test case, which should capture all the features of the example, but it works just fine

I would guess because zeros() is known and is simplified. I suppose it would be different if the call is a user-defined function.

[Francesco Casella]

Replying to sjoelund.se:

Replying to casella:

I tried the following test case, which should capture all the features of the example, but it works just fine

I would guess because zeros() is known and is simplified. I suppose it would be different if the call is a user-defined function.

Maybe, but in the ThermoPower models that fail to compile in the test suite, the zeros() function is used as well. This is the offending code:

  for j in 1:N loop
    if not QuasiStatic then
      cv[j] = Medium.heatCapacity_cv(gas[j].state);
      dddT[j] = Medium.density_derT_p(gas[j].state);
      dddp[j] = Medium.density_derp_T(gas[j].state);
      if nX > 0 then
        dddX[j, :] = Medium.density_derX(gas[j].state);
      end if;
    else
      // Dummy values (not needed by dynamic equations)
      cv[j] = 0;
      dddT[j] = 0;
      dddp[j] = 0;
      dddX[j, :] = zeros(nX);
    end if;
  end for;

In the case at hand, QuasiStatic==true, so the else branch is considered.

Of course your remark would apply if QuasiStatic = false.

[Lennart Ochel]

Replying to lochel:

I found a fix for the ThermoPower example, which breaks none of the test cases from the test suite. Anyway, I am not sure if it is a bad hack or a proper fix.

I committed the fix in r20343. I am still not so happy with that commit, but it works at least for the model above.

[Francesco Casella]

ThermoPower.Test.DistributedParameterComponents.TestGasFlow1DFV_A now compiles. However, all the other models in the library that showed the reported problem don't, namely:

ThermoPower.Examples.HRB.Simulators.ClosedLoopDigitalSimulator
ThermoPower.Examples.HRB.Simulators.ClosedLoopDigitalSimulatorSimplified
ThermoPower.Examples.HRB.Simulators.ClosedLoopSimulator
ThermoPower.Examples.HRB.Simulators.OpenLoopSimulator
ThermoPower.Examples.HRB.Simulators.OpenLoopSimulatorSS
ThermoPower.Examples.HRB.Simulators.OpenLoopSimulatorSimplified
ThermoPower.Examples.RankineCycle.Simulators.ClosedLoop
ThermoPower.Test.DistributedParameterComponents.TestGasFlow1DFV_B
ThermoPower.Test.DistributedParameterComponents.TestGasFlow1DFV_C

The problem is still the same: all elements of dddX[j, 1] are scalarized as dddx[1] in the equations.

[anonymous]

I get this when I connect an ideal cell to a resistor.

model ultraboost
  Modelica.Electrical.Analog.Basic.Resistor resistor1(R = 1);
  Modelica.Electrical.Analog.Sources.ConstantVoltage constantvoltage1(V = 1);
equation
  connect(resistor1.n,constantvoltage1.n);
  connect(constantvoltage1.p,resistor1.p);
end ultraboost;

[:0:0-0:0] Error: Internal error Transformation Module PFPlusExt index Reduction Method Pantelides failed!
[:0:0-0:0] Error: Internal error pre-optimization module removeSimpleEquations failed.
[:0:0-0:0] Error: Internal error Circular Equalities Detected for Variables:
constantvoltage1.p.i
constantvoltage1.n.i

---

resistor1.p.i
constantvoltage1.p.i

---

resistor1.p.i
resistor1.n.i

---

[anonymous]

I was using Openmodelica1.9.1Beta2 r19512 on Linux.

[Adrian Pop]

For the ultraboost model the message is correct. you're missing a ground:

model ultraboost
  Modelica.Electrical.Analog.Basic.Resistor resistor;
  Modelica.Electrical.Analog.Basic.Ground ground;
  Modelica.Electrical.Analog.Sources.ConstantVoltage constantVoltage;
equation 
  connect(constantVoltage.p, resistor.p);
  connect(ground.p, constantVoltage.n);
  connect(ground.p, resistor.n);
end ultraboost;

[Volker Waurich]

Replying to lochel:

Replying to lochel:

I found a fix for the ThermoPower example, which breaks none of the test cases from the test suite. Anyway, I am not sure if it is a bad hack or a proper fix.

I committed the fix in r20343. I am still not so happy with that commit, but it works at least for the model above.

I was so bold to remove your commit and added a more proper solution. The problem was in the declaration of the array. The Exp was a CREF and the concrete index of the vector is inside the ComponentRef and not in the T_ARRAY (there is only the dimension of the whole vector). Anyway, the current implementation works only for vectors. Since the remaining models contain matrices or arrays of higher dimension, they still fail. I will have a look on them but handling the various array declarations and subscript stuff is a bit puzzling.

[Francesco Casella]

Replying to vwaurich:

I was so bold to remove your commit and added a more proper solution. The problem was in the declaration of the array. The Exp was a CREF and the concrete index of the vector is inside the ComponentRef and not in the T_ARRAY (there is only the dimension of the whole vector). Anyway, the current implementation works only for vectors. Since the remaining models contain matrices or arrays of higher dimension, they still fail. I will have a look on them but handling the various array declarations and subscript stuff is a bit puzzling.

Doesn't seem to help much, the examples in HRB and RankineCycle still have the same problem (​https://test.openmodelica.org/libraries/ThermoPower/BuildModelRecursive.html)

[Volker Waurich]

At least a bit has improved for the models:

ThermoPower.Examples.HRB.Simulators.ClosedLoopDigitalSimulator
ThermoPower.Examples.HRB.Simulators.ClosedLoopSimulator
ThermoPower.Examples.HRB.Simulators.OpenLoopSimulator
ThermoPower.Examples.HRB.Simulators.OpenLoopSimulatorSS
ThermoPower.Examples.HRB.Simulators.OpenLoopSimulatorSimplified
ThermoPower.Test.DistributedParameterComponents.TestGasFlow1DFV_B
ThermoPower.Test.DistributedParameterComponents.TestGasFlow1DFV_C

[Francesco Casella]

Now I see it. It took some time for the changes to make their way down to ​https://test.openmodelica.org/libraries/ThermoPower/BuildModelRecursive.html

Thanks a lot, we are making good progress towards 100% support of ThermoPower!

[ryanh@…]

Can we re-open this ticket? It looks like the fix in r20343 was reverted in r20470. I am running into the same issue as stated above when trying to simulate some models in the OpenHydraulics library. I can attach one of them for reference if needed.

[ryanh@…]

I'm just realizing that r20470 was actually a more proper fix for what r20343 was trying to address (the changeset wasn't referenced in the comments). Regardless, I am still running into similar issues with the OpenHydraulics library where the PFPlusExt Pantelides algorithm fails. It may be failing due to other reasons though, I get a "Internal error post-optimization module encapsulateWhenConditions failed." error message prior to the Pantelides algorithm failing.

[Martin Sjölund]

Moved to new milestone 1.9.4

[Lennart Ochel]

Are there still problems with PFPlusExt Pantelides algorithm?

[res@…]

i have the same problem with modelica EnergyStoragesLibrary

[Lennart Ochel]

The models I've tested from this ticket are working. In the case that there are similar issues with other models (e.g. OpenHydraulics library), please open another ticket and assign it to me.

[Martin Sjölund]

Milestone renamed

[Martin Sjölund]

Milestone renamed