Please check if the PR fulfills these requirements
[x] The commit message follows our guidelines
[x] Tests for the changes have been added (for bug fixes / features)
[x] 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.
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?
Please check if the PR fulfills these requirements
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 CSA, TSOs may want to limit the number of elementary actions they will use for curative remedial actions.
In this example, the TSO can apply at most 3 elementary actions during the preventive optimization. This may be for example:
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?