Investment simulations for ANTARES studies
This package works along with RTE's adequacy software ANTARES that is also hosted on github
Please see the Antares-Xpansion Documentation for an introductory tutorial, and a full user guide. Visit the Antares-Simulator Documentation for more insights on ANTARES.
Antares-Xpansion
optimizes the installed capacities of an ANTARES study.
Typical uses of Antares-Xpansion are for example:
long-term scenario building: build an economically consistent long-term generation mix
transmission expansion planning : compute the network development which maximizes social welfare
In an ANTARES simulation, the user builds a power system with a network of zones characterised by power plants (with their constraints e.g., max power etc. and costs), power consumption and power transfer between zones(with the import-export transfer capacity and costs).
Antares performs probabilistic simulations of the system throughout many year-long scenarios made of 8760 hourly time-frames each. The goal of the simulation is to minimize the expected operation cost during one year.
Given an ANTARES simulation the user can define some investment candidates in the power network such as
- (increase or create) transfer capacity between to areas
- (increase or create) maximum power of a generation facility
Each investment candidate can potentially lower the operational cost of the power system, but is also characterised by one or more costs as:
- annualized investment costs to physically build it in real life
- operational costs and maintenance costs to sustain the operation
Antares-Xpansion optimises the values of the investments to minimize the global costs, that is the sum of the expected operation cost during one year and the investment annuity.
Antares-Xpansion
is currently under development. Feel free to submit any issue.
Antares-Xpansion is currently released as standalone-portable solution. It can be run either using the single file executable or an archive including multiple binaries called by a driver.
The user should first create an Antares study
that allows for the definition of investment candidates
(see the doc for detailed informations)
and create the candidates.ini
and settings.ini
files
in the directory study_path/user/expansion
.
Antares Xpansion does not have a GUI, the entry point to run Antares Xpansion is in the executable
/antares-xpansion-install-dir/antares-xpansion-launcher.exe
.
This binary should be run from a command prompt or unix terminal:
For example by runnin the following command inside the /antares-xpansion-install-dir/
Antares-Xpansion runs one of the examples
./antares-xpansion-launcher.exe -i examples/SmallTestFiveCandidates
The python script does several operations one after the other. The step option allows to execute only one step or all the steps (Interaction between the different bricks).
name | action |
---|---|
antares | Launch antares one time to get the Antares problem |
getnames | Launch getnamer one time to get the name of Antares variables |
lp | Launch lpnamer one time to create the master problem of expansion |
optim | Launch the resolution of Antares Xpansion |
update | Update antares study with investment solution |
full | Launch all steps in order (antares > getnames > lp > optim > update) |
Antares-Xpansion is developed mainly in C++ and uses a Python runner to drive the execution of multiple executables.
This software suite has been tested under:
Antares XPansion is built using CMake. For build and installation instructions, please visit doc/build/0-INSTALL.md
- README - This file.
- cmake/ - files for initializing a solution ready for compilation.
- conception/ - json output description
- docs/ - Markdown files for documentation generation
- data_test/ - Free sample data sets.
- documentation/ - Documentation generation with doxygen
- src/cpp/ - source code for cpp application (lpnamer, benders with mpi, benders without MPI, merge)
- src/python/ - python script for Antares XPansion launch.
The user of the package defines investment candidates. Each investment candidate is characterized with the following properties:
- name: name of the investment candidate (warnings : must not contains spaces)
- link: link whose capacity will be invested
- annual cost per MW: investment cost, per year and per MW
- unit size: size, in MW, of an investment unit (e.g. one group of 300 MW)
- maximum units: maximum number of units which can be built
- has link profile: True if candidate has a capacity profile
Concretely, the investment decision will affect only the capacity of the ANTARES' links. Investing in interconnections can be made directly with the package, while investing in generation capacity or storage capacity can be made using the so-called concept of "virtual nodes" with ANTARES.
The definition of all the investment candidates is given in a new input file, located in the user folder of the study: ./user/expansion/candidates.ini. The syntax used within this file is illustrated in the example below.
An example with two investments candidates, one in semi-base generation and one in network capacity, is given below.
The invested semi-base generation in area 1 is shifted in the "virtual node"
invest_semibase. Within the optimization process, the capacity of the link
between area 1 and invest_semibase will be updated with the new invested capacity.
The candidates.ini
file for this example will be the following one. This file has to be saved in the folder user/expansion/
[1]
name = semibase
link = area1 - invest_semibase
annual-cost-per-mw = 126000
unit-size = 200
max-units = 5
already_installed_capacity = 200
[2]
name = grid
link = area1 - area2
annual-cost-per-mw = 3000
unit-size = 500
max-units = 4
For the case of distributed generation and storage, the investment variables can be continuous, without steps of several MW. In that case, the properties unit-size and max-units can be replaced by the property max-investment, and the invested capacity will be able to take any real value between 0 and max-investment (in MW).
By default, the investment candidates offer a "perfect capacity". That is to say, when 1 MW is invested, this 1 MW will be fully available for all the hours of the year. However, by adding the property link-profile
, one can define a time series (with an hourly time step) of the ratio between the invested capacity and the capacity which is actually available at a given hour. This feature can be used to model investments in (e.g.) intermittent generation or thermal generation with seasonalized maintenance shutdowns.
The property link-profile
can be used as below:
[1]
name = solar_power
link = area1 - pv1
annual-cost-per-mw = 100000
max-investment = 10000
link-profile = pv1.txt
Where pv1.txt
is a text file, located in the user/expansion/capa/
folder of the study, and which contains the load factor time series of the candidate (one column of 8760 values between 0 and 1, or two columns if there is a direct and indirect profile on the link). When x MW of the candidate solar_power will be invested, the actual time series of available power will be equal to the product of x
and the time series pv1.txt
.
The method used to perform the optimal expansion is a benders decomposition in which:
- The slave problem is an ANTARES simulation, where the installed capacities of the investment candidates are fixed,
- The master problem is a MILP, in which the decision variables are the installed capacities of each investment candidate.
The objective function which is minimized, is the sum of the expected annual operation cost (column OV. COST + column HURDLE COST of the outputs of ANTARES) and the investment annuity (as defined in the candidates.ini
file).
Concretely, the package will run ANTARES iteratively. Depending on the number of candidates, the convergence to the optimal solution can be quite long (several hundred iterations, and so several hundred ANTARES' simulations). Some algorithmic settings are however available and propose different tradeoffs between the accuracy of the solution and the computation time.
The different settings can be modified by the user of the package. All the settings are saved in a file settings.ini
located in the folder user/expansion/
.
optimality_gap
: The optimality gap can take any numeric value. The optimality gap is the maximum possible distance (in euros) between the solution returned by the method and the optimal solution.master
: Can take two values,relaxed
orinteger
. Defines whether or not should integer variables be used for the master problem.uc-type
: The UC (Unit Commitment) type can take two different values,expansion_fast
orexpansion_accurate
. It defines which mode will be used in ANTARES.expansion_fast
correponds to the fast mode of ANTARES in which the minimum up/down and minimum stable power constraints are relaxed whereasexpansion_accurate
takes into account the technical constraints of the thermal power plants as well as their start-up costs.
An example of a settings.ini
file with the appropriate syntax is given below.
uc_type = expansion_fast
master = integer
optimality_gap = 0
max_iteration = 100
Note that the optimality gap can also be given relatively to be best found solution by entering a % after the numeric value of the setting. In that case, the optimality is between 0%and 100% and the decimal separator is a point (.).
1. If I have to run several expansion optimizations of different variants of a study and compare them
In that case, if the optimal solutions are not returned by the package, the comparison of several variants can be tricky as the imprecision of the method might be in the same order of magnitude as the changes brought by the input variations. It is therefore advised to be as closed as possile from the optimum of the expansion problem. To do so, the two following conditions should necessarily be fulfilled:
- set the
optimality_gap
to zero. [Remark : even with the conditions mentionned above, the reslult might be slighty different from the optimum due to numeric approximations, this can be partly solved by putting to optimality gap to -Inf]
As the optimal solution is not more realistic than an approximate solution of the modelled expansion problem. The settings can be less constraining with:
- an
optimality_gap
of a few million euros