v2.4.2

Release note

Breaking changes

• Instants are now enumerated and can only have one of 4 values (see details below)
• The NetworkActions API has been simplified (see details below)

New features

CRAC API

• A new getLocation() method has been added for convenience in BranchCnec and RemedialAction objects
• Instants are now enumerated: PREVENTIVE, OUTAGE, AUTO, CURATIVE
• Objects ComplexNetworkAction and ElementaryNetworkAction have been removed. They have been replaced with the single object NetworkAction, that can contain one or several ElementaryAction objects.

More tolerant GLSK import

The GLSK importer has been modified to accept GLSK blocks for which the validity range does not include initial target power of a generator.
It is a workaround to avoid exceptions in PowSyBl, and may be rolled back in the future, if the PowSyBl framework evolves.

RAO - PST optimization

The rounding of PST taps after the linear optimization has been improved. The PST taps are now rounded to the tap position maximizing the minimum margin, if the optimal setpoint is close to the limit between two taps.

Documentation

Configuration example

An updated confg.yml example configuration file has been added

Performance improvements

Flowbased computation

The performance of Flowbased computation has been improved, by computing sensitivities less frequently

Some remarks on the quick evolution of Farao's API

The code of farao-core is still evolving significantly from one release to the next. Several of those evolutions are impacting, in one way or another, the APIs of FARAO, and consequently the applications that rely on it. We are indeed in a stage in which we are still allowing ourselves to bring many breaking changes to our API.

These quick evolutions of the API give us the flexibility in the current stages of the Farao development to question some of our initial choices, and adapt some parts of the source code in order to make it more robust, scalable, easy-to-read and fitted to the newly developed features.

Eventually, the API of FARAO will be stabilized. Breaking changes will be made with more parsimony and be accompanied by more documentation. But this stabilization will come later as significant changes in the crac-api are still expected in the next releases.

v2.4.1

Release note

Breaking changes

New API for CRAC importer

• A new API have been designed for CRAC importers (see below). The current importers will be progressively migrated on the new API.

New features

NativeCrac and CracCreator

This release contains three new modules: farao-native-crac-api, farao-native-crac-io-api, farao-crac-creator-api.

Those three modules are the first step a refactoring of the CRAC importers. The main idea of this refactoring is to import the CRAC in two steps:

• first step: from a file, or an input steam, import a NativeCrac (java object). The NativeCrac is a raw translation of a file, based for instance on the generated classes of its xsd. It contains all the information present in the file.
• second step: create a Crac, from a NativeCrac and a Network.

The benefits of this refactoring are:

• to keep all the raw information of the input file in a java object: the NativeCrac
• to be able to have a network when interpreting the NativeCrac into a Crac object, and therefore be able to perform some operation with the Network (e.g. read IST, check the type of the network element, do a cross-quality check with the network, ...), which are currently done in less intuitive methods (e.g. synchronize(), cleanCrac(),...)
• to know how the NativeCrac information have been mapped in the Crac, thanks to the CracCreationContext object. This object can be usefull to reverse some information when exporting the RAO results.

Some remarks on the quick evolution of Farao's API

The code of farao-core is still evolving significantly from one release to the next. Several of those evolutions are impacting, in one way or another, the APIs of FARAO, and consequently the applications that rely on it. We are indeed in a stage in which we are still allowing ourselves to bring many breaking changes to our API.

These quick evolutions of the API give us the flexibility in the current stages of the Farao development to question some of our initial choices, and adapt some parts of the source code in order to make it more robust, scalable, easy-to-read and fitted to the newly developed features.

Eventually, the API of FARAO will be stabilized. Breaking changes will be made with more parsimony and be accompanied by more documentation. But this stabilization will come later as significant changes in the crac-api are still expected in the next releases.

v2.4.0

Release note

Breaking changes

Post-processor script

• A new script "core-cc-ucte-postProcessor.groovy" has been added for CORE (see usage below)

Parameters

• The relative-margin-ptdf-boundaries has changed (see usage below).
• A new "curative-rao-optimize-operators-not-sharing-cras" parameter has been added to the search tree parameters (see usage below).

New features

I/O

• An "operator" field has been added to CNECs

Remedial actions optimisation

