OM cannot run some electrical load flow calculations from open-source library PowerSysPro

[JPhi Tavella <jean-philippe.tavella@…>]

Hello All

EDF is developping some open-source Modelica libraries and you already know some of them (ThemoSysPro, BuildSysPro, ...).
In the electrical domain,a new library is being developped by EDF too.
This library is available here: ​https://bitbucket.org/simulage/powersyspro/wiki/Home

As you can read it in the Wiki of this page, OpenModelica is not currently able to run most of models instantiating PowerSysPro components.

You can check this trying to run cases from the package Examples of the library, especially for models mixing several lines and transformers.

Th problem occurs in the intialization part of the solver, something close to a Newton-Raphson algorithm.

Best regards

[Francesco Casella]

@jean-philippe, we would be happy to include PowerSysPro in the ​OpenModelica testuite to track the performance and problems with OpenModelica. Given our experience with the ​PowerGrids library (see also the ​paper, I am confident that you can use your library in OpenModelica as well.

In order to achieve that goal, the library needs to be strictly conforming to the ​Modelica Specification. This may be obvious but it's not, sometimes tools (including Dymola) are a bit lax and accept code which is not really conforming to the standard. This is a problem if you want to use your library across tools, to do that you really need to be as strict as possible.

You may check this with the "Pedantic check" option of Dymola and make sure you get no errors.

First of all, I would recommend you to store the Modelica source code on Bitbucket according to the standard, see Section ​13.2.2 of the Modelica specification. If you want to keep the whole library in a single file, either call that file PowerSysPro.mo or call it package.mo and put it in a directory called PowerSysPro.

Then, please add an experiment annotation, e.g. annotation(experiment(StopTime = 1)); to all the simulation models you want to test with OpenModelica. If you already have an annotation statement in the model, just add experiment(StopTime = 1) to the comma-separated list. This can also be done automatically with Dymola by setting any other stop time than the default value of 1.

Once you've done that, we can automatically test those models on our CI infrastructure as we did for ​PowerGrids and help you getting it going with OMC.

Thank you!

[JPhi Tavella <jean-philippe.tavella@…>]

@casella, thank you for these advices.

I corrected all the "Pedantic" errors using the "Pedantic check" option of Dymola, so that now I'm sure there are no errors.

Then as the whole library is in a single file, I named it PowerSysPro.mo and put it in a directory called PowerSysPro in the Bitbucket.

All my models in the library have a StopTime value, most of the time this value is 0 as the calculations are to be done at the initialization stage.

OM errors are still present. E.g. test the (simple) model named OneSourceOneTransfoOneLineOneTransfoOneLineOneLoad in package Examples.

Kind regards

[Martin Sjölund]

OneSourceOneTransfoOneLineOneTransfoOneLineOneLoad the test script can't find. Most examples generate code, but don't initialize.

[JPhi Tavella <jean-philippe.tavella@…>]

Yes that's the issue, most of the models in package Examples fail at initialization.

[Francesco Casella]

@sjoelund.se, could you please add this library to the testsuite, so I can make some analysis and follow the improvements?

Thanks!

[JPhi Tavella <jean-philippe.tavella@…>]

@all, I explicitly set an experiment(StopTime=xx) to all runable models.
I also removed all experiment(Dymola_Algorithm = "Dassl") everywhere.

[Adrian Pop]

Added:
​https://github.com/OpenModelica/OMLibraries/commit/6e43082c97ff4be081209b96ce2ecb9572fa44e0

[Francesco Casella]

@adrpo, I checked ​https://libraries.openmodelica.org/branches/newInst/ but I couldn't find PowerSysPro there. Did something go wrong?

[Martin Sjölund]

​https://github.com/OpenModelica/OpenModelicaLibraryTesting/commit/5b29b90a2b612d9ec7819d7b76e07cc4825eade0

[Adrian Pop]

What @sjoelund.se wanted to say is that even if I added the library to the repo of the libraries that are tested you need to also specify it in the configuration file. I forgot about that. Hopefully we will get some results now in a couple of hours.

[anonymous]

Some other observations:

• PowerSysPro.Components.myPVNode: Please fix the Icon annotation from

Icon(coordinateSystem(grid = {0.1, 0.1}, initialScale = 0.1), graphics = {Text(origin = {60.1, -63.1}, lineColor = {0, 0, 255}, extent = {{-124, 11}, {124, -11}}, textString = if OnePhaseLoad then "1" else "3", textStyle = {TextStyle.Bold}), coordinateSystem(preserveAspectRatio = false), Text(extent = {{-40.5, -6}, {41.5, -46}}, lineColor = {0, 0, 0}, textStyle = {TextStyle.Bold}, textString = "~")})

to

Icon(coordinateSystem(grid = {0.1, 0.1}, initialScale = 0.1, preserveAspectRatio = false), graphics = {Text(origin = {60.1, -63.1}, lineColor = {0, 0, 255}, extent = {{-124, 11}, {124, -11}}, textString = if OnePhaseLoad then "1" else "3", textStyle = {TextStyle.Bold}), Text(extent = {{-40.5, -6}, {41.5, -46}}, lineColor = {0, 0, 0}, textStyle = {TextStyle.Bold}, textString = "~")})

to comply with the Modelica standard.

• PowerSysPro.Regulations.myQfU contains a clocked when statement within an algorithm. This is not compliant with the Modelica language specification. You need to use an equation section instead.

• PowerSysPro.Examples.VariableLoad: The table file powersyspro/Resources/Files/variablePQLoad.csv is missing.

[Francesco Casella]

I'm not sure what is happening, but after three days there are still no test run results from any library (including this one). @adrpo, @sjoelund, could you please check?

[Adrian Pop]

​https://libraries.openmodelica.org/branches/newInst/PowerSysPro/PowerSysPro.html

[Francesco Casella]

OK, so we have 30 models failing out of 50.

• 9 models fail because an overdetermined system with two or four more equations than variables
• 2 fail because of Clock() being interpreted as an (undefined) function call
• the other 19 fail at initialization because of nonlinear solver failure

We'll investigate and get back to you.

[Francesco Casella]

As far as I understand, these connector definitions are not legal Modelica:

  connector myTerminalOutput "Output terminal for causal connections"
    output Modelica.SIunits.ComplexVoltage v "Phase-to-ground voltage phasor";
    flow input Modelica.SIunits.ComplexCurrent i "Line current phasor";
  end myTerminalOutput;

  connector myTerminalInput "Input terminal for causal connections"
    input Modelica.SIunits.ComplexVoltage v "Phase-to-ground voltage phasor";
    flow output Modelica.SIunits.ComplexCurrent i "Line current phasor";
  end myTerminalInput;

The Modelica Specification, ​section 9.3.1 states:

For each non-partial connector class the number of flow variables shall be equal to the number of variables that are neither parameter, constant, input, output, stream nor flow.

This condition is clearly violated in both connectors, which both have one flow variable and zero variables that are neither parameter, constant, input, output, stream nor flow.

The compiler does not complain directly about unbalanced connectors, because such checks and the corresponding diagnostic messages have not been implemented yet, see #3977. However, the models built with components using these connectors are unbalanced as a consequence.

I'm not sure exactly what is the design rationale of these connectors - I understand that you want to be able to export models to causal simulation environments. Maybe you could do that in a cleaner way by using adaptor components that have an a-causal terminal on one side and a connector with a pair of input and output variables on the other side?

[Francesco Casella]

Regarding the examples failing to compile because of Clock(), they both fail because myQfU contains a clocked when clause inside an algorithm. This is not allowed by the rules set forth in ​Section 16.6 of the Modelica Specification.

You should convert that algorithm section to an equation section, which should be relatively straightforward: turn all assignments := into equalities =, and merge the latest if clause in the if-elseif-else clause.

[Francesco Casella]

Regarding the models failing at runtime, there nonlinear systems of equations that are solved by tearing, ending up in a division by zero. The tearing is questionable and should be improved, see #6232.

For the time being, you may set --tearingMethod=minimalTearing in OMEdit to avoid this kind of problem; go to Tools | Options | Simulation, then add that translation flag to the space-separated list of additional translation flags. Note that this setting could cause problems on other models that rely on tearing to be successfully and efficiently solved.

[jean-philippe.tavella@…]

@casella
Thank you so much for the very accurate and interesting information you give me.
I am changing all you mention according to your proposals.

Already changed on my side: icon in myPVnode, clock in myQfU.
About the table file powersyspro/Resources/Files/variablePQLoad.csv you are right. But it is included in the zip file available in the bitbucket (as other resources in folder Resources like images).

About the unbalanced connectors, it seems to run when using the old frontend compiler...

When testing --tearingMethod=minimalTearing I see the model can be run and results are correct in the Variables Browser but the plot is very strange...

[Francesco Casella]

Replying to jean-philippe.tavella@…:

About the unbalanced connectors, it seems to run when using the old frontend compiler...

This is possible, but the old frontend is discontinued, and the development of the new frontend strictly adheres to the standard, as all tools should.

When testing --tearingMethod=minimalTearing I see the model can be run and results are correct in the Variables Browser but the plot is very strange...

Can you be more specific?

[jean-philippe.tavella@…]

Answering to @casella

About the unbalanced connectors, I will think more about it. The idea in the library is to offer causal connectors so that exporting FMUs is possible for very huge load flows gathering several FMUs (as we have in electric distribution grids at EDF).

Second, about the minimalTearing, I attach a pdf file comparing the plot from Dymola and OM.
Strangely, results are correct in the browser but the plot is not correct according to me...

[Philip Hannebohm]

Replying to jean-philippe.tavella@…:

Second, about the minimalTearing, I attach a pdf file comparing the plot from Dymola and OM.
Strangely, results are correct in the browser but the plot is not correct according to me...

The plot appears to be zoomed in very far, up to the resolution level of the underlying floating point numbers. But we can't really tell by looking at the plot because the labeling on the y-axis is too imprecise.
You should be able to hover your cursor on the curve to read some of the values more accurately.
I would suspect the result is perfectly fine and this might be a separate issue in the default behavior of plots in OMEdit. We may want to put a limit to the default magnification.

[jean-philippe.tavella@…]

@phannebohm:
I agree the labeling on the y-axis is too imprecise.
Nevertheless there should not be chattering as the load flow is calculated at t = 0 and after that nothing change as the variables are not time dependant.

So on my view we should get a single value calculated at t= 0, and this value should not change after when t>0.

When I run the case with stop time = 0, I also get a vertical Dirac, while a single dot is expected.

There should be an issue in the plotting. Do you want me to ppen another ticket for this?

[Philip Hannebohm]

Replying to jean-philippe.tavella@…:

@phannebohm:
I agree the labeling on the y-axis is too imprecise.
Nevertheless there should not be chattering as the load flow is calculated at t = 0 and after that nothing change as the variables are not time dependant.

So on my view we should get a single value calculated at t= 0, and this value should not change after when t>0.

When I run the case with stop time = 0, I also get a vertical Dirac, while a single dot is expected.

There should be an issue in the plotting. Do you want me to ppen another ticket for this?

My bad, I didn't look into the model at all. It looks like everything should be stationary, like you said.

Out of curiosity I studied the result file. So apparently all of the variables are oscillating pretty regularly (some in a 3-cycle, some in a 6-cycle). Most values only differ literally in their last one or two binary digits. :D

My guess is it's the nonlinear solver's fault. I'm not an expert on this part but, we recently changed it so the solver walks at least one step at each iteration, and obviously it doesn't know about the time independence.
The solution could be to walk back if the residual doesn't change by much in the first step.
@Karim can you confirm that?

[Philip Hannebohm]

Replying to phannebohm:

... and obviously it doesn't know about the time independence.

Or could we actually find time independent sub systems in the back end and only solve them during initialization and possibly at events?

[Francesco Casella]

Replying to jean-philippe.tavella@…:

About the unbalanced connectors, I will think more about it. The idea in the library is to offer causal connectors so that exporting FMUs is possible for very huge load flows gathering several FMUs (as we have in electric distribution grids at EDF).

I'm not exactly sure how that works, since you'll have algebraic loops among FMUs. I guess there will be some iterative algorithm to get them to converge, right?

In any case, as far as I understand, either you use an a-causal connector with coupled flow and effort (i.e. nor input, nor output, nor flow etc) variables, or you use a pair of input/output variables. You can't have both options at the same time. You can easily convert one into the other using adaptors, e.g.

connector AcausalPort
  Voltage v;
  flow Current i;
end AcausalPort;

connector CausalPortVIn
  input Voltage v;
  output Current i;
end CausalPortVIn;

connector CausalPortVOut
  output Voltage v;
  input Current i;
end CausalPortVOut;

model AdaptorVin
  AcausalPort ap;
  CausalPortVin cp;
equation
  cp.i + ap.i = 0;
  cp.v = ap.v;
end AdaptorVin;

model AdaptorVout
  AcausalPort ap;
  CausalPortVout cp;
equation
  cp.i + ap.i = 0;
  cp.v = ap.v;
end AdaptorVout;

Second, about the minimalTearing, I attach a pdf file comparing the plot from Dymola and OM.
Strangely, results are correct in the browser but the plot is not correct according to me...

It is, the problem is that the choice of units for the y axis makes you see minimal fluctuations on the 15th decimal digit, close to machine precision. Dymola uses a more reasonable scaling.

This issue has been already discussed in #4232. I could not convince my friend and colleague @ceraolo, who's also an electrical engineer, to make sure that an axis range is picked that does not show these fluctuations, because they are confusing. Maybe you can convince him yourself :)

[Francesco Casella]

Replying to phannebohm:

Replying to phannebohm:

... and obviously it doesn't know about the time independence.

Or could we actually find time independent sub systems in the back end and only solve them during initialization and possibly at events?

I thought we always did that. I'm not sure why this doesn't happen here.

[jean-philippe.tavella@…]

Replying to casella:

I'm not exactly sure how that works, since you'll have algebraic loops among FMUs. I guess there will be some iterative algorithm to get them to converge, right?

--> Yes algebraic loops among FMUs are solved by our co-initialization algorithm based on Newton-Raphson or another adoc algo both developped and used in our open-source tool DACCOSIM NG. I could send you some information on that if you want.
This perfectly works with Dymola FMUs and we would like to do the same with OM FMUs in spite of current limitations in FMUs from OM...

[jean-philippe.tavella@…]

Replying to casella:

In any case, as far as I understand, either you use an a-causal connector with coupled flow and effort (i.e. nor input, nor output, nor flow etc) variables, or you use a pair of input/output variables. You can't have both options at the same time. You can easily convert one into the other using adaptors, e.g.

I changed my connectors as a consequence and it seems to work well now.
Nevertheless we will have to pay attention as flow prefix will be fully accepted for input or output variables with the new FMI 3.0.
Probably there will be some changes there next year...

[jean-philippe.tavella@…]

Could you please redo your tests with the recently uploaded version 1.3 on the bitbucket(​https://bitbucket.org/simulage/powersyspro/downloads)?
You can also read the RELEASES.txt file if you want.

[Francesco Casella]

@jean-philippe, the situation with v. 1.13 is very much improved, see ​report. Now we can generate code for all 52 runnable models.

Half of them fails at initialization, from what I understand this is due to #6232. Please refer to that.

[jean-philippe.tavella@…]

Replying to casella:

@jean-philippe, the situation with v. 1.13 is very much improved, see ​report. Now we can generate code for all 52 runnable models.

Half of them fails at initialization, from what I understand this is due to #6232. Please refer to that.

Thank you very much for such speed and efficiency in replies.

[Francesco Casella]

Being a member of the OSMC brings some benefits :)

Thank you for EDF's continued support to the Consortium!

[Francesco Casella]

Retargeted to 1.18.0 because of 1.17.0 timed release.

[Francesco Casella]

Ticket retargeted after milestone closed