Releases: powsybl/powsybl-open-rao
v3.4.1
v3.4.0
Release Note
UCTE crac creation helpers
- addition of busIdMatchPolicy which replaces the 8th character of the UCTE node by *
UCTE GLSK importer
- ignore GLSK entry if all its generators/load are absent from the network
PST optimization
- possibility to optimize PST remedial actions with mixed-integer optimization, instead of linear optimization. Possibility to change from LP to MIP through the RAO parameter
pst-optimization-approximation - optimization solver can be switch with new RAO parameter
optimization-solver - addition of several RAO parameters to access the solver configurations:
relative-mip-gap,solver-specific-parameters
Loop-flows
- modifications on how the loop-flow threshold is calculated, with the configuration parameters related to loop-flows
loop-flow-acceptable-augmentationandloop-flow-constraint-adjustment-coefficientso that the initial solution is always feasible in the PST optimization
Relative margin:
- fix an issue in the calculation of the relative-margins after the outage on Alegro HVDC
Sensitivity-computation:
- change the construction of the sensitivity computation output object to make it work with open-load-flow management of NaN value
- fix an issue on the DC/AC fallback. Intensities are not computed anymore in fallback mode.
RAO:
- better management of RAM, fixing of some leaks
- computational improvement to speed up the RAO
- diversification of the conditions on which the second preventive optimization is run, with parameter
second-preventive-optimization-condition
v3.3.3
Fix release issues
v3.3.2
Fix
Fix javadoc generation
v3.3.1
New features
CRAC creation - Breaking changes
- New module has been created to gather CRAC creation features. Packages of crac-creator-api and crac-creation-util have changed.
- CRAC creation from CSE format is now handled
Bug fixes
- Performance improvement on loopflow computation
v3.3.0
Release note
General
- Adaptation of farao to PowSyBl v4.4.0: https://github.com/powsybl/powsybl-core/releases/tag/v4.4.0
- Adaptation to farao-virtual-hubs v0.0.6: https://github.com/farao-community/farao-virtual-hubs/releases/tag/v0.0.6
New features
CRAC API
- Some new interfaces have been created in order to streamline crac creation with good practice
- It is now possible to add custom CracCreationParameters to the crac creation process, in order to use settings that would be specific to the crac format imported
- UCTE helpers have been improved and a new HVDc helper has been added
- A new bus id match policy has been added to the UCTE helpers (REPLACE_8TH_CHARACTER_WITH_WILDCARD), allowing the user to match only the first 7 characters of the node name
RAO
- The range action sensitivity threshold parameters now adapt to the objective function when it is based on relative margins
- The range action filter now better handled aligned range actions, when filtering-out range actions to respect the maximum number of remedial actions allowed.
- The RAO now handles HVDC range actions. Use the HvdcRangeActionAdder in order to create this new type of remedial actions. Two new settings have been added to RaoParameters: "hvdc-sensitivity-threshold" (to filter-out HVDC actions that are not very effective) and "hvdc-penalty-cost" (to minimize HVDC usage when it has no effect on the margins)
- The RAO now handles simulating topological automatons at the AUTO instant. These automatons are activated as soon as their activation condition is triggered (ie when a contingency is triggered or when a critical element is constrainted)
- The second preventive RAO now handles advanced curative RAO stop criteria (PREVENTIVE_OBJECTIVE, PREVENTIVE_OBJECTIVE_AND_SECURE) as well as MNEC and LoopFlow constraints
New settings
- You can now define a sensitivity threshold for HVDC range actions (unit = unit of objective function per MW), using "hvdc-sensitivity-threshold"
- You can now define a penalty cost on the usage of HVDC range actions (unit = unit of objective function per MW), using "hvdc-penalty-cost"
Bug fixes
- A bug has been fixed in the initial sensitivity analysis in order for it to return relevant initial cost.
- A bug has been fixed in the PreventiveAndCurativesRaoOutput in order to filter-out perimeters with no functional cost when returning the overall functional cost after optimization (that is perimeters that only have virtual costs, like pure MNECs)
- A bug has been fixed in the GLSK importer where blocks concerning a load or generator with no power in the network were deleted. These are no longer deleted if we have a manual GLSK type, in order to be able to shift on them.
Full Changelog: v3.1.0...v3.3.0
v3.2.0
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.