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

slack bus has no generator in RTE cases #60

Closed
rdzman opened this issue Mar 6, 2019 · 8 comments
Closed

slack bus has no generator in RTE cases #60

rdzman opened this issue Mar 6, 2019 · 8 comments

Comments

@rdzman
Copy link
Member

rdzman commented Mar 6, 2019

It appears that the RTE cases have no generator at the slack/reference bus.

case1888rte
case1951rte
case2848rte
case2868rte
case6468rte
case6470rte
case6495rte
case6515rte

Currently, MATPOWER's runpf handles this by (silently) converting the specified slack/reference bus to a PQ bus, and selecting the first PV bus as a new slack/reference bus.

However, this should be corrected in the cases by specifying a slack/reference bus that has a generator.

Thanks to Drosos Kourounis for pointing this out.

@ccoffrin
Copy link

ccoffrin commented Mar 7, 2019

To the best of my knowledge, these cases originally appeared in this technical report. If the version distributed with Matpower changes from the original report, I worry that many people will publish papers without indicating which version they used, which will make it difficult to reproduce results down the road.

Thoughts?

@rdzman
Copy link
Member Author

rdzman commented Mar 7, 2019

Thanks. I share your hesitation about creating multiple versions of a case. On the other hand, the motivation to "fix" this is precisely for reproducibility of results.

At the moment, the power flow problem for each of these cases is not clearly defined, so any power flow solution is necessarily dependent on whatever convention was used by the particular power flow software internally to "fix" such a case before running it. MATPOWER's convention is undocumented and likely differs from that of other software. In fact, some software may simply treat this as an error and require that the case be fixed manually.

So, in my opinion, modifying these cases to use a valid slack bus is a minor change and the problem is serious enough to warrant a new "fixed" version. What do you think?

I'm in contact with the Cédric and his RTE colleagues about the issue.

@ccoffrin
Copy link

ccoffrin commented Mar 7, 2019

I think the best solution would be to fix both versions. So if the RTE team agrees to update the technical report along with the updates you make here, problem solved!

@rdzman
Copy link
Member Author

rdzman commented Mar 7, 2019

Great idea. I'll mention that to them. Thanks.

@rdzman
Copy link
Member Author

rdzman commented Mar 25, 2019

According to Jean Maeght of RTE-France, if I understand correctly, their operational power flow software uses the most meshed 400kV bus (which does not have a generator) as a temporary slack bus while iteratively solving the problem and distributing whatever slack arises among all generators.

My suggestions are:

  1. Simply select a 400kV bus that already has a generator (maybe the largest one?) as the slack bus. If the active power output of the other generators is a power flow solution (i.e. the current slack is zero), changing the slack bus for MATPOWER as suggested should not change the power flow solution.
  2. Give each of the updated RTE cases an explicit version number that appears in the comments at the top of the file and in an update to the original arXiv paper in which the data was first published. This version number could either be numerical (e.g. v2) or a date (e.g. v2019-03-25), but it would give researchers a way to specify explicitly which version they are using.

What does everyone think?

@jean-maths
Copy link

Hello,
In our industrial power flow software (named Hades, available here http://www.itesla-pst.org/ and http://www.rte.itesla-pst.org/ ), slack bus is in fact distributed.
We first look for the most meshed 400kV bus, and we use it as slack bus for the first Gauss-Newton run.
After Gauss-Newton convergence, the slack value at slack bus is dispatched over all generating units, proportionally to their participation to primary frequency reserve (or proportionally to their distance to Pmax in some cases).
Then a Gauss-Newton method is run again.
Then slack value is dispatched again.
And so on. A few iterations only are necessary until the slack value is zero.
So in that sense our slack bus is distributed.

In case of OPF computation, slack bus has no sense. In case of OPF, one might want to fix phase=0 for one bus (although this is not strictly necessary). Often people take slack bus for phase=0, but there is no real reason for. Smart choice of "phase=0" bus should be a research topic. Relying on "phase=0" bus in data sets is not a good choice.

I am now modifying our cases to add a generator on slack bus.
kind regards
Jean

@jean-maths
Copy link

After adding a generator at slack bus, I will modify the comments in case files, in order to mention that this is a new version.
My proposal would be to write "version 2019".
After we agree on this, I will also change the files in our arxiv paper.
Jean

@rdzman
Copy link
Member Author

rdzman commented Jun 5, 2019

Thanks. I think "version 2019" is ok, but it arbitrarily eliminates the possibility of more than 1 update in a given year. Hopefully, that will never happen, but I'd prefer either something like v2 or v2019-06-05. I'll leave the final call up to you.

@rdzman rdzman closed this as completed in ad48e30 Jun 5, 2019
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