PowerSystems: BackendDAEOptimize.createJacobian failed

[Rüdiger Franke]

The new head revision 2e0ca56 of PowerSystems

$ git clone https://github.com/modelica/PowerSystems.git

fixes some problems that showed up with OpenModelica (syntax error with array indexing and explicit instantiation of a global system model).

Now the code generation still fails for some models. In particular for models as simple as:

PowerSystems.Test.GenericComponentsTest.PMeterTest
PowerSystems.Test.GenericComponentsTest.GeneratorTest
PowerSystems.Test.GenericComponentsTest.GeneratorTest2

For instance PMeterTest gives the translation errors:

[1] 15:32:16 Translation Error
Internal error BackendDAEOptimize.createJacobian failed

[2] 15:32:16 Translation Error
Internal error BackendDAEOptimize.optimizeJacobianMatrix failed

[3] 15:32:16 Translation Error
Internal error Transformation Module PFPlusExt index Reduction Method Pantelides failed!

[4] 15:32:16 Symbolic Error
[/home/user/PowerSystems/PowerSystems/Generic.mo: 321:5-321:89]: Model is structurally singular, error found sorting equations 1: $CSE1$lB2$rB$pDERNLSJac12$P$CSE1$lB2$rB = 0.0; for variables $res1$pDERNLSJac12$PdummyVarNLSJac12(1)

Followed by the runtime error

residual function pointer is invalid
Simulation process failed. Exited with code 255.

[Rüdiger Franke]

I was wondering why yesterday's tests done with r24515 report success for PowerSystems.Examples.PowerWorld.PowerWorld , even though it exhibits the same problem. Indeed I was using the option +cseCall. The reported problem disappears with the default OMC flags.

However, the problem shows up again when adding external IO to the model. Simulation in OMEdit works despite of the translation errors (r24510). Export of FMU 2.0 fails for this PMeterTest with IO:

model PMeterTestWithIO
  inner PowerSystems.System system
    annotation(Placement(transformation(extent = {{-100, 80}, {-80, 100}})));
  PowerSystems.Generic.FixedVoltageSource source
    annotation(Placement(transformation(extent = {{-80, 0}, {-60, 20}})));
  PowerSystems.Generic.Sensors.PMeter pMeter
    annotation(Placement(transformation(extent = {{-40, 0}, {-20, 20}})));
  PowerSystems.Generic.PrescribedPowerLoad load(phi = atan(1000 / 3000))
    annotation(Placement(transformation(extent = {{0, 0}, {20, 20}})));
  Modelica.Blocks.Interfaces.RealInput Pin(start = 2.7076e6)
    annotation(Placement(transformation(extent = {{64, 0}, {44, 20}})));
  Modelica.Blocks.Interfaces.RealOutput Pout
    annotation(Placement(visible = true, transformation(extent = {{-10, 30}, {10, 50}})));
equation
  connect(pMeter.P, Pout)
    annotation(Line(points = {{-30, 21}, {-30, 40}, {0, 40}}, color = {0, 0, 127}));
  connect(source.terminal, pMeter.terminal_p)
    annotation(Line(points = {{-60, 10}, {-40, 10}}, color = {0, 120, 120}));
  connect(pMeter.terminal_n, load.terminal)
    annotation(Line(points = {{-20, 10}, {0, 10}}, color = {0, 120, 120}));
  connect(Pin, load.P)
    annotation(Line(points = {{54, 10}, {21, 10}}, color = {0, 0, 127}, smooth = Smooth.None));
  annotation(experiment(StopTime = 1), uses(Modelica(version = "3.2.1"), PowerSystems(version = 0.3")),
    Diagram(coordinateSystem(preserveAspectRatio = false, extent = {{-100, -100}, {100, 100}}), graphics));
end PMeterTestWithIO;

[Willi Braun]

I'll take a look today.

[Rüdiger Franke]

I was positively surprised to see the FMU export working using r24573. Then I played around with the model and got some fuzzy results.

It appears that the error shows up if the model file has DOS line endings, contains multi-line doc strings and is treated with OMEdit under Linux!?

See attached model file -- FMI export raises the errors below. It works if the multi-line doc string is removed or if using Unix line endings.

[3] 18:56:09 Translation Error
Error building simulator. Build log: clang -fPIC -O0 -march=native -I"/usr/include/omc/c" -I"/usr/include/omc/c/fmi2" -I. -c -o PMeterTestWithIO_FMU.o PMeterTestWithIO_FMU.c PMeterTestWithIO_FMU.c:447:79: warning: assigning to 'modelica_string' (aka 'void *') from 'fmi2String' (aka 'const char *') discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers] case $Psystem$Pini_ : comp->fmuData->simulationInfo.stringParameter[0]=value; break; ^~~~~~ PMeterTestWithIO_FMU.c:448:79: warning: assigning to 'modelica_string' (aka 'void *') from 'fmi2String' (aka 'const char *') discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers] case $Psystem$Pref_ : comp->fmuData->simulationInfo.stringParameter[1]=value; break; ^~~~~~ PMeterTestWithIO_FMU.c:449:79: warning: assigning to 'modelica_string' (aka 'void *') from 'fmi2String' (aka 'const char *') discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers] case $Psystem$Psim_ : comp->fmuData->simulationInfo.stringParameter[2]=value; break; ^~~~~~ 3 warnings generated. clang -fPIC -O0 -march=native -I"/usr/include/omc/c" -I"/usr/include/omc/c/fmi2" -I. -c -o PMeterTestWithIO.o PMeterTestWithIO.c In file included from PMeterTestWithIO.c:495: ./PMeterTestWithIO_init.c:1:1: warning: missing terminating '"' character [-Winvalid-pp-token] "\n\n\n: recipe for target 'PMeterTestWithIO.o' failed make: *** [PMeterTestWithIO.o] Error 1 

[4] 18:56:09 Translation Error
Internal error BackendDAEOptimize.createJacobian failed

[5] 18:56:09 Translation Error
Internal error BackendDAEOptimize.optimizeJacobianMatrix failed

[6] 18:56:09 Translation Error
Internal error Transformation Module PFPlusExt index Reduction Method Pantelides failed!

[7] 18:56:09 Translation Error
Internal error pre-optimization module removeSimpleEquations failed.

[8] 18:56:09 Symbolic Error
[/home/user/PowerSystems/PowerSystems/Generic.mo: 294:9-294:60]: Found equation without time-dependent variables: system$Ptheta$pDERD$PdummyVarD = 0.0

[Rüdiger Franke]

Btw. the attached model fails to simulate from OMEdit with +cseCall (see initial report of this ticket).

Can it be that the BackendDAEOptimize errors are things that are treated internally and that the error message buffer isn't cleaned up appropriately, so that the messages show up if something else goes wrong, like a DOS line ending?

[Willi Braun]

This issue with +cseCall seems to be caused by a wrong adjacency matrix.
For the following system:

eqns:
1/1 (1): $CSE1[2] = $CSE4[2]   [dynamic]
2/2 (1): $CSE1[1] = $CSE4[1]   [dynamic]
[...]
vars:
[...]
22: $CSE4[2]:VARIABLE()  type: Real 
23: $CSE4[1]:VARIABLE()  type: Real 
24: $CSE1[2]:VARIABLE()  type: Real 
25: $CSE1[1]:VARIABLE()  type: Real 

we get following corresponding adjacency rows:

[...]
1:23 22 25 24 
2:23 22 25 24 
[...]

This results into a really wrong strong component and generated code is wrong.

[Willi Braun]

fixed in r24635.