Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ieee14 static network issue? #135

Open
ceraolo opened this issue Mar 1, 2024 · 6 comments
Open

Ieee14 static network issue? #135

ceraolo opened this issue Mar 1, 2024 · 6 comments

Comments

@ceraolo
Copy link

ceraolo commented Mar 1, 2024

AFAICU, IEEE14busStaticNetwork should produce the same results ad IEEE14busPowerFlow.
I've just checked reactive power on bus1 (slack/reference node) and got looking at the numbers on diagram, -8.429 and 0.000 respectively .
It seems to me that something is not going as expected. Am I wrong?

@AndreaBartolini
Copy link
Member

AndreaBartolini commented Mar 2, 2024

The IEEE14busStaticNetwork does not use the EPF, this is the reason of the different results. It uses start values calculated by dynawo to initialise the network (see modifiers in the text view of the model).

The IEEE14busStaticNetworkEPF uses the EPF and produces the same results of IEEE14busPowerFlow.

Maybe this should be better explained in the documentation.

@ceraolo
Copy link
Author

ceraolo commented Mar 2, 2024

Maybe this should be better explained in the documentation.

Frankly I don't agree. It is not a documentation matter.

For me the very meaning of IEEE14busStaticNetwork it to show continuity with PF.
For me, IEEE14busStaticNetwork should produce the same results as IEEE14busPowerFlow.
It confuses users to link to a totally different library (dynawo)

@AndreaBartolini
Copy link
Member

There is an hystorical reason for this, the IEEE14Bus package in PowerGrids was created in the year 2017 to test PowerGrids vs the results produced by Dynawo, and to do this it was necessary to embed in the model the same powerflow used by Dynawo, in order to compare the transients.

After the recent implementation of the EPF the model IEEE14busStaticNetworkEPF has been created in order to check the EPF vs the same PF implemented by using PF components directly.

We have choosen to maintain both the models in the library, to show the two different ways that the user can follow in order to initialize the model.

@ceraolo
Copy link
Author

ceraolo commented Mar 3, 2024

We have choosen to maintain both the models in the library, to show the two different ways that the user can follow in order to initialize the model.

Good. that's exactly a good reason to show the same result in two different ways

@casella
Copy link
Member

casella commented Mar 3, 2024

AFAICU, IEEE14busStaticNetwork should produce the same results ad IEEE14busPowerFlow.

This is not necessarily the case. The EPF uses PV nodes with fixed active power and voltage, and PQ nodes with fixed active and reactive power, in order to make the power flow as simple as possible to solve. As explained in the tutorial, the goal is not to compute the actual initial power flow with full precision, but just to provide initialization results close enough to it to guarantee convergence when you solve the real problem.

In the case of this example, the original model (without EPF) was initialized with a power flow provided by an external tool, and the initialization type was set to fixed power flow, so AVR setpoints are adapted backwards to match the power flow.

With PowerGrids 2.0.0 we also added the EPF-based initialization, to show that this method also works for non-trivial cases such as the IEEE 14 bus. This is also set with the "fixed power flow" initialization option, which however fixes the solution of the EPF, which is slightly different, so the initial solution of the full dynamic model is also a bit different.

We could put three initialization cases in the library

  • no EPF, start power flow data from Dynawo, fixed power flow initialization. This allows to reproduce the initial power flow by Dynawo, for validation purposes
  • EPF, steady-state initialization, fixed set points initialization. This demonstrates that EPF works
  • no EPF, start power flow data from the previous case (copied manually), fixed set points initialization. This should produce the same result as the previous case, but without using the EPF mechanism, rather the values obtained by it

Note that in the second case, IEEE14busStaticNetwork will still differ from IEEE14busPowerFlow, because the former has voltage-dependent PQ loads, while the latter doesn't.

@ceraolo
Copy link
Author

ceraolo commented Mar 4, 2024

My opinion is that from a user's point-of-view this is not good (even if implicitly) requiring users to know about dinawo.

From a user point-of view, the best demonstration of Powergrids PF and EPF capability is to have exactly the same case working with PF and EPF components. Cross-library checks are obviously interesting, but it is something separate from the inherent coherency of Powergrids models.

This is just my opinion, I repeat. In case, however, you prefer keeping different Power Flow cases in IEEE14busPowerFlow and IEEE14busStaticNetworkEPF, I think it must be clearly stated in the docu (now empty) or, maibe better, suggested in the very model name.

Note that in the second case, IEEE14busStaticNetwork will still differ from IEEE14busPowerFlow, because the former has voltage-dependent PQ loads, while the latter doesn't.

Good point. Will IEEE14busStaticNetworkEPF run without troubles with alpha=beta=0? I see that in IEEE14busStaticNetwork all loads have alpha=1.5 and beta=2.5. Therefore they could be set as parameters for the simulation, so that they can be changed all at once to repeat a simulation with different values for them. Using this technique, it would be very fast showing the difference in transient with then two cases (first: alpha=beta=0, second: alpha=1.5 and beta=2.5).
These two examples can be proposed in the docu. Users will see exactly the same starting point as the PF in case of alpha=beta=0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants