FARAO functional perimeter

[nomont]

Dear development team,

I thank you for the already detailed information available on https://farao-community.github.io/
I have a few additional questions concerning FARAO that would help me to assess the tool.

• What are the Technological Readyness Level (TRL) of the platform? Of the different methodologies: "CASTOR", "CSA RAO" (closed optimization)?
  It seems that "CASTOR" is TRL 9 because it is used operationnally on "CWE, Northern Italy and SWE Capacity calculation". What about "Actual CSA RAO"? How extensively has it been tested?

• For "CASTOR" and "Actual CSA RAO", what is the typical size of the problem solved during operations or tests (number of monitored elements, of contingencies, of preventive actions, of curative actions, of PSTs, of redispatchable units)? How many cores does solving the problem for one hour require? How much time does it require?

• What file format (CGMES or UCTE), Load-Flow (Hades or Open Load-Flow), and linear solver (among those interfaced with OR Tools) have been used for testing and/or operation with "CASTOR"/"CSA RAO" methodology.

• Are intertemporal constraints on the roadmap? If yes, for which methodology "CASTOR", "Actual CSA RAO", other? For 2 successive hours? For 24 hours? For CASTOR? For "CSA RAO"?

• Is it possible to make a difference between network elements on which congestions have to be solved and network elements on which congestion should not be worsened? For CASTOR? For "CSA RAO"?

• It seems that "CASTOR" optimizes the transfer capacity. Would it make sense to use it to minimize redispatch costs as CSA RAO does?

I thank you in advance for your help!

[pet-mit]

Hello nomont,
Thank you for taking interest in FARAO.
Here are some answers to your questions; do not hesitate to create separate threads if you need more information for specific topics.

1. TRL

• CASTOR: 9, fully operational and heavily tested
• CSA RAO: some experimentation has been conducted about two years ago when farao was in early development. The results were not great in terms of performance; since then many things have changed and performance of the different bricks have improved but the CSA RAO has not been re-tested. The experimentation code has not been updated, it is now located here: https://github.com/farao-community/farao-legacy/tree/master/ra-optimisation/closed-optimisation-rao. Note that it is based on old data object models. So it is difficult to actually assign it a TRL; it would be a good idea to re-use its principles, but not the whole code itself.

2. Problem size & performance (average)

• CASTOR, on a European-scale 220-400kV network: ~800 contingencies, ~700 monitored network elements, ~43000 {monitored element, monitored state} couples, 80 remedial actions ( 40 PSTs & 40 topological actions, no dispatching, ~ 60 preventive and 20 curative actions). Solving a one-hour timestamp takes between 10 and 60 minutes on 16 cores.
• CSA RAO (2019 figures): figures not relevant due to poor data quality at the time of experimentation

3. Supported network formats: all formats supported by PowSyBl framework (https://github.com/powsybl/powsybl-core)
   XIIDM & UCTE have been heavily tested in CASTOR & CSA RAO
   CGMES has been lightly tested in CASTOR

4. Supported LoadFlow providers: all LoadFlow providers that implement PowSyBl's open-source interface
   Hades has been heavily tested (in DC & AC) in CASTOR & CSA RAO
   PowSyBl-OpenLoadFlow has been heavily tested (in DC only) in CASTOR

5. Supported solvers: all solvers compatible with Google's open-source optimization interface OR-Tools
   CBC has been heavily tested (in continuous LP mode) in CASTOR & CSA RAO
   XPRESS has been heavily tested (in MIP mode) in CASTOR, using XPRESS-ORTools interface developed by RTE.

6. Intertemporal constraints
   They are not actually on the roadmap.
   Theoretically, two approaches are possible:

• Combining multiple one-hour optimizations(CASTOR) by propagating the constraints
• Investigating a more global optimization solution, using CASTOR or not

7. Monitored/scanned elements vs optimized/critical elements ("difference between network elements on which congestions have to be solved and network elements on which congestion should not be worsened"):
   Possible and heavily tested in CASTOR, not implemented/tested in CSA RAO

8. Objective function
   CASTOR's actual objective function maximizes the minimum thermal margin of lines in the network (+ some penalty costs are applied on the usage of remedial actions and on the violation of soft constraints)
   I guess that it makes sense to replace this with a dispatch cost minimization, while making the margin objective a hard constraint (for CSA, the minimum margin should only be positive) or into a soft constraint with a big penalty cost

[nomont]

Hello pet-mit,
Thanks a lot for your detailed answers!
It is very helpful.