Conversation
Signed-off-by: Philippe Edwards <philippe.edwards@rte-france.com>
# Conflicts: # ra-optimisation/search-tree-rao/src/main/java/com/powsybl/openrao/searchtreerao/result/impl/PreventiveAndCurativesRaoResultImpl.java # tests/src/test/resources/files/configurations/epic91/RaoParameters_case_91_13_1.json
Signed-off-by: Thomas Bouquet <thomas.bouquet@rte-france.com>
Signed-off-by: Thomas Bouquet <thomas.bouquet@rte-france.com>
# Conflicts: # ra-optimisation/rao-api/src/main/java/com/powsybl/openrao/raoapi/parameters/extensions/SecondPreventiveRaoParameters.java # ra-optimisation/rao-api/src/test/resources/RaoParameters_config_withOLFParams.json
Signed-off-by: Godelaine de Montmorillon <godelaine.demontmorillon@rte-france.com>
…P is global Signed-off-by: Godelaine de Montmorillon <godelaine.demontmorillon@rte-france.com>
Signed-off-by: Godelaine de Montmorillon <godelaine.demontmorillon@rte-france.com>
Signed-off-by: Godelaine de Montmorillon <godelaine.demontmorillon@rte-france.com>
Signed-off-by: Godelaine de Montmorillon <godelaine.demontmorillon@rte-france.com>
Signed-off-by: Godelaine de Montmorillon <godelaine.demontmorillon@rte-france.com>
Signed-off-by: Godelaine de Montmorillon <godelaine.demontmorillon@rte-france.com>
Signed-off-by: Godelaine de Montmorillon <godelaine.demontmorillon@rte-france.com>
Signed-off-by: Godelaine de Montmorillon <godelaine.demontmorillon@rte-france.com>
Signed-off-by: Godelaine de Montmorillon <godelaine.demontmorillon@rte-france.com>
Signed-off-by: Godelaine de Montmorillon <godelaine.demontmorillon@rte-france.com>
ra-optimisation/rao-api/src/main/java/com/powsybl/openrao/raoapi/RaoParametersCommons.java
Show resolved
Hide resolved
| } else { | ||
| return firstCraoResult.isActivated(networkAction); | ||
| } | ||
| return secondPraoResult.isActivated(networkAction); |
There was a problem hiding this comment.
This does not seem quite coherent with getActivatedNetworkActions below anymore
In isActivated we systematically determine whether a NA was applied or not from the second RAO result whereas getActivatedNetworkActions always relies on the first
I suggest that we also update getActivatedNetworkActions so it uses second RAO results too
There was a problem hiding this comment.
and same for getActivatedNetworkActionsPerState
There was a problem hiding this comment.
more generally I wonder if the first RAO result is useful (except for curative NA) since everything is re-optimized in 2P
There was a problem hiding this comment.
it's useful for getRangeActions() : "Some range actions can be excluded from first CRAO (for example if they are only available after a constraint) but re-optimised in second PRAO".
On network actions : this is a curative result, during second preventive no curative network actions are reoptimized, that's why we look in firstCraoResult
...rc/main/java/com/powsybl/openrao/searchtreerao/result/impl/CurativeWithSecondPraoResult.java
Show resolved
Hide resolved
...rch-tree-rao/src/main/java/com/powsybl/openrao/searchtreerao/searchtree/algorithms/Leaf.java
Outdated
Show resolved
Hide resolved
...a/com/powsybl/openrao/searchtreerao/result/impl/PreventiveAndCurativesRaoResultImplTest.java
Outdated
Show resolved
Hide resolved
...a/com/powsybl/openrao/searchtreerao/result/impl/PreventiveAndCurativesRaoResultImplTest.java
Outdated
Show resolved
Hide resolved
.../powsybl/openrao/tests/features/epic15_specific_network_elements/epic15_11/US15_11_4.feature
Show resolved
Hide resolved
Signed-off-by: Godelaine de Montmorillon <godelaine.demontmorillon@rte-france.com>
Signed-off-by: Godelaine de Montmorillon <godelaine.demontmorillon@rte-france.com>
…rao/searchtreerao/searchtree/algorithms/Leaf.java Co-authored-by: Thomas Bouquet <thomas.bouquet@rte-france.com> Signed-off-by: Godelaine <87479798+Godelaine@users.noreply.github.com>
…rao/searchtreerao/result/impl/PreventiveAndCurativesRaoResultImplTest.java Co-authored-by: Thomas Bouquet <thomas.bouquet@rte-france.com> Signed-off-by: Godelaine <87479798+Godelaine@users.noreply.github.com>
…rao/searchtreerao/result/impl/PreventiveAndCurativesRaoResultImplTest.java Co-authored-by: Thomas Bouquet <thomas.bouquet@rte-france.com> Signed-off-by: Godelaine <87479798+Godelaine@users.noreply.github.com>
|
* force global 2P Signed-off-by: Philippe Edwards <philippe.edwards@rte-france.com> * fix after merge Signed-off-by: Thomas Bouquet <thomas.bouquet@rte-france.com> * bump parameters to v3.2 and add changelog Signed-off-by: Thomas Bouquet <thomas.bouquet@rte-france.com> * fix tests Signed-off-by: Thomas Bouquet <thomas.bouquet@rte-france.com> * add comments to getRaLimitationParameters Signed-off-by: Godelaine de Montmorillon <godelaine.demontmorillon@rte-france.com> * adapt 20.2.2 by using topo CRA to ensure CRA is kept in 2P now that 2P is global Signed-off-by: Godelaine de Montmorillon <godelaine.demontmorillon@rte-france.com> * clean/ adapt US20_1 Signed-off-by: Godelaine de Montmorillon <godelaine.demontmorillon@rte-france.com> * fix merge Signed-off-by: Godelaine de Montmorillon <godelaine.demontmorillon@rte-france.com> * delete re-optimize everywhere Signed-off-by: Godelaine de Montmorillon <godelaine.demontmorillon@rte-france.com> * update parameter files * update values far from ref Signed-off-by: Godelaine de Montmorillon <godelaine.demontmorillon@rte-france.com> * fix values Signed-off-by: Godelaine de Montmorillon <godelaine.demontmorillon@rte-france.com> * add UT to improve sonar Signed-off-by: Godelaine de Montmorillon <godelaine.demontmorillon@rte-france.com> * checkstyle Signed-off-by: Godelaine de Montmorillon <godelaine.demontmorillon@rte-france.com> * improve sonar Signed-off-by: Godelaine de Montmorillon <godelaine.demontmorillon@rte-france.com> * fix test Signed-off-by: Godelaine de Montmorillon <godelaine.demontmorillon@rte-france.com> * more sonar Signed-off-by: Godelaine de Montmorillon <godelaine.demontmorillon@rte-france.com> * PR changes Signed-off-by: Godelaine de Montmorillon <godelaine.demontmorillon@rte-france.com> * Update ra-optimisation/search-tree-rao/src/main/java/com/powsybl/openrao/searchtreerao/searchtree/algorithms/Leaf.java Co-authored-by: Thomas Bouquet <thomas.bouquet@rte-france.com> Signed-off-by: Godelaine <87479798+Godelaine@users.noreply.github.com> * Update ra-optimisation/search-tree-rao/src/test/java/com/powsybl/openrao/searchtreerao/result/impl/PreventiveAndCurativesRaoResultImplTest.java Co-authored-by: Thomas Bouquet <thomas.bouquet@rte-france.com> Signed-off-by: Godelaine <87479798+Godelaine@users.noreply.github.com> * Update ra-optimisation/search-tree-rao/src/test/java/com/powsybl/openrao/searchtreerao/result/impl/PreventiveAndCurativesRaoResultImplTest.java Co-authored-by: Thomas Bouquet <thomas.bouquet@rte-france.com> Signed-off-by: Godelaine <87479798+Godelaine@users.noreply.github.com> --------- Signed-off-by: Philippe Edwards <philippe.edwards@rte-france.com> Signed-off-by: Thomas Bouquet <thomas.bouquet@rte-france.com> Signed-off-by: Godelaine de Montmorillon <godelaine.demontmorillon@rte-france.com> Signed-off-by: Godelaine <87479798+Godelaine@users.noreply.github.com> Co-authored-by: Thomas Bouquet <thomas.bouquet@rte-france.com> Co-authored-by: Godelaine de Montmorillon <godelaine.demontmorillon@rte-france.com> Co-authored-by: Godelaine <87479798+Godelaine@users.noreply.github.com>


Please check if the PR fulfills these requirements
Does this PR already have an issue describing the problem?
Fixes #1422
fix in Leaf:getRaLimitationParameters : in 2P global optimization, we didn't take into account the already applied topological actions, leading to erroneous ra limits.
What kind of change does this PR introduce?
Code cleaning
What is the current behavior?
We allow to run a non global opt 2P (where we only reoptimize preventive remedial actions). This requires us to disable many actions (including preventive) for various reasons linking curative optimization to preventive. It also complicates the results structure a lot. And it gives worst results for little performance gain.
What is the new behavior (if this is a feature change)?
We now force global opt 2P, reoptimizing preventive actions and curative PSTs.
Does this PR introduce a breaking change or deprecate an API?
If yes, please check if the following requirements are fulfilled
What changes might users need to make in their application due to this PR? (migration steps)
Users will have to remove the "re-optimize-curative-range-actions" field from parameters.
Other information: