LfAction refactoring and area interchange target action support

[obrix]

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]

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.

[sonarqubecloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

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

See analysis details on SonarQube Cloud

[obrix]

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.

[m-guibert]

The behavior should change very soon, after #1156 's merge.

Because of the ContingencyLoadFlowParameters extension, AIC can be performed on some post-contingency cases even if networkParameters.isAreaInterchangeControl() is false. So Area-s will now always be created, and this assertion will fail

[obrix]

Thanks I will update if 1156 is merged before this one.

[vidaldid-rte]

Why don(t you return an optional ? The previous code could help detect NOOP actions for the network by returning an empty value if the element did not exist.
You now loose the ability to detect actions that do nothing on a given LfNetwork.

[obrix]

The old code was returning an optional but actually did not do anything with the "empty" information and just silently ignored the action.
Same checks are done in the apply method with a boolean return and a warning is logged (to be discussed maybe).
Ultimately I think the operator strategy result API should hold the info of what action was applied successfully, this is also why I designed it like this, but this a change of API to be seen in the futur..

[vidaldid-rte]

Thanks for the explanation.
But isn't there a functional change ?
In current code, I suppose there is no LF run if the list of LF actions is empty for a strategy. Is it the same here .

The point of reporting the missing action is a good point but:
Should be done in a report (users won't look at the log)
May not be relevant in the (rare ?) case of contingency and actions covering different network component.

[obrix]

In the current code, even if the list of lfAction converted from iidm actions is empty there is always a load flow done and an operator strategy result is produced (see AbstractSecurityAnalysis.runSimulations usage of lfActionById).
Whether that is a good thing is probably a good question but there is no functionnal change here as far as I can see.

Furthermore we still have the checkActions method that do some additional checks and raise an exception if there is some inconsistency. This one is still there.

Ok for putting the missing action in the report, good idea!