Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add RA usage limit on the number of applicable elementary actions per TSO #1009

Open
wants to merge 31 commits into
base: main
Choose a base branch
from

Conversation

bqth29
Copy link
Collaborator

@bqth29 bqth29 commented May 13, 2024

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)

What kind of change does this PR introduce?
This PR introduced a new RA usage limit called max-elementary-actions-per-tso. An elementary action is defined as follows:

  • for network actions, it is one topology action or one injection set-point action
  • for PST range actions, it corresponds to moving the tap by one step

For CSA, TSOs may want to limit the number of elementary actions they will use for curative remedial actions.

"ra-usage-limits-per-instant" : [ {
    "instant": "preventive",
    "max-elementary-actions-per-tso" : {"TSO": 3}
} ]

In this example, the TSO can apply at most 3 elementary actions during the preventive optimization. This may be for example:

  • moving a PST tap with 3 steps
  • setting one generator, opening one line and moving a PST tap with 1 step
  • etc.

⚠️ Warning: To use this RA usage limit, the "pst-model" RAO parameter must be set to "APPROXIMATED_INTEGERS" because this constraint would be intractable if PSTs were modelled using continuous values.

What is the new behavior (if this is a feature change)?
The limit has been defined in the CRAC API and the CRAC creation parameters. In the optimization, this limit is a constraint that appears both in the search tree bloomer (for network actions) and in the linear programming model (for PSTs' taps).

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

  • Yes
  • No

Signed-off-by: Thomas Bouquet <thomas.bouquet@rte-france.com>
Signed-off-by: Thomas Bouquet <thomas.bouquet@rte-france.com>
Signed-off-by: Thomas Bouquet <thomas.bouquet@rte-france.com>
@bqth29 bqth29 added feature New feature or request PR : dont-merge-before-other PR mustn't be merged before another (referenced in the description or in the comments) labels May 13, 2024
Signed-off-by: Thomas Bouquet <thomas.bouquet@rte-france.com>
Signed-off-by: Thomas Bouquet <thomas.bouquet@rte-france.com>
Signed-off-by: Thomas Bouquet <thomas.bouquet@rte-france.com>
# Conflicts:
#	data/crac/crac-api/src/main/java/com/powsybl/openrao/data/cracapi/RaUsageLimits.java
Signed-off-by: Thomas Bouquet <thomas.bouquet@rte-france.com>
Signed-off-by: Thomas Bouquet <thomas.bouquet@rte-france.com>
Signed-off-by: Thomas Bouquet <thomas.bouquet@rte-france.com>
Signed-off-by: Thomas Bouquet <thomas.bouquet@rte-france.com>
@bqth29 bqth29 removed the PR : dont-merge-before-other PR mustn't be merged before another (referenced in the description or in the comments) label May 16, 2024
# Conflicts:
#	ra-optimisation/search-tree-rao/src/main/java/com/powsybl/openrao/searchtreerao/searchtree/algorithms/SearchTree.java
#	ra-optimisation/search-tree-rao/src/main/java/com/powsybl/openrao/searchtreerao/searchtree/algorithms/SearchTreeBloomer.java
#	ra-optimisation/search-tree-rao/src/test/java/com/powsybl/openrao/searchtreerao/searchtree/algorithms/SearchTreeBloomerTest.java
Signed-off-by: Thomas Bouquet <thomas.bouquet@rte-france.com>
Signed-off-by: Thomas Bouquet <thomas.bouquet@rte-france.com>
Signed-off-by: Thomas Bouquet <thomas.bouquet@rte-france.com>
Signed-off-by: Thomas Bouquet <thomas.bouquet@rte-france.com>
Signed-off-by: Thomas Bouquet <thomas.bouquet@rte-france.com>
Signed-off-by: Thomas Bouquet <thomas.bouquet@rte-france.com>
Signed-off-by: Thomas Bouquet <thomas.bouquet@rte-france.com>
Signed-off-by: Thomas Bouquet <thomas.bouquet@rte-france.com>
@bqth29 bqth29 marked this pull request as ready for review May 22, 2024 06:46
Signed-off-by: Thomas Bouquet <thomas.bouquet@rte-france.com>
@bqth29 bqth29 added the PR: waiting-for-review This PR is waiting to be reviewed label May 22, 2024
@bqth29 bqth29 requested a review from phiedw May 22, 2024 08:58
@OpenSuze OpenSuze requested a review from jipea May 24, 2024 09:29
# Conflicts:
#	ra-optimisation/search-tree-rao/src/main/java/com/powsybl/openrao/searchtreerao/linearoptimisation/algorithms/fillers/RaUsageLimitsFiller.java
Signed-off-by: Thomas Bouquet <thomas.bouquet@rte-france.com>
@bqth29 bqth29 linked an issue May 29, 2024 that may be closed by this pull request
Signed-off-by: Thomas Bouquet <thomas.bouquet@rte-france.com>
docs/castor/linear-problem/ra-usage-limits-filler.md Outdated Show resolved Hide resolved
for (String tso : maxElementaryActionsPerTso.keySet()) {
for (PstRangeAction pstRangeAction : pstRangeActionsPerTso.getOrDefault(tso, Set.of())) {
// use pre-perimeter tap because PST's tap may be different from the initial tap after previous perimeter
int initialTap = prePerimeterRangeActionSetpoints.getTap(pstRangeAction);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if we want this to work in second preventif, we'll need to check the tap of the preventive variable (see how we compute relative taps for inspiration)

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it would probably be worth creating a test case for this

OpenRaoMPConstraint maxElementaryActionsConstraint = linearProblem.addTsoMaxElementaryActionsConstraint(0, maxElementaryActionsPerTso.get(tso), tso, state);
for (PstRangeAction pstRangeAction : pstRangeActionsPerTso.getOrDefault(tso, Set.of())) {
// use pre-perimeter tap because PST's tap may be different from the initial tap after previous perimeter
int initialTap = prePerimeterRangeActionSetpoints.getTap(pstRangeAction);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

same here for 2P

And the tap of PstRangeAction "pst_fr" should be 10 in preventive
And the worst margin is 7.0 MW

# TODO: second prev
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do the todo, some with global optimisation and some without

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request PR: waiting-for-review This PR is waiting to be reviewed
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add a RA limits per simple maneuver
2 participants