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.

Sign up for GitHub

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

Jump to bottom

Make RaoParameters generic #1084

Open
pet-mit opened this issue Jul 5, 2024 · 4 comments · May be fixed by #1112, #1139, #1101, #1191 or #1141
Open

Make RaoParameters generic #1084

pet-mit opened this issue Jul 5, 2024 · 4 comments · May be fixed by #1112, #1139, #1101, #1191 or #1141
Assignees
@pjeanmarie
Labels
breaking-change Changes could break users' code feature New feature or request

Comments

@pet-mit
Copy link
Collaborator

pet-mit commented Jul 5, 2024 •
edited by pjeanmarie
Loading

Describe the current behavior

The RaoParameters object (same applies to its json representation) mixes business parameters (such as objective function) with serach-tree-specific parameters (such as maximum search depth).

Describe the expected behavior

Taking as an example PowSyBl's LoadFlowParameters, separate RaoParameters into:

  • "business" RAO parameters that shall apply to any RAO implementation
  • extensions containing implementation-specific parameters
  • begin with a SearchTeeRaoParameters extension,which contains parameters specific to SearchTree

Describe the motivation

This would help create a generic RAO API, and make the two following things possible:

  • move the API to powsybl-core
  • create new RAO implementations

Extra Information

No response

Details

RaoParameters:
(B = business parameters, ST = search-tree specific parameter)

level 1 level 2 use case what to do
Objective Function Parameters
Type: MAX_MIN_MARGIN_IN_MEGAWATT, MAX_MIN_MARGIN_IN_AMPERE, MAX_MIN_RELATIVE_MARGIN_IN_MEGAWATT, MAX_MIN_RELATIVE_MARGIN_IN_AMPERE B Replace with these generic types : SECURE_FLOW / MAX_MIN_FLOW_MARGIN / MAX_MIN_RELATIVE_FLOW_MARGIN. Unit should be detected depending on LF DC flag -> obsolete, replaced by: New parameter Unit to store value MEGAWATT or AMPERE.
ForbidCostIncrease ST Remove, always set to true in OpenRAO
PreventiveStopCriterion: MIN_OBJECTIVE, SECURE B+ST Remove, compute depending on objective function
CurativeStopCriterion: MIN_OBJECTIVE, SECURE, PREVENTIVE_OBJECTIVE, PREVENTIVE_OBJECTIVE_AND_SECURE B+ST Remove, compute depending on objective function
CurativeMinObjImprovement B+ST Move to OpenRaoParameters extension
OptimizeCurativeIfPreventiveUnsecure B+ST Move to OpenRaoParameters. ObjectiveFunctionParameters. EnforceCurativeSecurity, use it also to replace "PREVENTIVE_OBJECTIVE_AND_SECURE" in cas of min margin maximization
Range Actions Optimization Parameters Move all this to OpenRaoParameters extension, except the three marked below
LinearOptimizationSolver.Solver: CBC, SCIP, XPRESS ST
LinearOptimizationSolver.RelativeMipGap ST
LinearOptimizationSolver.SolverSpecificParameters ST
MaxMipIterations ST
PstPenaltyCost B+ST Move to RaoParameters.RangeActionOptimizationParameters new param "PST RA min impact threshold"
PstSensitivityThreshold ST
HvdcPenaltyCost B+ST Move to RaoParameters.RangeActionOptimizationParameters new param "HVDC RA min impact threshold"
HvdcSensitivityThreshold ST
InjectionRaPenaltyCost B+ST Move to RaoParameters.RangeActionOptimizationParameters new param "Injection RA min impact threshold"
InjectionRaSensitivityThreshold ST
PstModel: CONTINUOUS, APPROXIMATED_INTEGERS ST
RaRangeShrinking: DISABLED, ENABLED, ENABLED_IN_FIRST_PRAO_AND_CRAO ST
Topo Optimization Parameters Split into generic (2 params) and specific (6 params)
MaxPreventiveSearchTreeDepth ST
MaxAutoSearchTreeDepth ST
MaxCurativeSearchTreeDepth ST
PredefinedCombinations ST
RelativeMinImpactThreshold B
AbsoluteMinImpactThreshold B
SkipActionsFarFromMostLimitingElement ST
MaxNumberOfBoundariesForSkippingActions ST
Multithreading Parameters Remove this section, replace with Multithreading.AvailableCpus. In OpenRAO, compute the old params (preventive leaves = contingency scenarios = cpus, the rest = 1)
ContingencyScenariosInParallel ST
PreventiveLeavesInParallel ST
AutoLeavesInParallel ST
CurativeLeavesInParallel ST
Second Preventive Rao Parameters Move to OpenRaoParameters extension
ExecutionCondition: DISABLED, POSSIBLE_CURATIVE_IMPROVEMENT, COST_INCREASE ST
ReOptimizeCurativeRangeActions ST
HintFromFirstPreventiveRao ST
Not Optimized Cnecs Parameters Keep in RaoParameters
do-not-optimize-curative-cnecs-for-tsos-without-cras B
Load Flow And Sensitivity Parameters
load-flow-provider ST Move to OpenRaoParameters extension
sensitivity-provider ST Move to OpenRaoParameters extension
sensitivity-failure-overcost ST Move to OpenRaoParameters extension
sensitivity-parameters ST Move to OpenRaoParameters extension
load-flow-parameters B -> obsolete Keep in RaoParameters. Don't forget to use it to set SensitivityParameters.LoadFlowParameters when calling sensitivity engine -> obsolete: stay inside sensitivity-parameters so it is in ST
Loop-flow extension Split into generic (2 params) and specific (3 params)
acceptable-increase B
ptdf-approximation ST
constraint-adjustment-coefficient ST
violation-cost ST
countries B
MNEC extension Split into generic (1 param) and specific (2 params)
acceptable-margin-decrease B
violation-cost ST
constraint-adjustment-coefficient ST
Relative margins extension Split into generic (1 param) and specific (2 params)
ptdf-boundaries B
ptdf-approximation ST
ptdf-sum-lower-bound ST
@pet-mit pet-mit added feature New feature or request breaking-change Changes could break users' code labels Jul 5, 2024
@pet-mit
Copy link
Collaborator Author