• The relative-margin-ptdf-boundaries parameter now supports defining complex zone-to-zone ptdf computation equations. The user now has to use { } around the zone ID (country code or EIC) and explicitly define the - or + operator. More than two zones can be used in one equation.
• During curative RAO, farao can now ignore CNECs belonging to operators that do not share any curative remedial actions (the operators are detected automatically). Their margin will not be taken into account in the objective function, unless it is worse than at the beginning of the curative perimeter (without any RA). Set the parameter "curative-rao-optimize-operators-not-sharing-cras" to false to activate this feature.

Bug fixes

Remedial actions optimisation

• RAO on a set of pure MNECS (monitored CNECs that are not optimized) was not handled and caused crashes. This has been fixed.
• The exported RAO result after preventive and curative RAOs contained the optimal cost of the preventive RAO. Now it contains the worst result among all perimeters.
• The commercial flow is correctly transmitted through the curative RAOs.

GLSKs

• The GLSK importer has been improved to support areas with multiple GSKSeries
• A new script "core-cc-ucte-postProcessor.groovy" has been added for CORE, it allows farao to create loads and generators in the network object, for nodes that have been ignored by PowSyBl (especially nodes that have zero load / generation). This is necessary to have correct GLSK usage.

Loop-flow computation

• The loop-flow computation does not shift anymore the net position of the virtual hubs which are already disconnected by a contingency

Some remarks on the quick evolution of Farao's API

The code of farao-core is still evolving significantly from one release to the next. Several of those evolutions are impacting, in one way or another, the APIs of FARAO, and consequently the applications that rely on it. We are indeed in a stage in which we are still allowing ourselves to bring many breaking changes to our API.

These quick evolutions of the API give us the flexibility in the current stages of the Farao development to question some of our initial choices, and adapt some parts of the source code in order to make it more robust, scalable, easy-to-read and fitted to the newly developed features.

Eventually, the API of FARAO will be stabilized. Breaking changes will be made with more parsimony and be accompanied by more documentation. But this stabilization will come later as significant changes in the crac-api are still expected in the next releases.

v2.3.0

Release note

General

• Adaptation of farao to PowSyBl v4.0.0: https://github.com/powsybl/powsybl-core/releases/tag/v4.0.0
• Adaptation to farao-virtual-hubs v0.0.3: https://github.com/farao-community/farao-virtual-hubs/releases/tag/v0.0.3

Breaking changes

Post-processor script for Alegro

• A new script "core-cc-ucte-postProcessor.groovy" has been added for Alegro in CORE capacity calculation (see usage below)

Parameters

• There are three new parameters in the SearchTreeRaoParameters: "max-curative-ra-per-tso", "max-curative-topo-per-tso", and "max-curative-pst-per-tso" (see usage below).
• The parameter "leaves-in-parallel" has been replaced by two new parameters: "preventive-leaves-in-parallel" and "curative-leaves-in-parallel" (see usage below).
• The name of the parameter "ptdf-boundaries" has been changed to "relative-margin-ptdf-boundaries" for more clarity, and the country separator character "-" has been replaced by the character "/" (see usage below).

New features

Alegro

• A new post-processor script "core-cc-ucte-postProcessor.groovy" has been added, in order to create artificial load and generation for Alegro HVDC line. This script should be used instead of the old one for the CORE region (or any eventual region containing Alegro).

Remedial actions optimisation

• Injection setpoint network actions are now handled in the search-tree RAO.
• Three new parameters have been added for the curative RAO:
  • max-curative-ra-per-tso: a String->Integer map, defining the maximum number of curative remedial actions per TSO in one curative optimization
  • max-curative-topo-per-tso: a String->Integer map, defining the maximum number of curative topological actions per TSO in one curative optimization
  • max-curative-pst-per-tso: a String->Integer map, defining the maximum number of curative PST remedial actions per TSO in one curative optimization
    Note that the name of the TSOs in these parameters should match the operators of the corresponding RAs found in the CRAC file.
• Range types for range actions are now more clearly defined, and the CRAC cleaner makes some extra checks
• A new type of contingency has been created: the XnodeContingency. This kind of contingency is defined upon two Xnodes and has to be synchronized with the network before RAO, in order to be mapped to the two corresponding dangling lines.
• The relative margins' PTDF boundaries parameter is now defined as a list of EICode pairs. Its importers use 2-characters country codes OR 16-characters EICode. This allows the PTDF sums to take into account borders between bidding zones that are not both countries. Note that the parameter's name now is "relative-margin-ptdf-boundaries", and that the separator character "-" has been replaced by the character "/" (beacuse EICodes can contain the character "-").
• In the linear problem, ranges actions that have an initial set point that violates their allowed range (ie range from the CRAC file) are filtered out of the optimization. This prevents errors in the RAO (typically loop-flow or MNEC constraints being artificially violated when the range actions are brought back into their allowed range).

