Ac emulation outerloop #1048
Ac emulation outerloop #1048
Conversation
Signed-off-by: Hadrien <[email protected]>
Signed-off-by: Hadrien <[email protected]>
Signed-off-by: Hadrien <[email protected]>
Signed-off-by: Hadrien <[email protected]>
Signed-off-by: Hadrien <[email protected]>
Signed-off-by: Hadrien <[email protected]>
Signed-off-by: Hadrien <[email protected]>
Signed-off-by: Hadrien <[email protected]>
Signed-off-by: Hadrien <[email protected]>
Signed-off-by: Hadrien <[email protected]>
Signed-off-by: Hadrien <[email protected]>
Signed-off-by: Hadrien <[email protected]>
Signed-off-by: Hadrien <[email protected]>
Signed-off-by: Hadrien <[email protected]>
Signed-off-by: Hadrien <[email protected]>
Signed-off-by: Hadrien <[email protected]>
Signed-off-by: Hadrien <[email protected]>
Signed-off-by: Hadrien <[email protected]>
Signed-off-by: Hadrien <[email protected]>
Signed-off-by: Hadrien <[email protected]>
src/main/java/com/powsybl/openloadflow/DefaultAcOuterLoopConfig.java
Outdated
Show resolved
Hide resolved
| contextData.incrementFeedingSideSwitchCount(hvdcId); | ||
| hvdc.updateFeedingSide(TwoSides.TWO); | ||
| if (contextData.getFeedingSideSwitchCount(hvdcId) == MAX_FEEDING_SIDE_SWITCH) { | ||
| LOGGER.debug("Two many feeding side switches (flow blocked to 0 MW) for Hvdc: {}", hvdcId); |
There was a problem hiding this comment.
I have a problem with this NULL status.
In the end it would produce a solution with status FULLY CONVERGED and where the HVDC transports no power.
But it may not represent the reality and be misleading. And cause users of the simulator to make wrong decisions.
For example the flip fop may result from changes of Phase Tap changers, or other automates, that changes the active power routes. It is not necessarily that the active power in the HVDC has small oscillations around 0 and can be neglected.
Have you found examples where small endless oscillations happen here ? Wouldn't a dead angle zone for which P is 0 be better ?
There was a problem hiding this comment.
The idea here is that, if the HVDC is changing its feeding side multiple times during the LF algorithm, then its flow should be very close to 0. In realistic case, the feeding side should never change at all during iterations.
We do not have any cases where endless oscillations around zero occur, but in theory, without this security, it may happen. It is mainly because of the discontinuity of the derivative from k to -k around 0.
src/main/java/com/powsybl/openloadflow/ac/outerloop/AcEmulationOuterLoop.java
Outdated
Show resolved
Hide resolved
|
|
||
| for (LfHvdc hvdc : context.getNetwork().getHvdcs()) { | ||
| if (!hvdc.isAcEmulation() || hvdc.getBus1().isDisabled() || hvdc.getBus2().isDisabled() || hvdc.isDisabled()) { | ||
| continue; |
There was a problem hiding this comment.
What you really want to know here is whether the hvdc link is active. That is if the hvdc in AC emulation mode and the P1 and P2 equations terms are active.
This condition here looks like a code duplication and may create problems in the future if we need to change the conditions and notifications that activate/deactivate P1 and P2 for LfHDVC.
Why not making getP1 and getP2 returning an EquationTerm instead of an evaluable and checking their active status ?
That would ensure consistency.
There was a problem hiding this comment.
Ok I will try that
| contextData.incrementModeSwitchCount(hvdcId); | ||
| hvdc.updateAcEmulationStatus(LfHvdc.AcEmulationControl.AcEmulationStatus.BOUNDED); | ||
| if (contextData.getModeSwitchCount(hvdcId) == MAX_MODE_SWITCH) { | ||
| LOGGER.debug("Two many mode switches (flow blocked to Pmax from CS1 to CS2) for Hvdc: {}", hvdcId); |
There was a problem hiding this comment.
Here again I am concerned that we give wrong result.
Is there a way to distringuish small oscillations near the maxP (where locking at bound status is acceptable) from large oscillations that mean no convergence ?
There was a problem hiding this comment.
Not really. But I think large system oscillations won't be solved with just fixing the flow on one HVDC line. Also, there is the same security with PV/PQ buses where switches are locked after some oscillations.
There was a problem hiding this comment.
Hi @Hadrien-Godard . I made a first macro review on the outerloop with focus on convergence criteria I have some concerns on potential incorrect convergence. Can you see if there is a better way to distinguish small oscillations around discontinuities from real convergence issues ?
Hi @vidaldid-rte . Many thanks for the review. I do not really see how easily distinguish small oscillations around discontinuities from real convergence issues. All I have to say is that real convergence issues have very small chances to be solved by fixing the flow on one line. Not real stronger arguments. Also, the pattern chosen here is similar to what is done for PV/PQ switching. |
Technically it is possible to store the value at previous loop iteration and compare the distance. [EDIT] WIth the current implementation of this outerloop you could have a result where an HVDC link is in state null, but the angles of the final solution are so that the HVDC link would flow power in reality. |
Hello @vidaldid-rte , thank you for your reply. But with ReactiveLimitsOuterloop, one could also end up with a generator controlling voltage and producing Q=Qmax with a voltage above its target (because blocked at PQ status). It is non-compliant with the model of generator voltage control, since reactive power output should value Qmax only if the generator cannot reach the voltage target. Furthermore, both solutions are physically correct in terms of Ohm's and Kirchhoff's laws. They are incorrect in terms of control device model. From my point of view, we can keep the design of this PR if we are ok with this method to fix impossible convergence issues, as we do for reactive limits. The question also holds for an Hvdc link blocked to Pmax. Maybe @geofjamg has an opinion on this. |
Signed-off-by: Hadrien <[email protected]>
|
Please check if the PR fulfills these requirements
Does this PR already have an issue describing the problem?
No
What kind of change does this PR introduce?
This PR introduces an outerloop to model the ability of AcEmulationControl to be bounded by Pmax and to change feeding side.
What is the current behavior?
Currently, those abilities are directly model in equation terms, leading to discontinuity in the computed derivatives.
What is the new behavior (if this is a feature change)?
An outerloop is introduced to control that an HVDC line in AcEmulation mode can be bounded by its Pmax values and that a loss coefficient is applied at the fed side.
Does this PR introduce a breaking change or deprecate an API?