[WIP] Fix boundary does not have the same power on each side

[OpenSuze]

I am looking for some help on this PR.
This is not urgent at all :)
Thank you in advance !

TODO:

• check electrotech ?
• move DanglingLineBoundaryImpl.java to API
• add doc
• ask for a new IIDM version ?
• add some integration tests to ensure same power on both side of the boundary
• add some integration tests by replacing the tie line with a dangling line
• check the behavior when a tie line is partially disconnected (only on one side)

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?

I have an issue that after an AC load flow, power on each side of the boundary may be different.

tieLine.getDanglingLine1().getBoundary().getP() != tieLine.getDanglingLine2().getBoundary().getP()

What kind of change does this PR introduce?

Bug fix

What is the current behavior?

The current behavior is that by default the shunt admittance will be split.
This is wrong with a UCT network. (check this for other formats ? CGMES ?)

What is the new behavior (if this is a feature change)?
I found strange to use a line equivalent model (ie splitting the shunt admittance) for a dangling line.
So I tried to disable this behavior to fix the issue and it seems to work.

A new parameter hasShuntAdmittanceLineEquivalentModel has been added to specify if a dangling line has a shunt admittance line equivalent model or not.
This parameter has no default value to see its impacts for the moment.
I was not able to fix such default value (true should keep the old behavior, but I disagree with this behavior).
I added a parameter for backward compatibility issues XIIDM.
I found this PR #1728 that gives some details about the history.

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:

[sonarqubecloud]

Quality Gate passed

Issues
3 New issues
0 Accepted issues

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

See analysis details on SonarCloud

[jeandemanged]

Hi @OpenSuze, cc @So-Fras @geofjamg

This might actually be urgent, as I see it, DanglingLine shunt admittance is network side only, OLF makes the computation in line with this.
I would argue that DanglingLineBoundaryImpl calculating V, Angle, P, Q at boundary considering that the shunt admittance is split between network side and boundary side is a bug.

As you mentioned, this is wrong for UCTE-DEF. This is wrong too for CGMES as this may cause SV-s to be issued with imbalances at boundary. And actually this is not an imported network format problem, but an iIDM calculation problem.

This problem is quite impacting, as you found out here in powsybl/powsybl-entsoe#161, and we are also experiencing it in powsybl/powsybl-open-loadflow#1055.

I would propose to fix it quickly, ideally in the current release train and in this PR:

• not modifying iIDM format / removing the addition of DanglingLine.hasShuntAdmittanceLineEquivalentModel attribute. DanglingLine-s has only one shunt admittance network side.
• Repairing DanglingLineBoundaryImpl to NOT split shunt admittance
• (adjusting unit tests wherever needed)

I do not know why DanglingLineBoundaryImpl was built always assuming split shunt admittance, there may be historical reasons I am not aware of...

Thanks for feedback.
Damien

[OpenSuze]

Hi @jeandemanged,

I tried to force DanglingLineBoundaryImpl to NOT split shunt admittance.
There were a few broken test in iidm-impl but it was easy to fix them.

However, I had a lot of issues with the retrocompatibility tests of iidm-serde.
This is why I added this parameter DanglingLine.hasShuntAdmittanceLineEquivalentModel.

But I agree, this is not a good idea.
We could really use some help !

[OpenSuze]

Fixed in #3169