Flow-based computation

• Curative remedial actions are now handled in flow-based computation, the same way as preventive remedial actions.

Loop-flow computation

• Loop-flows are now monitored and limited on all cross-zonal Cnecs, not just on preventive cross-zonal CNECs.

Performance related features

• PTDFs are no longer recomputed after the topological change at the beginning of the curative RAO. This improves the curative RAO's performance.
• The user can now fix the number of leaves to run in parallel specifically for preventive and curative perimeters using "preventive-leaves-in-parallel" and "curative-leaves-in-parallel".

I/O

• Relative margins and absolute PTDF sums are now exported in the CNE file.

Miscellaneous

• Application logs have been improved.

Bug fixes

Remedial actions optimisation

• A bug in the handling of CRAC variants in the RAO has been fixed. The RAO now creates N + 2 results variants, where N is the number of curative perimeters in the search tree.
• A bug in the curative RAO caused the initial set point of range actions to not correctly be initialized from the network file, which lead to errors in the RAO. Now the initial setpoints for all curative range actions are correctly set for all states.
• A bug where the dynamic ranges were able to update their limits while a perimeter was being optimized has been fixed.
• A bug in the threshold definition for relative margins in the linear problem has been fixed.

Maven deploy plugin

• The version of maven-deploy-plugin that was used is not stable yet and caused issues for internal deployment process. The version of maven-deploy-plugin has been downgraded to restore latest version used (2.8.2) that solves the internal artifact deployment issue.

Initial sensitivity computation

• A bug, caused by the absence of initial load flow computation on CNECs of curative perimeters, resulted in wrong loopf-flow and MNEC constraints in the curative RAO. This has been fixed by computing sensitivities for all CNECs before preventive RAO and storing them in the initial variant.

I/O

• InjectionSetpoint network actions can now be properly imported from a JSON CRAC.

Some remarks on the quick evolution of Farao's API

The code of farao-core is still evolving significantly from one release to the next. Several of those evolutions are impacting, in one way or another, the APIs of FARAO, and consequently the applications that rely on it. We are indeed in a stage in which we are still allowing ourselves to bring many breaking changes to our API.

These quick evolutions of the API give us the flexibility in the current stages of the Farao development to question some of our initial choices, and adapt some parts of the source code in order to make it more robust, scalable, easy-to-read and fitted to the newly developed features.

Eventually, the API of FARAO will be stabilized. Breaking changes will be made with more parsimony and be accompanied by more documentation. But this stabilization will come later as significant changes in the crac-api are still expected in the next releases.

Release v2.2.0

Release note

General

• Upgrade to java 11
• OR-Tools update (attached is the associated version of binaries for Linux & Windows)
• Migration of legacy modules into a new repository

Refactoring - breaking changes in API

Sensitivity computation

Migration of all that is related to sensitivity computations in a dedicated package. Improvement of the performance of the sensitivity computations with :

• the possibility to mutualize the sensitivity computations of PSTs and PTDFs
• a better handling of sensitivity factors in DC mode

Glsk importer

Refactoring of the API of the GLSK importers

Flow-based computation

Migration of the flow-based-computation module which now relies on the Crac object (instead of the CracFile object which have since been moved in the farao-legacy repository)

Crac packages

• refactoring of thresholds : fixing of some issues with tie-lines and transformers threshold
• refactoring of usage rules
• clarification of PstSetPoint tap convention

Remedial Action Optimization

• modification of the Rao API with the RaoInput object

New Features

Relative margin objective function

(the related margin of a Cnec is equal to its margin, weighted by the impact of zone-to-zone exchanges on the Cnecs)

• new objective functions : MAX_MIN_RELATIVE_MARGIN_IN_MEGAWATT, and MAX_MIN_RELATIVE_MARGIN_IN_AMPERE
• addition of several parameters in the configuration of the RAO related to this new objective function : ptdfBoundaries, ptdfSumLowerBound, negativeMarginObjectiveCoefficient.

Curative remedial action Optimization

Curative remedial actions are now optimized by Farao.
Farao solves sequentially the preventive perimeter, and curative perimeters. More information on the website

• possibility to solve in parallel several curative perimeters

Loop-flow computation

