Bugfix: SA - Absolute generator action ignores post-contingency slack

[vmouradian]

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?

What kind of change does this PR introduce?

Bug fix (i guess ?)

What is the current behavior?

Powsybl Generator actions are all converted to relative power actions, applied on top of the power after the contingency (and potential slack distribution)

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

If the action is absolute, the absolute targetP is directly set, regardless of the potential changes due to slack after contingency

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]

@vmouradian This is more an adjustment of behavior than a bugfix. It has been discussed and validated that absolute generator action setting a target P should be respected and enforced.

[obrix]

@Hadrien-Godard Can you have a quick look ?

[obrix]

Also we discussed with @annetill fixing the behavior for load actions that have the same issue. @vmouradian can you do the same fix for powershift ?

[Hadrien-Godard]

@Hadrien-Godard Can you have a quick look ?

I am looking at it

[vmouradian]

@vmouradian can you do the same fix for powershift ?

I am facing an issue here. An LfLoad aggregates all the powsybl loads that are connected to the same bus, and their targetPs are summed. This causes no issue for applying relative actions since you add the to the total regardless of the precise load the Action was targetting. But to apply an absolute action, my impression is that we would need to keep track of the values of each load aggregated in the LfLoad, otherwise we cannot know what change to apply. This will need some refactoring, but i would like to discuss with you if we want to do that and the possible ways of doing it

[vidaldid-rte]

@annetill @Hadrien-Godard @rosiereflo I agree this is fixing a bug for the absolute value. There is still an ambiguity for the relative case that may cause inconsistencies between powsybl simulators if they do not interprete it all the same way. The problem is the doc of GeneratorAction in com.powsyb.action. For relative active power change, the doc does not specify "Relative to what". I suggest to specify that in the doc. The current implementaton means "relative to the actual active power production in the state to which the action is applied." (personal note: this looks strange to me because this reference is unknown before the flow is computed - it depends on the contingency and the compensation made). But one would think "relative to the initial target P before any compensation is applied".

EDIT: I now see good use cases for relative as implemented here ("relative to the actual active power production in the state to which the action is applied." ). For example if a high capacity line between region A and B is lost, you may want to add, say 100MW to the generators in A, and remove the same amount 100MW to the region in B to reduce the transit between the to regions. And if your modifications are balanced the compensation will not change to much your settings.

[sonarqubecloud[bot]]

Quality Gate passed

Issues
0 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