pet-mit commented Jul 18, 2024

@pjeanmarie I updated the table

This was linked to pull requests Aug 5, 2024
Rao Parameters: separate business from implementation specific #1101
Open
[WIP] Rao parameters new objective function #1111
Closed
Rao parameters forbid cost increase always true #1112
Open
@pjeanmarie pjeanmarie removed a link to a pull request Aug 9, 2024
Rao Parameters: separate business from implementation specific #1101
Open
7 tasks
This was linked to pull requests Sep 18, 2024
Rao parameters remove curative stop criterion #1139
Open
Rao parameters use unit from is dc #1140
Open
@pjeanmarie pjeanmarie removed a link to a pull request Sep 18, 2024
[WIP] Rao parameters new objective function #1111
Closed
7 tasks
@pjeanmarie pjeanmarie linked a pull request Sep 23, 2024 that will close this issue
Rao Parameters: separate business from implementation specific #1101
Open
7 tasks
@pjeanmarie
Copy link
Member

Remove this section, replace with Multithreading.AvailableCpus. In OpenRAO, compute the old params (preventive leaves = contingency scenarios = cpus, the rest = 1)

@phiedw Does it means I need to keep MultithreadingParameters with same parameters then now and not update it to match the json and why? Or is it only instructions for how to do the conversion where it is used (in TreeParameters and CastorOptim) ?

This was referenced Nov 19, 2024
Open
Open
Open
Open
@pjeanmarie pjeanmarie linked a pull request Nov 25, 2024 that will close this issue
Rao parameters put back some extensions values into rao parameters #1191
Open
7 tasks
@pjeanmarie pjeanmarie removed a link to a pull request Nov 25, 2024
Rao parameters use unit from is dc #1140
Open
7 tasks
This was linked to pull requests Nov 25, 2024
Merge content of preventive stop criterion into type, no impact on te… #1141
Open
Rao parameters separate unit from objective function type #1197
Open
@pjeanmarie
Copy link
Member

load-flow-parameters:
Keep in RaoParameters. Don't forget to use it to set SensitivityParameters.LoadFlowParameters when calling sensitivity engine

Since SensitivityParameters is a not an open rao object and its load json is define elsewhere (on powsyble-core) then we will have duplicated object between the load-flow-parameters in rao-parameters and the one still in extension. So it was decided to not add load-flow-parameters in rao-parameters, it exist only in extension in SensitivityParameters.

Unit should be detected depending on LF DC flag.

Finally Unit is removed from type but added independently in objective function as parameter "unit". This is because we need it in rao-parameters but "dc" (isDC) of load-flow-parameters couldn't be added in rao-pramerts (see above). In addition to that, we had quite some cucumber tests failed when it was no longer possibe to have independant "unit" and "dc".

@pjeanmarie
Copy link
Member

Presence or absence of previous extensions Loop-flow, MNEC, and Relative margins, change behavior, so the new objects (inside rao-parameters or inside existing extension) are Optional.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@pjeanmarie pjeanmarie

Labels
breaking-change Changes could break users' code feature New feature or request
Projects
None yet
Milestone
No milestone
2 participants
@pet-mit @pjeanmarie