Support disconnection of DC elements in the load flow by bperr · Pull Request #1471 · powsybl/powsybl-open-loadflow

bperr · 2026-07-24T07:21:04Z

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)
A PR or issue has been opened in all impacted repositories (if any)

Does this PR already have an issue describing the problem?

No

What kind of change does this PR introduce?

Feature

What is the current behavior?

The AC-DC load flow did not consider wheher DC terminals of elements were connected or disconnected.

What is the new behavior (if this is a feature change)?
Disconnnected elements are properly taken into account during load flow

Does this PR introduce a breaking change or deprecate an API?

Yes
No

If yes, please check if the following requirements are fulfilled

The Breaking Change or Deprecated label has been added
The migration steps are described in the following section

What changes might users need to make in their application due to this PR? (migration steps)

Other information:

Signed-off-by: b.perreyon <baptiste.perreyon@supergrid-institute.com>

SGI-Landry

Thanks for this activity @bperr !
There are a few minor comments here and there. I think however that we should discuss tests in AcDcLoadFlowWithDisconnectionTest.

SGI-Landry · 2026-07-27T09:48:45Z

+    }
+
+    /**
+     * Verify the DC node voltage is coherent with the nominal voltage


Suggested change

* Verify the DC node voltage is coherent with the nominal voltage

* Verify the DC node voltage is consistent with the nominal voltage

But is this really needed? I would expect that you should know what values to expect precisely from your test cases, rather than test that the value is finite and "small enough".

SGI-Landry · 2026-07-27T13:05:13Z

+import static org.junit.jupiter.api.Assertions.*;
+
+/**
+ * @author Baptiste Perreyon {@literal <bapstiste.perreyon at supergrid-institute.com>}


Suggested change

* @author Baptiste Perreyon {@literal <bapstiste.perreyon at supergrid-institute.com>}

* @author Baptiste Perreyon {@literal <baptiste.perreyon at supergrid-institute.com>}

SGI-Landry · 2026-07-27T15:27:59Z

+ * @author Baptiste Perreyon {@literal <bapstiste.perreyon at supergrid-institute.com>}
+ */
+@ExtendWith(ServiceParameterResolver.class)
+class AcDcLoadFlowWithDisconnectionTest {


This can be simplified and made more robust. Can we please write down what behaviors to expect in a if condition then expectation way, and create just these tests, over observable behaviors? This should rely on analytical cases when this is numerical, with comparisons to expected values.

SGI-Landry · 2026-07-27T16:03:25Z

            // lcc converter not implemented yet
+        } else {
+            // Remove previous load flow results (we don't want the user to believe this are results from the new load flow)
+            acDcConverter.unsetSolvedValues();


Very good point. However, a converter whose DC terminals are both disconnected belongs to no DcBus so it is never added to the acDcConverterSet in the first place.

Same issue with DcLines disconnected at both ends.

Done after the load flow in Networks.resetState as all other equipments

SGI-Landry · 2026-07-27T16:18:08Z

+ *
+ * @author Baptiste Perreyon {@literal <baptiste.perreyon at supergrid-institute.com>}
+ */
+final class DcNetworkValidationHelpers {


Good call to factor out these static functions. I am wondering if it is possible to simplify this code a bit. Maybe extract the topology visitor, and replace the predicate on converters by a boolean stating whether the test is needed or not?

Signed-off-by: b.perreyon <baptiste.perreyon@supergrid-institute.com>

SGI-Landry

Thanks for largely simplifying tests! Can you please make sure that the behaviors you want to test are perfectly clear? I suggest writing them down in comments as if condition then expectation. Then you will be sure you are testing exactly what you want.

SGI-Landry · 2026-08-28T13:12:44Z

+        double dcLineR = network.getDcLine("dl34").getR(); // 0.1 Ohm
+        double expectedDcCurrent = 125; // 50 MW/400kV = 125A
+        // Check DC current
+        assertEquals(-expectedDcCurrent, network.getVoltageSourceConverter("conv23").getDcTerminal1().getI(), 1e-2);


How is the tolerance chosen?
1e-2 absolute ~ 1e-5 relative. Not bad, but depending on convergence parameters we can probably do better.

What about

checking the convergence parameters to decide on the relative tolerance.

factor it in a named constant, and document the choice.

1e^-2 is the default tolerance in OLF for Newton-Raphson.
I imported it in the test from NewtonRaphsonStoppingCriteria.java in which it is defined in p.u.

SGI-Landry · 2026-08-28T13:18:24Z

+
+    @Test
+    void dcLineTotalDisconnection() {
+        /// Same case study as dcLinePartialDisconnection. However, both terminals of the DC line are disconnected.


There seems to be a copy-paste error here. Code is inconsistent with the comment.

May I suggest to do this test at the end of the previous function? We would have

Results with both lines connected.

Results with one line disconnected.

Results with both lines disconnected.

The difference between the two test is whether the DC line is disconnected on one side or on both side; not whether there is one or two lines disconnected.

However its true that running the load flow on the fully connected network in the two tests brings no added value. I'll merge the two tests

SGI-Landry · 2026-08-28T13:21:03Z

+    }
+
+    @Test
+    void dcLineDisconnectionLeadsToZeroCurrentInConverter() {


I don't understand the difference with the previous test cases. Does it make sense to regroup them? I miss the general intent. What is your activity supposed to implement and what simple behaviors do you want to check?

In the previous test case, the disconnection of the DC line did not prevent the current to pass in the DC network (because there was a second DC line).
Here the disconnection of the DC line isolates the positive layer and triggers the automatic update of a converter's control mode. Additionnaly there is no DC current in this converter so its AC consumption corresponds to its idle loss

You are making a good point. It would be very helpful to put this in your comments. Does this mean that you are testing "isolate the pole of a VSC => trigger automatic update of control mode" and maybe "=> zero DC current"? Then is it possible to check it more directly?

I reformulated the comment hoping it is clearer now, but this was already mentioned.

In the test, I already check that the DC current in the isolated converter is 0.
As for the automatic update of the control mode, the IIDM is left untouched, so we cannot check it directly. However, what is already tested is that the voltage difference between the two DC buses of the converter is exactly 400 kV (the nominal voltage, set as targetVdc when the control mode of the converter is updated)

SGI-Landry · 2026-08-28T13:23:41Z

+    @Test
+    void testAcDcConverterDisconnectionLeadsToZeroCurrentInNearbyIsolatedDcLines() {
+        /// When disconnecting the converter, the current in the DC line at the disconnected pole (positive) should be
+        /// null, but the current should still pass through the negative and neutral pole, due to the second converter.


I would state the expected behavior as something like

Disconnecting a terminal of a VSC removes the equations from its branch but not of the others.

Is this what you want to test?

The network is a bipolar connection with DMR. When removing a converter with positive and neutral layer, the positive layer is isolated and no current can pass through it. However, the neutral layer is still connected to the negative layer, so the current can pass here. This is what this test verifies.

I don't understand what you mean by 'branch' here so I am not confortable with your proposal.

Signed-off-by: b.perreyon <baptiste.perreyon@supergrid-institute.com>

SGI-Landry · 2026-08-31T18:57:49Z

+    }
+
+    @Test
+    void dcLineDisconnectionLeadsToZeroCurrentInConverter() {


You are making a good point. It would be very helpful to put this in your comments. Does this mean that you are testing "isolate the pole of a VSC => trigger automatic update of control mode" and maybe "=> zero DC current"? Then is it possible to check it more directly?

Signed-off-by: b.perreyon <baptiste.perreyon@supergrid-institute.com>

jeandemanged

Thank you
This is a quite large PR with more features that the PR title and description suggests, please break it down because it makes reviewing difficult. for example:

import also DC components in LfNetwork (my other comment, is there any reason to not just use the islands computed by IIDM?)
the "Sanity checks : detecting invalid DC configuration and automatically resolving reference-less islands"
a fix to set unsolved values (Networks.java)
support of disconnected elements

also please check for sonar (coverage and issues).

jeandemanged · 2026-09-03T14:20:45Z

+    /**
+     * The set of DC buses reachable from a DC bus by following connected DC lines, together with
+     * the connected DC grounds and the AC-DC converters attached to them. Built by breadth-first search.
+     */
+    private static final class DcIsland implements DcTopologyVisitor {


I am wondering why this is needed, all topology processing: AC islands, DC islands, Connected AC/DC islands are already computed within IIDM.

LfNetwork-s are built from IIDM connected component-s
LfSynchronousNetwork are built from IIDM synchronous component-s

Instead of recomputing islands because of information lost at LfNetwork loading time, I think you should create for example LfDcNetwork from IIDM DC component-s at LfNetwork loading time.

I realise the name of this class conflicts with the DC Island concept (I only had DC component wording in mind, sorry), and the docstring may be a bit unclear.

Here the only elements used to navigate between DC buses are DC lines. Therefore, one can only reach DC buses of the same layer (positive/neutral/negative) which is different from the DC island computed in IIDM. I'll refactor this to make it clear.

Side note: This process is done using the original Network object not the LfNetwork, so no information has been lost at this stage.

I would add that when a DC line is disconnected, a "layer" may be split in two : the DC buses are not connected via the DC line anymore so their voltage are independent (so we need an element imposing it for each of them). However they are still part of the same DC component (because they are indireclty connected by converters and lines of another layer)

bperr · 2026-09-07T07:29:09Z

Hi @jeandemanged , thanks for your review !
The scope of this PR has indeed quite grown up. If needed, I'm fine with splitting it. Else, I'll update the description as you suggested

Signed-off-by: b.perreyon <baptiste.perreyon@supergrid-institute.com>

bperr · 2026-09-10T06:50:26Z

As suggested, I have split this PR:

Fix: Reset DC state variables #1486 covers the fix on DC variables reset
Detect and auto-repair invalid DC configuration #1487 covers detection and auto-correction of invalid DC component
Support disconnection of DC elements in the load flow #1471 (this one) implements load flow with DC elements disconnection and relies on the two others

sonarqubecloud · 2026-09-10T08:01:54Z

Quality Gate passed

Issues
2 New issues
0 Accepted issues

Measures
0 Security Hotspots
94.9% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

bperr added 5 commits June 24, 2026 16:42

Add tests for DC Ground and DC line disconnection

6845ec3

Signed-off-by: b.perreyon <baptiste.perreyon@supergrid-institute.com>

Implement VSC disconnection

a595b5b

Signed-off-by: b.perreyon <baptiste.perreyon@supergrid-institute.com>

Add safeguard check to throw error on invalid DC configuration

487ed75

Signed-off-by: b.perreyon <baptiste.perreyon@supergrid-institute.com>

Small refactor and add author tag

9b6f8cd

Signed-off-by: b.perreyon <baptiste.perreyon@supergrid-institute.com>

Update docs to specify behavior on disconnection

97c772e

Signed-off-by: b.perreyon <baptiste.perreyon@supergrid-institute.com>

bperr requested a review from SGI-Landry July 24, 2026 07:26

bperr added 2 commits July 24, 2026 09:28

Merge branch 'main' into dc-disconnection

89aacde

Improve code coverage

d34f682

Signed-off-by: b.perreyon <baptiste.perreyon@supergrid-institute.com>

SGI-Landry requested changes Jul 27, 2026

View reviewed changes

bperr added 7 commits July 28, 2026 11:36

Refactor tests

4e73ea9

Signed-off-by: b.perreyon <baptiste.perreyon@supergrid-institute.com>

Refactor DcNetworkValidationHelpers in DcComponentValidator

ce3844a

Signed-off-by: b.perreyon <baptiste.perreyon@supergrid-institute.com>

Handle properly reset of previous load flow result

c5651ac

Signed-off-by: b.perreyon <baptiste.perreyon@supergrid-institute.com>

Fix checkstyle

4a5f41d

Signed-off-by: b.perreyon <baptiste.perreyon@supergrid-institute.com>

Remove failing import

b817df2

Signed-off-by: b.perreyon <baptiste.perreyon@supergrid-institute.com>

Implement automatic switching to V_DC mode

2efc11a

Signed-off-by: b.perreyon <baptiste.perreyon@supergrid-institute.com>

Add docs and tests

1bd02e3

Signed-off-by: b.perreyon <baptiste.perreyon@supergrid-institute.com>

SGI-Landry requested changes Aug 28, 2026

View reviewed changes

bperr added 3 commits August 31, 2026 09:36

Update tests

de4a25c

Signed-off-by: b.perreyon <baptiste.perreyon@supergrid-institute.com>

lint

7277e6c

Signed-off-by: b.perreyon <baptiste.perreyon@supergrid-institute.com>

Update comments in test

b2818e0

Signed-off-by: b.perreyon <baptiste.perreyon@supergrid-institute.com>

SGI-Landry requested changes Sep 1, 2026

View reviewed changes

bperr added 3 commits September 1, 2026 10:37

Update comments in test

425fb8f

Signed-off-by: b.perreyon <baptiste.perreyon@supergrid-institute.com>

Update comments in test

e04d3e9

Signed-off-by: b.perreyon <baptiste.perreyon@supergrid-institute.com>

Merge branch 'main' into dc-disconnection

75e70f8

bperr marked this pull request as ready for review September 3, 2026 12:34

bperr requested a review from SylvestreSakti September 3, 2026 12:34

jeandemanged reviewed Sep 3, 2026

View reviewed changes

bperr added 2 commits September 7, 2026 09:38

Fix code coverage issue

eddbba5

Signed-off-by: b.perreyon <baptiste.perreyon@supergrid-institute.com>

Refactor DcIsland naming in DcComponentValidator

bfbd774

Signed-off-by: b.perreyon <baptiste.perreyon@supergrid-institute.com>

Merge branch 'main' into dc-disconnection

2d5e03e

bperr changed the base branch from main to dc-component-validator September 10, 2026 06:47

Merge branch 'dc-component-validator' into dc-disconnection

e852caf

	* Verify the DC node voltage is coherent with the nominal voltage
	* Verify the DC node voltage is consistent with the nominal voltage

	* @author Baptiste Perreyon {@literal <bapstiste.perreyon at supergrid-institute.com>}
	* @author Baptiste Perreyon {@literal <baptiste.perreyon at supergrid-institute.com>}

Uh oh!

Conversation

bperr commented Jul 24, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

SGI-Landry left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

SGI-Landry left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

jeandemanged left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

bperr commented Sep 7, 2026

Uh oh!

bperr commented Sep 10, 2026

Uh oh!

sonarqubecloud Bot commented Sep 10, 2026

Quality Gate passed

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

bperr commented Jul 24, 2026 •

edited

Loading

jeandemanged left a comment •

edited

Loading