Implement minTargetP and maxTargetP from ActivePowerControl extension

[vidaldid-rte]

It implements powsybl/powsybl-core#3054 for OpenLoadFlow

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?
In some situations the actual pMin and pMax that can be used for Active Power Operation is different from the group capabilities.
powsybl/powsybl-core#3054 enables to capture these temporary active power limitations in the AtivePowerOperation extension.

This PR implements this override in openloadflow.

What kind of change does this PR introduce?

The generators genuine pmin and pmax are still used in operations that are not related to active power operations (such as deetermining if a generator is really up and can control voltage).
But in all situations related to power operations such as slakc distribution, generator change and related details such as slack bus selection, the pMin and PMAx can be overridden by the Active Power Operation extension.
At implementation, these overridable values are called activePowerOperationMinP and activePowerOperationMaxP

What is the current behavior?
Impossible to define a temporary limit for Pmin and PMax to be used in active power operations.

What is the new behavior (if this is a feature change)?
No change by default, but if pMin and pMax are overridden in the Active Power Operations, these values are taken into account for compensation operations and generator actions (if p limits are to be checked for these actions).

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

• Yes
• No

What changes might users need to make in their application due to this PR? (migration steps)
Application developers should be aware the pMin and pMax can be overriden in the Active Power Control Operation Extension
for example to enable users to change temorary pMin or pMax, to display those limits, or to import generator data fro exetrnal datasources..

[jeandemanged]

please align namings, (both in PR description and in code), this would make things consistent / less confusing:

• the iIDM extension is ActivePowerControl, not ActivePowerOperation
• activePowerOperationMinP contains redundant information "activePower" and "P", same for activePowerOperationMaxP. Please find a better name (why not just name maxPOverride just like in the iIDM extension?)
• in the iIDM extension we have minPOverride, why change in OLF the name to operationMinP ?
• in PR description is mentionned also "temporary" min/max P, now we have 3 terms override, temporary, operational
• I have the list of where the override is applied if existing, I lack the list of the places where it is not used - and the rationale for not using it.

[vidaldid-rte]

* I have the list of where the override is applied if existing, I lack the list of the places where it is not used - and the rationale for not using it.

Before working on naming, vocabulary standardization and synonym eradication, I'd like to first address this question.

The purpose of this PR is that we have for generators some pmin and pmax that we consider the specification of the generator, independant of any condition, and some other limits (called in the extension pMinOverride and pMaOverride) that specify how much the generator can move in the current context.
We made the decision to:
- keep the generator specifications in the data as pmin and pmax
- if more restrictive limits exist, add them in the extension that controls compensation
- be agnostic about the cause of the restriction. It is just the degree of freedom for compensation for the timeframe and horizon of a simulation., in general, targetP is expected to be between those limits.

So we end up with the two concepts:
The absolute maxP/minP that are a characteristic of the Generators
The effective maxP/minP (currently called activePowerOperationMaxP/minP) that are the limits of what can be used to modify targetP in the scope of the simulation.

In this PR, the usage of the limits are as follow. The choices can be challenged and discussed - except for compensation where it is important to use the "effective" maxP/minP

slackBusSelection: absolute maxP
isGeneratorInvalid : absolute maxP
limits for volage control: absolute maxP/minP
check stared for voltage control: absolute minP

compensation: effective minP/maxP
generator actions: if limits are checked, it is against effective maxP/minP

[jeandemanged]

* I have the list of where the override is applied if existing, I lack the list of the places where it is not used - and the rationale for not using it.

Before working on naming, vocabulary standardization and synonym eradication, I'd like to first address this question.

The purpose of this PR is that we have for generators some pmin and pmax that we consider the specification of the generator, independant of any condition, and some other limits (called in the extension pMinOverride and pMaOverride) that specify how much the generator can move in the current context. We made the decision to: - keep the generator specifications in the data as pmin and pmax - if more restrictive limits exist, add them in the extension that controls compensation - be agnostic about the cause of the restriction. It is just the degree of freedom for compensation for the timeframe and horizon of a simulation., in general, targetP is expected to be between those limits.

So we end up with the two concepts: The absolute maxP/minP that are a characteristic of the Generators The effective maxP/minP (currently called activePowerOperationMaxP/minP) that are the limits of what can be used to modify targetP in the scope of the simulation.

In this PR, the usage of the limits are as follow. The choices can be challenged and discussed - except for compensation where it is important to use the "effective" maxP/minP

slackBusSelection: absolute maxP isGeneratorInvalid : absolute maxP limits for volage control: absolute maxP/minP check stared for voltage control: absolute minP

compensation: effective minP/maxP generator actions: if limits are checked, it is against effective maxP/minP

---

Thanks, clarifies what you want to achieve.

You mention:

if more restrictive limits exist

Looking at powsybl/powsybl-core#3054 there is not concept here of more restrictive limits, only an override, which by its naming alone suggests a complete replacement: i.e. it can restrict the range, but can also extend the range, and can also replace with a completely disjoint range.

I am OK with the choices you made on when to use generator Pmin/Pmax vs. when to use generator Pmin/Pmax override. I am OK also for both override possible interpretations:
a. it is an override = it replaces the generator value
b. it is a restriction = it replaces the generator value only if more restrictive

Currently a. is implemented in this PR, please confirm this is what you ant to do. If you want b. instead some of the code needs to be revisited (also maybe on the powsybl-core extension side).

[vidaldid-rte]

You mention:

if more restrictive limits exist

Looking at powsybl/powsybl-core#3054 there is not concept here of more restrictive limits, only an override, which by its naming alone suggests a complete replacement: i.e. it can restrict the range, but can also extend the range, and can also replace with a completely disjoint range.

Yes. That is a very good point.
My immediate use case is a restriction. But I decided to name it and use it as an override since we can imagine other use cases or what-if analysis where by exception you authorize to go beyond normal generators limits.

If you agree with that, then I can propose naming as a next steps.

[vidaldid-rte]

Naming proposal for what I called effective pmin/pmax earlier:
targetPMax / targetPMin.

[vidaldid-rte]

Renaming done. Won't compile until new release of powsyble-core is done that includes the renaming in the extension.
Criteria to check that targetP is within bounds for checkActivePowerControl now uses min/maxTargetP.
Checks that min/maxTargetP is in [minP,maxP] is delegated to the ActivePowerControl extension that does this in a robust way.

[annetill]

Why do you prefer to do everything here rather than do it at creation through 2 attributes? Same remark for generator impl.

[annetill]

Thanks a lot @jeandemanged, as usual.

[sonarqubecloud]

Quality Gate passed

Issues
3 New issues
0 Accepted issues

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

See analysis details on SonarCloud

dismiss