pf() after lopf() about etrago HOT 18 CLOSED

@mariusves will implement the slack bus definition.

from etrago.

added a branch with a first coupling lopf pf example: https://github.com/openego/eTraGo/blob/features/pf_after_lopf/etrago/appl.py#L106-L138

from etrago.

Just for your info: I just did a LOPF - then - PF run for the hours 1 and 2 for Germany NEP 2035 and it solved.

from etrago.

...but the error of the PF is not "0.000", but "nan"...

from etrago.

The functionality is already merged into dev branch see here and it can be chosen in the appl.py. The feature branch is still there because there still some features (see check list above) pending.

from etrago.

What exactly do you mean by additional costs? The costs induced through transmission losses? That would be part of #23

from etrago.

Your are right. That should be it and part of #23 . I changed it but left it there as a link, to have it in mind in case I forgot an effect. But I think we do not have to consider other costs due to the non-linear pf.

from etrago.

I forgot s.th. so far. We have to consider the position and usage of the slack in the pf!
For the position we defined it in redmine #935. It is still pending to implement this into this function.
Also an evaluation of the usage of this slack should be undertaken. We have to tackle possible inbalances in an adequate way.

from etrago.

The implementation of the cosphi assumptions is trivial. all big pp are PV generator. all small pp have a cosphi=1. (assumptions see redmine #935). Therefore we do not need any q_set for generators.
We just have to be sure that the q_set from the loads are imported. That should be the fact looking at the json

from etrago.

I added a first versionof a function to find the new slack generator, that needs to be evaluated still.

In the first step of this function, the control value of the "old" slack generator from the lopf is set back to its original state (PV or PQ) based on the rules set here.

Then, to find the new slack gen, the generator with the greatest dispatch (summarized over the whole simulation period) is determined and its control value is set to Slack.

Does this sound correct?

from etrago.

That is a how it is meant to be! Thx! Havent checked the code but the logic sounds like we talked about it.
@mariusves Can you work on the last checkbox?
Maybe we can close this ticket within the next release then...

from etrago.

I just checked the code. The logic is not 100% correct. The slack node will be the bus which has the maximal feed-in. Consequently you have to sum the generator_t over the buses, then select the bus with the highest feed-in over the year and take the biggest generator at that power plant which has to be a PV generator considering this condition.

Here are the original words from Rendel 2015:

Als Slack-Knoten wird derjenige Knoten gewählt, dessen Energieeinspeisung über den gesamten Simulationszeitraum gesehen am hächsten ist. Die Einspeisung muss dabei aus einem Großkraftwerk erfolgen, da dort die Annahme einer geregelten Spannung gerechtfertigt ist.

from etrago.

Testing has been moved to #63

@mariusves please close this ticket once the slack definition is finished.

from etrago.

I'm currently working on the suggested changes.
How should we deal with buses that don't have a PV generator available? I don't think that it's very likely that these buses will have the highest feed in, but I'm still wondering if I should implement a kind of "fail prove check"?

from etrago.

Yeah I think that would be good. Maybe an easy way is that you only take the buses where at least one PV generator is installed for the evaluation of the bus with the highest feed-in. That way the possibility you are talking about cannot happen.

from etrago.

with the latest commits 426e576 and 5510bf3 I improved the determination of the slack bus.
First, the dispatch of all generators are summed and grouped up per bus that they are connected to.
Then, it is verified if the bus with the highest dispatch has a PV generator. If that is not the case, the bus with the second highest dispatch is checked and so on. This repeats until a bus with a PV generator is found. Then, from this bus, the PV generator with the highest p_nom is selected to be the new slack bus.

Does that sound more reasonable?

from etrago.

For me that sounds very reasonable. Since @ulfmueller is on leave now, I think we can merge it to dev for the release tomorrow.
@mariusves could you create a PR once finished with the development on the branch?

from etrago.

Closed by a9aa595.
Further testing will be carried out in issue #63.

from etrago.