CGMES: adjust multiple unpaired dangling lines connected at same boundary node #2737
Conversation
Signed-off-by: Luma <zamarrenolm@aia.es>
| .forEach(dls -> adjustMultipleUnpairedDanglingLinesAtSameBoundaryNode(dls, context)); | ||
| } | ||
|
|
||
| private void adjustMultipleUnpairedDanglingLinesAtSameBoundaryNode(List<DanglingLine> dls, Context context) { |
There was a problem hiding this comment.
After a talk with my colleague, it seems that it is not the good solution because the merge will not work. Imagine we have 3 DLs with the same pairing key (1 disconnected and 2 connected). On the other side, we have 2 DLs with the same pairing key (both connected). If they are disconnected, they are excluded from the merging. If they are connected, we do nothing without any error message. I think we have to:
- Warn the user during the merge in order to create by hand the remaining tie lines ;
- Or :
- Put all the
P0andQ0on one DL that keep the good pairing key ; - For the other ones connected, we put zero and we change the pairing key (with #0 or something else). But which one chosen ? And on the other side ? The merge will be done in creating a tie line of 2 arbitrary dangling lines (and maybe not the good ones).
I am lost :-)
There was a problem hiding this comment.
But the merge scenario you discuss has nothing to do with this change.
This change just improves on how do you see the ONLY equivalent injection that exists in one IGM, when you have MULTIPLE (all connected) dangling lines.
I would discuss separately the function required for perform a merge when multiple dangling lines from each side exist at a single boundary point.
There was a problem hiding this comment.
I think the cleanest solution for the scenario you describe is that the user creates a modified boundary file, with a new connectivity/topological node. The user MUST then specify which lines go to each boundary node, in a way that always leaves only one line of each IGM at each boundary node.
If we do not want to modify the boundary file and the IGM to use the new (not "official" boundary point), then we can arbitrarily try to merge any pair of candidates or let the user configure it in some way. But this seems quite "dirty" for me: what happens if we have two connected lines in one side and only one in the other? How do we let the user specify the "correct" pairs to be merged? a parameter?
There was a problem hiding this comment.
Going a little bit further about merging multiple dangling lines in the same node:
We can try to pair the dangling lines from each side that have "closer values" of (p0, q0) (similar equivalent injection).
Following this idea, If there are 2 lines on one side and only one in the other: a tie line will be created, and a dangling line will be left on one side.
What do you think of this alternative ?
In any case, I think these considerations should go in a separate PR.
There was a problem hiding this comment.
We are going to open a new PR to increase merge logging, in order to warn the user that he has to do something!
…s_at_same_boundary_node
Signed-off-by: Luma <zamarrenolm@aia.es>
Signed-off-by: Anne Tilloy <anne.tilloy@rte-france.com>
…oundary_node' of https://github.com/powsybl/powsybl-core into cgmes_adjust_multiple_unpaired_dangling_lines_at_same_boundary_node
Signed-off-by: Luma <zamarrenolm@aia.es>
…s_at_same_boundary_node
This reverts commit bba7463.
…oundary_node' of https://github.com/powsybl/powsybl-core into cgmes_adjust_multiple_unpaired_dangling_lines_at_same_boundary_node
…s_at_same_boundary_node
|
Kudos, SonarCloud Quality Gate passed! |
annetill
deleted the
cgmes_adjust_multiple_unpaired_dangling_lines_at_same_boundary_node
branch
Please check if the PR fulfills these requirements
Does this PR already have an issue describing the problem?
What kind of change does this PR introduce?
Bug fix
What is the current behavior?
When multiple unpaired dangling lines have the same boundary node (it means they are different alternatives from the same TSO), all of them receive the same value of (p0, q0), equal to the total equivalent injection defined at the boundary node.
What is the new behavior (if this is a feature change)?
After the import, the total equivalent injection is split between all dangling lines connected at the boundary node.
The adjustment is made after handling dangling lines only disconnected at boundary (that may be potentially disconnected also at network side if configuration indicates it).
Does this PR introduce a breaking change or deprecate an API?
Other information: