LfAction refactoring and area interchange target action support #1172

obrix · 2025-01-16T15:59:02Z

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 issue

What kind of change does this PR introduce?

Add the support of AreaInterchangeTarget action and change the implementation of LfAction.
LfAction existing design was confusing as everything was handled in the unique LfAction object.
A proper class hierarchy has been setup so as the make feature extension and maintenance easier.

What is the current behavior?

All actions implemented in the LfAction object. Created through the create method and applied through the global update connectivity method (for switch and terminal connection actions) and apply method.
Each instance of LfAction was capable of describing all kind of actions through all the available attributes but a single instance was created per iidm action.

What is the new behavior (if this is a feature change)?

All action creation and application processes are implemented in dedicated class, with common code in AbstractLfAction for all actions and additional AbstractLfBranchAction for switch and terminal connection action (they both impact topology).

Applying the action can be done through a call to the apply method or through a call to LfActionUtils.applyListOfActions. This last method, in a similar way that was done before the refactoring, apply a list of action by first applying the actions modifying topology and then the rest of the actions.

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:

obrix · 2025-01-21T13:20:27Z

Note for the reviewer : There was no specific rule about crashing or outputing a warning when an action cannot be applied so I kept more or less the same behavior for each action. Some of the warning / exception raising have been moved from construction to action application though.

In my opinion I would prefer to raise warning and eventually have something in the output API to query which action has been applied rather that raising an exception for potentially a single wrong action and losing all the analysis.

obrix · 2025-01-22T09:33:42Z

To sum up a bit, there is 4 cases of action setup that causes an exception raise :

• For TapChangerAction, if the PiModel is a SimpleModel (no tap changer on the transformer) -> throw UnsupportedOperationException
• For GeneratorAction, if we want to do something else than simply set an active power target (with absolute or relative value) : throw UnsupportedOperationException
• For HvdcAction, if ac emulation is already enabled -> throw UnsupportedOperationException
• For TerminalsConnectionAction, is a side is provided -> throw UnsupportedOperationException (only both side can be opened / closed)

Those exception are the same as before the refactoring. All other potential issue are only outputting a warning, for example a branch not found in the network for a TerminalsConnectionAction.

I also added a global warning for failing to apply an action in LfActionUtils, which might lead to a lot of warning when doing a security analysis on multiple component. So not sure we should keep that.

src/test/java/com/powsybl/openloadflow/sa/LfActionTest.java

src/main/java/com/powsybl/openloadflow/network/action/LfActionUtils.java

src/main/java/com/powsybl/openloadflow/network/action/LfHvdcAction.java

src/main/java/com/powsybl/openloadflow/network/action/LfGeneratorAction.java

src/main/java/com/powsybl/openloadflow/network/action/LfHvdcAction.java

vidaldid-rte · 2025-02-04T13:29:59Z

src/main/java/com/powsybl/openloadflow/network/action/LfHvdcAction.java

