v3.2.0

Release note

Breaking changes

There is no breaking change in this release. It updates Powsybl and farao virtual hubs dependencies.

Bug fixes

• Consider GLSK not connected when bus is null
• Fix parallel computing in curative

v3.1.0

Release note

Breaking changes

There is no breaking change in this release.

New features

UCTE wildcards

• UCTE CRAC importers can now rely on the new UcteNetworkHelper to use wild cards in node names. This class also implements some features that render PowSyBl's UcteAliasCreation useless in Farao.

PST creation context

• The new PstRemedialActionCreationContext interface allows CRAC creators that implement the StandardCracCreationContext to add info about the creation of a PST remedial action: whether the PST convention in the CRAC is opposite to the network's, and the native network element as registered in the CRAC file. This interface is useful for PSTs defined using UCTE (from/to or to/from) standard.

Bug fixes

RaoResult import

• A bug was squashed in the RaoResult json deserializer.

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.

v3.0.0

Release note

Breaking changes

This is a major FARAO release. It contains a big overhaul of the CRAC and RAO APIs.
Modify your applications accordingly.

Refactoring

CRAC API

• The CRAC creation now relies exclusively on adders. The adders have been updated to allow you to create the most complete business objects that you may need.
• There's a new CRAC json exporter and importer. The json file is easier to read, and does not depend on the underlying CRAC object. Instead, the importer and exporter use the CRAC API like all other importers and exporters should. The json file is versioned and will be stable through the few upcoming releases.
• Some new helper classes in the crac-creation-util package are here to help you map the CRAC's objects to elements in the network, when creating a FARAO CRAC object.

RAO API

• The RAO API is now more feature-rich. It now relies on clearly defined inputs and outputs.
• There's a new RaoResult interface provided by the RAO providers, containing all the RAO results you need. You no longer have to go through the CRAC's extensions in order to look for the RAO results.
• The RaoResult has a json exporter and importer. It will be stable for the next few releases and will be versioned in the future.
• The CRAC's extensions are not used anymore: the CRAC stays untouched through the whole RAO.

New features

Second preventive RAO

• You now have the possibility to turn on the "with-second-preventive-optimization" in SearchTreeParameters, enabling you to run a second preventive RAO after the curative RAOs.
• This second preventive RAO can help mitigate some constraints created by the first one, that were not resolved by the curative RAOs.
• The second preventive RAO takes into account all the CNECs in the CRAC, as well as the optimal remedial actions decided during the curative RAOs.

On-constraint remedial actions

• The CRAC API and the RAO now handle the definition and optimization of remedial actions available in case of a constraint on a given CNEC.

New settings

• You can now define a maximum number of curative remedial actions to use in a given curative perimeter, using "max-curative-ra"
• You can now define a maximum number of TSOs that can use curative remedial actions in a given curative perimeter, using "max-curative-tso"
• You should now turn MNEC constraints ON or OFF using "rao-with-mnec-limitation", instead of using non-zero/zero mnec violation cost.

Bug fixes

RAO

• Aligned PSTs with different initial setpoints (in the network) are now excluded from the RAO. This ensures the initial solution is feasible for the RAO.

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.3

Release note

Bug fixes

• Better PST filtering when maximum number per TSO is reached
• In LoopFlow computation, Farao now ignores PTDFs for elements not connected to the main component of the network
• When the iterating linear optimizer degrades the minimum margin, the network is reset to the previous situation. This prevents the RAO from wrongly counting the number of used PSTs.

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.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