In RAO: replace RAO Contingency by Core Contingency, In Core: Extends Contingency to cover open-rao needs
pjeanmarie opened this issue · comments
Describe the current behavior
Core project and open-rao project have each have their own definition of contingency:
- core: class com.powsybl.contingency.Contingency
- rao: interface com.powsybl.openrao.data.cracapi.Contingency, impl com.powsybl.openrao.data.cracimpl.ContingencyImpl, used in particular in Crac
Describe the expected behavior
Core project and open-rao project should share a common definition and implementation of a contingency and a network-action which should be in core project only.
The idea is:
- when there is similar elements -> modify rao to use the one in core
- when there is necessary elements in rao which do not exist in core -> add them in core
In fact rao contingency define an apply method which create a core contingency and apply it to the iidm network, so the link between rao and core contingency is well defined here.
Changes details:
| rao | core | what to do? | change is validated in core or rao |
|---|---|---|---|
| name and id | only id | name is needed on rao side so getName which return an Optional name wil be added on core side | yes core (for the contingency and its builder) |
| network elements is a Set | network elements is a List | change to List on rao side | yes rao |
| getNetworkElements | getElements | rename on rao side since we should avoid regression on core side | yes rao |
| rao contingency contains NetworkElement | core contingency contains ContingencyElement | rao will use the core contingency so it will contains ContingencyElement and no more NetworkElement | yes rao |
| NetworkElement has getName | ContingencyElement has not | contingency elements' name not used in rao, no need to add a getName in core | yes rao |
| NetworkElement has getLocation | ContingencyElement has not | not called on contingecy elements so it can be removed | yes rao |
| equals | equals | keep core | yes rao |
| hash with id and network elements | hash with id | keep core | yes rao |
| ContingencyAdder | ContingencyBuilder | ContingencyBuilder need to be instantiated with contingency id, and add aslo non primitive type for some optional ".add", which is to much a change compare to ContingencyAdder and other rao adder so ContingencyAdder is keeped but we use ContingencyBuilder inside as much as possible | yes rao and core for the optional Name |
| NetworkElement add in Crac | Do not create a network element for each contingecy element to add in crac expecially beacuse they have no name so can create discrepences with same network-element with a name | yes rao (adder) | |
| need contingency type to create ContingencyElement | Use network to retreive contingency type whenever possible. For json add network as a parameter. wip: new json format. | yes rao, only add network, no new json format for now |
Describe the motivation
Do not multiply definitions of similar objects now that open-rao is part of powsybl.
Extra Information
Contingency have a DSL in powsybl core:
https://www.powsybl.org/pages/documentation/simulation/securityanalysis/contingency-dsl.html
Crac has Network Elements as child by composition of contingency and network-action, they will be both removed...
Hello, I discussed this with the RAO team.
Here are our first remarks:
- interface Contingency : the RAO does not really need it in the target solution; all openrao.Contingency usages should be replaceable with powsyblcore.Contingency usages
- name and id : we need to keep both in RAO, separated. You could add getOptionalName in the core Contingency object for example.
- Set vs List : ok to have a List, but we think it would be a shame, a Set would be better suited
- getElements : ok to use that
- equals / hash : ok
@pjeanmarie I updated my answer
- name and id : we need to keep both in RAO, separated. You could add getOptionalName in the core Contingency object for example.
The plan was to entirely remove Contingency on RAO side, so do I rename getName into getOptionalName on RAO side or do I add a getName on core side (or do I keep a minimal Contingency class on RAO side with the getName)?
- Set vs List : ok to have a List, but we think it would be a shame, a Set would be better suited
I can suggest the change to Set on core side and see if its ok
We were thinking about adding a getName on core side ; and yes, remove the RAO Contingency interface & implementations
For the merge of rao Set and core List, the main difference seems to be that the subtype of ContingencyElement is used (Branch, Generator...) to apply the correct modification in case of contingency, while NetworkElement as only one implementation. So we can get the NetworkElements from the ContingencyElements, but we need the network (for instance) to retrieve the type from a network-element (see "apply"). Also, again, only id on core side, no name for these elements. Not sure what to do.
For the merge of rao Set and core List, the main difference seems to be that the subtype of ContingencyElement is used (Branch, Generator...) to apply the correct modification in case of contingency, while NetworkElement as only one implementation. So we can get the NetworkElements from the ContingencyElements, but we need the network (for instance) to retrieve the type from a network-element (see "apply"). Also, again, only id on core side, no name for these elements. Not sure what to do.
It's OK to replace the usage of NetworkElement in RAO by ContingencyElement. Of course a lot of adaptations will be needed, but I don't see neither a technical nor a functional obstacle there
- a getName which return an Optional will be added in Contingency core, this means that contingency.getName() on rao side will need to be updated to manage the optional return, is it ok?
- After discussions, contingency will have a List of ContingecyElement and not a Set, can I validate?
- also other thinks need to be validated or discussed, especially remove of rao ContingencyAdder, see table in description.
- a getName which return an Optional will be added in Contingency core, this means that contingency.getName() on rao side will need to be updated to manage the optional return, is it ok?
- After discussions, contingency will have a List of ContingecyElement and not a Set, can I validate?
- also other thinks need to be validated or discussed, especially remove of rao ContingencyAdder, see table in description.
OK for the 2 first points.
For the third, I don't see why you must remove the ContingencyAdder. you can keep it, and use it to create Powsybl-core Contingencies in the CRAC
actually the name of the contingency element is not used in the RAO, so no need to add a name to core's ContingencyElement
To be decided: json files only have contingency element id, but the type is also necessary since we have to choose the correct implementation of ContingencyElement to create one.
@pet-mit For now, an iidm network will be added as a parameter to the deserialization to retrieve the contingency element type from the type of the element in the network.