• reference program file : new packages dedicated to the reference program file and its import from a xml file + consideration in loop-flow computation of the reference program when shifting net positions
• virtual hubs : consideration of virtual-hubs in loop-flow computation, relying on the new version of farao-virtual-hubs repository
• new configuration parameter : define which countries are taken into account in loop-flow computation
• new configuration parameter : define an acceptable loop-flow augmentation
• new configuration paramter : set a new possible approximation level (UPDATE_PTDF_AFTER_TOPO)

Miscellaneous

• parallel PSTs : addition of a groupId attribute to the RangeAction. All rangeActions from the same group must have the same setpoint.
• handle contingencies on dangling lines
• new utility method which enable to apply remedial action on a network

Performance related features

• geographical filter : addition of configuration parameters which enable to only investigate network action which are "geographically close" from the most limiting Cnec
• curative RAO stop criterion : addition of the possibility to have a curative stop criterion that is different from the preventive stop criterion, and which can be defined relatively to the objective function value found in preventive.
• improve crac usage performances in some crac-impl classes

Some remarks on the quick evolution of Farao's API

The code of farao-core is still evolving significantly from one release to the next. Several of those evolution are impacting, in one way or another, the APIs of Farao and consequently the applications that rely on it. We are indeed in a stage in which we are still allowing ourselves to bring many breaking changes to our API.

These quick evolution of the API give us the flexibility in the current stages of the Farao development to question some of our initial choices, and adapt some parts of the source in order to make them more robust, scalable, easy-to-read and fitted to the newly developed features.

Eventually the API of FARAO will be stabilized, and breaking changes will be made with parsimony and be accompanied by more documentation. But this stabilization will come later as significant changes in the crac-api are still expected in the next releases.

Release v2.1.1

Release note

GENERAL

• Upgrade powsybl-balances-adjustment

v2.1.0

Release note

GENERAL

• Adaptation of farao to PowSyBl v3.5.0: https://github.com/powsybl/powsybl-core/releases/tag/v3.5.0

CRAC

• The package crac-results-extensions enables to extend the crac object model with complementary information regarding the RAO output.
• The package crac-loopflow-extensions enables to extend the crac object model with complementary information regarding the consideration of loopflows into the RAO
• A Crac constructor following the builder pattern has been added in order to facilitate the construction of the Crac object model
• The frm (Flow Reliability Margin) is a new attribute which have been added to the Cnecs, and which is now subtracted from the Cnecs thresholds during the RAO
• The package crac-io-cne enables to export the crac object model into a CNE .xml file
• It is now possible to specify a timestamp in the crac importer to filter the data
• Switches topology network actions can now be applied on the network

LOOPFLOWS

• A significant new feature of this release is the possibility to monitor, during the RAO, the loopflows on some critical network element, and to ensure that they remain below a threshold defined as the maximum of (i) a threshold defined as input in the crac-loopflow-extensions (ii) the initial loopflow value computed before the application of any remedial action

MNECS

• Another significant new feature of this release is the integration of mnec (Monitored Network Element and Contingency) in the RAO. The margin of the mnec is not optimized. However, the RAO ensures that the margin of those mnecs is (i) positive or (ii) above their initial value.

AMPERE OR MEGAWATT

• A setting of the RAO's configuration gives the possibility to optimize the margin of the Cnecs in Ampere, or in Megawatt. Note than one unit is not just an homothety of the other one, as the margin in ampere tend to give more weights to the lower voltage levels than the margin in megawatt.

AC, DC AND FALLBACK

• The settings of the RAO now enable to define a default and a fallback configuration of the sensitivity computation. It could be typically used to define a default AC configuration, and a DC fallback configuration to prevent the fact that some of the sensitivity computations could diverge.

OTHER RAO FEATURES

• The package rao-commons exposes some "utils" blocks of the RAO, one of them being a cross quality-check of the Crac and Network.
• The node evaluations of the search-tree can now be made in parallel, using several threads of the same machine.
• The logs of the RAO have been made more verbose. The logback framework has been added into the tests in order to facilitate the management of the FARAO's logs.
• The configuration of the RAO (RaoParameters) has significantly evolved since the previous release, with many new parameters and a new organisation of the parameters.
• The RAO can now interact with the systematic sensitivity analysis service provided by PowSyBl

IMPORTANT REMARKS

