Check too far generator voltage remote control

[SylvestreSakti]

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 change introduces a new feature that checks if a controller bus is too far from its generator controlled bus when using voltage remote control (introducing a new parameter which is maxGeneratorVoltageRemoteControlDistance)

What is the current behavior?
There is no check of distance between buses

What is the new behavior (if this is a feature change)?
If a controller bus has a distance (number of branches) to its controlled bus that is higher than maxGeneratorVoltageRemoteControlDistance, then the voltage remote control switches to local voltage control.

(maxGeneratorVoltageRemoteControlDistance = 0 (or a negative value) deactivates the distance check. Default value for this parameter is 2)

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

• Yes
• No

[vidaldid-rte]

As discussed, can you also run this test during a contingence propagation (and make sure the status is correctly restored at the end).
The goal is to avoid a divergence in an AS or a Sensi computation if a line loss extends the distance between a group and its regulated point and make the next NR fail.

[geofjamg]

This is an unusual way to implement a BFS. We can do it much simpler without these kind of set manipulation (busesToCheck.removeAll(checkedBuses)). Also we should take care for a BFS to have an orderer neighbors traversal (be careful with HashSets)

[vidaldid-rte]

Can you add a unit test for the method with various cases (exected distance, farther than maxDistance etc..)

[SylvestreSakti]

This is an unusual way to implement a BFS. We can do it much simpler without these kind of set manipulation (busesToCheck.removeAll(checkedBuses)). Also we should take care for a BFS to have an orderer neighbors traversal (be careful with HashSets)

Reading again more conventional ways to implement breadth First Search (e.g. https://www.baeldung.com/java-breadth-first-search), I don't know (or I don't find) simpler ways to implement this. Here I chose this way of using sets for multiple reasons :

• Instead of iterating over LfBus (in a classical Queue), I prefered to iterate over levels of distance to easily keep track of this growing distance which is the main output
• This way of iterating goes well with the findNeighbors() method of LfBus that returns a map and its keySet listing all the neighbors

With this way of iteration (levels of distance) is it important to have an ordered neighbors traversal ?

[geofjamg]

Ok

[vidaldid-rte]

@geofjamg @SylvestreSakti shouldn't this be put into #1115
This way it could be used:

• to detect incorrect voltage controls
• to remove (or switch to local ?) incorrect remote voltage controls

[geofjamg]

@geofjamg @SylvestreSakti shouldn't this be put into #1115 This way it could be used:

• to detect incorrect voltage controls
• to remove (or switch to local ?) incorrect remote voltage controls

This is somehow related to #1115 indeed but #1115 is already quite large and we should keep it separatly.
Regarding #1115, it will be a useful feature only if we are able to discard a majority a inconsistencies (and making bad cases mosttly converging). If not the case I would go for abandonning it. Anyway I didn't finished this work and there I still have some ideas to test.

[vidaldid-rte]

@geofjamg @SylvestreSakti shouldn't this be put into #1115 This way it could be used:

• to detect incorrect voltage controls
• to remove (or switch to local ?) incorrect remote voltage controls

This is somehow related to #1115 indeed but #1115 is already quite large and we should keep it separatly. Regarding #1115, it will be a useful feature only if we are able to discard a majority a inconsistencies (and making bad cases mosttly converging). If not the case I would go for abandonning it. Anyway I didn't finished this work and there I still have some ideas to test.

OK. Let's put this on hold for now. My note was more related to the idea of creating a service as we have in #115 to detect inconsistent voltage control in an IIDM network. If we do that then I wonder if we should not show all voltage controls that are removed by OLF (such as this one - too far control) but also others existing (unrealistic / qmax-qmin to small etc...)

[EDIT] In breaker mode, we may want to ignore zero impedance branches such as switch.

review handover

[vidaldid-rte]

As discussed, can you also run this test during a contingence propagation (and make sure the status is correctly restored at the end). The goal is to avoid a divergence in an AS or a Sensi computation if a line loss extends the distance between a group and its regulated point and make the next NR fail.

As discussed - let's keep that refinement for later, it we see a problem with that.

[jeandemanged]

Please clarify that this is only for generator remote voltage control:

• in MR title
• in parameter name
• in documentation

And also precising in the doc that generator means here: generators + svcs + vsc converters.

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

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

See analysis details on SonarQube Cloud

[SylvestreSakti]

Please clarify that this is only for generator remote voltage control:

• in MR title
• in parameter name
• in documentation

And also precising in the doc that generator means here: generators + svcs + vsc converters.

Thanks for this precision. Done !

[vidaldid-rte]

I delay my approval since we are not certain of the right default. I would like to better understand what is a legitimate distance.