+        if (lfHvdc != null) {
+            if (action.isAcEmulationEnabled().isEmpty()) {
+                LOGGER.warn("Hvdc action {}: only explicitly disabling ac emulation is supported.", action.getId());
+                return false;


Wouldn't a report be better ? (It is the kind of information a user needs to know)

(Well - I realize that the old class used a lot logs instead of reports to communicate about action issues... Let me know if this is something you want to handle in this PR or that should be done later).

Also, this log is an improvement over the previous code that kept this error silent. Thanks !

I am not sure the original behavior for this was really thought out but yes at least there is a warning now.
For the report that may be a good idea indeed, but I would have to update all the action to be coherent and report everything probably. I would prefer to do it in another PR if that's okay for you.

src/main/java/com/powsybl/openloadflow/network/action/AbstractLfBranchAction.java

src/main/java/com/powsybl/openloadflow/network/action/LfActionUtils.java

src/main/java/com/powsybl/openloadflow/network/action/LfGeneratorAction.java

src/main/java/com/powsybl/openloadflow/network/action/LfShuntCompensatorPositionAction.java

vidaldid-rte

It's good for me. It would be nice and useful to change all the warning logs about reasons for not performing an action to reports, but I'm OK to commit this first step as providing a better user feedback was not the main goal of this PR.
This PR makes the action code much easier to read and understand.

Area interchange target action support. Signed-off-by: Bertrand Rix <[email protected]> Full refacto of LfAction. Signed-off-by: Bertrand Rix <[email protected]> Author and copyrights. Signed-off-by: Bertrand Rix <[email protected]> LfAction interface on top. Signed-off-by: Bertrand Rix <[email protected]> Clean. Signed-off-by: Bertrand Rix <[email protected]> Basic test for LfAreaInterchangeTargetAction. Signed-off-by: Bertrand Rix <[email protected]> Rework copyright and author to reflect history. Signed-off-by: Bertrand Rix <[email protected]> Add test for AreaInterchangeTargetAction usage within the security analysis. Signed-off-by: Bertrand Rix <[email protected]> Fix sonar issue and use apply return boolean to warn about potential failure of applying an action. Signed-off-by: Bertrand Rix <[email protected]> Oops. Signed-off-by: Bertrand Rix <[email protected]> Ref to new supported action. Signed-off-by: Bertrand Rix <[email protected]> Remove space. Signed-off-by: Bertrand Rix <[email protected]> PiModel already tested at construction. Signed-off-by: Bertrand Rix <[email protected]> Report instead of warn the failure of application of an action. Signed-off-by: Bertrand Rix <[email protected]> Unused logger. Signed-off-by: Bertrand Rix <[email protected]> Clean. Signed-off-by: Bertrand Rix <[email protected]> Move all exception raising at construction of the actions. Rework hvdc action. Signed-off-by: Bertrand Rix <[email protected]> Update message. Signed-off-by: Bertrand Rix <[email protected]> Unused parameters. Signed-off-by: Bertrand Rix <[email protected]> Unused parameters. Signed-off-by: Bertrand Rix <[email protected]> Per unit division in record. Signed-off-by: Bertrand Rix <[email protected]> Direct call to update connectivity. Signed-off-by: Bertrand Rix <[email protected]> Restore comment Signed-off-by: Bertrand Rix <[email protected]> If no branch to change found exit early. Signed-off-by: Bertrand Rix <[email protected]> Shunt action return false if no controller found. Signed-off-by: Bertrand Rix <[email protected]>

sonarqubecloud · 2025-02-04T15:19:29Z

Quality Gate passed

Issues
1 New issue
0 Accepted issues

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

See analysis details on SonarQube Cloud

obrix changed the title ~~LfAction refacto and area interchange target action support~~ [WIP] LfAction refacto and area interchange target action support Jan 16, 2025

obrix changed the title ~~[WIP] LfAction refacto and area interchange target action support~~ LfAction refacto and area interchange target action support Jan 20, 2025

obrix requested a review from jeandemanged January 20, 2025 08:20

m-guibert reviewed Jan 23, 2025

View reviewed changes

src/test/java/com/powsybl/openloadflow/sa/LfActionTest.java Show resolved Hide resolved

m-guibert assigned obrix Jan 23, 2025

m-guibert added Release 03/2025 Breaking Change labels Jan 23, 2025

m-guibert reviewed Jan 23, 2025

View reviewed changes

src/main/java/com/powsybl/openloadflow/network/action/LfActionUtils.java Show resolved Hide resolved

obrix removed the Breaking Change label Jan 24, 2025

vidaldid-rte reviewed Jan 24, 2025

View reviewed changes

src/main/java/com/powsybl/openloadflow/network/action/LfActionUtils.java Show resolved Hide resolved

jeandemanged changed the title ~~LfAction refacto and area interchange target action support~~ LfAction refactoring and area interchange target action support Jan 26, 2025

jeandemanged linked an issue Jan 27, 2025 that may be closed by this pull request

Support area interchange actions in SA with Operator Strategies #1090

Closed

obrix force-pushed the area_interchange_target_action_support branch from 6267896 to 3ec6d46 Compare January 27, 2025 13:43

vidaldid-rte reviewed Jan 29, 2025

View reviewed changes

src/main/java/com/powsybl/openloadflow/network/action/LfHvdcAction.java Show resolved Hide resolved

vidaldid-rte reviewed Jan 29, 2025

View reviewed changes

src/main/java/com/powsybl/openloadflow/network/action/LfGeneratorAction.java Show resolved Hide resolved