• As you can see with the content of this release, the code of farao-core is still evolving significantly from one release to the next. Several of those evolutions are impacting, in one way or another, the API of FARAO and consequently the applications that rely on it. We are indeed in a stage in which we are still allowing ourselves to bring many breaking changes to our API (crac-api, rao-api).
• These quick evolutions of the API gives us the flexibility in the current stages of the FARAO development to question some of our initial choices, and adapt some parts of the source in order to make them more robust, scalable, easy-to-read and fitted to the newly developed features.
• Eventually the API of FARAO will be stabilized, and breaking changes will be made with parsimony and be accompanied by more documentation. But this stabilization will come later as some new ground-breaking features are expected in the next release (including the curative remedial actions), and so impacting modification will still be made in the following releases.
• The website of FARAO has been updated since the previous release, with many new pages which describe the algorithms implemented into the RAOs: see https://farao-community.github.io/

v2.0.0

Release note

General

• Powybl upgrade : adapatation of Farao to PowSyBl version 3.2.0
  https://github.com/powsybl/powsybl-core/releases/tag/v3.2.0

Crac API
A new Crac API has been defined. It enables an easier manipulation of network optimization data. It gathers data on states, cnecs and remedial actions. In the end this new Crac API would replace the Crac file API.

Crac io API
Coming with the new Crac API a module that manages import/export of Crac implementations. For now it contains the Crac io API and one implementation of it with JSON format. This new Crac io API is defined according to new PowSyBl way of implementing this kind of interfaces.

Rao API
Following the creation of Crac API which would replace the Crac file API, the Rao API would replace the RA optimization API. It follows the same format as RA optimization API but it uses Crac API as input and not Crac file API. The inputs are mainly a PowSyBl network and a Crac API.

Linear Rao
Linear Rao is one implementation of the new Rao API. Given a network it defines the optimal tap positions of PSTs in preventive state, the one which maximizes the minimum margin. It is based on or-tools engine for linear optimization.

Search Tree Rao
Search Tree Rao is another implementation of the new Rao API. It looks for a good combination of topological remedial actions, and relies on the Linear Rao to optimize the application of PST remedial actions.

Systematic Sensitivity Analysis
The util package of Farao now offers a systematic sensitivity analysis. It is a wrapper arround the already existing sensitivity analysis which also takes as input a Crac, and which performs sensitivity analyses for the several states defined in the Crac.

Additional remarks
Farao will continue to significantly evolve in the next months. For now the documentation on Farao is not evolving as fast as its development. However, its website will be updated in the following weeks and more communication will be made about the new Farao features once the new Crac API and RAOs will start to stabilize (second semester of 2020).

v1.2.0

Release note

General

• Powybl upgrade : adapatation of Farao to PowSyBl version 3.0.0
  https://github.com/powsybl/powsybl-core/releases/tag/v3.0.0

Crac file API

• addition of field penaltyCost for PstElement
• addition of field targetPower for RedispatchingRemedialActionElement

PTDF computation (new feature)

• Calculation of PTDFs is now possible with Farao
• Export of PTDF results in csv format

RA Optimisation API

• addition of topological actions in RaoComputationResults

Closed Optimisation RAO

• switch contingencies are now taken into account
• several redispatch RA on the same generator can now be handle without bug
• addition of BranchOverloadVariablesFiller, MinimizationObjectiveFiller and OverloadPenaltyCostFiller
• addition of overload-penalty-cost in the configuration
• addition of optimisation stop criteria in the configuration : max-time-in-seconds and relative-mip-gap
• deletion of referenceFlowsPreProcessor, now calculated more efficiently in SensitivityPreProcessor
• addition of threshold in the configuration, under which sensitivities are considered null : redispatching-sensitivity-threshold and pst-sensitivity-threshold

To benefit from the new features of the closed optimisation RAO, Farao configuration file should be updated with (e.g.) :

closed-optimisation-rao-parameters:
relative-mip-gap: 0.001
max-time-in-seconds: 36000
redispatching-sensitivity-threshold: 0.05
pst-sensitivity-threshold: 1
overload-penalty-cost: 3000
problem-fillers:
- com.farao_community.farao.closed_optimisation_rao.fillers.BranchOverloadVariablesFiller
- com.farao_community.farao.closed_optimisation_rao.fillers.MinimizationObjectiveFiller
- com.farao_community.farao.closed_optimisation_rao.fillers.OverloadPenaltyCostFiller

v1.1.0

Release note

Features

• Add curative PST and RD optimisation to closed RAO algorithm
• Add CRAC file merging feature

Fixes

• Small fixes in CRAC XLSX import
• Code coverage improvements