DC Load Flow reference bus and multi slack support

[vmouradian]

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?

Handles multi slack for DC load flow
Fixes #1117

What kind of change does this PR introduce?

Feature and bugfix

What is the current behavior?

see #1117

What is the new behavior (if this is a feature change)?
DC Load Flow properly account for the selected reference bus - also important for the DC Values Voltage Initializer before the Newton-Raphson.
Only first slack bus has p balance equation deactivated.
For other slack buses the corresponding value in target vector is updated : (finalTarget = targetP + totalSlack/nbSlackBuses)

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

• No

[jeandemanged]

I would be nice also to explain multi slack handling in documentation.
In DC we can take shortcuts because it is a lossless model. In AC it is a different story.

[geofjamg]

I would be nice also to explain multi slack handling in documentation. In DC we can take shortcuts because it is a lossless model. In AC it is a different story.

So what is the purpose of this feature? In AC, the only aim was to allow convergence for very specific model (large and very imbalanced that was diverging at first NR). But in DC with just a simple linear system solving what could be the point?

[jeandemanged]

I would be nice also to explain multi slack handling in documentation. In DC we can take shortcuts because it is a lossless model. In AC it is a different story.

So what is the purpose of this feature? In AC, the only aim was to allow convergence for very specific model (large and very imbalanced that was diverging at first NR). But in DC with just a simple linear system solving what could be the point?

This is useful and needed solely when a DC voltage init is used before AC NR, we need to produce angles consistent with what the AC NR is trying to solve. Note that here is also solved an issue about angle reference.

[geofjamg]

I would be nice also to explain multi slack handling in documentation. In DC we can take shortcuts because it is a lossless model. In AC it is a different story.

So what is the purpose of this feature? In AC, the only aim was to allow convergence for very specific model (large and very imbalanced that was diverging at first NR). But in DC with just a simple linear system solving what could be the point?

This is useful and needed solely when a DC voltage init is used before AC NR, we need to produce angles consistent with what the AC NR is trying to solve. Note that here is also solved an issue about angle reference.

Ok it makes sense. Thanks.

[jeandemanged]

ty

[SylvestreSakti]

Can we imagine parametrizing the tests in AcMultipleSlackBusesTests rather than having a whole class DcMultipleSlackBusesTest that implements the same cases ? (To do so maybe a condition can be added in the test to differentiate asserts values between AC and DC)
By doing so, when adding new tests in the future, we would be sure to implement them in both AC and DC mode.

[vmouradian]

I agree, here a proposal for this : 2b39a11, what do you think ?

[SylvestreSakti]

Thank you ! It is good for me. #1116 has been merged so the values can be changed for the corresponding test.

[vmouradian]

I updated the values in a6ab981

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud