[WIP] HVDC AC emulation outerloop #1048

Hadrien-Godard · 2024-06-14T09:36:01Z

Please check if the PR fulfills these requirements

The commit message follows our guidelines
Tests for the changes have been added (for bug fixes / features)
Docs have been added / updated (for bug fixes / features)

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?

Yes
No

Signed-off-by: Hadrien <[email protected]>

src/main/java/com/powsybl/openloadflow/DefaultAcOuterLoopConfig.java

vidaldid-rte · 2024-06-18T14:14:50Z

src/main/java/com/powsybl/openloadflow/ac/outerloop/AcEmulationOuterLoop.java

+                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);


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 ?

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

vidaldid-rte · 2024-06-18T14:49:53Z

src/main/java/com/powsybl/openloadflow/ac/outerloop/AcEmulationOuterLoop.java

+
+        for (LfHvdc hvdc : context.getNetwork().getHvdcs()) {
+            if (!hvdc.isAcEmulation() || hvdc.getBus1().isDisabled() || hvdc.getBus2().isDisabled() || hvdc.isDisabled()) {
+                continue;


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.

Ok I will try that

vidaldid-rte · 2024-06-18T14:57:29Z

src/main/java/com/powsybl/openloadflow/dc/DcAcEmulationOuterLoop.java

+                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);


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 ?

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.

vidaldid-rte

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 ?

Hadrien-Godard · 2024-06-18T15:16:10Z

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.

vidaldid-rte · 2024-06-18T15:30:17Z

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]
@Hadrien-Godard I also think that the comparison with PV/PQ switching is incorrect. When Generators are blocked in PQ, they may not honnor a goal to control voltage. But the solution is physically correct. The values of angles, V, P, Q follow the physics.l

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.
OpenLoadFlow should NOT return a convergence status if this situation happened. And the current implementations provides no such warranty.

Hadrien-Godard · 2024-06-24T12:59:57Z

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] @Hadrien-Godard I also think that the comparison with PV/PQ switching is incorrect. When Generators are blocked in PQ, they may not honnor a goal to control voltage. But the solution is physically correct. The values of angles, V, P, Q follow the physics.l

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. OpenLoadFlow should NOT return a convergence status if this situation happened. And the current implementations provides no such warranty.

Hello @vidaldid-rte , thank you for your reply.
Yes you are right, there is a question about results interpretation. Notably, one could end up with a flow at 0 on a HVDC link and with a non-null angle difference at its ends.

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.
Or we can drop the side shifting count, and consider that there is no maximal side shifting. In this case, impossible convergence will lead to "max outerloop" exit criteria. It is still better than current main branch "NR divergence" exit criteria.

The question also holds for an Hvdc link blocked to Pmax.

Maybe @geofjamg has an opinion on this.

Signed-off-by: Hadrien <[email protected]>

sonarcloud · 2024-06-24T13:45:19Z

Quality Gate failed

Failed conditions
88.3% Coverage on New Code (required ≥ 90%)

See analysis details on SonarCloud

Hadrien-Godard added 23 commits May 27, 2024 15:53

AcEmulationControl

7b3b61c

Signed-off-by: Hadrien <[email protected]>

Continuing AcEmulationControl

14ea87e

Signed-off-by: Hadrien <[email protected]>

Merge remote-tracking branch 'origin/main' into ac_emulation_outerloop

e334a54

AcEmulationControl end

5bee2ba

Signed-off-by: Hadrien <[email protected]>

AcEmulationOuterLoop

2384e46

Signed-off-by: Hadrien <[email protected]>

Merge remote-tracking branch 'origin/main' into ac_emulation_outerloop

ec34c48

HvdcAcEmulationSide1ActiveFlowEquationTerm

4cf7a20

Signed-off-by: Hadrien <[email protected]>

Continuing outerloop

52edfd9

Signed-off-by: Hadrien <[email protected]>

End outerloop

2aaba91

Signed-off-by: Hadrien <[email protected]>

Merge branch 'main' into ac_emulation_outerloop

93d7de0

Fix typos

448652a

Signed-off-by: Hadrien <[email protected]>

Fix tests

25ad3a8

Signed-off-by: Hadrien <[email protected]>

Fix tests

1c22515

Signed-off-by: Hadrien <[email protected]>

Reporter

39bf64a

Signed-off-by: Hadrien <[email protected]>

Reporter test fix

7e30920

Signed-off-by: Hadrien <[email protected]>

Fix

8b596e8

Signed-off-by: Hadrien <[email protected]>

Tests ok

2f44f84

Signed-off-by: Hadrien <[email protected]>

Fix

510192e

Signed-off-by: Hadrien <[email protected]>

DcLoadFlow

eb70309

Signed-off-by: Hadrien <[email protected]>

Refacto

5897654

Signed-off-by: Hadrien <[email protected]>

Test

305a6a4

Signed-off-by: Hadrien <[email protected]>

Listeners

5d43d95

Signed-off-by: Hadrien <[email protected]>

New test

d295f9c

Signed-off-by: Hadrien <[email protected]>

vidaldid-rte reviewed Jun 18, 2024

View reviewed changes

src/main/java/com/powsybl/openloadflow/DefaultAcOuterLoopConfig.java Outdated Show resolved Hide resolved

vidaldid-rte reviewed Jun 18, 2024

View reviewed changes

src/main/java/com/powsybl/openloadflow/ac/outerloop/AcEmulationOuterLoop.java Outdated Show resolved Hide resolved

vidaldid-rte reviewed Jun 18, 2024

View reviewed changes

vidaldid-rte requested changes Jun 18, 2024

View reviewed changes

Merge branch 'main' into ac_emulation_outerloop

c174274

Hadrien-Godard added 2 commits June 24, 2024 15:42

Rename

198c4e1

Signed-off-by: Hadrien <[email protected]>

Merge remote-tracking branch 'origin/main' into ac_emulation_outerloop

2521db6

jeandemanged changed the title ~~Ac emulation outerloop~~ [WIP] HVDC AC emulation outerloop Oct 11, 2024

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

[WIP] HVDC AC emulation outerloop #1048

[WIP] HVDC AC emulation outerloop #1048

Hadrien-Godard commented Jun 14, 2024 •

edited by jeandemanged

Loading

vidaldid-rte Jun 18, 2024

Hadrien-Godard Jun 18, 2024

vidaldid-rte Jun 18, 2024

Hadrien-Godard Jun 18, 2024

vidaldid-rte Jun 18, 2024

Hadrien-Godard Jun 18, 2024

vidaldid-rte left a comment

Hadrien-Godard commented Jun 18, 2024

vidaldid-rte commented Jun 18, 2024 •

edited

Loading

Hadrien-Godard commented Jun 24, 2024

sonarcloud bot commented Jun 24, 2024

[WIP] HVDC AC emulation outerloop #1048

Are you sure you want to change the base?

[WIP] HVDC AC emulation outerloop #1048

Conversation

Hadrien-Godard commented Jun 14, 2024 • edited by jeandemanged Loading

vidaldid-rte Jun 18, 2024

Choose a reason for hiding this comment

Hadrien-Godard Jun 18, 2024

Choose a reason for hiding this comment

vidaldid-rte Jun 18, 2024

Choose a reason for hiding this comment

Hadrien-Godard Jun 18, 2024

Choose a reason for hiding this comment

vidaldid-rte Jun 18, 2024

Choose a reason for hiding this comment

Hadrien-Godard Jun 18, 2024

Choose a reason for hiding this comment

vidaldid-rte left a comment

Choose a reason for hiding this comment

Hadrien-Godard commented Jun 18, 2024

vidaldid-rte commented Jun 18, 2024 • edited Loading

Hadrien-Godard commented Jun 24, 2024

sonarcloud bot commented Jun 24, 2024

Quality Gate failed

Hadrien-Godard commented Jun 14, 2024 •

edited by jeandemanged

Loading

vidaldid-rte commented Jun 18, 2024 •

edited

Loading