diff --git a/.github/workflows/branchNameValidation.yml b/.github/workflows/branchNameValidation.yml
index ff0d8fc669..8485f70785 100644
--- a/.github/workflows/branchNameValidation.yml
+++ b/.github/workflows/branchNameValidation.yml
@@ -12,5 +12,5 @@ jobs:
- uses: deepakputhraya/action-branch-name@master
with:
regex: '([a-z])+\/([a-z])+' # Regex the branch should match. This example enforces grouping
- allowed_prefixes: 'feature,features,fix,release' # All branches should start with the given prefix
- ignore: master,develop # Ignore exactly matching branch names from convention
+ allowed_prefixes: 'feature,features,fix,release,doc' # All branches should start with the given prefix
+ ignore: master,develop,doc # Ignore exactly matching branch names from convention
diff --git a/.github/workflows/build-userguide.yml b/.github/workflows/build-userguide.yml
new file mode 100644
index 0000000000..f00cea6089
--- /dev/null
+++ b/.github/workflows/build-userguide.yml
@@ -0,0 +1,46 @@
+name: Build Userguide pdf
+
+on:
+ push:
+ branches:
+ - main
+ - develop
+ - doc
+jobs:
+
+ build:
+
+ runs-on: ${{ matrix.os }}
+ if: "!contains(github.event.head_commit.message, '[skip ci]')"
+ strategy:
+ matrix:
+ os: [ubuntu-20.04]
+
+ steps:
+ - uses: actions/checkout@v2
+
+ - name: Set up Python
+ uses: actions/setup-python@v2
+ with:
+ python-version: 3.8
+
+ - name: Install dependencies
+ run: |
+ python -m pip install --upgrade pip
+ pip3 install -r requirements-doc.txt
+
+ - name: Install libraries
+ run: |
+ sudo apt-get update --fix-missing
+ sudo apt-get install latexmk texlive-latex-recommended texlive-formats-extra
+
+ - id: create-user-guide
+ name: user guide pdf creation
+ uses: ./.github/workflows/generate-userguide-pdf
+
+ - name: user guide upload
+ uses: actions/upload-artifact@v2
+ with:
+ name: ${{ steps.create-user-guide.outputs.pdf-name }}
+ path: ${{ steps.create-user-guide.outputs.pdf-path }}
+
diff --git a/.github/workflows/generate-userguide-pdf/action.yml b/.github/workflows/generate-userguide-pdf/action.yml
new file mode 100644
index 0000000000..bac54a8237
--- /dev/null
+++ b/.github/workflows/generate-userguide-pdf/action.yml
@@ -0,0 +1,22 @@
+name: "Generate User Guide pdf"
+description: "Generate User Guide pdf using Sphinx (not supported on windows)"
+outputs:
+ pdf-path:
+ description: "path of the user guide pdf"
+ value: ${{ steps.create.outputs.pdf-path }}
+ pdf-name:
+ description: "name of the user guide pdf"
+ value: ${{ steps.create.outputs.pdf-name }}
+runs:
+ using: "composite"
+ steps:
+ - id: create
+ shell: bash
+ run: |
+ PDF_NAME=antares-UserGuide.pdf
+ cd docs/pdf-doc-generation-with-sphinx
+ bash create_pdf_doc.sh $PDF_NAME
+ mv antaressimulatoruserguide.pdf $PDF_NAME
+ PDF_PATH=docs/pdf-doc-generation-with-sphinx/$PDF_NAME
+ echo "::set-output name=pdf-path::$PDF_PATH"
+ echo "::set-output name=pdf-name::$PDF_NAME"
diff --git a/NEWS.md b/NEWS.md
index a96e1bbb55..8029ba32cd 100644
--- a/NEWS.md
+++ b/NEWS.md
@@ -1,1256 +1,4 @@
Antares Changelog
=================
-v8.1.0 (09/2021)
---------------------
-
-### New features
- - Allow up to 9 RES groups (off-shore wind, on-shore wind, rooftop solar, PV solar, etc.) as opposed to wind and solar previously. This allows the user to distinguish between more renewable energy sources. When creating a new study, renewable generation modelling is set to "clusters" by default. This change does not affect opening an existing study. Note that TS generation is not available for these new RES groups.
- - Add 3 thermal groups, named other, other 2, other 3 and other 4.
-
-### Bug fixes
- - When a binding constraint is marked as skipped in the GUI, disable it in the solver #366
-
-### GUI
- - Keep selection on thermal/renewable cluster when its group changes #360
- - Dialogs "Thematic trimming" and "User playlist" are now resizable
-
-### For developers
- - Add non-regression tests on each release
- - Fix vcpkg on Github Actions
- - Add build cache for Github Actions to speed up the build (Linux only)
-
-v8.0.3 (05/2021)
---------------------
-
-### Bug fixes
-
- - Fix calculation of average for variable "congestion probability"
- - Fix NODU when unit number is not an integer i.e has decimals
- - GUI: allow decimal nominal capacity for thermal clusters
- - GUI: Linux: use xdg-open to open pdf files instead of gnome-open
-
-### For developers
-
- - Remove code related to licence management
- - Remove openssl and libcurl dependencies
- - Remove dead code
-
-v8.0.2 (04/2021)
---------------------
-
-### Bug fixes
-
- - Fix GUI freeze when area color is changed but user don't validate new color
- - Correction of MC year weight use for PSP and MISC NDG
-
-v8.0.1 (03/2021)
---------------------
-### Features
-
- - Add "Continue Offline" button at startup if antares metric server is unreachable
-
-### Bug fixes
-
- - Error with hydro start when using scenario playlist and stochastic TS refresh span
- - Files needed for antares-xpansion not exported when using scenario playlist with first year disabled
- - Correction of crash if user define a stochastic TS refresh span of 0 : minimum value is now 0
- - Correction of MC years playlist weight write when sum of weight was equal to number oy years (no MC years playlist export in .ini)
-
-### For developers
-
- - Add a GitHub action to check if branch name will launch CI
- - Add shared dll in windows .zip archive
-
-v8.0.0 (03/2021)
---------------------
-
-### Features
-
- - OR-Tools integration :
- - add command line option in antares-solver to define OR-Tools use and OR-Tools solver (option --use-ortools and --ortools-solver='solver')
- - add GUI option in run simulation to define antares-solver launch with OR-Tools option
-
-- Add advanced hydro allocation feature. The default and existing behavior is to accomodate the guide curves, the new behavior is to maximize generation, even if it means that the reservoir level goes beyond the guide curves.
-
-- Add indication on how to disable anonymous metrics
-
- - antares-xpansion :
- - add option `include-exportstructure` in `generaldata.ini` to export .txt files needed for antares-xpansion
-
- - Scenario builder and hydraulic level :
- Adding an hydraulic starting level tab in the scenario builder.
- For each MC year and area, a starting level can be defined, that is a 0-100 value.
- When the scenario builder is enabled, these levels get priority upon hot-start mode.
-
- - Binding constraints (BC) and thermal clusters :
- If a must-run or disabled cluster is involved in a binding constraint :
- - the cluster is marked as "N/A" in the BC formula (GUI > Binding constraint > Summary)
- - the cluster is marked as must-run/disabled in the Weights or Offsets tabs.
-
- If a BC involves only zero weighted clusters/links or must-run/disabled clusters, the BC is :
- - marked with a red bullet in the Summary tab
- - marked as Skipped in the Weights and Offsets tabs
-
- - MC Scenario Playlist :
- Add possibility to define a weight for each MC years in the synthetis results.
- See : GUI > Configure > MC scenario playlist.
- By default, a MC year's weight is 1, but can be set by user to more or less.
- After simulation, the MC year have a contribution to averages or standard deviations in synthesis results
- depending on the weight it was given.
-
-### Bug fixes
-
- - Selecting an area and then, from the inspector, trying to select a thermal cluster or a link of this area in the dependencies
- section causes a crash. The inspector's cluster/link selection was removed.
- - Scenario builder :
- - It makes no sense for the user to access the scenario builder Configure menu item whereas the Building mode parameter is set
- to Automatic or Derated. In the previous cases, the Configute menu item is disabled.
- - If a disabled thermal cluster is given a time series number in a non active rule of the scenario builder, a warning should not be
- triggered. If the disabled cluster is given a number for many MC years in the active rule, a single summary warning should be raised,
- not a warning per year.
-
-### For developers
-
- - External dependencies :
- - use of new repository [antares-deps](https://github.com/AntaresSimulatorTeam/antares-deps) for external dependencies compilation
-
-- Fix several compilation warnings
-- Remove unused `COUT_TRANSPORT` constant
-- Add code formatting with clang-format
-- Remove PNE dead code
-
-- docker image :
- - create of dockerfile for docker image creation
-
- - continuous integration :
- - use docker images in CI
- - use of antares-deps release artifact in CI
- - push of docker image to dockerHub in [antaresrte/rte-antares repository](https://hub.docker.com/repository/docker/antaresrte/rte-antares)
- - add Centos7 support
-
- - Unit tests :
- - Adding an end-to-end test in memory (see simple-study.cpp) :
- This test calls high level functions to build a simple study and runs it.
- It then checks if some elements of results match associated expected values.
- During this process, file system is not involved : everything takes place in RAM
- - Adding pytest scripts to check reference output values
- - Add pytest scripts related to unfeasible problems
-
-v7.2.0 (06/2020)
---------------------
-
-### Features
-
- - Simulation dashboard: A new "Geographic Trimming" option
- is now available in the "Configure" menu. This option makes
- it possible to filter the simulation's output content so as
- to include only results regarding Areas and Links of interest
-
- - Optimization: a new parameter "Unfeasible Problems Behavior"
- is available in the "advanced preferences" section of the
- "Configure" menu, with four possible values:
- (Error Dry, Error Verbose, Warning Dry, Warning Verbose)
- The first two options make the simulation stop right after
- encountering the first mathematically unfeasible problem, if any
- The last two options make the simulation skip all unfeasible
- problems, if any
- "Verbose" options print faulty problems in the “mps” format
- "Dry" options only report the time frame (MC year, week) for which
- an unfeasible problem was detected
-
- - Compilation and cmake tree :
- Updates were made for more modern CMake use.
- Git submodules (extern dependencies : curl, openssl, wxwidget) are no more in use.
- These external dependencies can be retrieved :
- - either from a library manager : vcpkg for Windows, classic package
- repositories for Linux. With this way to proceed, an installation of external
- dependencies is required once for all.
- - or thanks to an automatic download : at Antares' cmake configure step,
- all needed downloads, compilation and installation are done.
-
- - Unit tests :
- unit tests around class Matrix are now available.
- They can be compiled (on demand) during Antares' cmake build step
- and run either with ctest or in the classic way.
- Boost.Test is required and can be priorily retrieved and installed in the
- same way as the other external dependencies.
-
- - Continuous integration : yaml files for github actions allow the run of
- all build chain and unit tests on several environment (Windows and Ubuntu).
- The 2 ways of getting external dependencies are also tested.
-
- - Documentation: updated reference guide
-
- - Usage metrics: added reference key for this version
-
-### Bug fixes
-
- - GUI of the "Thematic trimming" option: Window size is naturally readjusted
- to improve readability by upgrading wxwidgets (3.1.3 and above).
-
- - Auxiliary "Batchrun" tool: two options previously missing in the
- command line syntax have been introduced and now make it possible
- to launch a sequence of simulations to run in parallel
-
-v7.1.0 (12/2019)
---------------------
-
-### Features
-
- - Simulation Dashboard: A new option "Thematic Trimming"
- is available in the "Output Profile" Section. This option
- now makes it possible to define precisely the content of
- output files so as to include only variables of interest
-
- - Optimization: a new parameter "Hydro Pricing mode" is
- available in the "advanced parameters" section, with two
- possible values (fast, accurate):
- In mode "fast", water value is, in the course of optimization,
- taken to be constant throughout the (daily or weekly)
- optimization period, and equal to that found for the exact
- day and level at which the optimization begins. Water values
- are reassessed afterwards, for each hour, on the basis of
- relevant time and level.
- In mode "accurate", the variations of water value along with
- the reservoir level are taken into account in the course of
- the (weekly) optimization. Reference (level-dependent) values
- are those attached to the end of the week. Water values
- are reassessed afterwards, for each hour, on the basis of
- relevant time and level.
-
- - Documentation: updated reference guide
-
- - Documentation: updated optimization problem formulation
- (modelling of hydro pricing options)
-
- - Usage metrics: added reference key for this version
-
-### Bug fixes
-
- - Output file "mc-all/grid/digest.txt": replaced "NaN" values
- by zeroes, where appropriate
-
- - Output file "mc-all/grid/digest.txt": replaced "0" values
- by N/A, where appropriate (especially, hydro reservoir-related
- variables, when the "reservoir management" area attribute is set
- to "No")
-
- - Output GUI: fixed a display bug regarding missing items in the
- "links" panel, in the case where simulation parameters are set
- so as not to produce synthetic results
-
- - Links GUI: improved integrity control regarding hurdle costs.
- Negative values are allowed in either direct or indirect
- orientation, provided that the sum of both is non-negative
-
- - General GUI: removed redundant items and renamed option menu
- "Geographic District" as "Regional District" to avoid confusion
- with new "Trimming" options
-
- - Output: when simulation results are trimmed so as not to produce
- any data for given Areas or Links, avoid creation of empty folders
- named after said Areas or Links
-
-v7.0.1 (04/2019)
---------------------
-
-### Features
-
- - Time-series analysis: in "detrended mode", extended perimeter
- to raw data including periods with no meaningful signal
- (e.g. solar production at night)
- - Hydro-storage modelling: added ability to optimize pumping along
- with generation in mode "use heuristic target without leeway"
-
-v7.0.0 (12/2018)
---------------------
-
-### Features
-
- - GPL release: updated companion files (README,...)
- - GPL release: updated project Icons
- - GPL release: insertion of license headers
- - GPL release: translation of comments
- - GPL release: removal of license control
- - GPL release: code restructuring to separate Antares and Sirius
- - Examples library: upgraded and added 16 new examples
- - Documentation: updated reference guide
- - Documentation: updated map editor guide
- - Documentation: updated optimization problem formulation
- - Documentation: updated examples library
-
-v7.0.0-rc (12/2018)
---------------------
-
-### Features
-
- - Improved code for linux compilation with gcc 7
-
-### Bugs
-
- - Fixed various issues in GUI
- - Fixed RHS of constraints generated by the KCG when
- min and max values of PST settings are strictly equal
- and constraints are generated for the whole year
-
-v6.5.1 (11/2018)
-----------------
-
-### Bugs
-
- - Fixed index in hydro heuristic engine
- - Hydro GUI: added scrollbars for correct display on laptops
- - Output: improved presentation of results for incomplete calendar-based weeks
- - Kirchhoff's constraint generator: fixed several GUI issues
- - Districts GUI: improved syntax control
-
-v6.5.0 (11/2018)
-----------------
-
-### Features
-
- - Implementation of Kirchhoff's laws (DC approximation),
- modeling of phase-shifters and representation of passive
- loop flows (to account for on highly reduced gris): a
- dedicated Kirchhoff's constraints generator is now available
- It makes use of both classical input data (impedances)
- and new input data. Its results are specific binding
- constraints whose names begin by @UTO-, storable in the
- INPUT folder after user's validation ("save")
-
- New or modified input data for link L (8760 hourly values):
- Impedances (moved from col.3 to col.5)(Ohms at ref. voltage U)
- Loop flow (passive) (MW)
- Min Tap of phase-shifter (MW*Ohms/U2 along any AC cycle including L)
- Max Tap of phase-shifter (MW*Ohms/U2 along any AC cycle including L)
- New link parameters (one value)
- Asset type (AC,DC,Gas,Virtual,Other) : KCG deals only with AC links
- "account for loop flow" toggle
- "tune PST" toggle
- KCG generating directives:
- Working map to use for generation
- Calendar to use for constraints activation (relaxation outside)
- Status of passive loop flow in constraints RHS (included or not)
- Status or PST settings in constraints RHS (included or not)
- Auto-check of nodal loop flow balance (activated or not)
- Definition of the "infinite" to use for constraints relaxation
- KCG results:
- For AC Links involved in the generation process: The KCG sets the
- values of the two input data toggles related to loop flows and
- PST settings, in accordance with the current generation directives
-
- Identification of an optimal (minimum-weight) cycle basis for the
- formulation of constraints
-
- Generation of all relevant constraints (equality, inequalities, with
- or without relaxation)
-
- - Reservoir-type hydro and other energy storage facilities:
- interface, input and output data structure, functionalities,
- have been completely redesigned. As a consequence, a number
- of new items (variables & parameters) are introduced in both
- input and output, while a few input variables are redefined
- or deprecated:
-
- Deprecated hydro variables:
- Pmax hydro "min", Pmax hydro "max"
- Redefined hydro variables and parameters:
- Hydro-storage time-series : redefined at the daily scale
- Bounds for Reservoir levels: redefined at the daily scale
- Res.level initialization date: redefined at the monthly scale
- New hydro variables and parameters:
- Input : max daily hydro generating energy
- max daily hydro pumping energy and power
- monthly-to-daily inflow breakdown pattern
- water value (time, level)
- modulation of max generating power (level)
- modulation of max pumping power (level)
- pumping efficiency
- +many "storage management options" parameters
- Output: Reservoir level (H.LEV)
- Water value (H.VAL)
- Pumping power (H.PUMP)
- Natural Inflow (H.INFL)
- Forced Overflow (H.OVFL)
- Cost of Gen+Pumping (H.COST)
- Optimization preferences:
- "Hot/Cold start" (year N may start or not at the final N-1 level)
-
- - GUI: Districts may now be defined from within the interface
- (notepad tab connected to the Inspector's clipboard)
-
- - Time-series generation (solar, wind, load) : increased speed
- when "high accuracy" option is selected, in the special case
- where all diffusion processes produce "Normal" variables
-
- - Example library: upgraded to 6.5 (without extension)
-
-### Bug fixes
-
- - Time-series generation: the storage (Input folder)
- of time-series generated for thermal clusters either in the
- "disabled" or "must-run" state did not work properly
-
- - Time-series analysis: when short- and long-term levels
- defined for auto-correlation assessment are identical, the
- analyzer now performs a pure exponential fitting
-
- - Time-series analysis: monthly time-series containing no
- non-zero value are no longer rejected by the analyzer
-
- - Output: the link-variable "MARG.COST" was rounded to an integer
- value (changed to 2 decimal accuracy)
-
-
-v6.1.3 (06/2018)
-----------------
-
-### Features
-
- - Output: added a new file at the root of simulation results,
- displaying a short summary of the overall system economic
- performance throughout all Monte-Carlo years
-
- - Log file: added new info messages on the size of optimization
- problems
-
- - Updater (standalone): added new options and improved
- help messages
-
- - Expansion mode: presolve stage replaced by hot start
-
-### Bug fixes
-
- - Simulation: In the "accurate" Unit Commitment mode, the
- optimization preference "thermal Clusters Min Up/Down Time"
- can now be turned to "ignore"
-
- - Simulation: removed remaining debug traces
-
- - Simulation: zero-reset on interconnection marginal costs
- was sometimes missing in optimization final stage
-
- - Example library : upgraded to 6.1 and extended
-
-
-v6.1.2 (11/2017)
-----------------
-
-### Features
-
- - Solver, Simplexe package: Improvement of the Scaling stage
- (Matrix, right hand side, costs)
-
-
-v6.1.1 (11/2017)
-----------------
-
-### Features
-
- - Solver: Light changes in Presolve stage
-
-
- v6.1.0 (09/2017)
-----------------
-
-### Features
-
- - GUI and simulation: "binding constraints" objects may now involve
- not only flows on interconnections but also power generated from
- thermal clusters. Alike flows, generation from thermal clusters may
- be handled either on an hourly, daily or weekly basis and may be
- associated with arbitrary offsets (time-lags expressed in hours).
-
-
-v6.0.6 (07/2017)
-----------------
-
-### Features
-
- - GUI: Binding constraint parameters tables (weights and offsets) are trimmed
- line-wise so as to fit exactly with the content of the selected working map
-
- - Solver: strenghtening of the final admissibility check step in the "accurate"
- commitment mode
-
-
-
-v6.0.5 (07/2017)
-----------------
-
-### Bug fixes
-
- - Solver: Pruning of redundant messages in simulations launched from command line
-
- - Solver: Removal of misprints in command line help messages
-
- - Files: Fixed issues (detected as of 6.0.1) regarding storage of thermal time-series files
-
- - Study Cleaner: Unwarranted removal of the graphic multi-map lay-out could occur when
- cleaning datasets (detected as of 6.0.0)
-
-
-v6.0.4 (06/2017)
-----------------
-
-### Bug fixes
-
- - GUI: The "variable per variable" view of the output files allows
- to display the power generated by each thermal cluster
-
- - Simulation: Negative "ROW Balance" is properly included in
- unsupplied energy allowances
-
-
-v6.0.3 (06/2017)
-----------------
-
-### Features
-
- - GUI: The number of system maps that could be stored in a given study
- was limited to 19. This number is now unbounded.
-
-### Bug fixes
-
- - GUI: The list of thermal clusters displayed for a given Area in the
- current map was sometimes wrongly initialized (Area considered
- selected though not explicitly clicked on yet)
-
- - GUI: The order in which binding constraint terms are shown in the
- "summary" Window could depend on the execution platform used
-
- - GUI: The Antares study icon could not be properly copied in some
- circumstances
-
-
-v6.0.2 (06/2017)
-----------------
-
-### Features
-
- - Optimization : To help discriminate between equivalent economic
- solutions, random noises on hydro hourly prices are more regularly
- spread out (absolute values) in the interval (5 e-4 ,1 e-3)Euros/MWh
-
-### Bug fixes
-
- - Simulation : The identification of the Monte-Carlo year numbers
- in which the smallest/greatest values of random variables are
- reached could be ambiguous when identical results are found for
- two years ore more.
-
-
-v6.0.1 (05/2017)
-----------------
-
-### Features
-
- - Thermal Time-series generation: Data regarding all thermal clusters
- are generated and stored in the same way, regardless of their activity
- status (unabled/disabled). This makes easier to check data consistency
-
- - Simulation: Upper bounds for spilled power and unsupplied power are
- actually set to their maximum theoretical value(i.e. if economic
- conditions make it justified: spill all power or shed all demand)
- So far, spillage of power that could be absorbed by the local demand
- was not allowed
-
- - Simulation: a silent "Expansion" mode has been added to the regular
- modes "Economy/Adequacy/Draft". The three differences with the
- "Economy" mode are:
- a) In "accurate" unit commitment, integrity constraints are relaxed
- in the core optimization problem.
- b) Day-ahead reserve is no more subtracted from the initial demand
- to get back to "standard" conditions
- c) The values of all optimal criteria are printed in ad hoc files
- The use of this mode should be restricted to well-designed scripted
- automatic simulation sequences taking into account the simplifications
- listed above
-
-
-v6.0.0 (04/2017)
-----------------
-
-### Features
-
- - GUI: A new interface makes it possible to define several views (maps) of
- the Power System modelled in an Antares study. These maps are meant to give
- the user the ability to set different layouts in which each Antares Area
- or Link can be either shown or remain hidden. Accordingly, all input and
- output data windows can now adapt the information displayed so as to match
- exactly the content of any given map. Copy/Paste functions have been
- extended so as to work between different maps of different studies opened
- in multiple Antares sessions
-
- - Simulation: Introduction of a flexible multi-threaded mode for the processing
- of heavy problems: Antares "Monte-Carlo years" can be be distributed on a
- number of CPU cores freely set by the user. This parameter appears as a new
- tunable item of the "advanced parameters" list attached to any Antares Study.
- Five values are available in the [1, N] interval, N being the number of CPU
- cores of the machine (virtual or physical) Antares is run on
-
- - License control through the internet: a new system has been developed for
- accommodating situations where users wish to operate Antares on a large
- fleet of machines among which a limited set of commercial license tokens
- can float freely
-
- - Data organizer: Antares studies often include a great number of files of
- all sizes, which may take long to process when multiple copies are needed.
- Likewise, the management of the HDD space required for regular storage of
- all of the studies involved in a complex study workflow may turn out to be
- a demanding and heavy task. To save both time and hardware resources, the
- Antares Data Organizer, now provided as a companion tool to the Antares
- Simulator, brings the ability to schedule basic data management tasks
- such as study archiving/expansion (use of a specific compressed format),
- copy to backup folders, registering of studies and archives in catalogues.
-
-
-v5.0.9-SE (04/2017)
-----------------
-
-### Bug fixes
-
- - Random noises on thermal clusters costs now include the zero-cost
- "must-run" clusters (as a consequence, noises assumptions do not vary
- with the cluster status)
-
- - Fixing an initialization issue that could sporadically affect the
- minimum number of committed thermal units (+1 or -1 deviation,
- "accurate" mode only)
-
-v5.0.7-SE (04/2017)
-----------------
-
-### Features
-
- - License control : management of SSL certificates encrypted through SHA-256 algorithm
-
-
-v5.0.7 (12/2016)
-----------------
-
-### Bug fixes
-
- - Fixing a packaging error
-
-
-v5.0.6 (12/2016)
-----------------
-
-### Bug fixes
-
- - Results processing: For full "must-run" thermal clusters, the NODU variable
- could be wrongly assessed in the "accurate" unit commitment simulation mode
-
- - GUI: when the scenario builder feature is active, saving right after deleting
- a thermal cluster could result in a partial dataset corruption (references to
- the deleted object were kept alive in the scenario builder context)
-
-
-### Features
-
- - Unsupplied energy control: if the actual economic optimization requires it, load
- shedding is now allowed to occur in areas where the available thermal generation
- is higher than the local demand (e.g. if local VOLL < local thermal costs)
-
- - Linear solver, hot starting of weekly problems: in the "fast" unit commitment
- mode, optimal bases are flushed at the beginning of each Monte-Carlo year. This
- comes as a pre-requirement for the next versions of Antares, which will be
- fully multi-threaded
-
- - Simulation results: code segments processing all variables attached to spatial
- aggregates, and the variable representing the number of running thermal units
- on the first hour of the year, were re-written to be compatible with the next
- versions of Antares, which will be fully multi-threaded
-
-
-
-v5.0.5 (08/2016)
-----------------
-
-### Bug fixes
-
- - No-Load Heat costs and Start-up costs: in the "fast" unit commitment options,
- the result was slightly below the actual optimal possible cost for some
- datasets (i.e. datasets in which the thermal cluster coming last in alphabetic
- order had a minimum stable power equal to zero).
-
- - Spilled energy control: the three parameters defining how energy in excess should
- be split between the different possible sources when there is a choice to make
- can work properly again (feature inhibited in previous 5.0.x versions)
-
-
-### Features
-
- - License control throughout the internet: all combinations of UTF8 characters can
- now be used within proxy ids and passwords
-
- - Economic optimization: in an area where the amount of available thermal power
- exceeds that of load, the fact that the demand should necessarily be served
- is locally expressed as a constraint of the optimization problem (LOLE=0)
-
-
-v5.0.4 (05/2016)
-----------------
-
-### Bug fixes
-
- - Errors occured on loading the "min gen modulation" time-series of thermal clusters
-
-### Features
-
- - Better estimate of the number of thermal units dispatched in "fast" unit commitment mode
- - Nodal Marginal Prices and Marginal yield on interconnections are now available in
- "accurate" unit commitment mode
- - Binding constraints including offset parameters: unbounded positive or
- negative values can be used for all classes of constraints (hourly, daily, weekly)
-
-
-v5.0.3 (05/2016)
-----------------
-
-### Bug fixes
-
- - Crashes occured when the "full must-run status" parameter was set on
- "true" for thermal clusters
-
-
-v5.0.2 (04/2016)
-----------------
-
-### Bug fixes
-
- - Removed debug information that should not be displayed in release mode
-
-### Features
-
- - The optimization criterion used to assess the hydro energies to generate throughout
- each month incorporates heavier penalization terms for the 12 deviations from the
- theoretical monthly targets (formerly, only the largest deviation was penalized).
-
-
-v5.0.1 (04/2016)
-----------------
-
-### Bug fixes
-
- - Adequacy mode: fixed a memory allocation bug that forced the post-simulation
- output files processing to be interrupted
-
- - In the previous version, additional logs were added. That could lower the simulation
- performances in some cases. This problem is now solved.
-
-
-v5.0.0 (03/2016)
-----------------
-
-### Bug fixes
-
- - GUI, system map: copy /paste of binding constraints could alter the activity status or
- the names of the duplicated binding constraints in some instances
-
- - GUI, system map: some conflicts in copy/paste actions were not always properly raised
- (e.g. attempt to copy three nodes and paste them on two other nodes)
-
- - Thermal clusters: Improved checking of time-series generation parameters (improper use of a
- nominal capacity modulation factor lower than the minimum stable power is no longer possible)
-
- - Thermal clusters: Improved checking of ready-made time-series. If the user-chosen time-series
- are not consistent with the parameters set in the GUI, warnings are issued in log files
-
- - Output , LOLD variable: in some instances, the values assessed in "economic" simulation mode and in
- "adequacy" simulation mode could slightly differ because of sporadic rounding side-effects.
- rounding convention is now set uniformly to : 0 < X < 0.5 -> (X=0)
-
- - Output, MISC.NDG and PSP variable: values were not properly edited for the specific category
- "geographic districts, "year-by-year results"
-
- - Output, OV. COST, OP. COST, NP. COST variables: values were not properly edited for the last
- hour of the last day of the simulation
-
- - Output, File comparison functions: calendar marks were not properly displayed in some views
-
- - Output, File comparison functions: "Max" operator has been added
-
-
-### Features
-
- - Optimization: introduction of a new unit-commitment mode based on a MILP approach slower but more
- accurate than the former one. An option lets the user choose which mode should be used (fast/accurate)
-
- - Optimization: in "accurate" unit-commitment mode, incorporation of thermal start-up costs and
- no-load heat costs within the global objective function to minimize. In "fast" unit-commitment
- mode, start-up costs and no-load heat costs are minimized independently from the main objective
-
- - Optimization: in both unit-commitment modes, improvement of the inter-weekly start-up strategies
- (seamless reformulation of the optimization results obtained beforehand)
-
- - Thermal clusters: definition of separate minimum up/down durations to be used for unit-commitment
-
- - Thermal clusters: definition of a minimum amount of power (hourly time-series) to be generated
- by the units of the cluster, regardless of economic considerations (partial must-run commitment)
-
- - Thermal clusters: start-up cost can now be set from -5000000 to 5000000 (was from -50000 to 50000)
-
- - Binding constraints: introduction of new "offset" parameters which make it possible to define
- constraints whose terms can refer to different times (e.g. 2 X(t) - 1.5 Y(t-4) + 3 Z(t+1) <10)
-
- - Benchmarking: so as to allow transparent comparisons with other software, the user may demand
- that all optimization problems solved by Antares be printed in a standardized "mps" format
- along with the values of the optimized criterion.
-
- - GUI, System map : new button available in the tool bar for centring the map on a (x,y) location
-
- - GUI, System map : new button available in the tool bar for map trimming around used space
-
- - Output: In synthetic Monte-Carlo results,year-by-year results and cluster-by-cluster results,
- Addition of a field "Number of dispatched units" (NODU)
-
-
-
-v4.5.4 (03/2015)
-----------------
-
-### Bug fixes
-
- - License checking: internet proxys for which no login and/or password have been
- defined can now be used
-
- - Upgrade to 4.5 format of datasets edited in 4.4 format or lower, in which the "scenario builder"
- feature was activated: the conversion to 4.5 format could fail sometimes.
-
-v4.5.3 (02/2015)
-----------------
-
-### Features
-
- - Start-up and fixed thermal costs: the interpretation of the unit-commitment strategy
- (starting-up and shutting-down times of each thermal unit) includes the explicit
- minimization of the total sum of start-up costs and fixed costs (in previous versions,
- units were called on as late as possible and called off as soon as possible)
-
-
- - Various improvements in the linear solver yielding some speed increase in hard cases
-
-
- - Control of license validity through the internet (setting up of a dedicated server)
-
-
-### Bug fixes
-
- - Scenario builder: indices not subject to random draws could be mixed up in areas
- including both "must-run" units and "regular" units (bug circumscribed to the thermal
- time-series section)
-
- - Spillage management, when numerous binding constraints are active: an excessive leeway
- could be observed regarding the level of hydro power allowed to be curtailed
-
-v4.5.2 (06/2014)
-----------------
-
-### Bug fixes
-
- - In the previous version, the average values of interconnection-related variables were multiplied by two
- and this error was propagated to the standard deviation of the same variables
-
-v4.5.1 (06/2014)
-----------------
-
-### Features
-
- - Start-up and fixed thermal costs: the contribution of each thermal cluster to the operating
- cost is now explicitly displayed in the results (field : "non proportional cost")
-
-
- - Load time-series : negative values are now authorized
-
-
-
-
-### Bug fixes
-
- - Creation of a thermal cluster : the default value of the NPOMAX parameter is set to 100
-
-
- - Hydro energy spatial allocation matrix : values are displayed more clearly in the GUI
-
-
- - Copy/paste of nodes : the field "spread on unsupplied energy cost" was not pasted
-
-
-v4.5.0 (04/2014)
-----------------
-
-### Features
-
- - Simplex solver: acceleration regarding the control of the admissibility of the solution
- in the dual stages. This brings a significant improvement of the calculation time for
- large problems in which the relative scale of system costs is very wide
-
-
- - Identical upper and lower bounds have been set for the absolute values of all
- non-zero system costs ( max = 5 10^4 Euros/MWh ; min = 5 10^-3 Euros/MWh)
-
-
-### Bug fixes
-
- - Hydro Time-series generation : the GUI did not react properly when forbidden
- values (negative) were seized for energy expectation and/or standard deviation
-
-
- - Unit commitment of thermal plants: the time of the first activation of a plant
- within a week was not fully optimized
-
-
-v4.4.1 (05/2013)
-----------------
-
-### Bug fixes
-
- - Creation of a new binding constraint: the operation needed to be confirmed twice
- (double click on "create button") and the study had to be "saved as" and reloaded before
- proceeding further.
-
- - Time-series analyzer : due to round-off errors, spatial correlation of 100 %
- (perfectly identical sets of time-series in different locations) could sometimes
- be casted to 99%. Exact 100% correlations are now properly displayed.
-
-
-
-
-v4.4.0 (04/2013)
-----------------
-
-### Features
-
- - Antares licenses can be either static or floating. Floating tokens are managed and
- distributed by the Flexnet product, version 11.9.
-
- - Thermal plants time-series generator : availability parameters (outage rates and duration)
- corresponding to a Mean Time Between Failure (MTBF) < 1 day are now allowed. Though unusual,
- such sets of parameters may prove useful when it comes to modelling specific situations
-
- - Thermal plants time-series generator : it is possible to model the duration of each kind
- of outages as 365-day random arrays instead of 365-day constant arrays. Two parameters
- are available for the description of the probability distribution function of each component.
- A first parameter allows to set the variable law to either "uniform" or "geometric".
- A second parameter allows to set the ratio of the variable standard deviation to
- its expectation to a particular value
-
- - Thermal plants time-series generator : The planned outage process is now committed to meet a
- set of constraints defined by two 365-day arrays (PO Min Nb, PO Max Nb). For every day of
- each Monte-Carlo year, the actual number of overhauls is kept within the [Min,Max] interval,
- the exact value being determined by regular random draws based on outage rates and durations
-
- - As a consequence of the introduction of these new features, Monte-Carlo time-series
- of available thermal power generated with Antares 4.4 may differ from those generated with
- previous versions. Though differences may be observed draw by draw, the statistical
- properties of the generated time-series are strictly preserved when datasets are identical.
-
- - Hydro storage optimization : when the maximum available power of a given day is not high
- enough to allow the full use of the daily hydro storage energy credit, the energy in excess
- is levelled on the other days of the month with a flatter pattern.
-
-
-### Bug fixes
-
- - On creation of a new link, the transmission capacity status parameter is set
- to `Use transmission capacities` instead of `Set to null`.
-
-
-
-v4.3.7 (02/2013)
-----------------
-
-### Features
-
- - Performance improvements for graphical display of large tables
-
-
-### Bug fixes
-
- - The binding constraint data might not be written properly in some cases
- when the constraint was renamed.
-
-
-
-V4.3.6 (12/2012)
-----------------
-
-### Bug fixes
-
- - Windows only: fixed potential crash which could happen when exiting
- a simulation in adequacy mode with import of generated time-series
-
- - Windows only: improved free disk space assessment, which now takes into
- consideration user- and folder-related quotas
-
-
-V4.3.5 (10/2012)
-----------------
-
-### Features
-
- - The calendar field "year" is now available in the simulation main screen
- (allows not only simulations from JAN to DEC but also from OCT to SEP, etc.)
-
- - The attribute "Leap year" is now available in the simulation main screen
-
- - The attribute "Week" is now available in the main simulation screen
- (weekly results may be defined not only from MON to SUN but also from SAT to FRI,etc.)
-
- - Time-series screens: a new function is available for hourly and daily time-series
- (shift rows until #date#)
-
- - Linear solver: new version slightly more accurate than the previous one.
- Note that when a daily or weekly optimization has multiple equally optimal solutions,
- the ultimate choice may differ from that of the previous version
-
-
-### Bug fixes
-
- - Reference numbers of the time-series used in the course of a simulation:
- When the simulation is based on a user-defined scenario (building mode: custom)
- and when a printout of the reference numbers of the time-series used in the simulation
- is asked for (MC scenarios: true), the numbers printed for thermal clusters running
- under the "must-run" status were wrong
-
- - Interconnection results, marginal costs:
- For a congested interconnection whose transmission capacities are not symmetric,
- and in presence of hurdle costs, a zero could sometimes be delivered instead of
- the actually expected value
-
- - Districts: when the Monte-Carlo synthesis edition is skipped, the results regarding
- districts were not accessible via the output viewer.
-
-
-
-V4.2.6 (07/2012)
-----------------
-
-### Features
-
- - The field "MAX MRG" (last of the nodal results) is now available in the output files
-
- - The Monte-Carlo synthesis edition can be skipped when year-by-year results are asked for
-
-
-### Bug fixes
-
- - Binding constraints: in the filter available for the weight matrix, removal of
- redundant options
-
- - Copy/Paste nodes on the general map: "print status" parameters can now be copied like
- any other data
-
- - Upgrade of studies in 3.8 format: negative hurdle costs were not correctly transposed
-
- - Thermal plants time-series generator: outages lasting N days, starting on day D, were
- considered as outages lasting N days starting on D+1 (corrected by removal of the
- one-day shift)
-
- - Advanced parameters, option "shave peaks" used along with the "weekly" simplex range:
- the maximum intra-daily hydro storage limit on power could occasionally be overcome during
- the unsupplied energy levelling process (corrected by a slight lessening of the authorized
- levelling)
-
-
-
-
-v4.1.0 (06/2012)
-----------------
-
-### Features
-
- - Hydro storage energy management : each nodal policy of use can be tuned so as to
- accommodate simultaneously the net load of several nodes
-
- - Hydro storage energy modelling : monthly time-series of inflows and reference trajectories
- for reservoir levels can be used instead of monthly time-series of generated energies.
-
- - Load shedding strategies : when unsupplied energy is unavoidable, a choice is now possible
- between two policies : minimize the duration of sheddings or "shave" the load curve.
-
- - When multiple mathematically equivalent solutions exist a the first order for the
- economic optimization problem, a choice can be made at the second order between three
- ramping strategies
-
-
-
-
-v3.8.0 (12/2011)
-----------------
-
-### Features
-
- - The simulation mode `Adequacy` is renamed `Draft`.
-
- - A new simulation mode `Adequacy` is available. In this mode, all thermal plants are
- considered as must-run zero-cost units.
-
- - New possibilities are given regarding the filtering of simulation results (selection
- of nodes, of interconnections, etc.)
-
- - Automatic spatial aggregation of results is possible through the use of the new
- "district" object (a district is a sort of macro-node gathering several regions)
-
- - Nodal costs of unsupplied energy and of spilled energy : a small additive stochastic
- noise around the reference values can be introduced to help discriminate between
- theoretically equivalent solutions
-
-
-
-V3.7.4 (08/2011)
-----------------
-
-### Features
-
- - New version of the dual simplex engine (speed is about twice that of 3.6 version)
-
- - Economic optimizations now encompass a full week (168 hours) span. Traditional
- day-long optimizations can still be carried out (ad hoc "preference" parameter)
-
- - Binding constraints can be defined at the weekly scale in addition to the
- daily and hourly scales
-
- - Several other "optimization preferences" are made available to allow the quick examination
- of variants used in sensitivity analyses
-
- - A new graphic interface is available for the consultation of all simulation results
- (except those obtained in draft mode)
-
- - Extraction of data regarding any given variable from the whole Monte-Carlo year-by-year
- set of results is now possible
-
- - New variables are introduced in the economic output files : the overall available dispatchable
- thermal generation (AVL DTG) and the thermal margin (DTG MRG = AVL DTG - dispatched power)
-
-
-
-
-V3.6.4 (04/2011)
-----------------
-
-### Features
-
- - The "scenario builder" is now available. With this builder it is possible to define
- precisely the simulation context (for any given year, random numbers drawn for each
- kind of time-series can be replaced by user-defined numbers). This feature allows
- simulations to be carried out in a versatile "What If" mode.
-
-
-
-
-
-V3.5.3 (03/2011)
-----------------
-
-### Features
-
- - Addition of the fuel category "lignite" to the regular options available
- for the description of thermal plants.
-
- - Improvement of the presentation of the 365-day arrays "market bid modulation"
- and "marginal cost modulation".
-
- - Automatic processing of the inter-monthly & inter-regional hydro correlation hydro
- energy matrix to meet the feasibility constraints (the matrix has to be positive
- semi-definite). User should check in the simulation log file that no warning such as :
- "info : hydro correlation not positive semi-definite : shrink by factor x " appears.
-
-
-
-
-V3.4.4 (02/2011)
-----------------
-
-### Features
-
- - The names of nodes, thermal clusters and binding constraints can be extended to
- 128 characters. Authorized characters are : `a-z, A-Z,0-9,-,_, space`
-
-
-
-
-v3.4.3 (10/2010)
-----------------
-
-### Features
-
- - Two calculations modes are now available (in the "run" window):
-
- "regular": the software tries to hold all simulation data in RAM
- this mode is faster than the second one when datasets are small but
- can get dramatically slow when RAM limits are close
-
- "swap" : a dedicated memory management module loads in RAM amounts
- of data as small as possible. This mode should be prefered to the
- other when datasets are large.
-
- Note that in "regular" mode, the maximum amount of data loaded is
- limited by the OS to 2 Go on 32-bit machines, regardless of the
- memory installed. The integrality of installed memory can be used
- on 64-bit machines.
-
- - A new module (time-series analyzer) is available to help set the
- parameters of the stochastic time-series generators for wind power,
- solar power and load. The analyzer determines, on sets of historical
- 8760-hour time-series the relevant parameters for different kinds of
- random laws (uniform, normal,Weibull, Beta, Gamma), along with a
- description of the auto-correlation dynamic (two parameters)
- and a full spatial correlation matrix
-
-
-
-
-
-v3.3.2 (07/2010)
-----------------
-
-### Features
-
- - Improvement of the wind power time-series generator (faster calculations)
-
- - Introduction of new stochastic time-series generators for
- solar power and load
-
- - Introduction of an explicit modelling of wind-to-power curves.
- As a consequence, wind power time-series can now be generated
- either through a direct approach (by analysis of historical
- time-series of power) or through an indirect (more physical)
- approach, based on the analysis of historical time-series of
- wind speed
-
- - Introduction of a new 8760-hour power array for each node,
- representing the day-ahead reserve that should be made available
- (either on-site or at distance) to face last-minute incidents
- and/or forecasts errors.
-
- - Introduction of so-called hurdles costs on interconnection.
-
-
-
-
-v3.1.0 (01/2010)
-----------------
-
-### Features
-
- - Breakdown of monthly hydro storage energy credits in daily credits:
- The pilot curve is now the net load (i.e. load - all must-run generation)
- instead of the gross load
-
- - New functionalities available for datasets management (stucy cleaner,
- Log file wiewer)
-
- - New info is given for simulation context (available & required amounts
- of RAM & HDD space)
-
-
-
-From V1 to V2 (all versions)
-----------------------------
-
- - Refer to project development archives (TRAC thread)
-
+Please refer to [doc/CHANGELOG.md](doc/CHANGELOG.md)
\ No newline at end of file
diff --git a/README.md b/README.md
index 3c6c0f415c..831b97033c 100644
--- a/README.md
+++ b/README.md
@@ -20,7 +20,7 @@ as a cross-platform application (Windows, GNU/Linux ,Unix).
Until 2018 it was distributed under the terms of a proprietary license.
-In May 2018 RTE decided to relicense the project under the GPLv3 license.
+In May 2018 RTE decided to release the project under the GPLv3 license.
[linux_system_svg]: https://github.com/AntaresSimulatorTeam/Antares_Simulator/workflows/Linux%20CI%20(system%20libs)/badge.svg
diff --git a/docs/CHANGELOG.md b/docs/CHANGELOG.md
new file mode 100644
index 0000000000..83d1212fee
--- /dev/null
+++ b/docs/CHANGELOG.md
@@ -0,0 +1,1256 @@
+Antares Changelog
+=================
+
+v8.1.0 (09/2021)
+--------------------
+
+### New features
+- Allow up to 9 RES groups (off-shore wind, on-shore wind, rooftop solar, PV solar, etc.) as opposed to wind and solar previously. This allows the user to distinguish between more renewable energy sources. When creating a new study, renewable generation modelling is set to "clusters" by default. This change does not affect opening an existing study. Note that TS generation is not available for these new RES groups.
+- Add 3 thermal groups, named other, other 2, other 3 and other 4.
+
+### Bug fixes
+- When a binding constraint is marked as skipped in the GUI, disable it in the solver #366
+
+### GUI
+- Keep selection on thermal/renewable cluster when its group changes #360
+- Dialogs "Thematic trimming" and "User playlist" are now resizable
+
+### For developers
+- Add non-regression tests on each release
+- Fix vcpkg on Github Actions
+- Add build cache for Github Actions to speed up the build (Linux only)
+
+v8.0.3 (05/2021)
+--------------------
+
+### Bug fixes
+
+- Fix calculation of average for variable "congestion probability"
+- Fix NODU when unit number is not an integer i.e has decimals
+- GUI: allow decimal nominal capacity for thermal clusters
+- GUI: Linux: use xdg-open to open pdf files instead of gnome-open
+
+### For developers
+
+- Remove code related to licence management
+- Remove openssl and libcurl dependencies
+- Remove dead code
+
+v8.0.2 (04/2021)
+--------------------
+
+### Bug fixes
+
+- Fix GUI freeze when area color is changed but user don't validate new color
+- Correction of MC year weight use for PSP and MISC NDG
+
+v8.0.1 (03/2021)
+--------------------
+### Features
+
+- Add "Continue Offline" button at startup if antares metric server is unreachable
+
+### Bug fixes
+
+- Error with hydro start when using scenario playlist and stochastic TS refresh span
+- Files needed for antares-xpansion not exported when using scenario playlist with first year disabled
+- Correction of crash if user define a stochastic TS refresh span of 0 : minimum value is now 0
+- Correction of MC years playlist weight write when sum of weight was equal to number oy years (no MC years playlist export in .ini)
+
+### For developers
+
+- Add a GitHub action to check if branch name will launch CI
+- Add shared dll in windows .zip archive
+
+v8.0.0 (03/2021)
+--------------------
+
+### Features
+
+- OR-Tools integration :
+ - add command line option in antares-solver to define OR-Tools use and OR-Tools solver (option --use-ortools and --ortools-solver='solver')
+ - add GUI option in run simulation to define antares-solver launch with OR-Tools option
+
+- Add advanced hydro allocation feature. The default and existing behavior is to accomodate the guide curves, the new behavior is to maximize generation, even if it means that the reservoir level goes beyond the guide curves.
+
+- Add indication on how to disable anonymous metrics
+
+- antares-xpansion :
+ - add option `include-exportstructure` in `generaldata.ini` to export .txt files needed for antares-xpansion
+
+- Scenario builder and hydraulic level :
+ Adding an hydraulic starting level tab in the scenario builder.
+ For each MC year and area, a starting level can be defined, that is a 0-100 value.
+ When the scenario builder is enabled, these levels get priority upon hot-start mode.
+
+- Binding constraints (BC) and thermal clusters :
+ If a must-run or disabled cluster is involved in a binding constraint :
+ - the cluster is marked as "N/A" in the BC formula (GUI > Binding constraint > Summary)
+ - the cluster is marked as must-run/disabled in the Weights or Offsets tabs.
+
+ If a BC involves only zero weighted clusters/links or must-run/disabled clusters, the BC is :
+ - marked with a red bullet in the Summary tab
+ - marked as Skipped in the Weights and Offsets tabs
+
+- MC Scenario Playlist :
+ Add possibility to define a weight for each MC years in the synthetis results.
+ See : GUI > Configure > MC scenario playlist.
+ By default, a MC year's weight is 1, but can be set by user to more or less.
+ After simulation, the MC year have a contribution to averages or standard deviations in synthesis results
+ depending on the weight it was given.
+
+### Bug fixes
+
+- Selecting an area and then, from the inspector, trying to select a thermal cluster or a link of this area in the dependencies
+ section causes a crash. The inspector's cluster/link selection was removed.
+- Scenario builder :
+ - It makes no sense for the user to access the scenario builder Configure menu item whereas the Building mode parameter is set
+ to Automatic or Derated. In the previous cases, the Configute menu item is disabled.
+ - If a disabled thermal cluster is given a time series number in a non active rule of the scenario builder, a warning should not be
+ triggered. If the disabled cluster is given a number for many MC years in the active rule, a single summary warning should be raised,
+ not a warning per year.
+
+### For developers
+
+- External dependencies :
+ - use of new repository [antares-deps](https://github.com/AntaresSimulatorTeam/antares-deps) for external dependencies compilation
+
+- Fix several compilation warnings
+- Remove unused `COUT_TRANSPORT` constant
+- Add code formatting with clang-format
+- Remove PNE dead code
+
+- docker image :
+ - create of dockerfile for docker image creation
+
+- continuous integration :
+ - use docker images in CI
+ - use of antares-deps release artifact in CI
+ - push of docker image to dockerHub in [antaresrte/rte-antares repository](https://hub.docker.com/repository/docker/antaresrte/rte-antares)
+ - add Centos7 support
+
+- Unit tests :
+ - Adding an end-to-end test in memory (see simple-study.cpp) :
+ This test calls high level functions to build a simple study and runs it.
+ It then checks if some elements of results match associated expected values.
+ During this process, file system is not involved : everything takes place in RAM
+ - Adding pytest scripts to check reference output values
+ - Add pytest scripts related to unfeasible problems
+
+v7.2.0 (06/2020)
+--------------------
+
+### Features
+
+- Simulation dashboard: A new "Geographic Trimming" option
+ is now available in the "Configure" menu. This option makes
+ it possible to filter the simulation's output content so as
+ to include only results regarding Areas and Links of interest
+
+- Optimization: a new parameter "Unfeasible Problems Behavior"
+ is available in the "advanced preferences" section of the
+ "Configure" menu, with four possible values:
+ (Error Dry, Error Verbose, Warning Dry, Warning Verbose)
+ The first two options make the simulation stop right after
+ encountering the first mathematically unfeasible problem, if any
+ The last two options make the simulation skip all unfeasible
+ problems, if any
+ "Verbose" options print faulty problems in the “mps” format
+ "Dry" options only report the time frame (MC year, week) for which
+ an unfeasible problem was detected
+
+- Compilation and cmake tree :
+ Updates were made for more modern CMake use.
+ Git submodules (extern dependencies : curl, openssl, wxwidget) are no more in use.
+ These external dependencies can be retrieved :
+ - either from a library manager : vcpkg for Windows, classic package
+ repositories for Linux. With this way to proceed, an installation of external
+ dependencies is required once for all.
+ - or thanks to an automatic download : at Antares' cmake configure step,
+ all needed downloads, compilation and installation are done.
+
+- Unit tests :
+ unit tests around class Matrix are now available.
+ They can be compiled (on demand) during Antares' cmake build step
+ and run either with ctest or in the classic way.
+ Boost.Test is required and can be priorily retrieved and installed in the
+ same way as the other external dependencies.
+
+- Continuous integration : yaml files for github actions allow the run of
+ all build chain and unit tests on several environment (Windows and Ubuntu).
+ The 2 ways of getting external dependencies are also tested.
+
+- Documentation: updated reference guide
+
+- Usage metrics: added reference key for this version
+
+### Bug fixes
+
+- GUI of the "Thematic trimming" option: Window size is naturally readjusted
+ to improve readability by upgrading wxwidgets (3.1.3 and above).
+
+- Auxiliary "Batchrun" tool: two options previously missing in the
+ command line syntax have been introduced and now make it possible
+ to launch a sequence of simulations to run in parallel
+
+v7.1.0 (12/2019)
+--------------------
+
+### Features
+
+- Simulation Dashboard: A new option "Thematic Trimming"
+ is available in the "Output Profile" Section. This option
+ now makes it possible to define precisely the content of
+ output files so as to include only variables of interest
+
+- Optimization: a new parameter "Hydro Pricing mode" is
+ available in the "advanced parameters" section, with two
+ possible values (fast, accurate):
+ In mode "fast", water value is, in the course of optimization,
+ taken to be constant throughout the (daily or weekly)
+ optimization period, and equal to that found for the exact
+ day and level at which the optimization begins. Water values
+ are reassessed afterwards, for each hour, on the basis of
+ relevant time and level.
+ In mode "accurate", the variations of water value along with
+ the reservoir level are taken into account in the course of
+ the (weekly) optimization. Reference (level-dependent) values
+ are those attached to the end of the week. Water values
+ are reassessed afterwards, for each hour, on the basis of
+ relevant time and level.
+
+- Documentation: updated reference guide
+
+- Documentation: updated optimization problem formulation
+ (modelling of hydro pricing options)
+
+- Usage metrics: added reference key for this version
+
+### Bug fixes
+
+- Output file "mc-all/grid/digest.txt": replaced "NaN" values
+ by zeroes, where appropriate
+
+- Output file "mc-all/grid/digest.txt": replaced "0" values
+ by N/A, where appropriate (especially, hydro reservoir-related
+ variables, when the "reservoir management" area attribute is set
+ to "No")
+
+- Output GUI: fixed a display bug regarding missing items in the
+ "links" panel, in the case where simulation parameters are set
+ so as not to produce synthetic results
+
+- Links GUI: improved integrity control regarding hurdle costs.
+ Negative values are allowed in either direct or indirect
+ orientation, provided that the sum of both is non-negative
+
+- General GUI: removed redundant items and renamed option menu
+ "Geographic District" as "Regional District" to avoid confusion
+ with new "Trimming" options
+
+- Output: when simulation results are trimmed so as not to produce
+ any data for given Areas or Links, avoid creation of empty folders
+ named after said Areas or Links
+
+v7.0.1 (04/2019)
+--------------------
+
+### Features
+
+- Time-series analysis: in "detrended mode", extended perimeter
+ to raw data including periods with no meaningful signal
+ (e.g. solar production at night)
+- Hydro-storage modelling: added ability to optimize pumping along
+ with generation in mode "use heuristic target without leeway"
+
+v7.0.0 (12/2018)
+--------------------
+
+### Features
+
+- GPL release: updated companion files (README,...)
+- GPL release: updated project Icons
+- GPL release: insertion of license headers
+- GPL release: translation of comments
+- GPL release: removal of license control
+- GPL release: code restructuring to separate Antares and Sirius
+- Examples library: upgraded and added 16 new examples
+- Documentation: updated reference guide
+- Documentation: updated map editor guide
+- Documentation: updated optimization problem formulation
+- Documentation: updated examples library
+
+v7.0.0-rc (12/2018)
+--------------------
+
+### Features
+
+- Improved code for linux compilation with gcc 7
+
+### Bugs
+
+- Fixed various issues in GUI
+- Fixed RHS of constraints generated by the KCG when
+ min and max values of PST settings are strictly equal
+ and constraints are generated for the whole year
+
+v6.5.1 (11/2018)
+----------------
+
+### Bugs
+
+- Fixed index in hydro heuristic engine
+- Hydro GUI: added scrollbars for correct display on laptops
+- Output: improved presentation of results for incomplete calendar-based weeks
+- Kirchhoff's constraint generator: fixed several GUI issues
+- Districts GUI: improved syntax control
+
+v6.5.0 (11/2018)
+----------------
+
+### Features
+
+- Implementation of Kirchhoff's laws (DC approximation),
+ modeling of phase-shifters and representation of passive
+ loop flows (to account for on highly reduced gris): a
+ dedicated Kirchhoff's constraints generator is now available
+ It makes use of both classical input data (impedances)
+ and new input data. Its results are specific binding
+ constraints whose names begin by @UTO-, storable in the
+ INPUT folder after user's validation ("save")
+
+ New or modified input data for link L (8760 hourly values):
+ Impedances (moved from col.3 to col.5)(Ohms at ref. voltage U)
+ Loop flow (passive) (MW)
+ Min Tap of phase-shifter (MW*Ohms/U2 along any AC cycle including L)
+ Max Tap of phase-shifter (MW*Ohms/U2 along any AC cycle including L)
+ New link parameters (one value)
+ Asset type (AC,DC,Gas,Virtual,Other) : KCG deals only with AC links
+ "account for loop flow" toggle
+ "tune PST" toggle
+ KCG generating directives:
+ Working map to use for generation
+ Calendar to use for constraints activation (relaxation outside)
+ Status of passive loop flow in constraints RHS (included or not)
+ Status or PST settings in constraints RHS (included or not)
+ Auto-check of nodal loop flow balance (activated or not)
+ Definition of the "infinite" to use for constraints relaxation
+ KCG results:
+ For AC Links involved in the generation process: The KCG sets the
+ values of the two input data toggles related to loop flows and
+ PST settings, in accordance with the current generation directives
+
+ Identification of an optimal (minimum-weight) cycle basis for the
+ formulation of constraints
+
+ Generation of all relevant constraints (equality, inequalities, with
+ or without relaxation)
+
+- Reservoir-type hydro and other energy storage facilities:
+ interface, input and output data structure, functionalities,
+ have been completely redesigned. As a consequence, a number
+ of new items (variables & parameters) are introduced in both
+ input and output, while a few input variables are redefined
+ or deprecated:
+
+ Deprecated hydro variables:
+ Pmax hydro "min", Pmax hydro "max"
+ Redefined hydro variables and parameters:
+ Hydro-storage time-series : redefined at the daily scale
+ Bounds for Reservoir levels: redefined at the daily scale
+ Res.level initialization date: redefined at the monthly scale
+ New hydro variables and parameters:
+ Input : max daily hydro generating energy
+ max daily hydro pumping energy and power
+ monthly-to-daily inflow breakdown pattern
+ water value (time, level)
+ modulation of max generating power (level)
+ modulation of max pumping power (level)
+ pumping efficiency
+ +many "storage management options" parameters
+ Output: Reservoir level (H.LEV)
+ Water value (H.VAL)
+ Pumping power (H.PUMP)
+ Natural Inflow (H.INFL)
+ Forced Overflow (H.OVFL)
+ Cost of Gen+Pumping (H.COST)
+ Optimization preferences:
+ "Hot/Cold start" (year N may start or not at the final N-1 level)
+
+- GUI: Districts may now be defined from within the interface
+ (notepad tab connected to the Inspector's clipboard)
+
+- Time-series generation (solar, wind, load) : increased speed
+ when "high accuracy" option is selected, in the special case
+ where all diffusion processes produce "Normal" variables
+
+- Example library: upgraded to 6.5 (without extension)
+
+### Bug fixes
+
+- Time-series generation: the storage (Input folder)
+ of time-series generated for thermal clusters either in the
+ "disabled" or "must-run" state did not work properly
+
+- Time-series analysis: when short- and long-term levels
+ defined for auto-correlation assessment are identical, the
+ analyzer now performs a pure exponential fitting
+
+- Time-series analysis: monthly time-series containing no
+ non-zero value are no longer rejected by the analyzer
+
+- Output: the link-variable "MARG.COST" was rounded to an integer
+ value (changed to 2 decimal accuracy)
+
+
+v6.1.3 (06/2018)
+----------------
+
+### Features
+
+- Output: added a new file at the root of simulation results,
+ displaying a short summary of the overall system economic
+ performance throughout all Monte-Carlo years
+
+- Log file: added new info messages on the size of optimization
+ problems
+
+- Updater (standalone): added new options and improved
+ help messages
+
+- Expansion mode: presolve stage replaced by hot start
+
+### Bug fixes
+
+- Simulation: In the "accurate" Unit Commitment mode, the
+ optimization preference "thermal Clusters Min Up/Down Time"
+ can now be turned to "ignore"
+
+- Simulation: removed remaining debug traces
+
+- Simulation: zero-reset on interconnection marginal costs
+ was sometimes missing in optimization final stage
+
+- Example library : upgraded to 6.1 and extended
+
+
+v6.1.2 (11/2017)
+----------------
+
+### Features
+
+- Solver, Simplexe package: Improvement of the Scaling stage
+ (Matrix, right hand side, costs)
+
+
+v6.1.1 (11/2017)
+----------------
+
+### Features
+
+- Solver: Light changes in Presolve stage
+
+
+v6.1.0 (09/2017)
+----------------
+
+### Features
+
+- GUI and simulation: "binding constraints" objects may now involve
+ not only flows on interconnections but also power generated from
+ thermal clusters. Alike flows, generation from thermal clusters may
+ be handled either on an hourly, daily or weekly basis and may be
+ associated with arbitrary offsets (time-lags expressed in hours).
+
+
+v6.0.6 (07/2017)
+----------------
+
+### Features
+
+- GUI: Binding constraint parameters tables (weights and offsets) are trimmed
+ line-wise so as to fit exactly with the content of the selected working map
+
+- Solver: strenghtening of the final admissibility check step in the "accurate"
+ commitment mode
+
+
+
+v6.0.5 (07/2017)
+----------------
+
+### Bug fixes
+
+- Solver: Pruning of redundant messages in simulations launched from command line
+
+- Solver: Removal of misprints in command line help messages
+
+- Files: Fixed issues (detected as of 6.0.1) regarding storage of thermal time-series files
+
+- Study Cleaner: Unwarranted removal of the graphic multi-map lay-out could occur when
+ cleaning datasets (detected as of 6.0.0)
+
+
+v6.0.4 (06/2017)
+----------------
+
+### Bug fixes
+
+- GUI: The "variable per variable" view of the output files allows
+ to display the power generated by each thermal cluster
+
+- Simulation: Negative "ROW Balance" is properly included in
+ unsupplied energy allowances
+
+
+v6.0.3 (06/2017)
+----------------
+
+### Features
+
+- GUI: The number of system maps that could be stored in a given study
+ was limited to 19. This number is now unbounded.
+
+### Bug fixes
+
+- GUI: The list of thermal clusters displayed for a given Area in the
+ current map was sometimes wrongly initialized (Area considered
+ selected though not explicitly clicked on yet)
+
+- GUI: The order in which binding constraint terms are shown in the
+ "summary" Window could depend on the execution platform used
+
+- GUI: The Antares study icon could not be properly copied in some
+ circumstances
+
+
+v6.0.2 (06/2017)
+----------------
+
+### Features
+
+- Optimization : To help discriminate between equivalent economic
+ solutions, random noises on hydro hourly prices are more regularly
+ spread out (absolute values) in the interval (5 e-4 ,1 e-3)Euros/MWh
+
+### Bug fixes
+
+- Simulation : The identification of the Monte-Carlo year numbers
+ in which the smallest/greatest values of random variables are
+ reached could be ambiguous when identical results are found for
+ two years ore more.
+
+
+v6.0.1 (05/2017)
+----------------
+
+### Features
+
+- Thermal Time-series generation: Data regarding all thermal clusters
+ are generated and stored in the same way, regardless of their activity
+ status (unabled/disabled). This makes easier to check data consistency
+
+- Simulation: Upper bounds for spilled power and unsupplied power are
+ actually set to their maximum theoretical value(i.e. if economic
+ conditions make it justified: spill all power or shed all demand)
+ So far, spillage of power that could be absorbed by the local demand
+ was not allowed
+
+- Simulation: a silent "Expansion" mode has been added to the regular
+ modes "Economy/Adequacy/Draft". The three differences with the
+ "Economy" mode are:
+ a) In "accurate" unit commitment, integrity constraints are relaxed
+ in the core optimization problem.
+ b) Day-ahead reserve is no more subtracted from the initial demand
+ to get back to "standard" conditions
+ c) The values of all optimal criteria are printed in ad hoc files
+ The use of this mode should be restricted to well-designed scripted
+ automatic simulation sequences taking into account the simplifications
+ listed above
+
+
+v6.0.0 (04/2017)
+----------------
+
+### Features
+
+- GUI: A new interface makes it possible to define several views (maps) of
+ the Power System modelled in an Antares study. These maps are meant to give
+ the user the ability to set different layouts in which each Antares Area
+ or Link can be either shown or remain hidden. Accordingly, all input and
+ output data windows can now adapt the information displayed so as to match
+ exactly the content of any given map. Copy/Paste functions have been
+ extended so as to work between different maps of different studies opened
+ in multiple Antares sessions
+
+- Simulation: Introduction of a flexible multi-threaded mode for the processing
+ of heavy problems: Antares "Monte-Carlo years" can be be distributed on a
+ number of CPU cores freely set by the user. This parameter appears as a new
+ tunable item of the "advanced parameters" list attached to any Antares Study.
+ Five values are available in the [1, N] interval, N being the number of CPU
+ cores of the machine (virtual or physical) Antares is run on
+
+- License control through the internet: a new system has been developed for
+ accommodating situations where users wish to operate Antares on a large
+ fleet of machines among which a limited set of commercial license tokens
+ can float freely
+
+- Data organizer: Antares studies often include a great number of files of
+ all sizes, which may take long to process when multiple copies are needed.
+ Likewise, the management of the HDD space required for regular storage of
+ all of the studies involved in a complex study workflow may turn out to be
+ a demanding and heavy task. To save both time and hardware resources, the
+ Antares Data Organizer, now provided as a companion tool to the Antares
+ Simulator, brings the ability to schedule basic data management tasks
+ such as study archiving/expansion (use of a specific compressed format),
+ copy to backup folders, registering of studies and archives in catalogues.
+
+
+v5.0.9-SE (04/2017)
+----------------
+
+### Bug fixes
+
+- Random noises on thermal clusters costs now include the zero-cost
+ "must-run" clusters (as a consequence, noises assumptions do not vary
+ with the cluster status)
+
+- Fixing an initialization issue that could sporadically affect the
+ minimum number of committed thermal units (+1 or -1 deviation,
+ "accurate" mode only)
+
+v5.0.7-SE (04/2017)
+----------------
+
+### Features
+
+- License control : management of SSL certificates encrypted through SHA-256 algorithm
+
+
+v5.0.7 (12/2016)
+----------------
+
+### Bug fixes
+
+- Fixing a packaging error
+
+
+v5.0.6 (12/2016)
+----------------
+
+### Bug fixes
+
+- Results processing: For full "must-run" thermal clusters, the NODU variable
+ could be wrongly assessed in the "accurate" unit commitment simulation mode
+
+- GUI: when the scenario builder feature is active, saving right after deleting
+ a thermal cluster could result in a partial dataset corruption (references to
+ the deleted object were kept alive in the scenario builder context)
+
+
+### Features
+
+- Unsupplied energy control: if the actual economic optimization requires it, load
+ shedding is now allowed to occur in areas where the available thermal generation
+ is higher than the local demand (e.g. if local VOLL < local thermal costs)
+
+- Linear solver, hot starting of weekly problems: in the "fast" unit commitment
+ mode, optimal bases are flushed at the beginning of each Monte-Carlo year. This
+ comes as a pre-requirement for the next versions of Antares, which will be
+ fully multi-threaded
+
+- Simulation results: code segments processing all variables attached to spatial
+ aggregates, and the variable representing the number of running thermal units
+ on the first hour of the year, were re-written to be compatible with the next
+ versions of Antares, which will be fully multi-threaded
+
+
+
+v5.0.5 (08/2016)
+----------------
+
+### Bug fixes
+
+- No-Load Heat costs and Start-up costs: in the "fast" unit commitment options,
+ the result was slightly below the actual optimal possible cost for some
+ datasets (i.e. datasets in which the thermal cluster coming last in alphabetic
+ order had a minimum stable power equal to zero).
+
+- Spilled energy control: the three parameters defining how energy in excess should
+ be split between the different possible sources when there is a choice to make
+ can work properly again (feature inhibited in previous 5.0.x versions)
+
+
+### Features
+
+- License control throughout the internet: all combinations of UTF8 characters can
+ now be used within proxy ids and passwords
+
+- Economic optimization: in an area where the amount of available thermal power
+ exceeds that of load, the fact that the demand should necessarily be served
+ is locally expressed as a constraint of the optimization problem (LOLE=0)
+
+
+v5.0.4 (05/2016)
+----------------
+
+### Bug fixes
+
+- Errors occured on loading the "min gen modulation" time-series of thermal clusters
+
+### Features
+
+- Better estimate of the number of thermal units dispatched in "fast" unit commitment mode
+- Nodal Marginal Prices and Marginal yield on interconnections are now available in
+ "accurate" unit commitment mode
+- Binding constraints including offset parameters: unbounded positive or
+ negative values can be used for all classes of constraints (hourly, daily, weekly)
+
+
+v5.0.3 (05/2016)
+----------------
+
+### Bug fixes
+
+- Crashes occured when the "full must-run status" parameter was set on
+ "true" for thermal clusters
+
+
+v5.0.2 (04/2016)
+----------------
+
+### Bug fixes
+
+- Removed debug information that should not be displayed in release mode
+
+### Features
+
+- The optimization criterion used to assess the hydro energies to generate throughout
+ each month incorporates heavier penalization terms for the 12 deviations from the
+ theoretical monthly targets (formerly, only the largest deviation was penalized).
+
+
+v5.0.1 (04/2016)
+----------------
+
+### Bug fixes
+
+- Adequacy mode: fixed a memory allocation bug that forced the post-simulation
+ output files processing to be interrupted
+
+- In the previous version, additional logs were added. That could lower the simulation
+ performances in some cases. This problem is now solved.
+
+
+v5.0.0 (03/2016)
+----------------
+
+### Bug fixes
+
+- GUI, system map: copy /paste of binding constraints could alter the activity status or
+ the names of the duplicated binding constraints in some instances
+
+- GUI, system map: some conflicts in copy/paste actions were not always properly raised
+ (e.g. attempt to copy three nodes and paste them on two other nodes)
+
+- Thermal clusters: Improved checking of time-series generation parameters (improper use of a
+ nominal capacity modulation factor lower than the minimum stable power is no longer possible)
+
+- Thermal clusters: Improved checking of ready-made time-series. If the user-chosen time-series
+ are not consistent with the parameters set in the GUI, warnings are issued in log files
+
+- Output , LOLD variable: in some instances, the values assessed in "economic" simulation mode and in
+ "adequacy" simulation mode could slightly differ because of sporadic rounding side-effects.
+ rounding convention is now set uniformly to : 0 < X < 0.5 -> (X=0)
+
+- Output, MISC.NDG and PSP variable: values were not properly edited for the specific category
+ "geographic districts, "year-by-year results"
+
+- Output, OV. COST, OP. COST, NP. COST variables: values were not properly edited for the last
+ hour of the last day of the simulation
+
+- Output, File comparison functions: calendar marks were not properly displayed in some views
+
+- Output, File comparison functions: "Max" operator has been added
+
+
+### Features
+
+- Optimization: introduction of a new unit-commitment mode based on a MILP approach slower but more
+ accurate than the former one. An option lets the user choose which mode should be used (fast/accurate)
+
+- Optimization: in "accurate" unit-commitment mode, incorporation of thermal start-up costs and
+ no-load heat costs within the global objective function to minimize. In "fast" unit-commitment
+ mode, start-up costs and no-load heat costs are minimized independently from the main objective
+
+- Optimization: in both unit-commitment modes, improvement of the inter-weekly start-up strategies
+ (seamless reformulation of the optimization results obtained beforehand)
+
+- Thermal clusters: definition of separate minimum up/down durations to be used for unit-commitment
+
+- Thermal clusters: definition of a minimum amount of power (hourly time-series) to be generated
+ by the units of the cluster, regardless of economic considerations (partial must-run commitment)
+
+- Thermal clusters: start-up cost can now be set from -5000000 to 5000000 (was from -50000 to 50000)
+
+- Binding constraints: introduction of new "offset" parameters which make it possible to define
+ constraints whose terms can refer to different times (e.g. 2 X(t) - 1.5 Y(t-4) + 3 Z(t+1) <10)
+
+- Benchmarking: so as to allow transparent comparisons with other software, the user may demand
+ that all optimization problems solved by Antares be printed in a standardized "mps" format
+ along with the values of the optimized criterion.
+
+- GUI, System map : new button available in the tool bar for centring the map on a (x,y) location
+
+- GUI, System map : new button available in the tool bar for map trimming around used space
+
+- Output: In synthetic Monte-Carlo results,year-by-year results and cluster-by-cluster results,
+ Addition of a field "Number of dispatched units" (NODU)
+
+
+
+v4.5.4 (03/2015)
+----------------
+
+### Bug fixes
+
+- License checking: internet proxys for which no login and/or password have been
+ defined can now be used
+
+- Upgrade to 4.5 format of datasets edited in 4.4 format or lower, in which the "scenario builder"
+ feature was activated: the conversion to 4.5 format could fail sometimes.
+
+v4.5.3 (02/2015)
+----------------
+
+### Features
+
+- Start-up and fixed thermal costs: the interpretation of the unit-commitment strategy
+ (starting-up and shutting-down times of each thermal unit) includes the explicit
+ minimization of the total sum of start-up costs and fixed costs (in previous versions,
+ units were called on as late as possible and called off as soon as possible)
+
+
+- Various improvements in the linear solver yielding some speed increase in hard cases
+
+
+- Control of license validity through the internet (setting up of a dedicated server)
+
+
+### Bug fixes
+
+- Scenario builder: indices not subject to random draws could be mixed up in areas
+ including both "must-run" units and "regular" units (bug circumscribed to the thermal
+ time-series section)
+
+- Spillage management, when numerous binding constraints are active: an excessive leeway
+ could be observed regarding the level of hydro power allowed to be curtailed
+
+v4.5.2 (06/2014)
+----------------
+
+### Bug fixes
+
+- In the previous version, the average values of interconnection-related variables were multiplied by two
+ and this error was propagated to the standard deviation of the same variables
+
+v4.5.1 (06/2014)
+----------------
+
+### Features
+
+- Start-up and fixed thermal costs: the contribution of each thermal cluster to the operating
+ cost is now explicitly displayed in the results (field : "non proportional cost")
+
+
+- Load time-series : negative values are now authorized
+
+
+
+
+### Bug fixes
+
+- Creation of a thermal cluster : the default value of the NPOMAX parameter is set to 100
+
+
+- Hydro energy spatial allocation matrix : values are displayed more clearly in the GUI
+
+
+- Copy/paste of nodes : the field "spread on unsupplied energy cost" was not pasted
+
+
+v4.5.0 (04/2014)
+----------------
+
+### Features
+
+- Simplex solver: acceleration regarding the control of the admissibility of the solution
+ in the dual stages. This brings a significant improvement of the calculation time for
+ large problems in which the relative scale of system costs is very wide
+
+
+- Identical upper and lower bounds have been set for the absolute values of all
+ non-zero system costs ( max = 5 10^4 Euros/MWh ; min = 5 10^-3 Euros/MWh)
+
+
+### Bug fixes
+
+- Hydro Time-series generation : the GUI did not react properly when forbidden
+ values (negative) were seized for energy expectation and/or standard deviation
+
+
+- Unit commitment of thermal plants: the time of the first activation of a plant
+ within a week was not fully optimized
+
+
+v4.4.1 (05/2013)
+----------------
+
+### Bug fixes
+
+- Creation of a new binding constraint: the operation needed to be confirmed twice
+ (double click on "create button") and the study had to be "saved as" and reloaded before
+ proceeding further.
+
+- Time-series analyzer : due to round-off errors, spatial correlation of 100 %
+ (perfectly identical sets of time-series in different locations) could sometimes
+ be casted to 99%. Exact 100% correlations are now properly displayed.
+
+
+
+
+v4.4.0 (04/2013)
+----------------
+
+### Features
+
+- Antares licenses can be either static or floating. Floating tokens are managed and
+ distributed by the Flexnet product, version 11.9.
+
+- Thermal plants time-series generator : availability parameters (outage rates and duration)
+ corresponding to a Mean Time Between Failure (MTBF) < 1 day are now allowed. Though unusual,
+ such sets of parameters may prove useful when it comes to modelling specific situations
+
+- Thermal plants time-series generator : it is possible to model the duration of each kind
+ of outages as 365-day random arrays instead of 365-day constant arrays. Two parameters
+ are available for the description of the probability distribution function of each component.
+ A first parameter allows to set the variable law to either "uniform" or "geometric".
+ A second parameter allows to set the ratio of the variable standard deviation to
+ its expectation to a particular value
+
+- Thermal plants time-series generator : The planned outage process is now committed to meet a
+ set of constraints defined by two 365-day arrays (PO Min Nb, PO Max Nb). For every day of
+ each Monte-Carlo year, the actual number of overhauls is kept within the [Min,Max] interval,
+ the exact value being determined by regular random draws based on outage rates and durations
+
+- As a consequence of the introduction of these new features, Monte-Carlo time-series
+ of available thermal power generated with Antares 4.4 may differ from those generated with
+ previous versions. Though differences may be observed draw by draw, the statistical
+ properties of the generated time-series are strictly preserved when datasets are identical.
+
+- Hydro storage optimization : when the maximum available power of a given day is not high
+ enough to allow the full use of the daily hydro storage energy credit, the energy in excess
+ is levelled on the other days of the month with a flatter pattern.
+
+
+### Bug fixes
+
+- On creation of a new link, the transmission capacity status parameter is set
+ to `Use transmission capacities` instead of `Set to null`.
+
+
+
+v4.3.7 (02/2013)
+----------------
+
+### Features
+
+- Performance improvements for graphical display of large tables
+
+
+### Bug fixes
+
+- The binding constraint data might not be written properly in some cases
+ when the constraint was renamed.
+
+
+
+V4.3.6 (12/2012)
+----------------
+
+### Bug fixes
+
+- Windows only: fixed potential crash which could happen when exiting
+ a simulation in adequacy mode with import of generated time-series
+
+- Windows only: improved free disk space assessment, which now takes into
+ consideration user- and folder-related quotas
+
+
+V4.3.5 (10/2012)
+----------------
+
+### Features
+
+- The calendar field "year" is now available in the simulation main screen
+ (allows not only simulations from JAN to DEC but also from OCT to SEP, etc.)
+
+- The attribute "Leap year" is now available in the simulation main screen
+
+- The attribute "Week" is now available in the main simulation screen
+ (weekly results may be defined not only from MON to SUN but also from SAT to FRI,etc.)
+
+- Time-series screens: a new function is available for hourly and daily time-series
+ (shift rows until #date#)
+
+- Linear solver: new version slightly more accurate than the previous one.
+ Note that when a daily or weekly optimization has multiple equally optimal solutions,
+ the ultimate choice may differ from that of the previous version
+
+
+### Bug fixes
+
+- Reference numbers of the time-series used in the course of a simulation:
+ When the simulation is based on a user-defined scenario (building mode: custom)
+ and when a printout of the reference numbers of the time-series used in the simulation
+ is asked for (MC scenarios: true), the numbers printed for thermal clusters running
+ under the "must-run" status were wrong
+
+- Interconnection results, marginal costs:
+ For a congested interconnection whose transmission capacities are not symmetric,
+ and in presence of hurdle costs, a zero could sometimes be delivered instead of
+ the actually expected value
+
+- Districts: when the Monte-Carlo synthesis edition is skipped, the results regarding
+ districts were not accessible via the output viewer.
+
+
+
+V4.2.6 (07/2012)
+----------------
+
+### Features
+
+- The field "MAX MRG" (last of the nodal results) is now available in the output files
+
+- The Monte-Carlo synthesis edition can be skipped when year-by-year results are asked for
+
+
+### Bug fixes
+
+- Binding constraints: in the filter available for the weight matrix, removal of
+ redundant options
+
+- Copy/Paste nodes on the general map: "print status" parameters can now be copied like
+ any other data
+
+- Upgrade of studies in 3.8 format: negative hurdle costs were not correctly transposed
+
+- Thermal plants time-series generator: outages lasting N days, starting on day D, were
+ considered as outages lasting N days starting on D+1 (corrected by removal of the
+ one-day shift)
+
+- Advanced parameters, option "shave peaks" used along with the "weekly" simplex range:
+ the maximum intra-daily hydro storage limit on power could occasionally be overcome during
+ the unsupplied energy levelling process (corrected by a slight lessening of the authorized
+ levelling)
+
+
+
+
+v4.1.0 (06/2012)
+----------------
+
+### Features
+
+- Hydro storage energy management : each nodal policy of use can be tuned so as to
+ accommodate simultaneously the net load of several nodes
+
+- Hydro storage energy modelling : monthly time-series of inflows and reference trajectories
+ for reservoir levels can be used instead of monthly time-series of generated energies.
+
+- Load shedding strategies : when unsupplied energy is unavoidable, a choice is now possible
+ between two policies : minimize the duration of sheddings or "shave" the load curve.
+
+- When multiple mathematically equivalent solutions exist a the first order for the
+ economic optimization problem, a choice can be made at the second order between three
+ ramping strategies
+
+
+
+
+v3.8.0 (12/2011)
+----------------
+
+### Features
+
+- The simulation mode `Adequacy` is renamed `Draft`.
+
+- A new simulation mode `Adequacy` is available. In this mode, all thermal plants are
+ considered as must-run zero-cost units.
+
+- New possibilities are given regarding the filtering of simulation results (selection
+ of nodes, of interconnections, etc.)
+
+- Automatic spatial aggregation of results is possible through the use of the new
+ "district" object (a district is a sort of macro-node gathering several regions)
+
+- Nodal costs of unsupplied energy and of spilled energy : a small additive stochastic
+ noise around the reference values can be introduced to help discriminate between
+ theoretically equivalent solutions
+
+
+
+V3.7.4 (08/2011)
+----------------
+
+### Features
+
+- New version of the dual simplex engine (speed is about twice that of 3.6 version)
+
+- Economic optimizations now encompass a full week (168 hours) span. Traditional
+ day-long optimizations can still be carried out (ad hoc "preference" parameter)
+
+- Binding constraints can be defined at the weekly scale in addition to the
+ daily and hourly scales
+
+- Several other "optimization preferences" are made available to allow the quick examination
+ of variants used in sensitivity analyses
+
+- A new graphic interface is available for the consultation of all simulation results
+ (except those obtained in draft mode)
+
+- Extraction of data regarding any given variable from the whole Monte-Carlo year-by-year
+ set of results is now possible
+
+- New variables are introduced in the economic output files : the overall available dispatchable
+ thermal generation (AVL DTG) and the thermal margin (DTG MRG = AVL DTG - dispatched power)
+
+
+
+
+V3.6.4 (04/2011)
+----------------
+
+### Features
+
+- The "scenario builder" is now available. With this builder it is possible to define
+ precisely the simulation context (for any given year, random numbers drawn for each
+ kind of time-series can be replaced by user-defined numbers). This feature allows
+ simulations to be carried out in a versatile "What If" mode.
+
+
+
+
+
+V3.5.3 (03/2011)
+----------------
+
+### Features
+
+- Addition of the fuel category "lignite" to the regular options available
+ for the description of thermal plants.
+
+- Improvement of the presentation of the 365-day arrays "market bid modulation"
+ and "marginal cost modulation".
+
+- Automatic processing of the inter-monthly & inter-regional hydro correlation hydro
+ energy matrix to meet the feasibility constraints (the matrix has to be positive
+ semi-definite). User should check in the simulation log file that no warning such as :
+ "info : hydro correlation not positive semi-definite : shrink by factor x " appears.
+
+
+
+
+V3.4.4 (02/2011)
+----------------
+
+### Features
+
+- The names of nodes, thermal clusters and binding constraints can be extended to
+ 128 characters. Authorized characters are : `a-z, A-Z,0-9,-,_, space`
+
+
+
+
+v3.4.3 (10/2010)
+----------------
+
+### Features
+
+- Two calculations modes are now available (in the "run" window):
+
+ "regular": the software tries to hold all simulation data in RAM
+ this mode is faster than the second one when datasets are small but
+ can get dramatically slow when RAM limits are close
+
+ "swap" : a dedicated memory management module loads in RAM amounts
+ of data as small as possible. This mode should be prefered to the
+ other when datasets are large.
+
+ Note that in "regular" mode, the maximum amount of data loaded is
+ limited by the OS to 2 Go on 32-bit machines, regardless of the
+ memory installed. The integrality of installed memory can be used
+ on 64-bit machines.
+
+- A new module (time-series analyzer) is available to help set the
+ parameters of the stochastic time-series generators for wind power,
+ solar power and load. The analyzer determines, on sets of historical
+ 8760-hour time-series the relevant parameters for different kinds of
+ random laws (uniform, normal,Weibull, Beta, Gamma), along with a
+ description of the auto-correlation dynamic (two parameters)
+ and a full spatial correlation matrix
+
+
+
+
+
+v3.3.2 (07/2010)
+----------------
+
+### Features
+
+- Improvement of the wind power time-series generator (faster calculations)
+
+- Introduction of new stochastic time-series generators for
+ solar power and load
+
+- Introduction of an explicit modelling of wind-to-power curves.
+ As a consequence, wind power time-series can now be generated
+ either through a direct approach (by analysis of historical
+ time-series of power) or through an indirect (more physical)
+ approach, based on the analysis of historical time-series of
+ wind speed
+
+- Introduction of a new 8760-hour power array for each node,
+ representing the day-ahead reserve that should be made available
+ (either on-site or at distance) to face last-minute incidents
+ and/or forecasts errors.
+
+- Introduction of so-called hurdles costs on interconnection.
+
+
+
+
+v3.1.0 (01/2010)
+----------------
+
+### Features
+
+- Breakdown of monthly hydro storage energy credits in daily credits:
+ The pilot curve is now the net load (i.e. load - all must-run generation)
+ instead of the gross load
+
+- New functionalities available for datasets management (stucy cleaner,
+ Log file wiewer)
+
+- New info is given for simulation context (available & required amounts
+ of RAM & HDD space)
+
+
+
+From V1 to V2 (all versions)
+----------------------------
+
+- Refer to project development archives (TRAC thread)
+
diff --git a/docs/assets/Icone.png b/docs/assets/Icone.png
new file mode 100644
index 0000000000..597698eae9
Binary files /dev/null and b/docs/assets/Icone.png differ
diff --git a/docs/assets/antares.png b/docs/assets/antares.png
new file mode 100644
index 0000000000..0115f08967
Binary files /dev/null and b/docs/assets/antares.png differ
diff --git a/docs/assets/logo.png b/docs/assets/logo.png
new file mode 100644
index 0000000000..1bd094175d
Binary files /dev/null and b/docs/assets/logo.png differ
diff --git a/docs/build/0-INSTALL.md b/docs/build/0-INSTALL.md
new file mode 100644
index 0000000000..91ee46dc8e
--- /dev/null
+++ b/docs/build/0-INSTALL.md
@@ -0,0 +1,61 @@
+# Antares Simulator CMake Build Instructions
+
+[Supported OS](#supported-os) | [CMake version](#cmake-version) | [Python version](#python-version) | [Git version](#git-version) | [Dependencies](#dependencies)
+
+## C/I status
+| OS | System librairies | Built in libraries |
+|:-------|--------|------|
+| Ubuntu | [![Status][linux_system_svg]][linux_system_link] | [![Status][linux_deps_build_svg]][linux_deps_build_link] |
+| Windows | [![Status][windows_vcpkg_svg]][windows_vcpkg_link] | [![Status][windows_deps_build_svg]][windows_deps_build_link] |
+| Centos7 | [![Status][centos_system_svg]][centos_system_link] | [![Status][centos_deps_build_svg]][centos_deps_build_link] |
+
+## [Supported OS](#supported-os)
+*ANTARES* compilation is tested on :
+- Windows see [INSTALL-windows.md](INSTALL-windows.md)
+- Ubuntu see [INSTALL-ubuntu.md](INSTALL-ubuntu.md)
+- Centos7 see [INSTALL-centos.md](INSTALL-centos.md)
+
+## [CMake version](#cmake-version)
+CMake 3.x must be used.
+On some OS it is not available by default on the system.
+
+## [Python version](#python-version)
+Python 3.x is used for end-to-end test.
+
+## [Git version](#git-version)
+Git version must be above 2.15 for external dependencies build because `--ignore-whitespace` is not used by default and this option is needed during the OR-Tools compilation of ZLib to apply a patch on Windows (see https://github.com/google/or-tools/issues/1193).
+
+## [Dependencies](#deps)
+*ANTARES* depends on severals mandatory libraries.
+- [Sirius Solver](https://github.com/AntaresSimulatorTeam/sirius-solver/tree/Antares_VCPKG) (fork from [RTE](https://github.com/rte-france/sirius-solver/tree/Antares_VCPKG))
+- [OR-Tools](https://github.com/AntaresSimulatorTeam/or-tools/tree/rte_dev_sirius) (fork from [RTE](https://github.com/rte-france/or-tools/tree/rte_dev_sirius) based on official OR-Tools github)
+- [wxWidgets](https://github.com/wxWidgets/wxWidgets)
+ (Only for the complete Antares Simulator solution with GUI)
+- Boost librairies : test process filesystem regex dll (Only for unit tests)
+
+Installation of these dependencies is described in OS specific *ANTARES* install procedure.
+
+
+[linux_system_svg]: https://github.com/AntaresSimulatorTeam/Antares_Simulator/workflows/Linux%20CI%20(system%20libs)/badge.svg
+
+[linux_system_link]: https://github.com/AntaresSimulatorTeam/Antares_Simulator/actions?query=workflow%3A"Linux%20CI%20(system%20libs)"
+
+[linux_deps_build_svg]: https://github.com/AntaresSimulatorTeam/Antares_Simulator/workflows/Linux%20CI%20(deps.%20compilation)/badge.svg
+
+[linux_deps_build_link]: https://github.com/AntaresSimulatorTeam/Antares_Simulator/actions?query=workflow%3A"Linux%20CI%20(deps.%20compilation)"
+
+[windows_deps_build_svg]: https://github.com/AntaresSimulatorTeam/Antares_Simulator/workflows/Windows%20CI%20(deps.%20compilation)/badge.svg
+
+[windows_deps_build_link]: https://github.com/AntaresSimulatorTeam/Antares_Simulator/actions?query=workflow%3A"Windows%20CI%20(deps.%20compilation)"
+
+[windows_vcpkg_svg]: https://github.com/AntaresSimulatorTeam/Antares_Simulator/workflows/Windows%20CI%20(VCPKG)/badge.svg
+
+[windows_vcpkg_link]: https://github.com/AntaresSimulatorTeam/Antares_Simulator/actions?query=workflow%3A"Windows%20CI%20(VCPKG)"
+
+[centos_deps_build_svg]: https://github.com/AntaresSimulatorTeam/Antares_Simulator/workflows/Centos7%20CI%20(deps.%20compilation)/badge.svg
+
+[centos_deps_build_link]: https://github.com/AntaresSimulatorTeam/Antares_Simulator/actions?query=workflow%3A"Centos7%20CI%20(deps.%20compilation)"
+
+[centos_system_svg]: https://github.com/AntaresSimulatorTeam/Antares_Simulator/workflows/Centos7%20CI%20(system%20libs)/badge.svg
+
+[centos_system_link]: https://github.com/AntaresSimulatorTeam/Antares_Simulator/actions?query=workflow%3A"Centos7%20CI%20(system%20libs)"
diff --git a/docs/build/INSTALL-centos.md b/docs/build/INSTALL-centos.md
new file mode 100644
index 0000000000..62dad211ed
--- /dev/null
+++ b/docs/build/INSTALL-centos.md
@@ -0,0 +1,216 @@
+# Antares Simulator CMake Build Instructions
+
+[Environnement](#environment) | [CMake version](#cmake-version) | [GCC version](#gcc-version) | [Python version](#python-version) | [Dependencies](#dependencies) | [Building](#building-antares-solution) | [Tests](#tests) | [Installer creation](#installer-creation)
+
+## C/I status
+| OS | System librairies | Built in libraries |
+|:-------|--------|------|
+| Centos7 | [![Status][centos_system_svg]][centos_system_link] | [![Status][centos_deps_build_svg]][centos_deps_build_link] |
+
+[centos_deps_build_svg]: https://github.com/AntaresSimulatorTeam/Antares_Simulator/workflows/Centos7%20CI%20(deps.%20compilation)/badge.svg
+
+[centos_deps_build_link]: https://github.com/AntaresSimulatorTeam/Antares_Simulator/actions?query=workflow%3A"Centos7%20CI%20(deps.%20compilation)"
+
+[centos_system_svg]: https://github.com/AntaresSimulatorTeam/Antares_Simulator/workflows/Centos7%20CI%20(system%20libs)/badge.svg
+
+[centos_system_link]: https://github.com/AntaresSimulatorTeam/Antares_Simulator/actions?query=workflow%3A"Centos7%20CI%20(system%20libs)"
+
+## [CMake version](#cmake-version)
+CMake 3.x must be used.
+```
+sudo yum install epel-release
+sudo yum install cmake3
+```
+Note:
+> All ``cmake`` command must be replaced by ``cmake3``.
+
+## [GCC version](#gcc-version)
+By default, GCC version of Centos7 is 4.8.5.
+The compilation of *ANTARES* requires C++17 support.
+
+You can use a more recent version of GCC by enabling `devtoolset-7` :
+```
+sudo yum install centos-release-scl
+sudo yum install devtoolset-7
+```
+
+Before compiling *ANTARES* we must launch a new shell with `scl` tool :
+```
+scl enable devtoolset-7 bash
+```
+
+## [Python version](#python-version)
+Python 3.x must be used.
+
+```
+sudo yum install python3 python3-pip
+```
+
+Required python modules can be installed with :
+```
+pip3 install -r src/tests/examples/requirements.txt
+```
+
+## [Dependencies](#deps)
+ ANTARES depends on several mandatory libraries.
+ - [Sirius Solver](https://github.com/AntaresSimulatorTeam/sirius-solver/tree/Antares_VCPKG) (fork from [RTE](https://github.com/rte-france/sirius-solver/tree/Antares_VCPKG))
+ - [OR-Tools](https://github.com/AntaresSimulatorTeam/or-tools/tree/rte_dev_sirius) (fork from [RTE](https://github.com/rte-france/or-tools/tree/rte_dev_sirius) based on official OR-Tools github)
+ - [wxWidgets](https://github.com/wxWidgets/wxWidgets)
+ (Only for the complete Antares Simulator solution with GUI)
+ - Boost libraries : test process filesystem regex dll (Only for unit tests)
+
+This section describes the install procedures for the third-party Open source libraries used by ANTARES.
+The install procedure can be done
+- by compiling the sources after cloning the official git repository
+- by using a package manager
+- by using pre-compiled external libraries provided by [Antares dependencies compilation repository](https://github.com/AntaresSimulatorTeam/antares-deps/releases/tag/v1.2.0)
+
+#### Yum commands
+```
+sudo yum install redhat-lsb-core curl-devel wxGTK3-devel boost-test boost-filesystem boost-regex boost-devel unzip
+```
+### [Automatic librairies compilation from git](#git_compil)
+[Antares dependencies compilation repository](https://github.com/AntaresSimulatorTeam/antares-deps) is used as a git submodule for automatic librairies compilation from git.
+
+All dependencies can be built at configure time using the option `-DBUILD_ALL=ON` (`OFF` by default).
+For a list of available option see [Antares dependencies compilation repository](https://github.com/AntaresSimulatorTeam/antares-deps).
+
+Some dependencies can't be installed with a package manager.
+They can be built at configure step with a cmake option : `-DBUILD_not_system=ON` (`ON` by default).
+
+#### Defining dependency install directory
+It can be useful to have a common dependency install directory, when using multiple directories for antares development
+with multiple branches.
+
+The dependency-install-directory can be specified with `DEPS_INSTALL_DIR`.
+By default the install directory is `/../rte-antares-deps-`
+
+Note :
+> `DEPS_INSTALL_DIR` is added to `CMAKE_PREFIX_PATH`
+
+> If the dependency install directory contains CURL, or wxWidgets pre-compiled libraries an additionnal option must be used at configure time `-DUSE_PRECOMPILED_EXT=ON`
+
+### Pre-compiled libraries download : release version only
+You can download pre-compiled antares-deps archive from [Antares dependencies compilation repository](https://github.com/AntaresSimulatorTeam/antares-deps/releases/tag/v1.1.0). Only release version are available.
+
+There are still some system libraries that must be installed :
+
+```
+sudo yum install libuuid-devel libidn2-devel gtk2-devel redhat-lsb-core
+```
+
+## [Building Antares Solution](#build)
+
+Antares source directory is named `[antares_src]` in all following commands.
+
+### 1 - Update git submodule for dependency build
+
+First you need to update git submodule for dependency build :
+```
+git submodule update --init [antares_src]/antares-deps
+```
+
+### 2 - Enable `devtoolset-7`
+
+```
+scl enable devtoolset-7 bash
+```
+
+### 3 - CMake configure
+
+Here is a list of available CMake configure option :
+
+|Option | Description |
+|:-------|-------|
+|`CMAKE_BUILD_TYPE` | Define build type. Available values are `release` and `debug` |
+|`BUILD_UI`|Enable or disable Antares Simulator UI compilation (default `ON`)|
+|`BUILD_not_system`|Enable build of external librairies not available on system package manager (default `ON`)|
+|`BUILD_ALL`|Enable build of ALL external librairies (default `OFF`)|
+|`DEPS_INSTALL_DIR`|Define dependencies libraries install directory|
+|`USE_PRECOMPILED_EXT`| This option must be set if you use precompiled external librairies (default `OFF`)|
+|`BUILD_TESTING`| Enable test build (default `OFF`)|
+|`BUILD_OUTPUT_TEST`| Enable test with output compare build (default `OFF`)|
+
+
+```
+cmake3 -B _build -S [antares_src] -DCMAKE_BUILD_TYPE=release
+```
+
+### 4 - Build
+ ```
+cmake3 --build _build --config release -j8
+```
+Note :
+> Compilation can be done on several processor with ```-j``` option.
+
+## [Tests](#tests)
+
+Tests compilation can be enabled at configure time using the option `-DBUILD_TESTING=ON` (`OFF` by default)
+
+After build, tests can be run with ``ctest`` :
+ ```
+cd _build
+ctest3 -C Release --output-on-failure
+```
+Note:
+> Tests with output comparison must be enabled using the option `-DBUILD_OUTPUT_TEST=ON` (`OFF` by default)
+
+All tests are associated to a label and multiple labels can be defined. You can choose which tests will be executed at ctest run.
+
+This is the list of the available labels :
+
+| Label | Description |
+|:-------|-----|
+| `units` | Units tests|
+| `end-to-end` | End to end tests with antares study creation|
+| `short-examples` | Short duration pytest with antares solver call and objective function result check|
+| `medium-examples` | Medium duration pytest with antares solver call and objective function result check|
+| `long-examples` | Long duration pytest with antares solver call and objective function result check|
+| `short-output` | Short duration pytest with antares solver call and simulation output comparison|
+| `sirius` | Sirius related pytest|
+| `coin` | coin related pytest|
+| `ortools` | OR-Tools related pytest|
+
+Note :
+> Use `ctest -N` to see all available tests
+Here is an example for running only units tests:
+```
+ctest3 -C Release --output-on-failure -L units
+````
+
+Here is an example for running only sirius tests without OR-Tools used:
+```
+ctest3 -C Release --output-on-failure -L sirius -LE ortools
+````
+
+Here is an example for running only short sirius tests without OR-Tools used:
+```
+ctest3 -C Release --output-on-failure -R "short-examples.*sirius" -LE "ortools"
+````
+Note :
+> In this case the regex is on name (`-R`) so only short-examples are executed.
+For more information on `ctest` call see [documentation](https://cmake.org/cmake/help/latest/manual/ctest.1.html)
+
+## [Installer creation](#installer)
+CPack can be used to create the installer after the build phase.
+
+## RHEL .rpm (Experimental)
+ ```
+cd _build
+cpack3 -G RPM .
+```
+Note :
+> `rpm-build` must be installed for RPM creation : `sudo yum install rpm-build `
+
+## Linux .tar.gz
+ ```
+cd _build
+cpack3 -G TGZ .
+```
+
+There are still some system libraries that must be installed if you want to use *ANTARES*:
+
+```
+sudo yum install epel-release
+sudo yum install curl wxGTK3
+```
diff --git a/docs/build/INSTALL-ubuntu.md b/docs/build/INSTALL-ubuntu.md
new file mode 100644
index 0000000000..7033b02fd1
--- /dev/null
+++ b/docs/build/INSTALL-ubuntu.md
@@ -0,0 +1,191 @@
+# Antares Simulator CMake Build Instructions
+
+[Environnement](#environment) | [Build tools](#build-tools) | [Environnement build install](#env-build-install) | [Python version](#python-version) | [Dependencies](#dependencies) | [Building](#building-antares-solution) | [Tests](#tests) | [Installer creation](#installer-creation)
+
+## C/I status
+| OS | System librairies | Built in libraries |
+|:-------|--------|------|
+| Ubuntu | [![Status][linux_system_svg]][linux_system_link] | [![Status][linux_deps_build_svg]][linux_deps_build_link] |
+
+[linux_system_svg]: https://github.com/AntaresSimulatorTeam/Antares_Simulator/workflows/Linux%20CI%20(system%20libs)/badge.svg
+
+[linux_system_link]: https://github.com/AntaresSimulatorTeam/Antares_Simulator/actions?query=workflow%3A"Linux%20CI%20(system%20libs)"
+
+[linux_deps_build_svg]: https://github.com/AntaresSimulatorTeam/Antares_Simulator/workflows/Linux%20CI%20(deps.%20compilation)/badge.svg
+
+[linux_deps_build_link]: https://github.com/AntaresSimulatorTeam/Antares_Simulator/actions?query=workflow%3A"Linux%20CI%20(deps.%20compilation)"
+
+## [Build tools](#build-tools)
+
+```
+sudo apt install build-essential libssl-dev cmake
+```
+
+## [Python version](#python-version)
+Python 3.x must be used.
+
+```
+sudo apt install python3 python3-pip
+```
+Required python modules can be installed with :
+```
+pip3 install -r src/src/tests/examples/requirements.txt
+```
+
+## [Dependencies](#deps)
+ ANTARES depends on several mandatory libraries.
+ - [Sirius Solver](https://github.com/AntaresSimulatorTeam/sirius-solver/tree/Antares_VCPKG) (fork from [RTE](https://github.com/rte-france/sirius-solver/tree/Antares_VCPKG))
+ - [OR-Tools](https://github.com/AntaresSimulatorTeam/or-tools/tree/rte_dev_sirius) (fork from [RTE](https://github.com/rte-france/or-tools/tree/rte_dev_sirius) based on official OR-Tools github)
+ - [wxWidgets](https://github.com/wxWidgets/wxWidgets)
+ (Only for the complete Antares Simulator solution with GUI)
+ - Boost libraries : test process filesystem regex dll (Only for unit tests)
+
+This section describes the install procedures for the third-party Open source libraries used by ANTARES.
+The install procedure can be done
+- by compiling the sources after cloning the official git repository
+- by using a package manager.
+- by using pre-compiled external libraries provided by [Antares dependencies compilation repository](https://github.com/AntaresSimulatorTeam/antares-deps/releases/tag/v1.2.0)
+
+#### Command to install dependencies
+```
+sudo apt install uuid-dev libwxgtk3.0-gtk3-dev libboost-test-dev libboost-filesystem-dev libboost-regex-dev libboost-dev
+```
+
+### [Automatic librairies compilation from git](#git_compil)
+[Antares dependencies compilation repository](https://github.com/AntaresSimulatorTeam/antares-deps) is used as a git submodule for automatic librairies compilation from git.
+
+All dependencies can be built at configure time using the option `-DBUILD_ALL=ON` (`OFF` by default).
+For a list of available option see [Antares dependencies compilation repository](https://github.com/AntaresSimulatorTeam/antares-deps).
+
+Some dependencies can't be installed with a package manager.
+They can be built at configure step with a cmake option : `-DBUILD_not_system=ON` (`ON` by default).
+
+#### Defining dependency install directory
+It can be useful to have a common dependency install directory, when using multiple directories for antares development
+with multiple branches.
+
+The dependency-install-directory can be specified with `DEPS_INSTALL_DIR`.
+By default the install directory is `/../rte-antares-deps-`
+
+Note :
+> `DEPS_INSTALL_DIR` is added to `CMAKE_PREFIX_PATH`
+
+> If the dependency install directory contains wxWidgets pre-compiled libraries an additionnal option must be used at configure time `-DUSE_PRECOMPILED_EXT=ON`
+
+### Pre-compiled libraries download : release version only
+You can download pre-compiled antares-deps archive from [Antares dependencies compilation repository](https://github.com/AntaresSimulatorTeam/antares-deps/releases/tag/v1.1.0). Only release version are available.
+
+There are still some system libraries that must be installed :
+
+```
+sudo apt-get install libuuid1 uuid-dev libssh2-1 libssh2-1-dev libidn2-0 libidn2-dev libidn11 libidn11-dev gtk2.0 libb64-dev libjpeg-dev libtiff-dev libsecret-1-dev
+```
+
+## [Building Antares Solution](#build)
+
+Antares source directory is named `[antares_src]` in all following commands.
+
+### 1 - Update git submodule for dependency build
+
+First you need to update git submodule for dependency build :
+```
+git submodule update --init [antares_src]/antares-deps
+```
+
+### 2 - CMake configure
+
+#### Configure options
+
+Here is a list of available CMake configure option :
+
+|Option | Description |
+|:-------|-------|
+|`CMAKE_BUILD_TYPE` | Define build type. Available values are `release` and `debug` |
+|`BUILD_UI`|Enable or disable Antares Simulator UI compilation (default `ON`)|
+|`BUILD_not_system`|Enable build of external librairies not available on system package manager (default `ON`)|
+|`BUILD_ALL`|Enable build of ALL external librairies (default `OFF`)|
+|`DEPS_INSTALL_DIR`|Define dependencies libraries install directory|
+|`USE_PRECOMPILED_EXT`| This option must be set if you use precompiled external librairies (default `OFF`)|
+|`BUILD_TESTING`| Enable test build (default `OFF`)|
+|`BUILD_OUTPUT_TEST`| Enable test with output compare build (default `OFF`)|
+
+#### Configure
+
+```
+cmake -B _build -S [antares_src] -DCMAKE_BUILD_TYPE=release
+```
+
+### 3 - Build
+ ```
+cmake --build _build --config release -j8
+```
+Note :
+> Compilation can be done on several processor with ```-j``` option.
+
+## [Tests](#tests)
+
+Tests compilation can be enabled at configure time using the option `-DBUILD_TESTING=ON` (`OFF` by default)
+
+After build, tests can be run with ``ctest`` :
+ ```
+cd _build
+ctest -C Release --output-on-failure
+```
+Note:
+> Tests with output comparison must be enabled using the option `-DBUILD_OUTPUT_TEST=ON` (`OFF` by default)
+
+All tests are associated to a label and multiple labels can be defined. You can choose which tests will be executed at ctest run.
+
+This is the list of the available labels :
+
+| Label | Description |
+|:-------|-----|
+| `units` | Units tests|
+| `end-to-end` | End to end tests with antares study creation|
+| `short-examples` | Short duration pytest with antares solver call and objective function result check|
+| `medium-examples` | Medium duration pytest with antares solver call and objective function result check|
+| `long-examples` | Long duration pytest with antares solver call and objective function result check|
+| `short-output` | Short duration pytest with antares solver call and simulation output comparison|
+| `sirius` | Sirius related pytest|
+| `coin` | coin related pytest|
+| `ortools` | OR-Tools related pytest|
+
+Note :
+> Use `ctest -N` to see all available tests
+Here is an example for running only units tests:
+```
+ctest -C Release --output-on-failure -L units
+````
+
+Here is an example for running only sirius tests without OR-Tools used:
+```
+ctest -C Release --output-on-failure -L sirius -LE ortools
+````
+
+Here is an example for running only short sirius tests without OR-Tools used:
+```
+ctest -C Release --output-on-failure -R "short-examples.*sirius" -LE "ortools"
+````
+Note :
+> In this case the regex is on name (`-R`) so only short-examples are executed.
+For more information on `ctest` call see [documentation](https://cmake.org/cmake/help/latest/manual/ctest.1.html)
+
+## [Installer creation](#installer)
+CPack can be used to create the installer after the build phase.
+
+## Ubuntu .deb (Experimental)
+ ```
+cd _build
+cpack -G DEB .
+```
+
+## Linux .tar.gz
+ ```
+cd _build
+cpack -G TGZ .
+```
+There are still some system libraries that must be installed if you want to use *ANTARES*:
+
+```
+sudo apt-get install libwxgtk3.0-gtk3-0v5
+```
diff --git a/docs/build/INSTALL-windows.md b/docs/build/INSTALL-windows.md
new file mode 100644
index 0000000000..beac77ca9c
--- /dev/null
+++ b/docs/build/INSTALL-windows.md
@@ -0,0 +1,219 @@
+# Antares Simulator CMake Build Instructions
+
+[CMake version](#cmake-version) | [Python version](#python-version) | [Dependencies](#dependencies) | [Building](#building-antares-solution) | [Tests](#tests) | [Installer creation](#installer-creation)
+
+## C/I status
+| OS | System librairies | Built in libraries |
+|:-------|--------|------|
+| Windows | [![Status][windows_vcpkg_svg]][windows_vcpkg_link] | [![Status][windows_deps_build_svg]][windows_deps_build_link] |
+
+[windows_deps_build_svg]: https://github.com/AntaresSimulatorTeam/Antares_Simulator/workflows/Windows%20CI%20(deps.%20compilation)/badge.svg
+
+[windows_deps_build_link]: https://github.com/AntaresSimulatorTeam/Antares_Simulator/actions?query=workflow%3A"Windows%20CI%20(deps.%20compilation)"
+
+[windows_vcpkg_svg]: https://github.com/AntaresSimulatorTeam/Antares_Simulator/workflows/Windows%20CI%20(VCPKG)/badge.svg
+
+[windows_vcpkg_link]: https://github.com/AntaresSimulatorTeam/Antares_Simulator/actions?query=workflow%3A"Windows%20CI%20(VCPKG)"
+
+## [CMake version](#cmake-version)
+CMake 3.x must be used.
+
+You can download latest Windows version directly from [CMake website](https://cmake.org/download/).
+
+## [Python version](#python-version)
+Python 3.x must be used.
+
+You can download latest Windows version directly from [Python website](https://www.python.org/downloads/windows/).
+
+Required python modules can be installed with :
+```
+pip install -r src/tests/examples/requirements.txt
+```
+
+## [Dependencies](#deps)
+ ANTARES depends on several mandatory libraries.
+ - [Sirius Solver](https://github.com/AntaresSimulatorTeam/sirius-solver/tree/Antares_VCPKG) (fork from [RTE](https://github.com/rte-france/sirius-solver/tree/Antares_VCPKG))
+ - [OR-Tools](https://github.com/AntaresSimulatorTeam/or-tools/tree/rte_dev_sirius) (fork from [RTE](https://github.com/rte-france/or-tools/tree/rte_dev_sirius) based on official OR-Tools github)
+ - [wxWidgets](https://github.com/wxWidgets/wxWidgets)
+ (Only for the complete Antares Simulator solution with GUI)
+ - Boost libraries : test process filesystem regex dll (Only for unit tests)
+
+This section describes the install procedures for the third-party Open source libraries used by ANTARES.
+The install procedure can be done
+- by compiling the sources after cloning the official git repository
+- by using VCPKG
+- by using pre-compiled external libraries provided by [Antares dependencies compilation repository](https://github.com/AntaresSimulatorTeam/antares-deps/releases/tag/v1.2.0)
+
+### VCPKG
+
+For Windows we will use [vcpkg](https://github.com/microsoft/vcpkg) to download and compile the librairies.
+
+You must install the corresponding [vcpkg-triplet](https://vcpkg.readthedocs.io/en/latest/users/integration/#triplet-selection) depending on Antares version and libraries load:
+
+- ``x64-windows`` : 64 bits version with dynamic librairies load
+- ``x64-windows-static`` : 64 bits version with static librairies load
+
+The vcpkg-triplet used will be named [vcpg-triplet] later in this document.
+
+#### 1 Install vcpkg
+
+vcpkg can be installed anywhere on your computer :
+
+```
+git clone https://github.com/Microsoft/vcpkg.git
+cd vcpkg
+.\bootstrap-vcpkg.bat
+```
+
+Note :
+> all vcpkg further described commands must be run from the vcpkg folder. This folder will be named [vcpkg_root] later in this document.
+
+
+#### 2 Install dependencies
+```
+cd [vcpkg_root]
+vcpkg install wxwidgets:[vcpg-triplet]
+vcpkg install boost-test:[vcpg-triplet]
+vcpkg install boost-filesystem:[vcpg-triplet]
+vcpkg install boost-process[vcpg-triplet]
+vcpkg install boost-dll:[vcpg-triplet]
+vcpkg install boost-regex:[vcpg-triplet]
+```
+### [Automatic librairies compilation from git](#git_compil)
+[Antares dependencies compilation repository](https://github.com/AntaresSimulatorTeam/antares-deps) is used as a git submodule for automatic librairies compilation from git.
+
+All dependencies can be built at configure time using the option `-DBUILD_ALL=ON` (`OFF` by default).
+For a list of available option see [Antares dependencies compilation repository](https://github.com/AntaresSimulatorTeam/antares-deps).
+
+Some dependencies can't be installed with a package manager.
+They can be built at configure step with a cmake option : `-DBUILD_not_system=ON` (`ON` by default).
+
+#### Defining dependency install directory
+It can be useful to have a common dependency install directory, when using multiple directories for antares development
+with multiple branches.
+
+The dependency-install-directory can be specified with `DEPS_INSTALL_DIR`.
+By default the install directory is `/../rte-antares-deps-`
+
+Note :
+> `DEPS_INSTALL_DIR` is added to `CMAKE_PREFIX_PATH`
+
+> If the dependency install directory contains wxWidgets pre-compiled libraries an additionnal option must be used at configure time `-DUSE_PRECOMPILED_EXT=ON`
+
+### Pre-compiled libraries download : release version only
+You can download pre-compiled antares-deps archive from [Antares dependencies compilation repository](https://github.com/AntaresSimulatorTeam/antares-deps/releases/tag/v1.1.0). Only release version are available.
+
+Note:
+> You must you use a MSVC version compatible with MSVC version used in GitHub Action.
+
+## [Building Antares Solution](#build)
+
+Antares source directory is named `[antares_src]` in all following commands.
+
+### 1 - Update git submodule for dependency build
+
+First you need to update git submodule for dependency build :
+```
+git submodule update --init [antares_src]/antares-deps
+```
+
+### 2 - CMake configure
+
+Note :
+> cpack NSIS installer creation need an 'out of source build'. The build directory must be outside `[antares_src]` directory
+
+#### Configure options
+
+Here is a list of available CMake configure option :
+
+|Option | Description |
+|:-------|-------|
+|`CMAKE_BUILD_TYPE` | Define build type. Available values are `release` and `debug` |
+|`BUILD_UI`|Enable or disable Antares Simulator UI compilation (default `ON`)|
+|`BUILD_not_system`|Enable build of external librairies not available on system package manager (default `ON`)|
+|`BUILD_ALL`|Enable build of ALL external librairies (default `OFF`)|
+|`DEPS_INSTALL_DIR`|Define dependencies libraries install directory|
+|`USE_PRECOMPILED_EXT`| This option must be set if you use precompiled external librairies (default `OFF`)|
+|`VCPKG_ROOT`| Define [vcpkg_root] |
+|`VCPKG_TARGET_TRIPLET`| Define [vcpkg-triplet] |
+|`BUILD_TESTING`| Enable test build (default `OFF`)|
+|`BUILD_OUTPUT_TEST`| Enable test with output compare build (default `OFF`)|
+
+
+#### Configure using vcpkg (recommended)
+
+```
+cmake -B _build -S [antares_src] -DVCPKG_ROOT=[vcpkg_root] -DVCPKG_TARGET_TRIPLET=[vcpkg-triplet] -DCMAKE_BUILD_TYPE=release
+```
+
+
+#### Configure withouth VCPKG
+
+```
+cmake -B _build -S [antares_src] -DCMAKE_BUILD_TYPE=release
+```
+
+### 3 - Build
+ ```
+cmake --build _build --config release -j8
+```
+Note :
+> Compilation can be done on several processor with ```-j``` option.
+
+## [Tests](#tests)
+
+Tests compilation can be enabled at configure time using the option `-DBUILD_TESTING=ON` (`OFF` by default)
+
+After build, tests can be run with ``ctest`` :
+ ```
+cd _build
+ctest -C Release --output-on-failure
+```
+Note:
+> Tests with output comparison must be enabled using the option `-DBUILD_OUTPUT_TEST=ON` (`OFF` by default)
+
+All tests are associated to a label and multiple labels can be defined. You can choose which tests will be executed at ctest run.
+
+This is the list of the available labels :
+
+| Label | Description |
+|:-------|-----|
+| `units` | Units tests|
+| `end-to-end` | End to end tests with antares study creation|
+| `short-examples` | Short duration pytest with antares solver call and objective function result check|
+| `medium-examples` | Medium duration pytest with antares solver call and objective function result check|
+| `long-examples` | Long duration pytest with antares solver call and objective function result check|
+| `short-output` | Short duration pytest with antares solver call and simulation output comparison|
+| `sirius` | Sirius related pytest|
+| `coin` | coin related pytest|
+| `ortools` | OR-Tools related pytest|
+
+Note :
+> Use `ctest -N` to see all available tests
+Here is an example for running only units tests:
+```
+ctest -C Release --output-on-failure -L units
+````
+
+Here is an example for running only sirius tests without OR-Tools used:
+```
+ctest -C Release --output-on-failure -L sirius -LE ortools
+````
+
+Here is an example for running only short sirius tests without OR-Tools used:
+```
+ctest -C Release --output-on-failure -R "short-examples.*sirius" -LE "ortools"
+````
+Note :
+> In this case the regex is on name (`-R`) so only short-examples are executed.
+For more information on `ctest` call see [documentation](https://cmake.org/cmake/help/latest/manual/ctest.1.html)
+
+## [Installer creation](#installer)
+CPack can be used to create the installer after the build phase.
+
+```
+cd _build
+cpack -GNSIS
+```
+Currently missing in NSIS installer :
+- External libraries sources
diff --git a/docs/ortools-integration.md b/docs/build/ortools-integration.md
similarity index 100%
rename from docs/ortools-integration.md
rename to docs/build/ortools-integration.md
diff --git a/docs/index.md b/docs/index.md
new file mode 100644
index 0000000000..bfc03458db
--- /dev/null
+++ b/docs/index.md
@@ -0,0 +1,74 @@
+
+
+[![Status][linux_system_svg]][linux_system_link] [![Status][windows_vcpkg_svg]][windows_vcpkg_link] [![Status][centos7_system_svg]][centos7_system_link]
+
+[](https://www.gnu.org/licenses/gpl-3.0)
+
+
+Antares Simulator is an open source power system simulator meant to be
+used by anybody placing value in quantifying the adequacy or the
+economic performance of interconnected power systems, at short or
+remote time horizons:
+
+Transmission system Operators, Power Producers, Regulators, Academics,
+Consultants, NGO and all others actors concerned by energy policy issues
+are welcome to use the software.
+
+The Antares Simulator project was initiated by RTE (French Electricity
+Transmission system Operator) in 2007. It was developed from the start
+as a cross-platform application (Windows, GNU/Linux, Unix).
+
+Until 2018 it was distributed under the terms of a proprietary license.
+
+In May 2018 RTE decided to release the project under the GPLv3 license.
+
+## Links:
+
+- Antares web site : https://antares-simulator.org
+- RTE web site : http://www.rte-france.com/
+
+## Installation
+
+This software suite has been tested under:
+
+* Ubuntu 20.04 [![Status][linux_system_svg]][linux_system_link]
+* Microsoft Windows with Visual Studio 2019 (64-bit) [![Status][windows_vcpkg_svg]][windows_vcpkg_link]
+* Centos7 [![Status][centos7_system_svg]][centos7_system_link]
+
+Antares Simulator is built using CMake.
+For installation instructions, please visit [INSTALL.md](INSTALL.md)
+
+## Source Code Content
+
+* [AUTHORS](AUTHORS.txt) - Antares Simulator authors
+* [CERTIFICATE](CERTIFICATE.txt) - A standard DCO that has to be signed by every contributor
+* [CONTRIBUTING](CONTRIBUTING.txt) - How to submit patches and discuss about code evolutions
+* [COPYING](COPYING.txt) - The GPL v3 license.
+* [INSTALL](INSTALL.md) - Installation and building instructions.
+* [NEWS](NEWS.md) - Important modifications between the releases.
+* [README](README.md) - This file.
+* [ROADMAP](ROADMAP.txt) - Main orientations for further developements
+* [THANKS](THANKS.txt) - Attribution notices for external libraries and contributors.
+* [resources/](resources) - Free sample data sets.
+* [src/analyzer/](src/analyzer) - source code for the statistical analysis of historical time-series.
+* [src/cmake/](src/cmake) - files for initializing a solution ready for compilation.
+* [src/distrib/](src/distrib) - system redistributable libraries Win(x64,x86),unix.
+* [src/ext/](src/ext) - third party libraries used by Antares_Simulator: libYuni, Sirius_Solver.
+* [src/libs/](src/libs) - miscellaneous Antares_Simulator libraries.
+* [src/internet/](src/internet) - web access (check for updates, usage metrics, data exchange).
+* [src/simulator/](src/simulator) - Time-series generation, Monte-Carlo simulation and weekly optimization modelling.
+* [src/tools/](src/tools) - miscellaneous tools for dataset management.
+* [src/ui/](src/ui) - Graphic user interface.
+
+[linux_system_svg]: https://github.com/AntaresSimulatorTeam/Antares_Simulator/workflows/Linux%20CI%20(system%20libs)/badge.svg
+
+[linux_system_link]: https://github.com/AntaresSimulatorTeam/Antares_Simulator/actions?query=workflow%3A"Linux%20CI%20(system%20libs)"
+
+[windows_vcpkg_svg]: https://github.com/AntaresSimulatorTeam/Antares_Simulator/workflows/Windows%20CI%20(VCPKG)/badge.svg
+
+[windows_vcpkg_link]: https://github.com/AntaresSimulatorTeam/Antares_Simulator/actions?query=workflow%3A"Windows%20CI%20(VCPKG)"
+
+[centos7_system_svg]: https://github.com/AntaresSimulatorTeam/Antares_Simulator/workflows/Centos7%20CI%20(system%20libs)/badge.svg
+
+[centos7_system_link]: https://github.com/AntaresSimulatorTeam/Antares_Simulator/actions?query=workflow%3A"Centos7%20CI%20(system%20libs)"
+
diff --git a/docs/pdf-doc-generation-with-sphinx/create_pdf_doc.sh b/docs/pdf-doc-generation-with-sphinx/create_pdf_doc.sh
new file mode 100644
index 0000000000..a44fbc0602
--- /dev/null
+++ b/docs/pdf-doc-generation-with-sphinx/create_pdf_doc.sh
@@ -0,0 +1,11 @@
+#!/bin/bash
+# copy reference guide md files and assets
+cp -r ../reference-guide source/
+cp -r ../assets/ source/
+# change style for inline latex math \\( -> $ and \\) -> $
+find source/reference-guide/ -type f -name "*.md" -exec sed -i 's=\\\\)=$=g ; s=\\\\(=$=g' {} \;
+# actually make the pdf
+sphinx-build -M latexpdf source build
+mv build/latex/antaressimulatoruserguide.pdf .
+# clean
+rm -rf source/reference-guide source/assets build
diff --git a/docs/pdf-doc-generation-with-sphinx/source/conf.py b/docs/pdf-doc-generation-with-sphinx/source/conf.py
new file mode 100644
index 0000000000..6a1ff80689
--- /dev/null
+++ b/docs/pdf-doc-generation-with-sphinx/source/conf.py
@@ -0,0 +1,59 @@
+# Configuration file for the Sphinx documentation builder.
+#
+# This file only contains a selection of the most common options. For a full
+# list see the documentation:
+# https://www.sphinx-doc.org/en/master/usage/configuration.html
+
+# -- Path setup --------------------------------------------------------------
+
+# If extensions (or modules to document with autodoc) are in another directory,
+# add these directories to sys.path here. If the directory is relative to the
+# documentation root, use os.path.abspath to make it absolute, like shown here.
+#
+# import os
+# import sys
+# sys.path.insert(0, os.path.abspath('.'))
+
+
+# -- Project information -----------------------------------------------------
+
+project = 'Antares Simulator User Guide'
+copyright = '2021, RTE'
+author = 'RTE'
+
+
+# -- General configuration ---------------------------------------------------
+
+# Add any Sphinx extension module names here, as strings. They can be
+# extensions coming with Sphinx (named 'sphinx.ext.*') or your custom
+# ones.
+extensions = ['myst_parser']
+myst_enable_extensions = [
+ "amsmath",
+ "dollarmath",
+]
+
+
+# Add any paths that contain templates here, relative to this directory.
+templates_path = ['_templates']
+
+# List of patterns, relative to source directory, that match files and
+# directories to ignore when looking for source files.
+# This pattern also affects html_static_path and html_extra_path.
+exclude_patterns = []
+
+
+# -- Options for HTML output -------------------------------------------------
+
+# The theme to use for HTML and HTML Help pages. See the documentation for
+# a list of builtin themes.
+#
+
+html_sidebars = {
+ "**": ["logo-text.html", "globaltoc.html", "localtoc.html", "searchbox.html"]
+}
+
+# Add any paths that contain custom static files (such as style sheets) here,
+# relative to this directory. They are copied after the builtin static files,
+# so a file named "default.css" will overwrite the builtin "default.css".
+# html_static_path = ['_static']
\ No newline at end of file
diff --git a/docs/pdf-doc-generation-with-sphinx/source/index.rst b/docs/pdf-doc-generation-with-sphinx/source/index.rst
new file mode 100644
index 0000000000..22a9894bcb
--- /dev/null
+++ b/docs/pdf-doc-generation-with-sphinx/source/index.rst
@@ -0,0 +1,7 @@
+Welcome to Antares Simulator User Guide'!
+=======================================================
+.. toctree::
+ Modeling
+ Modeling
+ :maxdepth: 2
+ :caption: Contents:
diff --git a/docs/reference-guide/1-reference-guide.md b/docs/reference-guide/1-reference-guide.md
new file mode 100644
index 0000000000..7f2f5f235b
--- /dev/null
+++ b/docs/reference-guide/1-reference-guide.md
@@ -0,0 +1,2914 @@
+General reference guide v8.1.0
+
+# Introduction
+
+This document describes all the main features of the **Antares\_Simulator** package, version 8.1.0.
+
+It gives useful general information regarding the way data are handled and processed,
+as well as how the Graphic User Interface (GUI) works. To keep this documentation
+as compact as possible, many redundant details (how to mouse-select, etc.) are omitted.
+
+Some features described in this guide are not fully operational in 8.1.0 version.
+Features not yet available appear in grey in the GUI.
+
+Real-life use of the software involves a learning curve process that cannot be supported by a
+simple reference guide. In order to be able to address this basic issue, two kinds of resources may be used:
+
+- The examples' library, which is meant as a self-teaching way to learn how to use the software.
+It is enhanced in parallel to the development of new features.
+The content of this library may depend on the type of installation package it comes from
+(general public or members of the users' club).
+
+- The [https://antares-simulator.org](https://antares-simulator.org/) website
+
+Please report misprints or other errors to:
+
+[support@antares-simulator.org](mailto:support@antares-simulator.org)
+
+# General content of Antares\_Simulator sessions
+
+A typical **Antares\_Simulator** [1] session involves different steps that are usually run in sequence,
+either automatically or with some degree of man-in-the-loop control, depending on the kind of study to perform.
+
+These steps most often involve:
+
+1. GUI session dedicated to the initialization or to the updating of various input data sections
+(time-series of many kinds, grid topology, generating fleet description, etc.)
+
+2. GUI session dedicated to the definition of simulation contexts
+(definition of the number and consistency of the "Monte-Carlo years" to simulate)
+
+3. Simulation session producing actual numeric scenarios following the directives defined in (b)
+
+4. Optimization session aiming at solving all the optimization problems associated with
+each of the scenarios produced in (c)
+
+5. GUI session dedicated to the exploitation of the detailed results yielded by (d)
+
+The scope of this document is to give a detailed description of the software involved in
+step (1) to (5) mostly based on a functional approach, leaving thereby aside a significant
+part of the mathematical content involved in several of these steps.
+[2] The following picture gives a functional view of all that is involved in steps (a) to (e).
+
+
+
+The number and the size of the individual problems to solve (typically, a least-cost hydro-thermal power schedule and
+unit commitment, with an hourly resolution and throughout a week, over a large interconnected system) make
+optimization sessions often computer-intensive.
+
+Depending on user-defined results accuracy requirements, various practical options allow to simplify either
+the formulation of the problems or their resolution.
+
+In terms of power studies, the different fields of application Antares has been designed for are the following:
+
+- **Generation adequacy problems:**
+- **Transmission project profitability:**
+
+The common rationale of the modeling used in all of these studies is, whenever it is possible,
+to decompose the general issue (representation of the system behavior throughout many years,
+with a time step of one hour) into a series of standardized smaller problems.
+
+In Antares, the "elementary" optimization problem resulting from this approach is that of the minimization of
+the overall system operation cost over a week, taking into account all proportional and
+non-proportional generation costs, as well as transmission charges and "external" costs such as
+that of the unsupplied energy (generation shortage) or, conversely, that of the spilled energy (generation excess).
+In this light, carrying out generation adequacy studies or transmission projects studies means formulating and
+solving a series of a great many week-long operation problems (one for each week of each Monte-Carlo year),
+assumed to be independent to some extent (note that, however, issues such as the management of hydro resources –or
+possibly other kinds of energy storage facilities– may bring a significant coupling between the successive problems,
+which needs to be addressed properly).
+
+### Generation adequacy problems
+Adequacy problems aim to study the need for new generating plants to keep the security of
+supply above a given critical threshold.
+
+What is most important in these studies is to survey a great number of scenarios that represent well enough
+the random factors that may affect the balance between load and generation. Economic parameters do not play
+as much a critical role as they do in the other kinds of studies since the stakes are mainly to know if and
+when supply security is likely to be jeopardized (detailed costs incurred in more ordinary conditions are of
+comparatively lower importance). In these studies, the default Antares option to use is the "Adequacy"
+simulation mode, or the "Draft" simulation mode (which is extremely fast but which produces crude results).
+
+### Transmission project profitability
+Transmission project profitability studies the savings brought by a specific reinforcement of the grid,
+in terms of decrease of the overall system generation cost (using an assumption of fair and perfect market) and/or
+improvement of the security of supply (reduction of the loss-of-load expectation).
+
+In these studies, economic parameters and the physical modeling of the dynamic constraints bearing on
+the generating units are of paramount importance. Though a thorough survey of many "Monte-Carlo years"
+is still required, the number of scenarios to simulate is not as large as in generation adequacy studies.
+In these studies, the default Antares option to use is the "Economy" simulation mode.
+
+
+# Data organization
+
+In Antares, all input and output data regarding a given study are located within a folder named after the study
+and which should preferably be stored within a dedicated library of studies
+(for instance: `C/.../A\_name\_for\_an\_Antares\_lib/Study-number-one`).
+
+The software has been designed so that all input data may be handled (initialized, updated, deleted) through
+the simulator's GUI. Likewise, all results in the output data can be displayed and analyzed within the simulator:
+its standard GUI is actually meant to be able to provide, on a stand-alone basis, all the features required to access
+input and output in a user-friendly way.
+
+In addition to that, the Antares simulator may come [3] with or without functional extensions that provide additional
+ways to handle input and output data.
+
+These extensions take the form of companion applications whose documentation is independent of that of the main simulator.
+For information regarding these tools (*Antares Data Organizer*, *AntaresViz* R packages, …) please refer to
+the specific relevant documents.
+
+Besides, a point of notice is that most of Antares files belong to either ".txt" or ".csv" type:
+as an alternative to the standard GUI, they can therefore be viewed and updated by many applications
+(Windows Notepad, Excel, etc.). However, this is not recommended since handling data this way may result in fatal
+data corruption (e.g. as a consequence of accidental insertion of special characters).
+
+Direct access to input or output data files should therefore be reserved to experienced users.
+
+The input data contained in the study folder describe the whole state of development of the interconnected power system
+(namely: grid, load and generating plants of every kind) for a given future year.
+
+As already stated, all of these data may be reviewed, updated, deleted through the GUI, whose commands and windows
+are described in Sections 3 and 4.
+
+Once the input data is ready for calculation purposes, an Antares session may start and involve any or all of
+the following steps: historical time-series analysis, stochastic times-series generation, (draft) adequacy simulation,
+(full) adequacy simulation and economic simulation.
+
+The results of the session are stored within the output section of the study folder.
+The results obtained in the different sessions are stored side by side and tagged.
+The identification tag has two components: a user-defined session name and the time at which the session was launched.
+
+Particular cases are:
+
+1. The outputs of the Antares time-series analyzer are not printed in the general output files but kept within
+the input files structure (the reason being that they are input data for the Antares time - series generators).
+The associated data may nonetheless be accessed to be reviewed, updated and deleted at any time through the GUI.
+
+2. Some specific input data may be located outside the study folder: this is the case for the historical times-series
+to be processed by the time-series analyzer, which may be stored either within the "user" subfolder of the
+study or anywhere else (for instance, on a remote "historical data" or "Meteorological data" server).
+
+3. The study folder contains a specific subfolder named "user", whose status is particular: Antares is not allowed
+to delete any files within it (yet files may be updated on the user's requirement). As a consequence,
+the "user" subfolder is unaffected by the "clean study" command (see [Commands](#commands)).
+This subfolder is therefore a
+"private" user space, where all kinds of information can be stored without any kind of interference with Antares.
+Note that on using the "save as" command (described further below), the choice is given to make or not a copy of
+this subfolder.
+
+4. The times-series analyzer requires the use of a temporary directory in which intermediate files are created
+in the course of the analysis and deleted in the end, unless the user wishes to keep them for further examination.
+Its location is user-defined and should usually be the "user" subfolder if files are to be kept, otherwise any
+proper temporary space such as `C..../Temp`.
+
+5. If the interconnected system to study is large and/or if the computer is low on RAM, it is possible to run
+the Monte-Carlo adequacy simulator as well as the Monte-Carlo economic simulator in "Swap" mode.
+Swap is not handled by the computer's OS but by an Antares specific swap manager, whose operation requires
+the definition of a space where the software can store temporary files. This location is user-defined but
+should never be chosen within the study folder. `C/.../Temp` may typically be used but an external drive may
+be preferred if the computer is low on HDD.
+
+6. The outputs of the Antares Kirchhoff's constraints generator are not printed in the general output files
+but kept within the input files structure, the reason being that they are input data for the proper Antares simulation.
+The associated data (so-called binding constraints bearing in their name the prefix "@UTO-") may nonetheless
+be accessed to be reviewed, updated and deleted at any time through the GUI.
+
+# Commands
+
+The Antares GUI gives access to a general menu of commands whose name and meanings are described hereafter.
+
+## File
+
+- **New** Create a new empty study to be defined entirely from scratch (network topology, interconnections
+ratings, thermal power plants list, fuel costs, hydro inflows stats, wind speed stats, load profiles ,etc.)
+
+- **Open** Load in memory data located in a specified Antares study folder. Once loaded, these data may be reviewed,
+updated, deleted, and simulations may be performed. If "open" is performed while a study was already opened, the former study will be automatically closed.
+
+- **Quick Open** Same action as open, with a direct access to the recently opened studies
+
+- **Save** Save the current state of the study, if necessary by replacing original files by updated ones.
+After using this command the original study is no longer available, though some original files may be kept until
+the "clean" command is used (see "clean" command )
+
+- **Save as** Save the current state of the study under a different name and / or location.
+Using this command does not affect the original study. When "saving as", the user may choose whether
+he/she prefers to save input and output data or only input data. Note that Antares does not perform "autosave":
+Therefore, the actions performed on the input data during an Antares session (adding an interconnection,
+removing a plant, etc.) will have no effect until either "save" or "save as" have been used
+
+- **Export Map** Save a picture of the current map as a PNG, JPEG or SVG file. Default background color and
+storage location can be changed
+
+- **Open in Windows Explorer** Open the folder containing the study in a standard Windows Explorer window
+
+- **Clean** Remove all junk files that may remain in the study folder if the Antares session has involved lots
+of sequences such as "create area – add plant –save –rename area – save - rename plant ..."
+(Antares performs only low level auto-clean for the sake of GUI's efficiency)
+
+- **Close** Close the study folder. If no "save" or "save as" commands have been performed,
+all the modifications made on the input data during the Antares session will be ignored
+
+- **Quit** Exit from Antares
+
+## Edit
+
+- **Copy** Prepare a copy of elements selected on the current system map.
+The command is available only if the current active tab (whose name appears at the top line of the subcommand menu)
+is actually that of the System maps.
+
+- **Paste** Paste elements previously prepared for copy. The command is available only if the current
+active tab (whose name appears at the top line of the subcommand menu) is actually that of the System maps.
+Note that copy/paste may be performed either within the same map or between two different maps, attached to
+the same study or to different studies. To achieve that, launch one instance of Antares to open the "origin" study,
+select elements on the map and perform copy, launch another instance of Antares to open the destination study,
+perform paste. Copied elements are stored in an Antares clipboard that remains available for subsequent (multiple)
+paste as long as the system map is used as active window.
+
+- **Paste Special** Same as Paste, with a comprehensive set of parameterized actions (skip, merge, update, import)
+that can be defined for each data cluster copied in the clipboard. This gives a high level of flexibility for
+carrying out complex copy/paste actions.
+
+- **Reverse** The elements currently selected on the system map are no longer selected and are replaced by
+those not selected beforehand.
+
+- **Unselect All** Unselect all elements currently selected on the system map.
+
+- **Select All** Select all elements on the system map.
+
+## Input
+
+- **Name of the study** Give a reference name to the study. The default name is identical to that of
+the study's folder but the user may modify it. The default name of a new study is "no title"
+
+- **Author(s)** Set the study's author(s) name. Default value is "memory"
+
+The other "input" subcommands here below are used to move from one active window to another.
+Note that the availability of the __Wind__, __Solar__, and __Renewable__ subcommands depend on the advanced
+parameter *"Renewable Generation modeling"* described in [miscellaneous](#Miscellaneous).
+
+- **System Maps**
+- **Simulation**
+- **User's Notes**
+- **Load**
+- **Solar**
+- **Wind**
+- **Renewable**
+- **Hydro**
+- **Thermal**
+- **Misc. Gen.**
+- **Reserves/DSM**
+- **Links**
+- **Binding constraints**
+- **Economic opt.**
+
+## Output
+
+**\\**
+
+For each simulation run for which results have been generated, open a GUI for displaying results.
+Results may be viewed by multiple selections made on a number of parameters. Note that, since all simulations do
+not include all kinds of results (depending on user's choices), some parameters are not always visible.
+Parameters stand as follows:
+
+- Antares area (node)
+- Antares interconnection (link)
+- Class of Monte-Carlo results :
+ - Monte-Carlo synthesis (throughout all years simulated)
+ - Year-by-Year (detailed results for one specific year)
+- Category of Monte-Carlo results :
+ - General values (operating cost, generation breakdown, ...)
+ - Thermal plants (detailed thermal generation breakdown)
+ - Renewable generation (per cluster)
+ - Record years (for each Antares variable, identification of the Monte-Carlo year for which lowest and highest values were encountered)
+
+- Span of Monte-Carlo results :
+ - _Hourly_
+ - _Daily_
+ - _Weekly_
+ - _Monthly_
+ - _Annual_
+
+The interface provides a user-friendly way for the comparison of results between multiple simulations
+(e.g. "before" and "after" commissioning of a new plant or interconnection):
+
+- Use "new tab" button and choose a first set of simulation results
+- Use again "new tab" and choose a second set of simulation results
+
+The results window will be automatically split so as to show the two series of results in parallel.
+To the right of the "new tab" button, a symbolic (icon) button gives further means to compare results on a
+split window (average, differences, minimum, maximum and sum).
+
+Besides, when the simulation results contain the "year-by-year" class, it is possible to carry out an
+extraction query on any given specific variable (e.g. "monthly amounts of CO2 tons emitted") throughout
+all available years of simulation.
+
+The results of such queries are automatically stored within the output file structures, so as to
+be available at very short notice if they have to be examined later in another session (extractions may require
+a significant computer time when there are many Monte-Carlo years to process).
+
+- **Open in Windows Explorer** This command displays the list of available simulation results and allows
+browsing through the output files structure. The content of these files may be reviewed by tools such as Excel.
+File structures are detailed in [Output Files](#output-files).
+
+## Run
+
+- **Monte Carlo Simulation** Runs either an economy simulation, an adequacy simulation, or a "draft" simulation,
+depending on the values of the parameters set in the "simulation" active window (see [Active windows](#active-windows)).
+If hardware resources and simulation settings allow it, simulations benefit from full multi-threading
+(see [System requirements](#ystem-requirements))
+
+- **Time-series Generators** Runs any or all of the Antares stochastic time-series generators,
+depending on the values of the parameters set in the "simulation" active window (see [Active windows](#active-windows))
+
+- **Time-series Analyzer** Runs the Antares historical time-series analyzer.
+The parameters of this module are defined by a specific active window, available only on launching the analyzer
+(see [Time-series analysis and generation](#time-series-analysis-and-generation))
+
+- **Kirchhoff's Constraints Generator** Runs the Antares Kirchhoff's Constraints Generator.
+The parameters of this module are defined by a specific active window, available only on launching the KCG
+(see [Kirchhoff Constraints Generator](#kirchhoff-constraints-generator))
+
+## Configure
+
+- **Thematic Trimming** Opens a window in which a choice can be made regarding the individual output status of
+the variables defined in [Output Files](#output-files). Each computed variable can either be stored as part of
+the Output data to produce at the end of the simulation, or trimmed from it. In the latter case, the variable is regularly computed but the printing stage is skipped. Thematic Trimming does not reduce computation time but can bring some benefits on total runtime (smaller files to write). Thematic Trimming can save large amounts of storage space in simulations where only a handful of variables are of interest.
+
+- **Geographic Trimming** Opens an auxiliary window that allows multiple selection of the results to store at
+the end of a simulation: Choice of areas, interconnections, temporal aggregations (hourly, daily, etc.).
+Note that in addition to this feature, alternative access to the function is available
+(see [Active windows](#active-windows), "output profile"). Geographic Trimming does not reduce actual computation
+time but can bring some benefits on total runtime (fewer files to write). Geographic Trimming can save large
+amounts of storage space in simulations where only a few Areas and Links are of interest.
+
+- **Regional Districts** Allows selecting a set of areas to bundle them together in a "district".
+These are used in the course of simulations to aggregate results over several areas.
+They can be given almost any name (a "@" prefix is automatically added by Antares).
+Bypassing the GUI is possible (see [Miscellaneous](#miscellaneous)).
+
+- **MC Scenario builder** For each Monte-Carlo year of the simulation defined in the "Simulation" window,
+this command allows to state, for each kind of time-series, whether it should be randomly drawn from
+the available set (be it ready-made or Antares-generated)_ _ **OR** _ _should take a user-defined value
+(in the former case, the default "rand" value should be kept; in the latter, the value should be the reference number of the time-series to use). Multiple simulation profiles can be defined and archived. The default active profile gives the "rand" status for all time-series in all areas (full probabilistic simulation).
+
+- **MC Scenario playlist** For each Monte-Carlo year of the simulation defined in the "Simulation" active window,
+this command allows to state whether a MC year prepared for the simulation should be actually simulated or not.
+This feature allows, for instance, to refine a previous simulation by excluding a small number of "raw" MC years
+whose detailed analysis may have shown that they were not physically realistic. A different typical use consists
+in replaying only a small number of years of specific interest (for instance, years in the course of which Min or Max
+values of a given variable were encountered in a previous simulation).
+
+- **Optimization preferences** Defines a set of options related to the optimization core used in the simulations.
+The set of preferences is study-specific; it can be changed at any time and saved along with study data.
+Options refer to objects (binding constraints, etc.) that are presented in subsequent sections of this document.
+The values set in this menu overlay the local parameters but do not change their value: for instance, if the LOCAL
+parameter "set to infinite" is activated for some interconnections, and if the GLOBAL preference regarding transmission
+capacities is "set to null", the simulation will be carried out as if there were no longer any grid BUT the local
+values will remain untouched. If the preference is afterwards set to "local values", the interconnections will be
+given back their regular capacities (infinite for those being set on "set to infinite").
+
+ - _Binding constraints (include / ignore)_
+ - _Hurdle costs (include / ignore)_
+ - _Transmission capacities (local values / set to null / set to infinite)_
+ - _Min Up/down time of thermal plants (include / ignore)_
+ - _Day-ahead reserve (include / ignore)_
+ - _Primary reserve (include / ignore)_
+ - _Strategic reserve (include / ignore)_
+ - _Spinning reserve (include / ignore)_
+ - _Export mps (false/true)_
+ - _Simplex optimization range # 4_ _(day / week)_
+ - _Unfeasible problems behavior (Error Dry/ Error Verbose/ Warning Dry/ Warning Verbose_
+
+- **Advanced parameters** Advanced Parameters allow to adjust the simulation behavior regarding issues
+that are more numerical than physical. The set of parameters is study-specific and can be updated at any time.
+
+ - Seeds for random number generation
+ - Time-series draws (MC scenario builder)
+ - Wind time-series generation
+ - Solar time-series generation
+ - Hydro time - series generation
+ - Load time - series generation
+ - Thermal time-series generation
+ - Noise on thermal plants costs
+ - Noise on unsupplied energy costs
+ - Noise on spilled energy costs
+ - Noise on virtual hydro cost
+ - Initial hydro reservoir levels
+ - Spatial time-series correlation
+ - Numeric Quality : load `[standard | high]`
+ - Numeric Quality : wind `[standard | high]`
+ - Numeric Quality : solar `[standard | high]`
+ - Other preferences
+ - Reservoir Level Initialization `[cold start | hot start]`
+ - Hydro Pricing mode `[fast|accurate]`
+ - Power fluctuations `[free modulations | minimize excursions | minimize ramping]`
+ - Shedding policy `[shave peaks | minimize duration]`
+ - District marginal prices : `[average | weighed]`
+ - Day-ahead reserve management `[global | local]`
+ - Unit commitment mode `[fast | accurate]`
+ - Simulation cores `[minimum | low | medium | high | maximum]`
+ - Renewable Generation modeling `[aggregated | cluster]`
+
+## Tools
+
+- **Study manager** Launches the "study manager" external package (Please refer to dedicated documentation
+for this package)
+
+- **Resources monitor** Indicates the amounts of RAM and disk space currently used and those required for a simulation
+in the available modes (see [System requirements](#ystem-requirements)).
+Note that the "disk requirement" amount does not include the footprint of the specific "mps" files that may have
+to be written aside from the regular output (see previous § "optimization preferences").
+Besides, the resources monitor shows the number of CPU cores available on the machine Antares is running on.
+
+- **Configure the swap folder** Defines the location that will be used by Antares to store the temporary files of
+the MC simulators when the swap mode is activated (this location may also be used by Antares
+GUI when handling large studies). The default setting is the system temporary folder
+
+## Window
+
+- **Toggle full window** Uses the whole window for display
+
+- **Inspector** Opens a window that gives general information on the study and allow quick browsing
+through various area- or interconnection-related parameters. The Inspector window displays the content of the
+Antares clipboard, e.g. areas and interconnections selected on the current study map. If the "Geographic Trimming"
+option of the general simulation dashboard has the value "custom", the filtering parameters can be defined within
+the Inspector window. Besides, areas currently selected, displayed in the Inspector window,
+can be bundled into an "output district" by using the Configure/district command previously described
+
+- **Log viewer** Displays the log files regarding every Antares session performed on the study
+
+## Active windows
+
+Data can be reviewed, updated, deleted by selecting different possible active windows whose list and content
+are described hereafter. On launching Antares, the default active window is "System Maps".
+
+### System Maps
+
+This window is used to define the general structure of the system, i.e. the list of areas and that of the interconnections. Only the area's names, location and the topology of the grid are defined at this stage. Different colors may be assigned to different areas. These colors may later be used as sorting options in most windows. They are useful to edit data in a fashion that has a geographic meaning (which the lexicographic order may not have). This window displays copy/paste/select all icons equivalent to the relevant EDIT menu commands.
+
+The top left side of the window shows a "mouse status" field with three icons. These icons (one for nodes, one for links and one for binding constraints) indicate whether a selection made on the map with the mouse will involve or not the related elements. When a copy/paste action is considered, this allows for instance to copy any combination of nodes, links and binding constraints. Status can be changed by toggling the icons. Default is "on" for the three icons. Two other purely graphic icons/buttons (no action on data) allow respectively to center the map on a given set of (x , y) coordinates, and to prune the "empty" space around the current map. Multiple additional maps may be defined by using the cross-shaped button located top right. A detailed presentation of all system map editor features can be found in the document "System Map Editor Reference Guide".
+
+### Simulation
+
+The main simulation window is divided up in two parts. On the left side are the general parameters while the right side is devoted to the time-series management.
+
+These two parts are detailed hereafter.
+
+#### __LEFT PART: General parameters__
+
+- **Simulation**
+
+ - _Mode:_ Economy, Adequacy, Draft [5]
+ - _First day:_ First day of the simulation (e.g. 8 for a simulation beginning on the second week of the first
+ month of the year)
+ - _Last day:_ Last day of the simulation (e.g. 28 for a simulation ending on the fourth week of the first month
+ of the year) [6]
+
+- **Calendar**
+
+ - _Horizon:_ Reference year (static tag, not used in the calculations)
+
+ - _Year:_ Actual month by which the Time-series begin (Jan to Dec, Oct to Sep, etc.)
+
+ - _Leap Year:_ (Yes/No) indicates whether February has 28 or 29 days
+
+ - _Week:_ In economy or adequacy simulations, indicates the frame (Mon- Sun, Sat-Fri, etc.) to use for
+ the edition of weekly results
+
+ - _1st January:_ First day of the year (Mon, Tue, etc.)
+
+- **Monte-Carlo scenarios**
+
+ - _Number:_ Number of MC years that should be prepared for the simulation (not always the same as the
+ Number of MC years actually simulated, see "selection mode" below)
+
+ - _Building mode_:
+ - **Automatic** For all years to simulate, all time-series will be drawn at random
+ - **Custom** The simulation will be carried out on a mix of deterministic and probabilistic conditions,
+ with some time-series randomly drawn and others set to user-defined values. This option allows setting
+ up detailed "what if" simulations that may help to understand the phenomena at work and quantify various kinds of risk indicators. To set up the simulation profile, choose in the main menu: Configure/ MC scenario builder
+ - **Derated** All time-series will be replaced by their general average and the number of MC years
+ is set to 1. If the TS are ready-made or Antares-generated but are not to be stored in the INPUT folder,
+ no time-series will be written over the original ones (if any). If the time-series are built by Antares
+ and if it is specified that they should be stored in the INPUT, a single average-out time series will be stored
+ instead of the whole set.
+
+ - _Selection mode_:
+ - **Automatic** All prepared MC years will actually be simulated.
+
+ - **Custom** The years to simulate are defined in a list. To set up this list, choose in the main menu:
+ Configure/ MC scenario playlist [7].
+
+- **Output profile**
+
+ - Simulation synthesis:
+ - **True** Synthetic results will be stored in a directory:
+ `Study_name/OUTPUT/simu_tag/Economy/mc-all`
+ - **False** No general synthesis will be printed out
+
+ - Year-by-Year:
+ - **False** No individual results will be printed out
+ - **True** For each simulated year, detailed results will be printed out in an individual directory [8]:
+ `Study_name/OUTPUT/simu_tag/Economy/mc-i-number
+
+ - Geographic Trimming:
+ - **None** Storage of results for all areas, geographic districts, interconnections as well as all time spans
+ (hourly, daily, etc.)
+ - **Custom** Storage of the results selected with the "Geographic Trimming" command of the "Configure"
+ option available in the main menu.
+ Filters on areas, interconnections and time spans may also be defined as follows:
+ - On the map, select area(s) and/or interconnection(s)
+ - Open the inspector module (Main menu, Windows)
+ - Set adequate parameters in the "output print status" group
+
+ - Thematic Trimming:
+ - **None** Storage, for the geographic selection defined previously,
+ of all variables defined in [Output Files](#output-files) for Areas and Links.
+ - **Custom** Storage, for the geographic selection defined previously, of the variables selected with
+ the "Thematic Trimming" command of the "Configure" option available in the main menu.
+
+ - MC Scenarios:
+ - **False** No storage of the time-series numbers (either randomly drawn or user-defined) used to
+ set up the simulation
+ - **True** A specific OUTPUT folder will be created to store all the time-series numbers drawn when
+ - preparing the MC years.
+
+#### RIGHT PART: Time-series management
+
+For the different kinds of time-series that Antares manages in a non-deterministic way (load, thermal generation, hydro power, wind power, solar power or renewable depending on the option chosen):
+
+1. **Choice of the kind of time-series to use**
+Either « ready-made » or «stochastic » (i.e. Antares-generated), defined by setting the value to either "on" or "off"
+
+2. **For stochastic TS only**:
+ - **Number** Number of TS to generate
+
+ - **Refresh** (Yes /No) ndicates whether a periodic renewal of TS should be performed or not
+
+ - **Refresh span** Number of MC years at the end of which the renewal will be performed (if so required)
+
+ - **Seasonal correlation** ("monthly" or "annual") Indicates whether the spatial correlation matrices to use are defined month by month or if a single annual matrix for the whole year should rather be used (see [Time-series analysis and generation](#time-series-analysis-and-generation))
+
+ - **Store in input**
+ - **Yes** the generated time-series will be stored in the INPUT in replacement of the original ones (wherever they may come from)
+ - No: the original time-series will be kept as they were
+
+ - **Store in output**
+ - **Yes**: the generated times-series will be stored as part of the simulation results
+ - **No**: no storage of the generated time-series in the results directories
+
+3. **General rules for building up the MC years**
+ - **Intra-modal**:
+ - **Yes** For each mode, the same number should be used for all locations (or 1 where there is only one TS), but this number may differ from one mode to another. For instance, solar power TS = 12 for all areas, while wind power TS number = 7 for all areas.
+ - **No** Independent draws
+ - **Inter-modal**:
+ - **Yes** For all modes, the same number should be used but may depend on the location (for instance, solar and wind power TS = 3 for area 1, 8 for area 2, 4 for area 3, etc.)
+ - **No** Independent draws
+
+A full meteorological correlation (for each MC year, one single number for all modes and areas) is, from a theoretical standpoint, accessible by activating "intra-modal" and " inter-modal" for all but the "thermal" kind of time-series. The availability of an underlying comprehensive multi-dimensional Meteorological data base of ready-made time-series is the crux of the matter when it comes to using this configuration.
+
+### User's Notes
+
+A built-in notepad for recording comments regarding the study. Such comments typically help to track successive input data updates (upgrading such interconnection, removing such plant, etc.). Another simple use is to register what has been stored in the "user" subfolder and why. Such notes may prove useful to sort and interpret the results of multiple simulations carried out at different times on various configurations of the power system.
+
+### Load
+
+This window is used to handle all input data regarding load. In Antares load should include transmission losses. It should preferably not include the power absorbed by pumped storage power plants. If it does, the user should neither use the "PSP" array (see window "Misc. Gen") nor the explicit modeling of PSP plants
+
+The user may pick any area appearing in the list and is then given access to different tabs:
+
+- The "time-series" tab display the "ready-made" 8760-hour time-series available for simulation purposes. These data may come from any origin outside Antares, or be data formerly generated by the Antares time-series stochastic generator, stored as input data on the user's request. Different ways to update data are :
+
+ - direct typing
+
+ - copy/paste a selected field to/from the clipboard
+
+ - load/save all the time-series from/to a file (usually located in the "user" subfolder)
+
+ - Apply different functions (+,-, \*, /,etc.) to the existing (possibly filtered) values
+ (e.g. simulate a 2% growth rate by choosing "multiply-all-by-1.02")
+
+ - Handle the whole (unfiltered) existing dataset to either
+
+ - Change the number of columns (function name: resize)
+ - Adjust the values associated with the current first day of the year (function name: shift rows)
+
+ Versatile "Filter" functions allow quick access to user-specified sections of data
+(e.g. display only the load expected in the Wednesdays of January, at 09:00, for time-series #12 to #19). Hourly load is expressed in round numbers and in MW. If a smaller unit has to be used, the user should define accordingly ALL the data of the study (size of thermal plants, interconnection capacities, etc.)
+
+ - Note that:
+
+ - If the "intra-modal correlated draw" option has not been selected in the_ **simulation** _window,
+ MC adequacy or economy simulations can take place even if the number of time-series is not the same
+ in all areas (e.g. 2 , 5 , 1 , 45 ,...)
+ - If the "intra-modal correlated draws" option has been selected in the_ **simulation** _window,
+ every area should have either one single time-series or the same given number (e.g. 25 , 25 , 1 , 25...)
+
+ - The "spatial correlation" tab gives access to the inter-area correlation matrices that will be used
+ by the stochastic generator if it is activated. Different sub-tabs are available for the definition of 12 monthly
+ correlation matrices and of an overall annual correlation matrix.
+
+ A matrix A must meet three conditions to be a valid correlation matrix:
+
+ $$\forall i,\ \forall j,\ {A_{ii} = 100; -100 \le A_{ij} \le 100}; A\ symmetric; A\ positive\ semi\mbox{-}definite$$
+
+ When given invalid matrices, the TS generator emits an infeasibility diagnosis
+
+ - The "local data" tab is used to set the parameters of the stochastic generator.
+ These parameters are presented in four sub-tabs whose content is presented in
+ [Time-series analysis and generation](#time-series-analysis-and-generation).
+
+ - The "digest" tab displays for all areas a short account of the local data
+
+### Thermal
+
+This window is used to handle all input data regarding thermal dispatchable power.
+
+The user may pick any area appearing in the area list and is then given access to the list of thermal plants
+clusters defined for the area (e.g. "CCG 300 MW", "coal 600", etc.). Once a given cluster has been selected,
+a choice can be made between different tabs:
+
+- The "time-series" tab displays the "ready-made" 8760-hour time-series available for simulation purposes.
+These data may come from any origin outside Antares, or be data formerly generated by the Antares time-series
+stochastic generator, stored as input data on the user's request. Different ways to update data are :
+
+ - direct typing
+ - copy/paste a selected field to/from the clipboard
+ - load/save all the time-series from/to a file (usually located in the "user" subfolder)
+ - Apply different functions (+,-, \*, /,etc.) to the existing (possibly filtered) values (e.g. simulate a
+ 2% growth rate by choosing "multiply-all-by-1.02")
+ - Handle the whole (unfiltered) existing dataset to either
+
+ - Change the number of columns (function name: resize)
+ - Adjust the values associated with the current first day of the year (function name: shift rows)
+
+ Versatile "Filter" functions allow quick access to user-specified sections of data (e.g. display only
+the generation expected on Sundays at midnight, for all time-series).
+
+ Hourly thermal generation is expressed in round numbers and in MW. If a smaller unit has to be used, the user should define accordingly ALL the data of the study (Wind generation, interconnection capacities, load, hydro generation, solar, etc.)
+
+ - Note that:
+
+ - If the "intra-modal correlated draws" option has not been selected in the_ **simulation**_window,
+ MC adequacy or economy simulations can take place even if the number of time-series is not the same in all
+ areas (e.g. 2, 5, 1, 45,etc.)
+
+ - If the "intra-modal correlated draws" option has been selected in the_ **simulation**_window,
+ every area should have either one single time-series or the same given number (e.g. 25, 25, 1, 25, etc.).
+ Note that, unlike the other time-series (load, hydro, etc.), which depend on meteorological conditions and
+ are therefore inter-area-correlated, the thermal plants time-series should usually be considered as uncorrelated.
+ Using the "correlated draws" feature makes sense only in the event of having to play predefined scenarios
+ (outside regular MC scope)
+
+
+- The "TS generator" tab is used to set the parameters of the stochastic generator.
+These parameters are defined at the daily scale and are namely, for each day: the average duration of
+forced outages (beginning on that day), the forced outage rate, the duration of planned outages (beginning on that day),
+the planned outage rate, planned outages minimum and maximum numbers.
+Durations are expressed in days and rates belong to [0 , 1].
+
+
+- The "Common" tab is used to define the cluster's techno-economic characteristics :
+
+ - _Name_
+ - _Fuel used_
+ - _Location (Area)_
+ - _Activity status_
+ - false: not yet commissioned, moth-balled, etc.
+ - true : the plant may generate
+ - _Number of units_
+ - _Nominal capacity_
+ - _Full Must-run status_
+ - false: above a partial "must-run level" (that may exist or not, see infra) plants
+ will be dispatched on the basis of their market bids.
+ - true: plants will generate at their maximum capacity, regardless of market conditions
+ - _Minimum stable power (MW)_
+ - _Minimum Up time (hours)_
+ - _Minimum Down time (hours)_
+ - _Default contribution to the spinning reserve (% of nominal capacity)_
+ - _CO2 tons emitted per electric MWh_
+ - _Marginal operating cost (€/MWh)_
+ - _Fixed cost (No-Load heat cost) (€ / hour of operation )_
+ - _Start-up cost (€/start-up)_
+ - _Market bid (€/MWh)_
+ - _Random spread on the market bid (€/MWh)_
+ - _Seasonal marginal cost variations (gas more expensive in winter, ...)_
+ - _Seasonal market bid modulations (assets costs charging strategy )_
+ - _Nominal capacity modulations (seasonal thermodynamic efficiencies, special over-generation allowances, etc.). These modulations are taken into account during the generation of available power time-series_
+ - _Minimal generation commitment (partial must-run level) set for the cluster_
+
+ - _Note that:_
+
+ - The **optimal dispatch plan** as well as **locational marginal prices** are based on **market bids**,
+ while the assessment of the **operating costs** associated with this optimum are based on **cost parameters**.
+ (In standard "perfect" market modeling, there is no difference of approaches because market
+ bids are equal to marginal costs)
+
+### Hydro
+
+This section of the GUI is meant to handle all input data regarding hydro power,
+as well as any other kind of energy storage system of any size (from a small battery to a large
+conventional hydro-storage reservoir with or without pumping facilities, etc.): Hydro power being
+historically the first and largest form of power storage, it stood to reason that it should play in
+Antares the role of a "generic template" for all forms of storable power. This versatility, however,
+comes at the price of a comparatively more complex data organization than for other objects,
+which explains the comparatively long length of this chapter.
+
+In the main Window, the user may pick any area appearing in the list and is then given access to different tabs:
+
+- The "time-series" tab displays the "ready-made" time-series already available for simulation purposes. There are two categories of time-series (displayed in two different subtabs): the Run of River (ROR) time-series on the one hand and the Storage power (SP) time-series on the other hand.
+
+ ROR time-series are defined at the hourly scale; each of the 8760 values represents the ROR power expected at a given hour, expressed in round number and in MW. The SP time-series are defined at the daily scale; each of the 365 values represents an overall SP energy expected in the day, expressed in round number and in MWh. These natural inflows are considered to be storable into a reservoir for later use.
+
+ Both types of data may come from any origin outside Antares, or may have been formerly generated by the Antares time-series stochastic generator and stored as input data on the user's request. Different ways to update data are:
+
+ - direct typing
+ - copy/paste a selected field to/from the clipboard
+ - load/save all the time-series from/to a file (usually located in the "user" subfolder)
+ - Apply different functions (+,-, \*, /,etc.) to the existing (possibly filtered) values
+ (e.g. simulate a 2% growth rate by choosing "multiply-all-by-1.02")
+ - Handle the whole (unfiltered) existing dataset to either
+
+ - Change the number of columns (function name: resize)
+ - Adjust the values associated with the current first day of the year (function name: shift rows)
+
+ - Note that:
+
+ - For a given area, the number of ROR time-series and SP times-series **must** be identical
+ - If the "intra-modal correlated draws" option was not selected in the **simulation** window,
+ MC adequacy or economy simulations can take place even if the number of hydro time-series is not the same
+ in all areas (e.g. 2 , 5 , 1 , 45 ,...)
+ - If the "intra-modal correlated draws" option was selected in the **simulation** window, every
+ area should have either one single time-series or the same given number (e.g. 25 , 25 , 1 , 25...)
+
+
+- _The "spatial correlation" tab gives access to an annual inter-area correlation matrix that will be used by the stochastic generator if it is activated. Correlations are expressed in percentages, hence to be valid this matrix must be symmetric, p.s.d, with a main diagonal of 100s and all terms lying between (-100 ,+100)_
+
+
+- _The "Allocation" tab gives access to an annual inter-area allocation matrix A(i,j) that may be used during a heuristic hydro pre-allocation process, regardless of whether the stochastic time-series generator is used or not. This matrix describes the weights that are given to the loads of areas (i) in the definition of the monthly and weekly hydro storage generation profiles of areas (j). The way this is done in detailed in [Miscellaneous](#miscellaneous)._
+
+
+- _The "local data" tab is used to set up the parameters of the stochastic generator_ **AND** _to define techno-economic characteristics of the hydro system that are used in Economy and Adequacy optimizations. For the purpose of versatility (use of the hydro section to model storage facilities quite different in size and nature), this "local tab" is itself divided up into four different subtabs whose list follows and which are further described:_
+
+ - _Inflow Structure_
+ - _Reservoir Levels and water value_
+ - _Daily Power and Energy Credits_
+ - _Management options_
+
+**Inflow Structure**
+
+This tab contains all the local parameters used for the stochastic generation of hydro time-series. These are namely:
+
+- The expectations, standard deviations, minimum and maximum values of monthly energies (expressed in MWh), monthly shares of Run of River within the overall hydro monthly inflow.
+- The average correlation between the energy of a month and that of the next month (inter-monthly correlation).
+- The average daily pattern of inflows within each month. Each day is given a relative "weight" in the month. If all days are given the same weight, daily energy time-series will be obtained by dividing the monthly energy in equal days. If not, the ratio between two daily energies will be equal to that of the daily weights in the pattern array.
+
+Overall hydro energy is broken down into two parts: Run of River- ROR and storage -STOR
+
+ROR energy has to be used on the spot, as it belongs to the general "must-run" energy category.
+
+STOR energy can be stored for use at a later time. The way how stored energy may actually be used depends
+on the options chosen in the "management options" Tab and of the values of the parameters defined in the other Tabs.
+
+**Reservoir Levels and Water Values**
+
+Reservoir levels (left side)
+
+On the left side are defined 365 values for the minimum, average and maximum levels set for the reservoir
+at the beginning of each day, expressed in percentage of the overall reservoir volume. The lower and upper level
+time-series form a pair of so-called lower and upper "reservoir rule curves"
+
+Depending on the set of parameters chosen in the "management options" Tab, these rule curves may be used in
+different ways in the course of both heuristic seasonal hydro pre-allocation process and subsequent weekly
+optimal hydro-thermal unit-commitment and dispatch process.
+
+Water values (right side)
+
+On the right side is a table of marginal values for the stored energy, which depends on the date (365 days) and
+of the reservoir level (101 round percentage values ranging from 0% to 100%). These values may have different origins;
+they theoretically should be obtained by a comprehensive (dual) stochastic dynamic programming study carried out over
+the whole dataset and dealing simultaneously with all reservoirs.
+
+Depending on the set options chosen in the "management options" Tab, these values may be used or not in the course of
+the weekly optimal hydro-thermal unit-commitment and dispatch process.
+
+**Daily Power and Energy Credits**
+
+Standard credits (Bottom part)
+
+The bottom part displays two daily time-series (365 values) defined for energy generation/storage
+(hydro turbines or hydro pumps). In each case, the first array defines the maximum power (generated or absorbed),
+and the second defines the maximum daily energy (either generated or stored).
+
+For the sake of clarity, maximum daily energies are expressed as a number of hours at maximum power.
+
+Credit modulation (Upper part)
+
+The upper part displays two level-dependent (101 round percentage values ranging from 0% to 100%) time-series
+of modulation coefficients defined for either generating or storing (pumping).
+
+These modulations, which can take any positive value, may (depending on the options chosen in the management
+options Tab) be used to increase (value >1) or to decrease (value <1) the standard credits defined previously
+for the maximum daily power and energies.
+
+**Management Options**
+
+This Tab is a general dashboard for the definition of how storage units, whatever their size or nature, should be managed.
+It includes 15 parameters (out of which 7 are booleans) presented hereafter:
+
+- "Follow load" (y|n): defines whether an "ideal" seasonal generation profile should somehow follow the load OR an
+"ideal" seasonal generation profile should remain as close as possible to the natural inflows
+(i.e. instant generation whenever possible)
+
+- "Inter-daily breakdown" and "Inter-monthly breakdown" : parameters used in the assessment, through a
+heuristic process, of an "ideal" seasonal generation profile, if the use of such a profile is required
+(the heuristic itself is presented in [Miscellaneous](#miscellaneous))
+
+- "Intra-daily modulation": parameter which represents, for the storage power, the maximum authorized value for
+the ratio of the daily peak to the average power generated throughout the day. This parameter is meant to allow
+simulating different hydro management strategies. Extreme cases are : 1 : generated power should be constant throughout
+the day 24 : use of the whole daily energy in one single hour is allowed
+
+- "Reservoir management" `y|n`: defines whether the storage should be explicitly modeled or not.
+
+ Choosing "No" implies that available data allow or require that, regardless of the reservoir characteristics:
+ - The whole amount of STOR energy of each month MUST be used during this month (no long-term storage)
+
+ - The actual daily generation should follow, during the month, an "ideal" profile defined by the heuristic defined in [Miscellaneous](#miscellaneous)
+
+ Choosing "Yes" implies that available data allow or require explicit modeling of the storage facility,
+regardless of whether a pre-allocation heuristic is used or not.
+
+- "Reservoir capacity": size of the storage facility, in MWh
+
+- "Initialize reservoir level on the 1st of": date at which the reservoir level should be initialized by a random draw. The "initial level" is assumed to follow a "beta" variable with expectation "average level", upper bound U=max level, lower bound L= min level, standard deviation = (1/3) (U-L)
+
+- "Use Heuristic Target" (y|n): defines whether an "ideal" seasonal generation profile should be heuristically determined or not.
+
+ Choosing "No" implies that available data allow or require that full confidence should be put in water values determined upstream (through [dual] stochastic dynamic programming) OR that there are no "natural inflows" to the storage facility (battery or PSP, etc.)
+
+ Choosing "Yes" implies that available data allow or require the definition of an "ideal" generation profile, that can be used to complement –or replace– the economic signal given by water values AND that there are "natural inflows" on which a generation heuristic can be based.
+
+- "Power-to-Level modulations (y|n)": defines whether the standard maximum daily energy and power credit should be or not multiplied by level-dependent modulation coefficients.
+
+- "Hard bounds on rule curves (y|n)": states whether, beyond the preliminary heuristic stage (if any), lower and upper reservoir rule curves should still be taken into account as constraints in the hydro-thermal unit commitment and dispatch problems.
+
+- "Use leeway (y|n)", lower bound L, upper bound U: states whether the heuristic hydro ideal target (**HIT**) should be followed exactly or not.
+
+ Choosing "No" implies that, in optimization problems, the hydro energy generated throughout the time interval will be subject to an equality constraint, which may include short-term pumping cycles independent of water value: sum{ 1,t,T} (hydro(t)) – sum{1,t,T} (r. pump(t))= **HIT*
+
+ Choosing "Yes", with bounds L and U, implies that, in optimization problems, the hydro energy generated throughout the time span will be subject to inequality constraints: L_*__HIT__ _<=sum{1,t,T} (hydro(t)) <= U\*_**HIT*
+
+ Independently, short- or long-term pumping may also take place if deemed profitable in the light of water values.
+
+ - "Use Water Value (y|n)": states whether the energy taken from / stored into the reservoir should be given the reference value defined in the ad hoc table OR should be given a zero value.
+
+ - "Pumping Efficiency Ratio": setting the value to r means that, for the purpose of storing 1 gravitational MWh, pumps will have to use (1/r) electrical MWh.
+
+### Wind
+
+This window is used to handle all input data regarding Wind power.
+This window is only accessible when the advanced parameter Renewable Generation modeling is set to "Aggregated".
+
+The user may pick any area appearing in the list and is then given access to different tabs:
+
+- The "time-series" tab display the "ready-made" 8760-hour time-series already available for simulation purposes. These data may come from any origin outside Antares, or be data formerly generated by the Antares time-series stochastic generator, stored as input data on user's request. Different ways to update data are :
+
+ - direct typing
+ - copy/paste a selected field to/from the clipboard
+ - load/save all the time-series from/to a file (usually located in the "user" subfolder)
+ - Apply different functions (+,-, \*, /,etc.) to the existing (possibly filtered) values (e.g. simulate a 2% growth rate by choosing "multiply-all-by-1.02")
+ - Handle the whole (unfiltered) existing dataset to either
+ - Change the number of columns (function name: resize)
+ - Adjust the values associated with the current first day of the year (function name: shift rows)
+
+ Versatile "Filter" functions allow quick access to user-specified sections of data (e.g. display only the wind generation expected between 17:00 and 21:00 in February, for time-series 1 to 100).
+
+ Hourly wind generation is expressed in round numbers and in MW. If a smaller unit has to be used, the user should define accordingly ALL the data of the study (size of thermal plants, interconnection capacities, load, etc.)
+
+ - Note that:
+
+ - If the "intra-modal correlated draws" option has not been selected in the **simulation** window, MC adequacy or economy simulations can take place even if the number of time-series is not the same in all areas (e.g. 2, 5, 1,45, ...)
+
+ - If the "intra-modal correlated draws" option has been selected in the **simulation** window, every area should have either one single time-series or the same given number (e.g. 25, 25, 1, 25, ...)
+
+- The "spatial correlation" tab gives access to the inter-area correlation matrices that will be used by the stochastic generator if it is activated. Different sub-tabs are available for the definition of 12 monthly correlation matrices and an overall annual correlation matrix.
+
+ A matrix A must meet three conditions to be a valid correlation matrix:
+
+ $$\forall i,\ \forall j,\ {A_{ii} = 100; -100 \le A_{ij} \le 100}; A\ symmetric; A\ positive\ semi\mbox{-}definite$$
+
+ When given invalid matrices, the TS generator emits an infeasibility diagnosis
+
+- The "local data" tab is used to set the parameters of the stochastic generator. These parameters are presented in four subtabs whose content is presented in [Time-series analysis and generation](#time-series-analysis-and-generation).
+
+- The "digest" tab displays for all areas a short account of the local data
+
+
+### Solar
+
+_This window is used to handle all input data regarding Solar power. Both thermal solar generation and PV solar generation are assumed to be bundled in this data section._
+_This window is only accessible when the advanced parameter Renewable Generation modeling is set to "aggregated”._
+
+_The user may pick any area appearing in the list and is then given access to different tabs:_
+
+- _The "time-series" tab display the "ready-made" 8760-hour time-series available for simulation purposes. These data may come from any origin outside Antares, or be data formerly generated by the Antares time-series stochastic generator, stored as input data on the user's request. Different ways to update data are :_
+
+ - _direct typing_
+ - _copy/paste a selected field to/from the clipboard_
+ - _load/save all the time-series from/to a file (usually located in the "user" subfolder)_
+ - _Apply different functions (+,-, \*, /,etc.) to the existing (possibly filtered) values (e.g. simulate a 2% growth rate by choosing "multiply-all-by-1.02")_
+ - _Handle the whole (unfiltered) existing dataset to either_
+
+ - _Change the number of columns (function name: resize)_
+ - _Adjust the values associated with the current first day of the year (function name: shift rows)_
+
+ _Versatile "Filter" functions allow quick access to user-specified sections of data (e.g. display only the solar power expected in August at noon, for all time-series)._
+
+ _Hourly solar power is expressed in round numbers and in MW. If a smaller unit has to be used, the user should define accordingly ALL the data of the study (size of thermal plants, interconnection capacities, etc.)_
+
+ - _Note that:_
+
+ - _If the "intra-modal correlated draws" option was not selected in the_ **simulation** _window, MC adequacy or economy simulations can take place even if the number of time-series is not the same in all areas (e.g. 2 , 5 , 1 , 45 ,...)_
+
+ - _If the "intra-modal correlated draws" option was selected in the_ **simulation** _window, every area should have either one single time-series or the same given number (e.g. 25 , 25 , 1 , 25...)_
+
+- _The "spatial correlation" tab gives access to the inter-area correlation matrices that will be used by the stochastic generator if it is activated. Different sub-tabs are available for the definition of 12 monthly correlation matrices and of an overall annual correlation matrix._
+
+ A matrix A must meet three conditions to be a valid correlation matrix:
+
+ $$\forall i,\ \forall j,\ {A_{ii} = 100; -100 \le A_{ij} \le 100}; A\ symmetric; A\ positive\ semi\mbox{-}definite$$
+
+ When given invalid matrices, the TS generator emits an infeasibility diagnosis
+
+
+- _The "local data" tab is used to set the parameters of the stochastic generator. These parameters are presented in four subtabs whose content is presented in [Time-series analysis and generation](#time-series-analysis-and-generation)._
+
+- _The "digest" tab displays for all areas a short account of the local data_
+
+
+### Renewable
+
+_This window is used to handle all input data regarding renewable generation._
+_This window is only accessible when the advanced parameter Renewable Generation modeling is set to "cluster” (default value)._
+
+_The user may pick any area appearing in the area list and is then given access to the list of renewable clusters defined for the area (e.g. "Onshore Wind Farm 200MW", "Solar Rooftop 50MW", etc.). Once a given cluster has been selected, a choice can be made between different tabs:_
+
+- _The "time-series" tab displays the "ready-made" 8760-hour time-series available for simulation purposes. These data may come from any origin outside Antares, or be data formerly generated by the Antares time-series stochastic generator, stored as input data on the user's request. Different ways to update data are :_
+
+ - _direct typing_
+ - _copy/paste a selected field to/from the clipboard_
+ - _load/save all the time-series from/to a file (usually located in the "user" subfolder)_
+ - _Apply different functions (+,-, \*, /,etc.) to the existing (possibly filtered) values (e.g. simulate a 2% growth rate by choosing "multiply-all-by-1.02")_
+ - _Handle the whole (unfiltered) existing dataset to either_
+
+ - _Change the number of columns (function name: resize)_
+ - _Adjust the values associated with the current first day of the year (function name: shift rows)_
+
+ _Versatile "Filter" functions allow quick access to user-specified sections of data (e.g. display only the generation expected on Sundays at midnight, for all time-series)._
+
+ _Hourly thermal generation is expressed in round numbers and in MW. If a smaller unit has to be used, the user should define accordingly ALL the data of the study (Wind generation, interconnection capacities, load, hydro generation, solar, etc.)_
+
+ - _Note that:_
+
+ - _If the "intra-modal correlated draws" option has not been selected in the_ **simulation** _window, MC adequacy or economy simulations can take place even if the number of time-series is not the same in all areas (e.g. 2, 5, 1, 45,etc.)_
+
+ - _If the "intra-modal correlated draws" option has been selected in the_ **simulation** _window, every area should have either one single time-series or the same given number (e.g. 25, 25, 1, 25, etc.). Note that, unlike the other time-series (load, hydro, etc.), which depend on meteorological conditions and are therefore inter-area-correlated, the thermal plants time-series should usually be considered as uncorrelated. Using the "correlated draws" feature makes sense only in the event of having to play predefined scenarios (outside regular MC scope)_
+
+
+- _The "TS generator" tab is not accessible for this version._
+
+
+- _The "Common" tab is used to define the cluster's techno-economic characteristics :_
+
+ - _Name_
+ - _Group: The group can be any one of the following: Wind Onshore, Wind Offshore, Solar Thermal, Solar PV, Solar Rooftop, Other RES 1, Other RES 2, Other RES 3, or Other RES 4. If not specified, the renewable cluster will be part of the group Other RES 1._
+ - _Location (Area)_
+ - _Timeseries mode:_
+ - _Power generation means that the unit of the timeseries is in MW_
+ - _Production factor means that the unit of the timeseries is in p.u. (between 0 and 1, 1 meaning the full installed capacity)_
+ - _Activity status_
+ - _false: not yet commissioned, moth-balled, etc._
+ - _true: the cluster may generate_
+ - _Number of units_
+ - _Nominal capacity (in MW per unit)_
+
+
+### Misc. Gen.
+
+_This window is used to handle all input data regarding miscellaneous non dispatchable generation._
+
+_On picking any area in the primary list, the user gets direct access to all data regarding the area, which amount to_ **8** _ready-made 8760-hour time-series (expressed in MW):_
+
+- _CHP generation_
+
+- _Bio Mass generation_
+
+- _Bio-gas generation_
+
+- _Waste generation_
+
+- _Geothermal generation_
+
+- _Any other kind of non-dispatchable generation_
+
+- _A predefined time-series for the operation of Pumped Storage Power plants, if they are not explicitly modeled. A positive value is considered as an output (generating) to the grid, a negative value is an input (pumping) to the station._
+
+ _Note that the sum of the 8760 values must be negative, since the pumping to generating efficiency is lower than 1. The user may also use only the negative values (prescribed pumping), while transferring at the same time the matching generating credit on the regular hydro storage energy credit._
+
+- _ROW balance: the balance with the rest of the world. A negative value is an export to ROW, a positive value is an import from ROW. These values acts as boundary conditions for the model. Different ways to update data are:_
+
+ - _direct typing_
+ - _copy/paste a selected field to/from the clipboard_
+ - _load/save all the time-series from/to a file (usually located in the "user" subfolder)_
+ - _Apply different functions (+,-, \*, /,etc.) to the existing (possibly filtered) values (e.g. simulate a 2% growth rate by choosing "multiply-all-by-1.02")_
+ - _Handle the whole (unfiltered) existing dataset to either_
+
+ - _Change the number of columns (function name: resize)_
+ - _Adjust the values associated with the current first day of the year (function name: shift rows)_
+
+### Reserves / DSM
+
+_This window is used to handle all input data regarding reserves and the potential of "smart" load management (when not modeled using "fake" thermal dispatchable plants). On picking any area in the primary list, the user gets direct access to all data regarding the area, which amount to_ **four** _ready-made 8760-hour time-series (expressed in MW). The first two are used only in "draft" simulations, while the last two are available in either "adequacy" or "economy" simulations:_
+
+- _Primary reserve: must be provided whatever the circumstances, even at the price of some unsupplied energy (Draft simulations only)_
+
+- _Strategic reserve: sets a limit on the backup power that an area is supposed to be able to export to its neighbors. This reserve may represent an actual generation reserve, an energy constraint too complex to model by standard means (e.g. energy policy regarding special reservoirs) or can also be justified by simplifications made in grid modeling. (Draft simulations only)._
+
+- _Day-ahead reserve: power accounted for in setting up the optimal unit-commitment and schedule of the following day(s), which must consider possible forecasting errors or last-minute incidents. If the optimization range is of one day, the reserve will be actually seen as "day-ahead". If the optimization range is of one week, the need for reserve will be interpreted as "week-ahead". (Adequacy and Economy simulations)_
+
+- _DSM: power (decrease or increase) to add to the load. A negative value is a load decrease, a positive value is a load increase. Note that an efficient demand side management scheme may result in a negative overall sum (All simulation modes)._
+
+### Links
+
+_This window is used to handle all input data regarding the interconnections. On picking any interconnection in the primary list, the user gets direct access to all data regarding the link, which are five annual parameters and a set of eight ready-made 8760-hour time-series_
+
+_The five parameters, used in economy or adequacy simulations (not in draft), are namely:_
+
+- "_Hurdle cost": set by the user to state whether (linear) transmission fees should be taken into account or not in economy and adequacy simulations_
+- "_Transmission capacities": set by the user to state whether the capacities to consider are those indicated in 8760-hour arrays or if zero or infinite values should be used instead (actual values / set to zero / set to infinite)_
+- "_Asset type": set by the user to state whether the link is either an AC component (subject to Kirchhoff's laws), a DC component, or another type of asset_
+- "_Account for loop flows": set by the KCG9 to include (or not) passive loop flows in the formulation of the constraints enforcing Kirchhoff's laws_
+- "_Account for PST": set by the KCG to include (or not) the settings of phase-shifting transformers in the formulation of the constraints enforcing Kirchhoff's laws_
+
+_The eight 8760-hour times-series are:_
+
+- _NTC direct: the upstream-to-downstream capacity, in MW_
+
+- _NTC indirect: the downstream-to-upstream capacity, in MW_
+
+- _Hurdle cost direct: an upstream-to-downstream transmission fee, in €/MWh_
+
+- _Hurdle cost indirect: a downstream-to-upstream transmission fee, in €/MWh_
+
+- _Impedance: used in economy simulations to give a physical meaning to raw outputs, when no binding constraints have been defined to enforce Kirchhoff's laws (see "Output" section, variable "Flow Quad") OR used by the Kirchhoff's constraint generator to build up proper flow constraints (AC flow computed with the classical "DC approximation"). Since voltage levels are not explicitly defined and handled within Antares, all impedances are assumed to be scaled to some reference_ $$U_{ref}$$
+
+- _Loop flow: amount of power flowing circularly though the grid when all "nodes" are perfectly balanced (no import and no export). Such loop flows may be expected on any "simplified" grid in which large regions (or even countries) are modeled by a small number of "macro" nodes, and should accordingly be accounted for._
+
+- _PST min (denoted \\(Y^-\\) in [Kirchhoff Constraints Generator](#kirchhoff-constraints-generator)): lower bound of phase-shifting that can be reached by a PST installed on the link, if any (note : the effect of the active loop flow generated by the PST may be superimposed to that of the passive loop flow)_
+
+- _PST max (denoted \\(Y^+\\) in [Kirchhoff Constraints Generator](#kirchhoff-constraints-generator)): upper bound of phase-shifting that can be reached by a PST installed on the link, if any (note : the effect of the active loop flow generated by the PST may be superimposed to that of the passive loop flow)_
+
+_For the sake of simplicity and homogeneity with the convention used for impedance, PST settings are assumed to be expressed in_ $$rad/U^2_{ref}$$
+
+### Binding constraints
+
+_This section of the GUI is used to handle all data regarding special constraints that one may wish to include in the formulation of the optimization problems to solve._
+
+_The set of tabs described hereafter provides for that purpose all the means required to define arbitrary linear constraints on any subset of continuous variables involved in the modeling of the power system._
+
+_Since no limitation is set on the number and content of the constraints that may be defined that way, it is the user's sole responsibility to make sure that these so-called "binding constraints" are realistic and meaningful, be it from a technical or economic standpoint._
+
+_A typical situation in which this feature proves useful is, for instance, encountered when data at hand regarding the grid include an estimate of the impedances of the interconnections._
+
+_In such cases, assuming that:_
+
+- \\(Z_l\\) denotes the impedance of interconnections \\(l=1, L\\)
+- _A preliminary study of the graph modeling the grid has shown that it can be described by a set of independent meshes_ \\(c=1, C\\)_(cycle basis of the graph)_
+
+_Then the DC flow approximation may be implemented, for each time-step of the simulation, by a set of C binding constraints between AC flows \\(F_l\\):_
+
+$$ c= 1, ..., C : \sum_{i \in C}{sign(l,c)F_lZ_l = 0}$$
+
+_Note that such specific binding constraints can be automatically generated within Antares by using the auxiliary module "Kirchhoff's Constraints Generator" further described in [Kirchhoff Constraints Generator](#kirchhoff-constraints-generator)._
+
+_Aside from such sets of constraints, which may help to give realistic geographic patterns to the flows, completely different sets of constraints may be also defined, such as those set up by the market organization, which may define precise perimeters for valid commercial flows # 10._
+
+_More generally, Antares allows to define three categories of binding constraints between transmission flows and/or power generated from generating units:_
+
+- "_hourly" binding constraints, which are applied to instant power (transmitted and/or generated)_
+
+- "_daily" binding constraints, that are applied to daily energies. This class makes more sense for commercial modeling (say: imports and exports from/to such and such area should be comprised between such and such lower bound and upper bound). Daily binding constraints are also commonly used to model specific facilities, such as pumped storage units operated on a daily cycle_
+
+- "_weekly" binding constraints, that are applied to weekly energies. Like the previous ones, these constraints may be used to model commercial contracts or various phenomena, such as the operation of a pumped storage power plant operated on a weekly cycle._
+
+_The Binding Constraints section of the GUI involves six main tabs described hereafter:_
+
+- **TAB "summary"** _Creation, edition or removal of a binding constraint. A binding constraint is here defined by four macroscopic attributes that can be set by the edit command:_
+
+ - _Name (caption)_
+ - _Time-range (hourly, daily, weekly)_
+ - _Numerical type (equality, bounded above, below, on both sides)_
+ - _Status (active /enabled or inactive/disabled)_
+
+- **TAB "weights"** _Definition of the coefficients given to each flow variable or generation variable in the formulation of the constraints. Two sub-tabs make it possible to handle the coefficients associated with transmission assets (links) and those associated with generation assets (thermal clusters). In both cases:_
+
+ - _The lines of the tables show only the components (links or clusters) that are visible on the current map_
+ - _The columns of the tables show only the constraints that do not have non-zero weights attached to components that are nor visible on the current map_
+
+- **TAB "offsets"** _Definition of the time-lag (in hours) assigned to each flow variable or generation variable in the formulation of the constraints. Two sub-tabs make it possible to handle the offsets associated with transmission assets (links) and those associated with generation assets (thermal clusters). In both cases:_
+
+ - _The lines of the tables show only the components (links or clusters) that are visible on the current map_
+ - _The columns of the tables show only the constraints that do not have non-zero weights attached to components that are nor visible on the current map_
+
+- **TAB "="** _Definition of the right-hand side of equality constraints. This RHS has either 8760 values (hourly constraints) or 365 values (daily or weekly constraints). Depending on the range actually chosen for the simplex optimization (see section_ **Configure** _of the main menu), the weekly constraints RHS will either be represented by the sum of seven daily terms or by a set of seven daily terms (weekly constraint downgraded to daily status)._
+
+- **TAB ">"** _Definition of the right-hand side of "bounded below" and "bounded on both sides" inequality constraints. This RHS has either 8760 values (hourly constraints) or 365 values (daily or weekly constraints). Depending on the range actually chosen for the simplex optimization (see section_ **Configure** _of the main menu), the weekly constraints RHS will either be represented by the sum of seven daily terms or by a set of seven daily terms (weekly constraint downgraded to daily status)._
+
+- **TAB "<"** _Definition of the right-hand side of "bounded above" and "bounded on both sides" inequality constraints. This RHS has either 8760 values (hourly constraints) or 365 values (daily or weekly constraints). Depending on the range actually chosen for the simplex optimization (see section_ **Configure** _of the main menu), the weekly constraints RHS will either be represented by the sum of seven daily terms or by a set of seven daily terms (weekly constraint downgraded to daily status)._
+
+_When defining binding constraints between (hourly) power, daily or weekly (energy) flows, special attention should be paid to potential conflicts between them or with the "basic" problem constraints. Lack of caution may result in situations for which the optimization has no solution. Consider for instance a case in which three variables X1, X2, X3 (whatever they physical meaning) are involved in the following binding constraints:_
+
+$$X1 + X2 > 5$$
+
+$$X2 < -3$$
+
+$$X3 > 0$$
+
+$$X1 + X3 < 7$$
+
+_These commitments are obviously impossible to meet and, if the economic simulator is run on a dataset including such a set of constraints, it will produce an infeasibility diagnosis._
+
+_The advanced preference "Unfeasible Problems Behavior" gives to the user the ability to choose between four different strategies regarding these situations._
+
+### Economic Opt.
+
+_This window is used to set the value of a number of area-related parameters that, aside from the costs of each generating plant, define the optimal solution that Antares has to find in economic simulations. These parameters are namely, for each area of the system:_
+
+- _The value of the unsupplied energy (also commonly denoted Value Of Lost Load,VOLL) , in €/MWh. This value should usually be set much higher than the cost of the most expensive generating plant of the area_
+
+- _The random spread within which the nominal unsupplied energy value is assumed to vary_
+
+- _The value of the spilled energy, in € /MWh. This value reflects the specific penalty that should be added to the economic function for each wasted MWh, if any. Note that even if this value is set to zero no energy will be shed needlessly_
+
+- _The random spread within which the nominal unsupplied energy value is assumed to vary_
+
+- _Three parameters named "shedding status" and related to different kinds of generation. If the system cannot be balanced without shedding some generation, these parameters give control on how each kind of generation ("Non dispatchable power","Dispatchable hydropower" and "Other dispatchable generating plants") should contribute to the shedding. Depending on the value chosen for the status, the generation can or cannot be shed to find a solution to the load/generation balance problem. Note that enforcing a negative status for all types of plants may lead to simulations scenarios for which there are no mathematical solutions._
+
+_On running the economic simulator, such situations produce an infeasibility diagnosis._
+
+
+### Miscellaneous
+
+_In all previous windows showing Input data, the content can be filtered so as to reflect only items that are associated with Areas and Links defined as "visible" in a particular map. In that regard, binding constraints are considered as visible if and only if all of their non-zero weight associated objects are visible on the map._
+
+## Output files
+
+_The general file organization is the same for Economy, Adequacy and Draft simulations._
+
+- _Economy and Adequacy results may be displayed in the GUI ( "Output" in main menu)_
+- _Draft results are available only as flat .txt files. They can be viewed with "Tool /csv viewer" in the main menu (As well as any other files, they can also be accessed by Excel or suchlike)_
+
+**Economy:**
+
+| OUTPUT/Simu id/economy/mc-all/ | | | |
+|----------------------------------|---------------|-----------------|---------------------------------------|
+| |/grid/... | | contains a summary file "digest.txt" |
+| |/areas/name/...| | contains area-related results |
+| |/links / name/...| | contains interconnection-related results |
+| |/mc-ind /year_number| | |
+| | |/areas/name/...| contains area-related results|
+| | |/links/name/...| contains interconnection-related results|
+
+_("mc-all" files contain synthetic results over all years, "year-number" files contain results for a single year)_
+_The variables present in each file are detailed in the following sections._
+_In "Economy" simulations, all variables have a techno-economic meaning._
+
+**Adequacy:**
+
+| OUTPUT/Simu id/adequacy/mc-all/ | | | |
+|----------------------------------|---------------|-----------------|---------------------------------------|
+| |/grid/... | | contains a summary file "digest.txt" |
+| |/areas/name/...| | contains area-related results |
+| |/links / name/...| | contains interconnection-related results |
+| |/mc-ind /year_number| | |
+| | |/areas/name/...| contains area-related results|
+| | |/links/name/...| contains interconnection-related results|
+
+_("mc-all" files contain synthetic results over all years, "year-number" files contain results for a single year)_
+_The variables present in each file bear exactly the same name as in Economy simulations but do not have the same values._
+_The only variables that have a techno-economic meaning are the "Adequacy" indicators (unsupplied energy,LOLD,LOLP)_
+
+**Draft:**
+
+| OUTPUT/Simu id/adequacy-draft/mc-all/ | | |
+|----------------------------------|-------------------|-----------------------------------|
+| |/grid/... | contains a summary file "digest.txt" |
+| |/areas/name/...| contains area-related results |
+
+
+_("mc-all" files contains mostly synthetic results over all years; However, there is (for each area) a "mc-annual.txt" file that gives a short view of local results for each simulated year)_
+
+**IMPORTANT** _Adequacy and Economy files look the same but their content are specific_
+
+_In "Economy" and "Adequacy" simulations, the optimization ignores the "primary" and "strategic" reserves (however, it may include the [other] spinning and day-ahead reserves, depending on the settings made in "optimization preferences")._
+
+_In "Adequacy" simulations, all dispatchable thermal units are given the "must-run" status (hence, they will generate at Pmax, regardless of the demand). As a consequence the only variables that are actually meaningful are the adequacy indicators (unsupplied energy, LOLD,LOLP), that may depend on assumptions made regarding the economic values of Unsupplied and spilled energies, and on hurdle costs on interconnections._
+
+_As a consequence, both "Adequacy" and "Economy" simulations yield the same values for the adequacy indicators under the following conditions: if hurdle costs on interconnections are higher than the difference between the maximum VOLL and the minimum VOLL assigned to the different areas of the system._
+
+_The files and their content are hereafter described._
+
+### Economy and Adequacy, area results [11]
+
+**15** _files resulting from the combination of the following attributes:_
+**[values | id | details] X [hourly | daily | weekly | monthly | annual]**
+
+- _The second attribute defines the time span over which the results are assessed: hourly detail, daily bundle, weekly bundle, monthly bundle, annual bundle._
+
+- _The first attribute defines the nature of the results presented in the file :_
+
+**Values** _Values of different variables (price, load, overall generation issued from coal, etc.), the list of which is common to all areas of the interconnected system. Files of type "values" have therefore the same size for all areas._
+_These results appear under the label "general values" in the output GUI_
+
+**details** _Values regarding the different dispatchable thermal generating plants of each area (e.g. "older 300 MW coal from the south coast"). The sizes of these files differ from one area to another._
+_These results appear under the label "thermal plants" in the output GUI_
+
+**id** _Identifier (number) of the Monte-Carlo years for which were observed the extreme values of the different variables presented in the « values » files_
+_These results appear under the label "record years" in the output GUI_
+
+_The area files that belong to the « values » class display_ **122** _fields corresponding to the expectation, standard deviation, minimal and maximal values of the variables whose list is given hereafter._
+
+| variables | description |
+|-----------|-------------|
+| OV.COST | Overall cost = operating cost + unsupplied cost+ spilled cost+ hydro cost |
+| OP.COST | Operating cost = Proportional costs + Non- proportional costs |
+| MRG. PRICE | LMP : overall economic effect of a local 1MW load increase |
+| CO2 EMIS. | Amount of CO2 emitted by all dispatchable thermal plants |
+| BALANCE | Overall Import/export balance of the area (positive value : export) |
+| ROW BAL | Import/export with areas outside the modeled system (positive value: import)12 |
+| PSP | User-defined settings for pumping and subsequent generating |
+| MISC. NDG | Miscellaneous non dispatchable generation |
+| LOAD | Demand (including DSM potential if relevant) |
+| H.ROR | Hydro generation, Run-of-river share |
+| WIND | Wind generation (only when using aggregated _Renewable generation modeling_)|
+| SOLAR | Solar generation (thermal and PV) (only when using aggregated _Renewable generation modeling_)|
+| NUCLEAR | Overall generation of nuclear clusters |
+| LIGNITE | Overall generation of dispatchable thermal clusters burning brown coal |
+| COAL | Overall generation of dispatchable thermal clusters burning hard coal |
+| GAS | Overall generation of dispatchable thermal clusters burning gas |
+| OIL | Overall generation of dispatchable thermal clusters using petroleum products |
+| MIX.FUEL | Overall gen. of disp. thermal clusters using a mix of the previous fuels |
+| MISC.DTG | Overall gen. of disp. thermal clusters using other fuels |
+| MISC.DTG 2 | Overall gen. of disp. thermal clusters using other fuels |
+| MISC.DTG 3 | Overall gen. of disp. thermal clusters using other fuels |
+| MISC.DTG 4 | Overall gen. of disp. thermal clusters using other fuels |
+| WIND OFFSHORE | Wind Offshore generation (only when using clustered _Renewable generation modeling_) |
+| WIND ONSHORE | Wind Onshore generation (only when using clustered _Renewable generation modeling_) |
+| SOLAR CONCRT. | Concentrated Solar Thermal generation (only when using clustered _Renewable generation modeling_) |
+| SOLAR PV | Solar Photovoltaic generation (only when using clustered _Renewable generation modeling_) |
+| SOLAR ROOFT | Rooftop Solar generation (only when using clustered _Renewable generation modeling_) |
+| RENW. 1 | Overall generation of other Renewable clusters (only when using clustered _Renewable generation modeling_) |
+| RENW. 2 | Overall generation of other Renewable clusters (only when using clustered _Renewable generation modeling_) |
+| RENW. 3 | Overall generation of other Renewable clusters (only when using clustered _Renewable generation modeling_) |
+| RENW. 4 | Overall generation of other Renewable clusters (only when using clustered _Renewable generation modeling_) |
+| H.STOR | Power generated from energy storage units (typically: Hydro reservoir) |
+| H.PUMP | Power absorbed by energy storage units (typically: PSP pumps consumption) |
+| H.LEV | Energy level remaining in storage units (percentage of reservoir size) |
+| H.INFL | External input to the energy storage units (typically: natural inflows) |
+| H.OVFL | Wasted natural inflow overflowing from an already full energy storage unit |
+| H.VAL | Marginal value of stored energy (typically: shadow water value) |
+| H.COST | Expenses /Income brought by energy storage actions (H.STOR,H.PUMP) |
+| UNSP. | ENRG Unsupplied energy: adequacy indicator (Expected Energy Not Served–EENS) |
+| SPIL. | ENRG Spilled energy (energy produced that cannot be used and has to be wasted) |
+| LOLD | Loss of load duration: adequacy indicator (length of shortfalls) |
+| LOLP | Loss of Load probability: adequacy indicator (probability of shortfalls) |
+| AVL | DTG Available dispatchable thermal generation (sum of av. power over all plants) |
+| DTG | MRG Disp. Ther. Gen. (AVL DTG – sum of all dispatched thermal generation) |
+| MAX | MRG Maximum margin: operational margin obtained if the hydro storage energy of the week were used to maximise margins instead of minimizing costs |
+| NP COST | Non-proportional costs of the dispatchable plants (start-up and fixed costs) |
+| NODU | Number of Dispatched Units13 |
+
+
+### Economy and Adequacy, interconnection results [14]
+**10** _files resulting from the combination of the following attributes:_
+**[values | id] X [hourly | daily | weekly | monthly | annual]**
+
+- _The second attribute defines the period of time over which the results are assessed: hourly detail, daily bundle, weekly bundle, monthly bundle, annual bundle._
+- _The first attribute defines the nature of the results presented in the file_
+
+
+**values** _values of different variables (flow, congestion rent) the list of which is common to all interconnections. The files of type "values" have therefore the same size everywhere_
+_These results appear under the label "general values" in the output GUI_
+
+**id** _identifier (number) of the Monte-Carlo years for which were observed the extreme values of the different variables presented in the « values » files_
+_These results appear under the label "record years" in the output GUI_
+
+
+_The area files that belong to the « values » class display_ **28** _fields corresponding to the expectation, standard deviation, minimal and maximal values of the variables whose list is given hereafter._
+
+| variables | description |
+|-----------|-------------|
+| FLOW LIN. | Flow (signed + from upstream to downstream) assessed by the linear optimization. These flows follow Kirchhoff's law only if these laws have been explicitly enforced by the means of suitable binding constraints |
+| UCAP | Used capacity: absolute value of FLOW LIN. This indicator may be of interest to differentiate the behavior of interconnectors showing low average flows: in some cases this may indicate that the line is little used, while in others this may be the outcome of high symmetric flows |
+| LOOP FLOW | Flow circulating through the grid when all areas have a zero import/export balance. This flow, to be put down to the simplification of the real grid, is not subject to hurdle costs in the course of the optimization |
+| FLOW QUAD. | Flow computed anew, starting from the linear optimum, by minimizing a quadratic function equivalent to an amount of Joule losses, while staying within the transmission capacity limits. This calculation uses for this purpose the impedances found in the "Links" Input data. If congestions occur on the grid, these results are not equivalent to those of a DC load flow|
+| CONG. FEE ALG | Algebraic congestion rent = linear flow \* (downstream price – upstream price) |
+| CONG. FEE ABS | Absolute congestion rent = linear flow\* abs(downstream price–upstream price) |
+| MARG. COST | Decrease of the system's overall cost that would be brought by the optimal use of an additional 1 MW transmission capacity (in both directions) |
+| CONG PROB + | Up>Dwn Congestion probability = (NC+) / (total number of MC years) with:
NC+ = number of years during which the interconnection was congested in the Up>Dwn way for **any** length of time within the time frame relevant with the file|
+| CONG PROB - | Dwn>Up Congestion probability = (NC-) / (total number of MC years) with:
NC- = number of years during which the interconnection was congested in the Dwn>Up way for **any** length of time within the time frame relevant with the file|
+| HURD. COST | Contribution of the flows to the overall economic function through the "hurdles costs" component. For each hour:
`if (FLOW.LIN –LOOP FLOW) > 0 `
`HURD. COST = (hourly direct hurdle cost) * (FLOW LIN.)`
`else HURD.COST = (hourly indirect hurdle cost) * (-1) * (FLOW LIN.)`|
+
+### Economy and Adequacy, other results
+
+_Depending on the options chosen in the main simulation window, the output folders may also include either, both or none of the following sections:_
+
+| OUTPUT/Simu id/ts-numbers/ | | |
+|------------------------------|--------------------|--------------------------------|
+| |/Load | /area names/... |
+| |/Thermal | /area names/... |
+| |/Hydro | /area names/... |
+| |/Wind | /area names/... |
+| |/Solar | /area names/... |
+
+_These files contain, for each kind of time-series, the number drawn (randomly or not) in each Monte-Carlo year (files are present if "output profile / MC scenarios" was set to "true")_
+
+| OUTPUT/Simu id/ts-generator/ | | |
+|------------------------------|--------------------|--------------------------------|
+| |/Load | /batch number/area names/... |
+| |/Hydro | /batch number/area names/... |
+| |/Wind | /batch number/area names/... |
+| |/Solar | /batch number/area names/... |
+
+
+_These files contain, for each kind of Antares-generated time-series, copies of the whole set of time-series generated. Batch numbers depend on the values set for the "refresh span" parameters of the stochastic generators (files are present if "store in output" was set to "true")_
+
+### Draft, area results
+
+**1** _file « annual » +_ **6** _files resulting from the combination of the following attributes :_
+[with-network | without-network | id] X [hourly | annual]
+
+- _The second attribute defines the period of time over which the results are assessed : hourly detail or annual summary._
+
+- _The first attribute defines the nature of the results presented in the file_
+
+**with network** _values of adequacy indices (shortfall duration, loss of load probability) assessed while taking into account the effective grid capacities. The results in these files bear the suffix –CN (connex)_
+
+**without network** _values of adequacy indices (shortfall duration, loss of load probability) assessed without taking into account any interconnection. The results in these files bear the suffix –IS (isolated areas)_
+
+**id** _identifiers (numbers) of the MC years for which were observed the extreme values of the different variables presented in the « w/net » and "wo/net" files_
+
+_Files « with network » et « without network » present the expectations and extreme values observed for the variables whose list is given hereafter:_
+
+| variables | description |
+|-----------|-------------|
+|LOLD | Overall length of time for which there were shortfalls (Loss of Load Duration)
(note: the commonly used LOLE index is equivalent to LOLD expectation )|
+|LOLP | Loss of Load Probability |
+|EENS | Energy Not Supplied |
+|MARG | Margin = available generation – (load + primary reserve)
When MARG > 0, MARG is a security margin
When MARG < 0, MARG is a curtailment depth |
+
+
+_The file « annual » has one line per simulated Monte-Carlo year and gives, for each year, the following information:_
+
+| variables | description |
+|-----------|-------------|
+| LOLD IS | Load shedding duration, if the grid capacities are not considered as available |
+| LOLD CN | Load shedding duration, if the grid capacities are actually available |
+| MAX DEPTH IS | Margin available at the most critical hour of the whole MC year, w/o grid
When MAX DEPTH > 0, MAX DEPTH is a security margin
When MAX DEPTH < 0, MAX DEPTH is a shortfall depth |
+| MAX DEPTH CN | Margin available at the most critical hour of the whole MC year, w/ grid
When MAX DEPTH >0, MAX DEPTH is a security margin
When MAX DEPTH < 0, MAX DEPTH is a shortfall depth |
+
+_Remark: In spite of their likenesses, the fields « MARG » of the files w/net, wo/net and the fields « MAX DEPTH » of the file mc-details are not identical (hence different names):_
+
+- _MARG (expectation, min, max) is related to the whole set of MC years_
+- _MAX DEPTH regards one single year._
+
+_Note that the following relations hold:_
+
+_Min { MC years } MAX DEPTH IS = Min { hours} MARG IS [MIN]_
+
+_Min { MC years } MAX DEPTH CN = Min { hours} MARG CN [MIN]_
+
+### Miscellaneous
+
+_Alike Input data, output results can be filtered so as to include only items that are associated with Areas and Links defined as "visible" in the current map. In addition, the output filtering dialog box makes it possible to filter according to two special categories (**Districts** and **Unknown**) that are not related to standard maps:_
+
+- **Districts** _displays only results obtained for spatial aggregates_
+- **Unknown** _displays only results attached to Areas or Links that no longer exist in the Input dataset (i.e. study has changed since the last simulation)_
+
+
+## 6 Time-series analysis and generation
+
+### General
+
+_When ready-made time-series are not available or are too scarce for building the required number of Monte-Carlo annual simulation scenarios, Antares provides means to generate sets of stochastic time-series to use instead._
+
+_The different categories of time-series call for wholly different generation processes:_
+
+- _For thermal power, the generator is based on the animation of a daily three-state Markov chain (available – planned outage – forced outage) attached to each plant._
+
+- _For Hydro-power, the generator works out monthly time-series of energies, based on the assumption that they can be modeled by Log Normal variables with known correlations through space and time. So as to keep the model simple, for an interconnected system made of N areas, the user defines, along with the N expectations and N standard deviations of the monthly energies, the N X N correlation matrix R(n,m) of the logs of the annual hydro energies between the areas n,m, and the N average auto-correlations r(k) between one month and the next in each area k. The correlation **C(n,i,m,j)** between the logs of hydro energies in area **n**, month **i** and area **m**, month **j** is taken to be $$C(n,i,m,j) = R(n,m)*\sqrt{(r(n)*r(m))^{|j-i|}}$$ This most simplified model asks for considerably fewer data than a comprehensive 12N X 12N time-space matrix. Note that if R is positive semi-definite but C is not, matrix C is automatically transformed into a fitting p.s.d matrix and the data generation keeps going on (however, the log report will show a warning message). If the primary matrix R is not p.s.d, data are considered as corrupted, the generation stops and a fatal error message will be displayed in the log report_
+
+- _For Wind power, Solar power and Load, the required time-series are 8760-hour long and have to emulate as closely as possible the response of the system to variations of wind speed, sunshine and temperature. In all three cases, the rationale of the model is to offer the possibility to consider either the final variable to model (wind power output, solar power output, load) or an underlying intermediate variable (wind speed, nebulosity, deviation between load and the level expected in standard temperature conditions) as a stationary stochastic process, with given marginal laws, given auto-correlation functions and given spatial correlations (eventually, the values of the final variables and those of the core stationary process are tied by diurnal/seasonal rhythms and scaling functions)._
+
+_The identification of all relevant parameters can be made outside Antares by any appropriate means but can also be made automatically by the time-series analyzer, which is then to be fed with the largest available set of historical time-series. Note however that, using the time-series analyzer, one has to consider whether the time-series at hand are statistically meaningful or whether they need some pre-processing (for instance, if wind power time-series are gathered for a period within which the fleet has been expanded, the time-series to analyze should be expressed in % of installed power rather than in MW. For Solar power, the relevant variable to model as a stationary stochastic process is probably not the raw output of solar power but more likely a meteorological indicator related to the sky clarity (for instance , time-series of nebulosity expressed on a 0-100 scale may be used)._
+
+_Once generated by appropriate algorithms, the values of the stationary processes are turned into final values by using a number of parameters that put back in the series the diurnal and seasonal patterns that may have been observed in the course of the historical data analysis and that were temporarily removed to identify the core stationary processes._
+
+##
+
+
+## Time-series generation (load, wind, solar): principles
+
+For the generation of wind, solar and load time-series, Antares gives access to different marginal laws and autocorrelation functions presented hereafter. Note that wind speed modeling should usually be based upon a Weibull modeling, while almost all other situations are likely to be best modeled by Beta variables.
+
+The stationary processes are defined at a monthly scale. For each month, there are:
+
+- Four parameters for the definition of the marginal law
+
+TS Gen. Parameters : $$\alpha, \beta, \gamma\ and\ \delta$$
+
+| **Law** | $$\alpha$$ | $$\beta$$ | $$\gamma$$ | $$\delta$$ | **Expectation** | **Variance** |
+|---------|:----------:|:---------:|:----------:|:----------:|:---------------:|:------------:|
+| Uniform | N/A | N/A | $$< \delta$$ | $$> \gamma$$ | $${(\delta - \gamma)\over 2}$$ | $${(\delta - \gamma)^2\over 12}$$ |
+| Beta | >0 | >0 | $$< \delta$$ | $$> \gamma$$ | $$\gamma + {\alpha(\delta - \gamma)\over (\alpha + \beta)}$$ | $$\alpha\beta(\delta - \gamma)^2\over (\alpha + \beta + 1)(\alpha + \beta)^2$$ |
+| Normal | Any | >0 | N/A | N/A | $$\alpha$$ | $$\beta^2$$ |
+| Weibull | >=1
<50 | >0 | N/A | N/A | $$\beta \Gamma (1 + {1\over\alpha})$$ | $$\beta^2[\Gamma(1+{2\over \alpha}) - \Gamma (1 + {1\over \alpha})^2]$$ |
+| Gamma | >=1
<50 | >0 | N/A | N/A | $$\alpha * \beta$$ | $$\alpha * \beta^2$$ |
+
+Uniform: uniform defined on $$(\gamma, \delta)$$.
+
+Beta: Beta $$(\alpha, \beta)$$ defined on $$(\gamma, \delta)$$.
+
+Normal: expectation $$\alpha$$, standard deviation $$\beta$$.
+
+Weibull: shape $$\alpha$$, scale $$\beta$$, defined on $$(0,+\infty)$$.
+
+Gamma: shape $$\alpha$$, scale $$\beta$$, defined on $$(0, +\infty)$$.
+
+In the expressions of expectation and variance, $$\Gamma(x)$$ is the standard Euler Function
+
+- Two parameters for the definition of the autocorrelation function
+
+**TS Gen. Parameters : $$\theta\ and\ \mu$$**
+
+| **Law** | $$\theta$$ | $$\mu$$ | **Corr(Xt, Xt+h)** |
+|-----|----|-----|--------|
+| Pure exponential decay | $$\theta > 0$$ | $$\mu = 1$$ | $$e^{-\theta h}$$ |
+| Smoothed exponential decay (*) | $$\theta > 0$$ | $$ 1 < \mu < 24$$ | $$\Phi(\theta, \mu, h)$$ |
+
+$$\Phi(\theta, \mu, h)\ =\ {1\over A}\ *\ \sum_{i=0, \mu}{\ \sum_{j=h, h+\mu}{e^{-\theta|j-i|}}}$$
+
+**with $$A=\mu + 2 \sum_{i=1, \mu; j=1, \mu; j > i}{e^{-\theta(j-i)}}$$**
+
+(\*) Obtained by the generation of purely exponentially autocorrelated values (parameter $$\theta$$ ) followed by a moving average transformation (parameter $$\mu$$ ). $$\theta$$ and $$\mu$$ should be carefully chosen so as to accommodate at best the experimental data at hand. If meaningful historical data are available, this identification may be directly made using the Antares time-series analyzer.
+
+## Time-series generation (load, wind, solar): GUI
+
+_The section of the GUI specific to the generation of wind, solar and load time-series comprises:_
+
+1. **Spatial correlation matrices that are located within the "spatial correlation" tab of each path "Wind|Solar|Load / <area\_name>"**
+
+_This tab contains a workspace for the description of 12 monthly spatial correlation matrices_ $$\Xi$$ _and one annual correlation matrix. For the stochastic generators to work properly, these matrices must meet the usual requirements (matrices must be p.s.d, symmetric, with all terms between -100 and +100, and a main diagonal made of 100s). If this is not the case, generators will emit an infeasibility diagnosis. Matrices can be either set up manually OR automatically filled out by the time-series analyzer (see next paragraph)._
+
+_Depending on the choices made in the main "simulation" window, the matrices used will be either the 12 monthly matrices or the annual matrix. Whether to use the first or the second option depends on the quality of the statistical data at hand: with high quality data (for instance, that derived from the analysis of a very large pool of historical data), use of monthly correlations is recommended because monthly differences between matrices have a physical meaning ; with less robust data (derived from a handful of historical data,…), use of the single annual correlation matrix should be preferred because it smooths out the numeric noise which impairs the monthly matrices._
+
+2. **Four parameters and four subtabs that are located within the "local" tab of each path "Wind|Solar|Load / <area\_name>"**
+
+**FOUR PARAMETERS**
+
+- _Capacity: This first parameter is used to scale up time-series generated on the basis of the ($$\alpha,\ \beta,\ \gamma,\ \delta,\ \theta,\ \mu$$) parameters described previously in the "principles" paragraph, together with coefficients characterizing the diurnal pattern (see below)_
+
+- _Distribution: This second parameter gives the type of marginal distribution of the stationary stochastic processes to generate (Beta, Weibull, Normal, Gamma, Uniform)_
+
+- _Translation: This third parameter has three possible values:_
+
+ - _Do not use: parameter ignored_
+ - _Add before scaling: A specific 8760-hour array is added to the time-series produced by the primary stochastic generator, BEFORE use of the conversion table (optional) followed by the final multiplication by the capacity factor_
+ - _Add after scaling: A specific 8760-hour array is added to the time-series produced by the primary stochastic generator, AFTER use of the conversion table (optional) followed by the final multiplication by the capacity factor_
+
+- _Conversion: This fourth parameter has two possible values:_
+
+ - _Do not use: Any transfer function that may be described in the "conversion" subtab (see below) should not be used for the final stage of data elaboration (for instance, if the primary parameters describe the physics of wind speeds, the time-series eventually produced should remain wind speeds and not wind power)._
+
+ - _Use: The time-series produced by the stochastic generators (wind speeds, for instance) are turned into other values (wind power) by using the transfer function described in the "conversion" subtab._
+
+**FOUR SUBTABS**
+
+- _Subtab "Coefficients"_
+
+_A twelve-month table of values for the primary parameters_ $$\alpha,\ \beta,\ \gamma,\ \delta,\ \theta,\ \mu$$
+_This table may be either filled out manually or automatically (use of the time-series analyzer)_
+
+- _Subtab "Translation"_
+
+_Contains an 8760-hour array T to add to the time-series generated, prior or after scaling. This array can be either filled out manually or by the time-series analyzer._
+
+- _Subtab "Daily profile"_
+
+_A 24\*12 table of hourly / monthly coefficients K(hm) that are used to modulate the values of the stationary stochastic process by which the actual process is approximated. This table can be either filled out manually or by the time-series analyzer._
+
+- _Subtab "Conversion"_
+
+_A table of 2 \* N values (with 1<=N<=50) that is used to turn the initial time-series produced by the generators (for instance, wind speeds) into final data (for instance, wind power). The transfer function (speed to power, etc.) is approximated by N discrete points whose abscises X(N) an ordinates Y(N) are given by the table._
+
+## Time-series analysis (load, wind, solar)
+
+##
+
+_The time-series analyzer module available in Antares is meant to identify the values that should be given to the parameters used in the time-series generators (load, solar power, wind power) so as to fit best historical time-series at hand._
+
+**IMPORTANT**
+
+_When the time-series analyzer is used, it automatically updates the parameters relevant to the analysis (for instance: analysis of "wind" time-series will overwrite all local and global "wind" parameters [correlation matrices] that may have been previously set manually)._
+
+_The primary TS analyzer window shows two tabs:_
+
+1. **Tab "Time-series and areas"**
+
+- _Time-series (load, wind, solar): class of parameters to be assessed by the analyzer_
+
+- _Browse: location of the historical time-series files. These are txt files in which 8760-hour time-series must be stored in adjacent columns separated by a tabulation_
+
+- _For each area:_
+
+ - _Activity status_
+ - _yes: parameters will be assessed and updated by the analyzer_
+ - _no: the area will be skipped (_**local** _parameters for the area will remain unchanged, however_ **spatial** _correlation with other areas will be reset to zero)_
+
+ - _Distribution_
+ - _Type of distribution to fit (beta, normal, etc.)_
+
+ - _Data_
+ - _Raw: data to analyze are the actual historical time-series_
+ - _Detrended: data to analyze are the time-series of the deviations to average (for instance: load time-series need to be analyzed in "detrended" mode while wind speeds can be analyzed in "raw" mode)_
+
+ - _File to analyze_
+ - _Name of the file that should contain historical time-series to analyze_
+ - _Status_
+ - _Ready (a file bearing the expected name was found)_
+ - _Not found (no file found with the expected name)_
+
+**IMPORTANT** _To generate stochastic data similar to the historical data analyzed, generation parameters must be kept consistent with the results of the analysis, which means, in the generators:_
+
+- _Keep the same:_
+
+ - _Type of distribution_
+ _Values for_ $\alpha,\ \beta,\ \gamma,\ \delta$$ _and for the diurnal–seasonal pattern (table of 12 X 24 values)_
+ _Value for the "capacity" parameter (the analyzer automatically sets it to 1)_
+
+- _Besides:_
+ - _"Conversion" option must be set to "no"_
+ _"Translation" option must be set to "do not use "if data were analyzed as "raw"_
+ _and to "add after scaling" or "add before scaling" if data were analyzed as "detrended" (both options give the same value in this case because the scaling is 1:1)_
+
+2. **Tab "Global settings"**
+
+- _Temporary folder: workspace that can be used for the analysis (cleaned after use)_
+
+- _Analyzer settings_
+
+ - _Short-term autocorrelation adjustment (\%)_
+ - _Long-term autocorrelation adjustment (\%)_
+ These two parameters are used by Antares as targets for the fitting of $$\theta$$ and $$\mu$$ parameters. For instance, if the historical time-series autocorrelation function is such that Corr(T,T+ 18 hours)=90 \% and Corr(T,T+60 hours)= 50\%, and if the parameters in the analyzer are (ST = 90\%,LT = 50\%) , then it will search values of $$\theta$$ and $$\mu$$ matching the historical autocorr.function in two points(18 hours, 60 hours).
+
+ - _Trimming threshold (\%)_
+ _In the spatial correlation matrices, terms lower than the threshold will be replaced by zeroes_
+
+- _Input data_
+
+ - _Time-series per area (n)_
+ _limits the analysis to the first n historical time-series at hand_
+ - _Upper-bound (Max)_
+ _In the analysis, all values above Max in the historical files will be replaced by Max_
+ - _Lower-bound (Min)_
+ _In the analysis, all values below Min in the historical files will be replaced by Min_
+
+**IMPORTANT** _For each month, time-series to analyze are assumed to represent a stationary stochastic signal modulated by 24 hourly shape-factors. All of these shape-factors are expected to be different from zero. If the signal is partly masked by sequences of zeroes (for instance, if solar power time-series are to be analyzed as such because time-series of nebulosity are not available), the analysis is possible but is subject to the following restrictions:_
+
+- **Use of the "detrended" mode in the first Tab is mandatory** _(use of the "raw" mode would produce wrong correlation matrices)_
+
+- **Short- and Long- Term autocorrelation parameters in the second Tab must be identical and set to 99\%** _(to ensure that auto-correlation be assessed for the shortest possible time lag, i.e. one hour)_
+
+**NOTICE** _For the whole year, the analyzer delivers a table of 12x24 hourly shape-factors consistent with the 12 sets of parameters identified for the stationary stochastic processes. The content of the table depends on the mode of analysis chosen:_
+
+"**raw"** _analysis: for each month, the sum of the 24 hourly shape-factors is equal to 24 (i.e. each term is a modulation around the daily average)._
+
+"**detrended"** _analysis: for the whole year, hourly coefficients are expressed relatively to the annual hourly peak of the (zero-mean) signal absolute value. (i.e. all factors belong to the [0,1] interval)_
+
+## Time-series generation (thermal)
+
+_The stochastic generator for time-series of available dispatchable power generation works, for each plant of each set (cluster), with the following parameters:_
+
+- _The nominal plant capacity and a 8760-hour array of modulation coefficients to apply to it (default value: 1)_
+
+- _A 365-day array of forced outages rates ("FOR", lies in [0,1] )_
+
+- _A 365-day array of planned outages rates ("POR", lies in [0,1])_
+
+- _A 365-day array of forced outages average durations ("FOD" in days, integer, lies in [1,365])_
+
+- _A 365-day array of planned outages average durations ("POD" in days, integer,lies in [1,365])_
+
+- _A 365-day array of planned outages minimum number (PO Min Nb)_
+ _(integer, lies in [0, PO Max Nb])_
+
+- _A 365-day array of planned outages maximum number (PO Max Nb)_
+ _(integer, lies in [PO Min Nb, Nb of units in the cluster]_
+
+- _Two parameters describing how forced outages durations may randomly deviate from their average value (law: uniform or geometric , volatility: lie in [0,1])_
+
+- _Two parameters describing how planned outages durations may randomly deviate from their average value (law: uniform or geometric , volatility: lie in [0,1])_
+
+1. **Outage duration : meaning and modeling**
+
+_In the thermal time-series generator, the concept of outage duration (either forced or planned) is simple enough: for any given plant affected by such an event, it is the duration of a single outage, expressed in days._
+
+_The fact that 365 different values can be used to describe what may happen in the course of a year (for each kind of outages) means that the average outage duration may depend on the day the outage begins on. For instance, very short outages may be sometimes be planned on week-ends. Likewise, historical statistics can show that forced outages do not last the same average time in winter and summer, etc._
+
+_In complement to the average value of the duration D of outages beginning on a particular day, the time-series generator allows to set two parameters that describe how the actual outage durations may deviate from the calendar-related average value._
+
+- _The first parameter (law) can take either the value "uniform" or "geometric":_
+ _Uniform: the actual outage duration will be randomly drawn (one draw per outage), according to a_ **uniform distribution** _centred on the average value_ **D**_. The width of the interval [min duration, max duration] will depend on the value of the second parameter (volatility)._
+ _Geometric: the actual outage duration will be expressed as the sum of a fixed value F and a randomly drawn (one draw per outage) variable following a_ **geometric distribution** _of expectation G, with_ **F+G=D**_. The ratio of F to G will depend on the value of the second parameter (volatility)._
+
+
+- _The second parameter (volatility) can take any value within [0,1]_
+
+ - _0: The outage duration does not show any stochastic fluctuation at all._
+ _Therefore, regardless of the chosen distribution law:_
+ **actual duration = D**
+
+ - _1: The variability of the actual outage duration is as high as the chosen distribution law makes it possible, which means respectively that:_
+
+ - _If choice = "uniform":_ **1 <= actual duration <= 2D-1**
+ - _If choice = "geometric":_ **F = 0 and G = D**
+ _(which in turn implies 1 <= actual duration <= #4D)_
+
+ - _0<V<1: The variability of the actual outage duration is such that the ratio_ $$\sigma / D$$ _of its standard deviation to its expectation has a value that depends on_ **V** _, on_ **D** _and on the chosen distribution law. More precisely:_
+
+ - _If choice = "uniform": $$\sigma$$ **/ D = [1/3^0.5] \* V \* (D-1) / D**_
+ _and_
+ _**Duration min = D (1-V) + V**_
+ _**Duration max = D (1+V) - V**_
+
+ - _If choice = "geometric": $$\sigma$$ **/ D = V \* [(D-1) / D]^0.5**_
+ _and_
+ _**Duration min = F**_
+ _**Duration max # 4D-3F**_
+ _with F = D – G_
+ _G = 2z /[(1+4z)^0.5 - 1]_
+ _z = (V^2) \* D \* (D-1)_
+
+**NOTE:** _The calculation time required for the generation of time-series does not depend of the kind of chosen law but depends on the fact that the volatility is null or not (it is minimal for zero-volatility)._
+
+**NOTE:** _A geometric law associated with a volatility parameter V yielding a characteristic parameter F (according to the previous formulas) will produce a distribution summarized by:_
+
+- _63 \% of values in the interval [F, D]_
+- _23 \% of values in the interval [D, 2D-F]_
+- _12 \% of values in the interval [2D-F, 4D-3F]_
+- _2 \% of values in the interval [4D-3F, infinite)_
+
+**Remark:** _Antares is able to provide these options because it involves more than a simple Markov chain mechanism (intrinsically limited to : law = geometric, volatility = 1)_
+
+2. **Outage rates: meaning and modeling**
+
+_The concept of outage rate is not always clearly distinguished from the notion of failure rate, to which it is closely related._
+
+_Outage rates OR represent the average_ **proportion** _of time during which a plant is unavailable (for instance, OR = 5.2\%)._
+
+_Failure rates FR represent the average_ **number** _of outages_ **starting** _during a period of time of a given length (for instance, FR = 1.5 per year). If the time step is short enough (typically one day, which is the value used in Antares), the failure rates are always lower than 1 (for instance, FR = (1.5 / 365) per day)._
+
+_When this condition is met and if the physical outage process can be modelled by a Poisson process, failure rates can be interpreted as probabilities._
+
+_In Antares the following relation between failure rates FR, outage rates OR and outage durations OD is used:_
+
+_**FR = OR / [OR+ OD \* ( 1 – OR )]**_
+
+_To determine whether a plant available on day D is still available on day D+1, the Antares stochastic generator therefore makes draws based on the failure rates equivalent to the data provided in the form of outage rates and outage durations._
+
+_Since two processes may be described in the GUI, consecutive draws are made for each process so as to determine whether:_
+
+- _An outage of the first category begins (it will last for the specified duration)_
+- _An outage of the second category begins (it will last for the specified duration)_
+- _No outage occurs, the plant is still available on D+1_
+
+_Whether to describe the "planned outage" process as a random process or not depends of the kind of data at hand, which is often related to the horizon of the studies to carry out: when actual overhauls plans are known, the PO rates can be set at 1 when the plant is deemed to be unavailable and to zero on the other days._
+
+_For long term studies in which only general patterns are known, season-, month- or week- modulated rates and duration may be used to describe the "planned" process as a stochastic one. Another possible use of the model is to incorporate the overhauls plans in the "nominal capacity modulation" array, and consider the stochastic "planned outage" processor as a simulator for a second modality of forced outage (longer or shorter than the main component)_
+
+**NOTE:** _Once the outage duration and outage rate are defined, the failure rate is completely determined. For the sake of clarity, the Antares GUI displays still another parameter often used in reliability analysis, which is the MTBF (Mean Time Between Failure). Relations between MTBF, FR and OR are:_
+
+_**FR= 1 / ( MTBF+1 ) OR = OD / ( MTBF+OD )**_
+
+**NOTE:** _When two stochastic processes of outages (forced and planned, or forced-type-1 and forced-type-2) are used, the overall resulting outage rate OOR is not equal to the sum of the two rates FOR and POR. Instead, the following relation holds:_
+
+_**OOR = ( FOR + POR – 2\*FOR\*POR ) / (1 - FOR\*POR)**_
+
+_The explanation of this formula lies in the definition of the different outages rates:_
+
+_Over a long period of operation, FOR represents the ratio of the time spent in forced outages to the overall time not spent in planned outages._
+
+_Likewise, POR represents the ratio of the time spent in planned outages to the overall time not spent in forced outages._
+
+_OOR represents the ratio of the time spent in either forced or planned outages to the overall operation period._
+
+_The period of operation can be broken down into three categories of hours:_
+
+_F hours spent in forced outages_
+
+_P hours spent in planned outages_
+
+_A hours of availability_
+
+_The following relations hold and explain the previous formula:_
+
+_FOR = F/(A+F)_
+
+_POR=P/(A+P)_
+
+_OOR=(F+P)/(A+F+P)_
+
+3. **Planned Outages Minimum and Maximum Numbers**
+
+_In the description given so far regarding how outages are modeled, no true difference was made between "forced" and "planned" outages, i.e. both relied on unconstrained random draws. This is satisfactory only if the process to model through the "planned" data is actually little constrained, or not at all._
+
+_In all other occurrences, it makes sense to define a general framework for the maintenance schedule. In Antares this is defined at the cluster scale by two specific 365-day arrays:_
+
+_PO Min Nb and PO Max Nb._
+
+_These parameters are used by the time-series generator as constraints that_ **cannot be violated**_, regardless of the raw outcome of regular random draws. To meet these constraints, the generator may have to anticipate or delay "planned" outages yielded by the primary random draws stage. If data regarding planned outage rates and planned outage Max and Min numbers are not consistent, the Max and Min Numbers take precedence._
+
+_Exemples (for simplicity'sake, they are described here with only one value instead of 365):_
+
+_Cluster size = 100 PO rate =10\% PO Min Nb=0 PO Max Nb= 100_
+
+- _Actual number in [0,100], average = 10, wide fluctuations (unconstrained)_
+
+_Cluster size = 100 PO rate =10\% PO Min Nb=7 PO Max Nb= 11_
+
+- _Actual number in [7,11], average = 10 (to remain within the bounds, some outages will be anticipated, while others will be delayed)_
+
+_Cluster size = 100 PO rate =0\% PO Min Nb=10 PO Max Nb= 10_
+
+- _Actual number =10 (to remain within the bounds, outages are set up even if none come from random draws)_
+
+##
+
+## Time-series analysis (thermal)
+
+_The stochastic generator for time-series of available dispatchable power generation needs to be given assumptions regarding forced & planned outages rates & durations. Depending on the quality and quantity of statistics at hand, these estimates can be either described as "flat" (same constant values used from the beginning to the end of the year) or as more or less modulated signals, with the possibility of choosing different values for each day of the year._
+
+_Different ways can be considered to work out values for FOR,POR,FOD,POD from historical data regarding outages. For any (family of) plant(s) to study, notations have to be defined with respect to the "calendar accuracy" chosen by the user. For the sake of clarity, assume from now on that the user wants to assess weekly rates and durations, that is to say: describe the whole year with 52 values for rates and durations, for both forced and planned outages (within any given week, identical values will therefore be assigned to the seven days of the week)._
+
+_With the following notations:_
+
+_D(w) = Overall cumulated statistical observation time available for week (w)_
+
+_for instance, for w = 1= first week of January : D(w) = 3500 days coming from 10 years of observation of 50 identical plants_
+
+_Df(w) = Within D(w), overall time spent in forced outages, either beginning_
+
+_during week w or before (for instance , Df(1) = 163 days)_
+
+_Dp(w) = Within D(w), overall time spent in planned outages, either beginning_
+
+_during week w or before (for instance, Dp(1) = 22 days)_
+
+_Kf(w) = Number of forced outages beginning during week (w)_
+
+_(for instance, Kf(1) = 26)_
+
+_Kp(w) = Number of planned outages beginning during week (w)_
+
+_(for instance, Kp(1) = 3)_
+
+_FOT(w) = Overall cumulated time (expressed in days) spent in forced outages beginning during week (w) (for instance, FOT(1)= 260)_
+
+_Note that if outages last more than one week FOT(w) necessarily includes days from weeks w+1, w+2,…_
+
+_POT(w) = Overall cumulated time (expressed in days) spent in planned outages beginning during week (w) (for instance, POT(1) = 84)_
+
+_Note that if outages last more than one week POT(w) necessarily includes days from weeks w+1, w+2,…_
+
+_The following formulas can be used :_
+
+_**FOD (w) = FOT(w) / Kf(w)**_
+
+_**POD (w) = POT(w) / Kp(w)**_
+
+_**FOR(w) = FOD(w) / [FOD(w) + ( (D(w) - Dp(w)) / Kf(w))]**_
+
+_**POR(w) = POD(w) /[POD(w) + ( (D(w) - Df(w))) / Kp(w))]**_
+
+_For the examples given above, the estimated parameters would therefore be :_
+
+_FOD(1) = 10 (days)_
+
+_POD(1) = 28 (days)_
+
+_FOR(1) = 0.0695 # 7 \%_
+
+_POR(1) = 0.0245 # 2.5 \%_
+
+_These values should eventually (using the GUI or other means) be assigned to the first seven days of January._
+
+## Time-series generation and analysis (hydro)
+
+_The stochastic hydro generator assesses monthly time-series of energies, based on the assumption that they can be modeled by Log Normal variables. The values generated are interpreted as monthly amounts of hydro energies generated (sum of Run of River – ROR – and hydro storage – HS) or as amounts of hydro inflows, depending on the modeling chosen for the area (straightforward estimate of energies generated or explicit management of reservoirs)._
+
+_The historical data to work from depend on the kind of modeling chosen (statistics of monthly generation in the first case, or statistics of monthly inflows in the second case)._
+
+_In both cases, assuming that a large number of historical time-series of energies are available, the rationale of the assessment of parameters is the following (from now on, "energies" mean either "ROR and HS energies generated" or "inflows to ROR and HS"),_
+
+1. _For each area n, build up annual energy time-series **A(n)** by aggregation of the original monthly energy time-series **M(n)**. For each pair of areas (n,m) , assess the correlation **R(n,m)** between the random variables **Log(A(n))** and **Log(A(m))**. Expressed in percentage, matrix **R** should be used to fill out the "spatial correlation tab" of in the active window "hydro"_
+
+2. _For each area n, build up two monthly time-series derived from the original array **M(n)**, by proceeding as follows. Assuming that **M(n)** has K elements (for instance, K= 180 if 15 years of statistics are available):_
+
+ - _**M'(n)** = time-series of K-1 elements obtained by deleting the first element of the time-series Log(M(n))_
+ - _**M''(n)** = time-series of K-1 elements obtained by deleting the last element of the time-series Log(M(n))_
+
+_Assess the correlation **IMC(n)** between the random variables **M'(n)** and **M''(n)**. This value (lying in [-1,1]) should be used to fill out the field "inter-monthly correlation value" of the "local data" tab in the "hydro" active window_
+
+3. _For each area n, build up 12 monthly energy time-series derived from the original array **M(n)** by extracting from **M(n)** the values related to each month of the year (**M1(n)**= time-series of energies in January,…, **M12(n)** = time-series of energies in December.)_
+
+_Assess the expectations and standard deviations of the 12 random variables **M1(n)** ,…, **M12(n)**. These values should be used to fill out the fields "expectation" and "std deviation" of the "local data" tab in the "hydro" active window._
+
+_Aside from expectation and standard deviations, minimum and maximum bounds can be freely set on the monthly overall energies (ROR + HS). Whether to assess these bounds by examination of historical data or on the basis of other considerations depends on the context of the studies to carry out_
+
+4. _For each area n, extract from the 12 monthly overall energy time-series **M1(n) ,…, M12(n)** the contribution of the 12 monthly time-series of ROR energies **R1(n),…, R12(n)**._
+
+_Assess the expectations of the 12 random variables **R1(n)/M1(n),…., R12(n)/M12(n)** . These values should be used to fill out the fields "ROR share" of the "local data" tab in the "hydro" active window._
+
+# Kirchhoff Constraints Generator
+
+_Binding Constraints introduced in [Active windows](#active-windows) can take many forms (hourly, daily, weekly), involve flows or thermal generated power, etc. Sets of binding constraints of special interest are those which can be used to model and enforce Kirchhoff's second law on the AC flows._
+
+_In other words, it is possible to make Antares work as a genuine DC OPF, provided that consistent binding constraints are written down for each cycle belonging to any cycle basis of the graph made out from all AC components of the power system (V vertices, E edges)._
+
+_The declaration of binding constraints can be made manually through the regular GUI. However, it is preferable not to carry out this task that way because there are many different possible formulations, among which some are better than others:_
+
+- _In a fully connected graph (V, E), there are as many binding constraints to write down as there are cycles in any cycle basis of the graph, which amounts to (E+1-V). The number of different possible basis is equal to that of spanning trees, which can be assessed by the Kirchhoff's theorem_
+ _# 15_
+
+- _Among all cycle basis, some should be preferred to others because they lead to a sparser constraint matrix._
+
+_To get around this issue, the KCG is an autonomous Antares module (much like the time-series analyzer) which automatically instantiates a set of adequate binding constraints that will enforce Kirchhoff's law on the AC subgraph of the power system. The graph cycle basis associated with the generated constraints is optimal, in that sense that it leads to a constraint matrix as sparse as possible._
+
+_To achieve that, the KCG implements an efficient algorithm yielding a minimal cycle basis_
+_# 16_ _and, for all cycles of the chosen basis, generates constraints of the form:_
+
+$$c= 1, ..., C : \sum_{l \in C}{sign(l,c)F_lZ_l} = 0$$
+
+_Where_ \\(Z_l\\) _are the impedances (parameters) and \\(F_l\\) are the flows (variables)._
+
+_Beyond this basic purpose, the KCG is meant to provide additional modeling capacities, so as to allow the representation of two important phenomena:_
+
+- _As a rule, the power system graph represented in Antares in not fully detailed, it is usually more a "backbone" approximation, in which "vertices" are not equivalent to individual bus-bars. More likely, vertices of the graph stand for whole regions, or even countries: as a consequence, it is highly possible that when all Areas/Vertices have a zero-balance (neither import, nor export), there are real physical flows between them, so-called "loop flows". If assessments of the level of these loop flows are available (and filled out as link input data), the KCG may include them (on user's request) in the binding constraints formulation, which becomes:_
+
+$$c= 1, ..., C : \sum_{l \in C}{sign(l,c)F_lZ_l} = \sum_{l \in C}{sign(l,c)\varphi_lZ_l}$$
+
+- _To mitigate the effects of actual loop flows, or more generally to allow the transmission assets to give the maximum of their potential, the power system may include components such as phase-shifting transformers, whose function can be modeled by changing the formulation of the binding constraints. Provided that estimates of the shifting capacities ($$Y_l^-$$, $$Y_l^+$$) of the installed PST are known and filled out in the link data section, the KCG will (on user's request) automatically reformulate the binding constraints as:_
+
+$$c= 1, ..., C : Y_c^- + \sum_{l \in C}{sign(l,c)\varphi_lZ_l} \leq \sum_{l \in C}{sign(l,c)F_lZ_l} \leq Y_c^+ + \sum_{l \in C}{sign(l,c)\varphi_lZ_l}$$
+
+with:
+
+$$Y_c^- = \sum_{l \in C}{Min(sign(l,c)Y_l^-, sign(l,c)Y_l^+)}$$
+
+$$Y_c^+ = \sum_{l \in C}{Max(sign(l,c)Y_l^-, sign(l,c)Y_l^+)}$$
+
+_Besides, the KCG takes into account the fact that the "best estimates" of all critical data (loop flows, phase-shifting ratings, or even impedances) may vary in time: In such cases, the KCG formulates as many different binding constraints as necessary to model this operating context diversity, and relax them when appropriate (by setting the right hand sides of the equation to +/- infinite)_
+
+_From a practical standpoint, assessments of $$Y^-, Y^+$$ should be derived from knowledge about the actual components installed on the grid, while \\(Z_l\\) and $$\varphi_l$$ can be estimated by various methods._
+
+_In addition to the previous functionalities, the KCG's GUI also includes the following options:_
+
+- _Choice a specific period of time for which the constraints should be applied, while completely relaxed at other moments_
+- _Before actual generation of binding constraints, preview of the "minimal length" spanning tree used as starting point for the optimal basis algorithm (left column of the table – links displayed with "0" do not belong to the tree)_
+- _Before actual generation of binding constraints, preview of the "optimal cycle basis" used as starting point for constraints generation (right column of the table – links displayed with "n" appear in n different cycles of the basis)_
+
+# Miscellaneous
+
+## Antares at one glance
+
+_This section gives a summary of the whole simulation process followed by Antares in Economy simulations (Adequacy and Draft simulations being simplified variants of it)_
+
+1. _Load or Generate [stochastic generators] Time-series of every kind for all system areas_
+
+2. _For each Monte-Carlo year, pick up at random or not [scenario builder] one time-series of each kind for each area_
+
+3. _For each area and each reservoir:_
+
+ 1. _Split up the annual overall hydro storage inflows into monthly hydro storage generation, taking into account reservoir constraints, hydro management policy and operation conditions (demand, must-run generation, etc.) [heuristic + optimizer]_
+
+ 2. _For every day of each month, break down the monthly hydro energy into daily blocks, taking into account hydro management policy and operation conditions (demand, must-run generation, etc.) [heuristic + optimizer]. Aggregate daily blocks back into weekly hydro storage energy credits (used if the final optimization is run with full weekly 168-hour span)_
+
+ 3. _For each week of the year (daily/weekly hydro energy credits are now known in every area), run a three-stage 168-hour optimization cycle (or seven 24-hour optimizations, if the optimization preference is set to "daily"). This aim of this cycle is to minimize the sum of all costs throughout the optimization period. This sum may include regular proportional fuel costs, start-up and no-load heat costs, unsupplied and spilled energy costs, and hurdle costs on interconnection. The solution has to respect minimum and maximum limits on the power output of each plant, minimum up and down durations, as well as interconnection capacity limits and "binding constraints" at large (which may be technical – e.g. DC flow rules – or commercial – e.g. contracts). Note that an accurate_ _resolution of this problem requires mixed integer linear programming (because of dynamic constraints on thermal units). A simplified implementation of this approach is used when the advanced parameter "Unit commitment" is set on "accurate". This high quality option may imply long calculation times. This is why, when "Unit commitment" is set on "fast", Antares makes further simplifications that save a lot of time (starting costs are not taken into account within the optimization step but are simply added afterwards, units within a thermal cluster are subject to starting up/shutting down constraints more stringent than the minimum up/down durations). In both cases, the general optimization sequence is as follows:_
+
+ 1. _Minimization of the overall system cost throughout the week in a continuous relaxed linear optimization. Prior to the optimization, an 8760-hourly vector of operating reserve R3 (see next section) may be added to the load vector (this will lead in step (ii) to identify plants that would not be called if there were no reserve requirements. Their actual output will be that found in step (iii), wherein the load used in the computations takes back its original value)_
+
+ 2. _So as to accommodate the schedule resulting from (i), search for integer values of the on/off variables that satisfy the dynamic constraints with the smallest possible cost increase._
+
+ 3. _Take into account the integer variables found in (ii) and solve again the optimal schedule problem for the week._
+
+## Operating reserves modeling
+
+_Many definitions may be encountered regarding the different operating reserves (spinning / non spinning, fast / delayed, primary-secondary-tertiary, frequency containment reserve – frequency restoration reserve – replacement reserve, etc.)._
+
+_Besides, all of them need not be modeled with the same level of accuracy in a simulator such as Antares. Furthermore, the best way to use the concept is not always quite the same in pure Adequacy studies and in Economy studies._
+
+_Several classes of reserves may therefore be used in Antares; how to use them at best depend on the kind and quality of operational data at hand, and on the aim of the studies to carry out; though all kinds of reserves may always be defined in the INPUT dataset, the set of reserves that will effectively be used depends on the kind of simulations to run. Note that any or all classes of reserves may be ignored in a given simulation (without being removed from the INPUT dataset) by setting the matching "optimization preference" to "ignore reserve X":_
+
+- _**Pre-allocated reserve on dispatchable thermal plants (R0)**_
+ _This reserve (which corresponds to the parameter "spinning" attached to the thermal plants) is expressed as a percentage of the nominal capacity of the plants. It is simply used as a derating parameter: for instance, a 1000 MW plant with a 2.5\% spinning parameter will not be able to generate more than 975 MW. It is important to notice that, if the plant is not scheduled on, it will NOT contribute to the spinning reserve (to be effectively available, the 25 MW of reserve would need the plant to be started). This first class of reserve is available for_ **Adequacy** _as well as for_ **Economy** _simulations but is not taken into account in_ **Draft** _simulations._
+
+
+- _**Primary and strategic reserves (R1,R2):**_
+ _These two reserves may be used in_ **Draft** _simulations, with the following meaning:_
+ - _Primary reserve must be supplied by local generation and has a higher priority than load: for instance, if overall load L=43.6 GW, overall generation G=44.0 GW, primary reserve = 0.7 GW, then an adequacy analysis will show 300 MW of unsupplied energy. The primary reserve is in essence a frequency containment reserve._
+ - _The strategic reserve is an amount of power that should remain available for balancing domestic load, i.e. cannot be exported regardless of the load/generation balance of the neighboring areas. For instance, if loads in area A and B are LA= 45 GW and LB= 50 GW, if available generations are GA= 49 GW and GB = 47 GW, and if there is a 1.5 GW strategic reserve to be kept in A, then an adequacy analysis will show 500 MW of unsupplied energy in B. The strategic reserve may include amounts of power known to be unavailable for actual exports (for instance, because of grid limitations not thoroughly modeled in the Antares study dataset)._
+
+
+- _**Day-ahead reserve (R3):**_
+ _This reserve is available in_ **Adequacy** _and_ **Economy** _simulations, with the following meaning:_
+ "_For any day D, to be able to accommodate last-minute random variations of the expected demand and/or generation (as they were seen from day D -1), a certain amount of power (R3) should be ready to be available at short notice"_
+
+ _In actual operating terms, R3 is a complex (spinning/non-spinning) mix as well as (hydro/thermal) mix. It may involve or not part of the primary and secondary power/frequency regulation reserves. R3 may represent as much as the overall amount of frequency containment reserve, frequency restoration reserve and replacement reserve required for operation on day D, as seen from day D-1._
+
+ _In the simulations, R3 is construed as a "virtual" increase of the load to serve, which influences the optimal unit commitment and dispatch (because of minimum stable power levels and minimum On / Down times)._
+
+_IMPORTANT:_
+
+_The optimization makes sure that, should the need arise, reserve R3 will actually be available where it is needed_ **BUT** _there is no commitment regarding whether this service should be provided by an increase of local generation, a decrease of exports or even an increase of imports: the optimizer will choose the mix leading to the minimal cost for the system._
+
+_Note that this "standard" feature of Antares makes it possible to assess the potential value of keeping some headroom in interconnections for the purpose of transferring operating reserves, when "remote" reserves are less expensive than domestic ones._
+
+_The table below gives an overview of the different reserves available in Antares_
+
+| | _Economy_ | _Adequacy_ | _Draft_ |
+|:---:|:---:|:---:|:---:|
+| _R0_ | _Yes_ | _Yes_ | _No_ |
+| _R1_ | _No_ | _No_ | _Yes_ |
+| _R2_ | _No_ | _No_ | _Yes_ |
+| _R3_ | _Yes_ | _Yes_ | _No_ |
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+## The heuristic for seasonal hydro pre-allocation
+
+
+This heuristic, first introduced in broad terms in [Active windows](#active-windows), chapter "hydro",
+is fully detailed in this paragraph.
+
+Basically, the seasonal hydro pre-allocation process comprises two stages carried out two times
+(first time: monthly scale; second time: daily scale).
+
+- Stage 1: Definition of an allocation ideal modulation profile, which may be based (or not) on local and/or
+ remote load profiles.
+- Stage 2: Mitigation of the previous raw profile to obtain a feasible hydro ideal target,
+ compatible as much as possible with reservoir rule curves.
+
+The description given hereafter makes use of the following local notations,
+not be confused with those of the document "optimization problem formulation"
+(dedicated to the optimal hydro-thermal unit-commitment and dispatch problem):
+
+\\(Z\\) Number of Areas (zones \\(z\\)) in the system
+
+\\(M_{zh}\\) Hourly time-series of cumulated must-generation of all kinds for zone \\(z\\)
+
+\\(M_{zd}\\) Daily time-series of cumulated must-generation of all kinds for zone \\(z\\) (sum of \\(M_{zh}\\))
+
+\\(M_{zm}\\) Monthly time-series of cumulated must-generation of all kinds for zone \\(z\\) (sum of \\(M_{zh}\\))
+
+\\(M_{z.}\\) Either \\(M_{zd}\\) or \\(M_{zm}\\), relevant time index "." is defined by the context
+
+\\(L_{z.}\\) Time-series of "natural" load for zone \\(z\\)
+
+\\(A\\) Inter-area hydro-allocation matrix (dimension_ \\(x Z\\) ) \\(A_{uv}\\) is a weight given to the load
+of area \\(u\\) in the definition of the monthly and daily primary hydro generation target of area \\(v\\)
+
+Extreme cases are:
+- **A is the identity matrix**
+ The hydro storage energy monthly and weekly profiles of each zone \\(z\\) depend only on the local demand and
+ must-run generation in \\(z\\)
+
+- **A has a main diagonal of zeroes**
+ The hydro storage energy monthly and weekly profiles of each zone \\(z\\) do not depend at all on the local
+ demand and must-run generation in \\(z\\)
+
+\\(L_{z.}^+\\) Time-series of "net" load for zone \\(z\\), defined as: \\(L{z.}^+ = L{z.} - M{z.}\\)
+
+\\(L_{z.}\\) Time-series of "weighted" load for zone \\(z\\), defined as:_ \\(L_{z.} = A^t L_{z.}^+\\)
+
+All following parameters are related to the generic zone \\(z\\)
+
+\\(\alpha$$ "inter-monthly generation breakdown" parameter
+
+\\(\beta\\) "inter-daily generation breakdown" parameter
+
+\\(j\\) "follow-load" parameter
+
+\\(m\\) "reservoir-management" parameter
+
+\\(S\\) Reservoir size
+
+\\(\overline{S_d}\\) Reservoir maximum level at the end of day d, expressed as a fraction of \\(S\\) (rule curve)
+
+\\(\underline{S_d}\\) Reservoir minimum level at the end of day d, expressed as a fraction of \\(S\\) (rule curve)
+
+\\(S_0\\) Reservoir initial level at the beginning of the first day of the "hydro-year"
+
+\\(I_d\\) Natural inflow of energy to the reservoir during day d
+
+\\(I_m\\) Natural inflow of energy to the reservoir during month m (sum of \\(I_d\\)
+
+\\(\overline{W_d}\\) Maximum energy that can be generated on day d (standard credit)
+
+All following variables, defined for both stages, are related to the generic zone
+
+\\(S_d^k\\) Reservoir level at the end of day d, at the end of stage k of pre-allocation
+
+\\(S_m^k\\) Reservoir level at the end of month m, at the end of stage k of pre-allocation
+
+\\(O_d^k\\) Overflow from the reservoir on day d, at the end of stage k of pre-allocation (inflow in excess to an already full reservoir)
+
+\\(W_d^k\\) Energy to generate on day d, at the end of stage k of pre-allocation
+
+\\(W_m^k\\) Energy to generate on month m, at the end of stage k of pre-allocation
+
+
+Following variables and parameters are local to linear optimization problems \\(M\\) & \\(D(m)\\)
+solved within the heuristic. For the sake of clarity, the same generic index is used for all time steps,
+knowing that in \\(M\\) there are 12 monthly time-steps, while in \\D(m)t\\) there are from 28 to 31 daily
+time-steps. Costs \\(\gamma_{Var}\\) given to these variables are chosen to enforce a logical hierarchy
+of penalties (letting the reservoir overflow is worse than violating rule curves, which is worse than deviating
+from the generation objective assessed in stage 1, etc.)
+
+\\(Y\\) Generation deficit at the end of the period, as compared to the objective aimed at
+
+\\(O_t\\) Overflow from the reservoir on time step \\(t\\)
+
+\\(G_t, \overline{G_t}\\) Optimal generation and maximum generation on time step \\(t\\)
+
+\\(T_t\\) Generation objective assessed in the first stage, for time step t ( \\(W_m^1\\) or \\(W_d^1\\))
+
+\\(S_t, \overline{S_t}, \underline{S_t}\\) Optimal stock level, maximum level, minimum level at the end of time step \\(t\\)
+
+\\(I_t\\) Natural inflow on time step \\(t\\)
+
+\\(D_t\\) Deviation (absolute difference) between target reached and initial aim
+
+\\(\Delta\\) Maximum deviation throughout the period
+
+\\(V_t^+\\) Amplitude of the violation of the upper rule curve at time step \\(t\\)
+
+\\(V_t^-\\) Amplitude of the violation of the lower rule curve at time step \\(t\\)
+
+\\(Y\\) Maximum violation of lower rule curve throughout the period
+
+
+**General heuristic for each zone**
+
+Begin
+
+$$if not. m \{ S \leftarrow \infty ; \underline{S_d} \leftarrow 0; \overline{S_d}; S_0 \leftarrow S/2 \}$$
+
+_M1:_
+
+$$if j and \mu : for m\in [1, 12]: \{ W_m^1 \leftarrow L_m^{\alpha}. (\sum_{m}{I_m} \over \sum_{m}{L_m^{\alpha}}) \}$$
+
+$$else: for m\in [1, 12]: \{W_m^1 \leftarrow I_m\}$$
+
+
+_M2:_
+
+$$for m\in [1, 12]: W_m^2 \leftarrow Solution of linear problem M$$
+
+_D1:_
+
+$$if j: for d\in [1, 31]: \{ W_d^1 \leftarrow L_d^{\beta}. (W_m^2) \over (\sum_{d\in m}{L_d^{\beta}}) \}$$
+
+$$else: for d\in [1, 31]: \{ W_d^1 \leftarrow I_d . (W_m^2) \over (\sum_{d\in m}{I_d}) \}$$
+
+_D2:_
+
+$$for m \in [1, 12]: W_{d\in m}^2 \leftarrow Solution of linear problem D(m)$$
+
+_End_
+
+Note: In the formulation of the optimal hydro-thermal unit-commitment and dispatch problem (see dedicated document), the reference hydro energy __HIT__ used to set the right hand sides of hydro- constraints depends on the value chosen for the optimization preference "simplex range" and is defined as follows:
+
+- Daily : for each day **d** of week \\(\omega\\) : \\(HIT = W_d^2\\)
+- Weekly : for week \\(\omega$$\\): \\(HIT = \sum_{d\in \omega}{W_d^2}\\)
+
+**Optimization problem M**
+
+$$\min_{G_t, S_t, ...}{\gamma_{\Delta}\Delta + \gamma_Y Y + \sum_{t}{(\gamma_D D_t + \gamma_{V+} V_t^+ + \gamma_{V-} V_t^-)}}$$
+
+s.t
+
+$$S_t \geq 0$$
+
+$$S_t \leq S$$
+
+$$S_t + G_t - S_{t-1} = I_t$$
+
+(see note)
+
+$$\sum_{t}{G_t} = \sum_{t}{T_t}$$
+
+$$G_t - D_t \leq T_t$$
+
+$$G_t + D_t \geq T_t$$
+
+$$V_t^- + S_t \geq \underline{S_t}$$
+
+$$V_t^+ - S_t \geq -\overline{S_t}$$
+
+$$Y - V_t^- \geq 0$$
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+**Optimization problems** \\(D(m)\\)
+
+$$\min_{G_t, S_t, ...}{\gamma_{\Delta}\Delta + \gamma_Y Y + \sum_{t}{(\gamma_D D_t + \gamma_{V-} V_t^- + \gamma_{O} O_t + \gamma_S S_t)}}$$
+s.t
+
+$$S_t \geq 0$$
+
+$$S_t \leq S$$
+
+$$G_t \geq 0$$
+
+$$G_t \leq \overline{G_t}$$
+
+$$S_t + G_t + O_t - S_{t-1} = I_t$$
+
+(see note)
+
+$$\sum_{t}{G_t + Y} = \sum_{t}{T_t} + Y_{m-1}$$
+
+(value of Y previously found in solving **D(m-1)**)
+
+$$G_t - D_t \leq T_t$$
+
+$$G_t + D_t \geq T_t$$
+
+$$\Delta - D_t \geq 0$$
+
+$$V_t^- + S_t \geq \underline{S_t}$$
+
+$$Y - V_t^- \geq 0$$
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+## Conventions regarding colors and names
+
+- Names for areas, thermal plants, etc.
+ Name length should not exceed 256 characters.
+ Characters must belong to:
+ { A-Z , a-z , 0-9 , - , \_ , ( , ) , & , comma , space }
+
+
+- Colors:
+ After being entered in the GUI, some numeric fields can see their color change. The meaning of that is:
+ - Turn to red: invalid value. Saving the study in this state is possible, but the field will have to be corrected at some point in the future. Should the simulator be launched on the dataset, it will detect an error and stop.
+
+ - Turn to orange: value is valid, though unusual (user may want to double-check data).
+
+
+- Abbreviations :
+ Fields requiring to be filled out with "YES" or "NO" can alternatively accept "Y" , "1" or "N" , "0"
+ Fields requiring to be filled out with "ON" or " OFF" can alternatively accept "true", "1" or "false", "0"
+ Fields requiring to be filled out with "annual" or "monthly" can alternatively accept "a" or "m"
+ Fields requiring to be filled out with:
+ "Raw" ,"Detrended"," Beta", "Normal", "Uniform", " Gamma", " Weibull" can alternatively accept: "R", "D", " B", "N", "U", "G", "W"
+
+
+## Definition of regional districts
+
+_Typical uses of the "district" feature are:_
+
+_1) On a large system, define an "all system" zone to get an overall synthesis on all the system nodes_
+
+_2) In a study involving different countries modeled by different regions, define "country" macro-nodes to aggregate regional results to the national level._
+
+_3) In a study using some specific modeling such as PSP modeling with fake nodes, define a local cluster involving all the relevant real and fake nodes to simplify the edition of results._
+
+_Hereafter is described the process to follow to bypass the GUI for the definition of districts._
+_It is based on the edition of a special "sets.ini" file._
+
+_IMPORTANT :_
+- _Make sure that the sets.ini file is ready for use before opening the Antares study. Attempts to update the sets.ini file while the study is opened will not be effective_
+- _Definition of meaningless districts (references to nodes that do not exist,…) will generate warnings in the GUI log files_
+
+**HOW TO UPDATE / CREATE the file** _: Use Notepad (or equivalent)_
+
+**WHERE TO FIND / STORE THE FILE** _: INPUT/areas/sets.ini_
+
+_PRINCIPLE:_
+
+_The file is divided in consecutive sections, one for each district to define._
+
+_A section contains:_
+
+a) A header line that gives its name to the district. The header syntax is: `[district_name]`
+To avoid confusion with the real area names, the results regarding this macro-area will later be found in the OUTPUT files under a name bearing the prefix "@", i.e. `@district_name`
+
+_b) A list of parametrized building rules to be processed in their apparition order_
+
+_The different elementary rules are:_
+
+_+= area\_name : add the area "area\_name" to the district_
+_-= area\_name : remove the area "area\_name" from the district_
+_apply-filter = add-all : add all areas to the district_
+_apply-filter = remove-all : remove all areas (clear the district)_
+
+_c) A special "output" parameter that defines whether the results for the district will actually be computed or not
+(this latter option allows inactivating parts of the sets.ini without altering the file)_
+
+_The syntax is: `output=false` or `output= true`
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+**EXAMPLES OF SETS.INI FILES**
+
+a) File defining a single district named "set1" involving three areas named "area1, area3, area42":
+
+```ini
+[set1]
++ = area1
++ = area3
++ = area42
+output = true
+```
+
+b) File defining a district gathering all areas but five:
+
+```ini
+[most of the system
+apply-filter = add-al
+- = country
+- = neighbour
+- = fake antenna 1
+- = region
+- = region 3
+output = true
+```
+c) File defining two districts, the current simulation will ignore the second one:
+
+```ini
+[All countries]
+apply-filter= add-all
+output=true
+
+
+[All but one]
+apply-filter = add-all
+-= special region 12
+output=false
+```
+
+## The Annual System Cost Output file
+
+In addition to the general files introduced in [Output Files](#output-files), the Output folder of each economic or adequacy simulation includes, at its root, a file "Annual\_System\_Cost.txt" It presents the metrics of a global Monte-Carlo variable further denoted ASC
+
+The value of ASC for any given simulated year is defined as the sum, over all areas and links, of the annual values of the area-variable "OV.COST" and of the link-variable "HURD. COST".
+
+The metrics displayed in the "Annual system cost" file take the form of four values:
+
+- Expectation EASC
+
+- Standard deviation SASC
+
+- Minimum LASC
+
+- Maximum UASC
+
+As with all other random variables displayed in the Antares Output section, the computed standard deviation of the variable can be used to give a measure of the confidence interval attached to the estimate of the expectation. For a number of Monte-Carlo years N, the law of large numbers states for instance that there is a 95 \% probability for the actual expectation of ASC to lie within the interval:
+
+**EASC +/- 1.96 (SASC / sqrt(N))**
+
+There is also a 99.8 \% probability that it lies within the interval:
+
+**EASC +/- 3 (SASC / sqrt(N))**
+
+##
+
+## The "export mps" optimization preference
+
+_This preference can be set either on "false" or "true". Choosing either value does not influence the way calculations are carried out, nor does it change their results._
+
+_The effect of this preference is that, if the "true" value is selected, Antares will produce and store in the simulation output folder two files for every linear problem solved in the whole simulation._
+
+_The first file ("problem" file) contains a standardized description of the mathematical problem solved by Antares' built-in linear solver. The format standard used in this file is known as "mps"._
+
+_The second file ("criterion" file) contains the value of the optimal (minimum) value found for the objective function of the optimization problem (overall system cost throughout a day or a week)._
+
+_All commercial as well as Open Source linear solvers are able to process mps files. As a consequence, tests aiming at comparing Antares' solver with other commercial solutions can be easily carried out: all that has to be done is to submit the mps problem to the solver at hand and measure its performances (calculation time, criterion value) with those of Antares._
+
+_Note that this kind of comparisons brings no information regarding the quality of the physical modelling on which the simulation is based. It is useful, however, to gather evidence on mathematical grounds._
+
+_File names are structured as follows:_
+
+- _When the optimization preference "simplex range" is set on "week":_
+ _Problem-MC year-week number-date-time.mps_
+ _Criterion-MC year-week number-date-time.txt_
+
+- _When the optimization preference "simplex range" is set on "day":_
+ _Problem-MC year-week number-date-time-day number.mps_
+ _Criterion-MC year-week number-date-time-day number.txt_
+
+_Besides, each economic problem generally demands to be solved through two successive optimization problems. Files related to these two problems will bear almost the same name, the only difference being the "time" suffix. The files related to the second optimization (final Antares results) are those that bear the latest tag._
+
+_Finally, it is possible that, on special occasions (very small files), the files attached to the two optimization rounds begin to be printed within the same second. In that case, an additional suffix is added before the mps or txt extension._
+
+**Note that:**
+
+- _The disk space used to store mps file is not included in the disk resources assessment displayed in the resources monitor menu_
+
+- _The extra runtime and disk space resulting from the activation of the "mps" option may be quite significant. This option should therefore be used only when a comparison of results with those of other solvers is actually intended._
+
+## The "Unfeasible Problems Behavior" optimization preference
+
+_This preference can take any of the four values:_
+
+_Error Dry, Error Verbose, Warning Dry, Warning Verbose_
+
+_If "Error Dry" or "Error Verbose" is selected, the simulation will stop right after encountering the first mathematically unfeasible optimization (daily or weekly) problem. No output will be produced beyond this point. Should the dataset contain several unfeasible problems (i.e. regarding different weeks of different MC years), it is possible that successive runs of the same simulation stop at different points (if parallel computation is used, the triggering problem may differ from one run to the other)._
+
+_If "Warning Dry" or "Warning Verbose" is selected, the simulation will skip all mathematically unfeasible optimization (daily or weekly) problems encountered, fill out all results regarding these problems with zeroes and resume the simulation. The hydro reservoir levels used for resuming the simulation are those reached at the end of the last successful week._
+
+_With "Dry" options no specific data are printed regarding the faulty problem(s). With "Verbose" options, the full expression of the faulty problem(s) is printed in the standard "mps" format, thus allowing further analysis of the infeasibility issue._
+
+## The "Reservoir Level Initialization" advanced parameter
+
+_This parameter can take the two values "cold start" or "hot start". [default: cold start]. Simulations results may in some circumstances be heavily impacted by this setting, hence proper attention should be paid to its meaning before considering changing the default value._
+
+**General:**
+
+_This parameter is meant to define the initial reservoir levels that should be used, in each system area, when processing data related to the hydro-power storage resources to consider in each specific Monte-Carlo year (see [Active windows](#active-windows))._
+
+_As a consequence, Areas which fall in either of the two following categories are not impacted by the value of the parameter:_
+- _No hydro-storage capability installed_
+- _Hydro-storage capability installed, but the "reservoir management" option is set to "False"_
+
+_Areas that have some hydro-storage capability installed and for which explicit reservoir management is required are concerned by the parameter. The developments that follow concern only this category of Areas._
+
+**Cold Start:**
+
+_On starting the simulation of a new Monte-Carlo year, the reservoir level to consider in each Area on the first day of the initialization month (see [Active windows](#active-windows)) is randomly drawn between the extreme levels defined for the Area on that day._
+
+_More precisely:_
+
+- The value is drawn according to the probability distribution function of a "Beta" random variable, whose four internal parameters are set so as to adopt the following behavior:
+ Lower bound: Minimum reservoir level.
+ Upper bound: Maximum reservoir level
+ Expectation: Average reservoir level
+ Standard Deviation: (1/3) (Upper bound-Lower bound)
+
+- The random number generator used for that purpose works with a dedicated seed that ensures that results can be reproduced
+ [17] from one run to another, regardless of the simulation runtime mode (sequential or parallel)
+ and regardless of the number of Monte-Carlo years to be simulated [18].
+
+**Hot Start:**
+
+_On starting the simulation of a new Monte-Carlo year, the reservoir level to consider in each Area on the first day of the initialization month is set to the value reached at the end of the previous simulated year, if three conditions are met:_
+
+- _The simulation calendar is defined throughout the whole year, and the simulation starts on the day chosen for initializing the reservoir levels of all Areas._
+
+- _The Monte-Carlo year considered is not the first to simulate, or does not belong to the first batch of years to be simulated in parallel. In sequential runtime mode, that means that year #N may start with the level reached at the end of year #(N-1). In parallel runtime mode, if the simulation is carried out with batches of B years over as many CPU cores, years of the k-th batch_
+ _# 19_ _may start with the ending levels of the years processed in the (k-1)-th batch._
+
+- _The parallelization context (see [System requirements](#ystem-requirements)) must be set so as to ensure that the M Monte-Carlo years to simulate will be processed in a round number of K consecutive batches of B years in parallel (i.e. M = K\*B and all time-series refresh intervals are exact multiple of B)._
+
+_The first year of the simulation, and more generally years belonging to the first simulation batch in parallel mode, are initialized as they would be in the cold start option._
+
+**Note that:**
+
+- _Depending on the hydro management options used, the amount of hydro-storage energy generated throughout the year may either match closely the overall amount of natural inflows of the same year, or differ to a lesser or greater extent. In the case of a close match, the ending reservoir level will be similar to the starting level. If the energy generated exceeds the inflows (either natural or pumped), the ending level will be lower than the starting level (and conversely, be higher if generation does not reach the inflow credit). Using the "hot start" option allows to take this phenomenon into account in a very realistic fashion, since the consequences of hydro decisions taken at any time have a decisive influence on the system's long term future._
+
+- _When using the reservoir level "hot start" option, comparisons between different simulations make sense only if they rely on the exact same options, i.e. either sequential mode or parallel mode over the same number of CPU cores._
+
+- _More generally, it has to be pointed out that the "hydro-storage" model implemented in Antares can be used to model "storable" resources quite different from actual hydro reserves: batteries, gas subterraneous stocks, etc._
+
+## The "Hydro Heuristic policy" advanced parameter
+
+_This parameter can take the two values "Accommodate rule curves" or "Maximize generation". [default: Accommodate rule curves]._
+
+**General:**
+
+_This parameter is meant to define how the reservoir level should be managed throughout the year, with emphasis put either on the respect of rule curves or on the maximization of the use of natural inflows._
+
+**Accommodate rule curves:**
+
+_Upper and lower rule curves are accommodated in both monthly and daily heuristic stages (described page 58). In the second stage, violations of the lower rule curve are avoided as much as possible (penalty cost on Y. higher than penalty cost on Y). This policy may result in a restriction of the overall yearly energy generated from the natural inflows._
+
+**Maximize generation:**
+
+_Upper and lower rule curves are accommodated in both monthly and daily heuristic stages (described page 58). In the second stage, incomplete use of natural inflows is avoided as much as possible (penalty cost on Y higher than penalty cost on Y). This policy may result in violations of the lower rule curve._
+
+## The "Hydro Pricing mode" advanced parameter
+
+_This parameter can take the two values "fast" or "accurate". [default: fast]._
+
+_Simulations carried out in "accurate" mode yield results that are theoretically optimal as far as the techno-economic modelling of hydro (or equivalent) energy reserves is concerned. It may, however, require noticeably longer computation time than the simpler "fast" mode._
+
+_Simulations carried out in "fast" mode are less demanding in computer resources. From a qualitative standpoint, they are expected to lead to somewhat more intensive (less cautious) use of stored energy._
+
+**General:**
+
+_This parameter is meant to define how the reservoir level difference between the beginning and the end of an optimization week should be reflected in the hydro economic signal (water value) used in the computation of optimal hourly generated /pumped power during this week._
+
+**Fast:**
+
+_The water value is taken to remain about the same throughout the week, and a constant value equal to that found at the date and for the level at which the week_ **begins** _is used in the course of the optimization. A value interpolated from the reference table for the exact level reached at each time step within the week is used ex-post in the assessment of the variable "H.COST" (positive for generation, negative for pumping) defined in [Output Files](#output-files). This option should be reserved to simulations in which computation resources are an issue or to simulations in which level-dependent water value variations throughout a week are known to be small._
+
+**Accurate:**
+
+_The water value is considered as variable throughout the week. As a consequence, a different cost is used for each "layer" of the stock from/to which energy can be withdrawn/injected, in an internal hydro merit-order involving the 100 tabulated water-values found at the date at which the week_ **ends**_. A value interpolated from the reference table for the exact level reached at each time step within the week is used ex-post in the assessment of the variable "H.COST" (positive for generation, negative for pumping) defined in [Output Files](#output-files). This option should be used if computation resources are not an issue and if level-dependent water value variations throughout a week must be accounted for._
+
+
+## The "Unit Commitment mode" advanced parameter
+
+_This parameter can take the two values "fast" or "accurate". [default: fast]._
+
+_Simulations carried out in "accurate" mode yield results that are expected to be close to the theoretical optimum as far as the techno-economic modelling of thermal units is concerned. They may, however, require much longer computation time than the simpler "fast" mode._
+
+_Simulations carried out in "fast" mode are less demanding in computer resources. From a qualitative standpoint, they are expected to lead to a more costly use of thermal energy. This potential bias is partly due to the fact that in this mode, start-up costs do not participate as such to the optimization process but are simply added ex post._
+
+**General:**
+
+_In its native form # 20, the weekly optimization problem belongs to the MILP (Mixed Integer Linear Program) class. The Integer variables reflect, for each time step, the operational status (running or not) of each thermal unit. Besides, the amount of power generated from each unit can be described as a so-called semi-continuous variable (its value is either 0 or some point within the interval [Pmin , Pmax]). Finally, the periods during which each unit is either generating or not cannot be shorter than minimal (on- and off-) thresholds depending on its technology._
+
+_The Unit Commitment mode parameter defines two different ways to address the issue of the mathematical resolution of this problem. In both cases, two successive so-called "relaxed" LP global optimizations are carried out. In-between those two LPs, a number of local IP (unit commitment of each thermal cluster) are carried out._
+
+_Besides, dynamic thermal constraints (minimum on- and off- time durations) are formulated on time-indices rolling over the week; this simplification brings the ability to run a simulation over a short period of time, such as one single week extracted from a whole year, while avoiding the downside (data management complexity, increased runtime) of a standard implementation based on longer simulations tiled over each other (illustration below)._
+
+
+
+
+
+**Fast:**
+
+_In the first optimization stage, integrity constraints are removed from the problem and replaced by simpler continuous constraints._
+
+_For each thermal cluster, the intermediate IP looks simply for an efficient unit-commitment compatible with the operational status obtained in the first stage, with the additional condition (more stringent than what is actually required) that on- and off- periods should be exact multiple of the higher of the two thresholds specified in the dataset._
+
+_In the second optimization stage, the unit commitment set by the intermediate IPs is considered as a context to use in a new comprehensive optimal hydro-thermal schedule assessment. The amount of day-ahead (spinning) reserve, if any, is added to the demand considered in the first stage and subtracted in the second stage. Start-up costs as well as No-Load Heat costs are assessed in accordance with the unit-commitment determined in the first stage and are added ex post._
+
+**Accurate:**
+
+_In the first optimization stage, integrity constraints are properly relaxed. Integer variables describing the start-up process of each unit are given relevant start-up costs, and variables attached to running units are given No-Load Heat costs (if any), regardless of their generation output level. Fuel costs / Market bids are attached to variables representing the generation output levels._
+
+_For each thermal cluster, the intermediate IP looks for a unit-commitment compatible with the integrity constraints in the immediate neighborhood of the relaxed solution obtained in the first stage. In this process, the dynamic thresholds (min on-time, min off-time) are set to their exact values, without any additional constraint._
+
+_In the second optimization stage, the unit commitment set by the intermediate IP is considered as a context to use in a new comprehensive optimal hydro-thermal schedule assessment. The amount of day-ahead (spinning) reserve, if any, is added to the demand considered in the first stage and subtracted in the second stage._
+
+## The "Renewable Generation modeling" advanced parameter
+
+_This parameter can take the two values “aggregated” or “cluster”. For a new study, it will default to cluster. For a legacy (Antares version <8.1.0) study it will default to aggregated._
+
+_If the parameter is set to "aggregated”, the user will have access to the Wind & Solar windows, but not the Renewable window. When the parameter is set to “cluster", the Renewable window will be available, but not the Wind nor the Solar windows. The data stored in the windows that are not available will always be conserved. However, only Renewable data (and not the wind and solar data) will be considered for the calculations when the parameter is set to “cluster”. And only the wind and solar data (and not the renewable data) will be considered for the calculations when the parameter is set to “aggregated”._
+
+_The Renewable window can be filled out with the different renewable clusters inside each node. Each renewable cluster needs to have a group specified or will default to the «Other RES 1» group. Production Timeseries can be filled out much like the Thermal production ones. Note that unlike thermal clusters, negative production values are allowed. The Renewable window is described in more details in the “4. Active Windows” section. In the Simulation window, only “Ready-made” timeseries can be selected for renewables for now. This should be modified in a future release. The MC scenario builder for Renewables works the same way as for Thermal Clusters._
+
+# 9 System requirements
+
+## Operating system
+
+_Antares\_Simulator code is cross-platform (Windows/Linux/Unix) and installation packages for various versions of these OS are available at:_ [_https://antares-simulator.org_](https://antares-simulator.org/)
+
+## Hard drive disk
+
+_Installed alone, the Antares simulator does not require a lot of HDD space (less than 1 GB). Installation packages including companion tools (study manager, graph editor) are however significantly heavier. The proper storage of data (i.e. both Input and Output folders of Antares studies) may require a large amount of space. The disk footprint of any individual study mainly depends on:_
+
+- _The size of the power system modeled (number of Areas, Links, Thermal clusters, etc.)_
+- _The number of ready-made Time-Series and the number of Time-Series to be generated at runtime and stored afterwards_
+- _The activation of output filters (Geographic Trimming and / or Thematic Trimming)_
+- _The number of Monte-Carlo years involved in the simulation session (if the storage of detailed year-by-year results is requested)_
+- _The status of the "export mps" optimization preference_
+
+_At any moment, the amount of disk resources required for a simulation is accessible through the Tools/resources monitor menu_
+
+## Memory
+
+_The amount of RAM required for a simulation depends on:_
+
+- _The size of the power system modeled (number of Areas, Links, Thermal clusters, etc.)_
+- _The number of ready-made Time-Series and that of Time-Series to be generated at runtime_
+- _The simulation mode (draft, adequacy, economy with "fast" or "accurate" unit commitment)_
+- _The execution mode (swap, default, parallel)_
+
+_At any moment, the amount of RAM resources required for a simulation is accessible through the Tools/resources monitor menu_
+
+## Multi-threading
+
+_The GUI of Antares and all I/O operations on Input / Output files automatically benefit from full multi-threading on the local machine's CPU cores. Multi-threading is also available on the proper calculation side, on a user-defined basis._
+
+_Provided that hardware resources are large enough, this mode may reduce significantly the overall runtime of heavy simulations._
+
+_To benefit from multi-threading, the simulation must be run in the following context:_
+
+- _In the "run" window, the option "parallel" must be selected_
+ _# 21_
+- _The simulation mode must be either "Adequacy" or "Economy"_
+ _# 22_
+
+_When the "parallel" solver option is used, each Monte-Carlo year is dispatched as an individual process on the available CPU cores._
+_The number of such individual processes depends on the characteristics of the local hardware and on the value given to the study-dependent " __**simulation cores**__" advanced parameter. This parameter can take five different values (Minimum, Low, Medium, High, Maximum). The number of independent processes resulting from the combination (local hardware + study settings) is given in the following table, which shows the CPU allowances granted in the different configurations._
+
+**Simulation Cores:**
+
+| _Machine_
_Size # 23_ | _Minimum_ | _Low_ | _Medium_ | _Large_ | _Maximum_ |
+|:---:|:---:|:---:|:---:|:---:|:---:|
+| _1_ | 1 | 1 | 1 | 1 | 1 |
+| _2_ | 1 | 1 | 1 | 2 | 2 |
+| _3_ | 1 | 2 | 2 | 2 | 3 |
+| _4_ | 1 | 2 | 2 | 3 | 4 |
+| _5_ | 1 | 2 | 3 | 4 | 5 |
+| _6_ | 1 | 2 | 3 | 4 | 6 |
+| _7_ | 1 | 2 | 3 | 5 | 7 |
+| _8_ | 1 | 2 | 4 | 6 | 8 |
+| _9_ | 1 | 3 | 5 | 7 | 8 |
+| _10_ | 1 | 3 | 5 | 8 | 9 |
+| _11_ | 1 | 3 | 6 | 8 | 10 |
+| _12_ | 1 | 3 | 6 | 9 | 11 |
+| _S > 12_ | 1 | Ceil(S/4) | Ceil(S/2) | Ceil(3S/4) | S-1 |
+
+**CPU allowances in parallel mode**
+
+**Note**_: The number of independent threads actually launched by Antares in parallel mode may appear smaller than that shown in the table above. In this case, the resources monitor menu and the dashboard displayed on starting the simulation indicates:_
+
+_simulation cores:_ **nn** _reduced to_ **pp**
+
+**nn** _is the regular allowance and_ **pp** _is the practical value that the solver has to work with. Allowance reduction may occur if the built-in Time-Series generators are activated, their "refresh" status is set to "Yes" and the values given to the "refresh span" parameters are not appropriate (parallel execution demand that refresh operations do not take place within a bundle of parallel years). Optimal use of the "parallel" execution mode is obtained when all activated built-in time –series generators are set up in either of the two following ways:_
+- _Refresh status :_ **No**
+- _Refresh status :_ **Yes**_, refresh span =_ _**Ki \* (CPU allowance)**_ _, with_ **Ki >= 1**
+
+_Examples of reduction from an initial allowance of 12 cores are given hereafter. The reduced allowance is the size of the_ **smallest** _bundle of parallel years between two consecutive "refresh" (it indicates the slowest point of the simulation # 24). Note that RAM requirements displayed in the resources monitor are, contrariwise, assessed on the basis on the **largest** bundle of parallel years encountered in the simulation)._
+
+Built-in TS generators status / refresh span # 25 | **Reduced Allowance (from 12)**
+
+| Load | Thermal | Hydro | Wind | Solar | MC Years : 80 | MC years: 400 |
+|:---:|:---:|:---:|:---:|:---:|:---:|:---:|
+| _50_ | _1_ | _50_ | _50_ | _50_ | 1 | 1 |
+| _No_ | _10_ | _50_ | _No_ | _No_ | 10 | 10 |
+| _No_ | _11_ | _50_ | _No_ | _No_ | 5 | 1 |
+| _No_ | _100_ | _100_ | _100_ | _100_ | **No reduction** | 4 # 26 |
+| **No** | **12** | **12** | **12** | **No** | **No reduction** | **No reduction** |
+| **12** | **24** | **48** | **48** | **36** | **No reduction** | **No reduction** |
+
+
+# 10 Using the command line
+
+_Several executable parts of Antares\_Simulator can be run in command line from a console. The list and general syntax of these components is given hereafter._
+
+_In all cases, arguments " –h" or "–help" can be used to get help_
+
+**antares-8.1-solver**
+**antares-8.1-solver-swap** (simulation in low-RAM swap mode)
+
+- Simulation
+
+|command|meaning|
+|:---|:---|
+|-i, --input | Study folder |
+|--expansion | Force the simulation in expansion mode |
+|--economy | Force the simulation in economy mode |
+|--adequacy | Force the simulation in adequacy mode |
+|--draft | Force the simulation in adequacy-draft mode |
+|--parallel | Enable the parallel computation of MC years |
+|--force-parallel=VALUE | Override the max number of years computed simultaneously |
+
+- Parameters
+
+|command|meaning|
+|:---|:---|
+|-n, --name=VALUE | Set the name of the new simulation to VALUE |
+|-g, --generators-only | Run the time-series generators only |
+|-c, --comment-file=VALUE | Specify the file to copy as comments of the simulation |
+|-f, --force | Ignore all warnings at loading |
+|--no-output | Do not write the results in the output folder |
+|-y, --year=VALUE | Override the number of MC years |
+|--year-by-year | Force the writing the result output for each year
(economy only) |
+|--derated | Force the derated mode |
+
+- Optimization
+
+|command|meaning|
+|:---|:---|
+|--optimization-range | Force the simplex optimization range ('day' or 'week') |
+|--no-constraints | Ignore all binding constraints|
+|--no-ts-import | Do not import timeseries into the input folder.
(This option may be useful for running old studies without upgrade)|
+|--mps-export | Export weekly or daily optimal UC+dispatch linear |
+
+- Misc.
+
+|command|meaning|
+|:---|:---|
+|--progress | Display the progress of each task |
+|--swap-folder=VALUE | Folder where the swap files will be written. This
option has effect only in swap mode (swap files are only
available for 'antares-solver-swap') |
+|-p, --pid=VALUE | Specify the file where to write the process ID |
+|-v, --version | Print the version of the solver and exit |
+|-h, --help | Display this help and exit |
+|--use-ortools --ortools-solver= Sirius | Use the standard Antares solver through the OR-Tools modelling library |
+|--use-ortools --ortools-solver= Coin | Use the Coin solver through the OR-Tools modelling library |
+
+**antares-8.1-study-updater**
+
+|command|meaning|
+|:---|:---|
+|-i, --input=VALUE | Add an input folder where to look for studies
This argument is mandatory.|
+|-c, --clean | Clean all studies found |
+|--remove-generated-timeseries | Remove time-series which will be regenerated by
the ts-generators |
+|-d, --dry | List the study folders which may be upgraded and do nothing else |
+|--force-readonly | Force read-only mode for all studies found |
+|-v, --version | Print the version and exit |
+|-h, --help | Display this help and exit |
+
+**antares-8.1-study-finder**
+
+|command|meaning|
+|:---|:---|
+|-i, --input=VALUE | Add an input folder where to look for studies.
When no input folder is given, the current working dir is used. |
+|-e, --extra | Print the version of the study |
+|--csv | Print in a CSV format (semicolon) |
+|-v, --version | Print the version and exit |
+|-h, --help | Display this help and exit |
+
+**antares-8.1-study-cleaner**
+
+|command|meaning|
+|:---|:---|
+|-i, --input=VALUE | An input folder where to look for studies |
+|--dry | List the folder only and do nothing |
+|--mrproper | Suppress the outputs and logs files |
+|-v, --version | Print the version and exit |
+|-h, --help | Display this help and exit |
+
+**antares-8.1-config**
+
+|command|meaning|
+|:---|:---|
+|-p, --print | Print the current configuration |
+|-v, --version | Print the version and exit |
+|-h, --help | Display this help and exit |
+
+**antares-8.1-batchrun**
+
+- Studies
+
+|command|meaning|
+|:---|:---|
+|-i, --input=VALUE | The input folder, where to look for studies on which to run simulations |
+
+- Simulation mode
+
+|command|meaning|
+|:---|:---|
+|--expansion | Force the simulation(s) in expansion mode |
+|--economy | Force the simulation(s) in economy mode |
+|--adequacy | Force the simulation(s) in adequacy mode |
+
+- Parameters
+
+|command|meaning|
+|:---|:---|
+|-n, --name=VALUE | Set the name of the new simulation outputs |
+|-y, --year=VALUE | Override the number of MC years |
+|-f, --force | Ignore all warnings at loading |
+|--no-output | Do not write the results in the output folder |
+|--year-by-year | Force the writing of the result output for each year |
+
+- Optimization
+
+|command|meaning|
+|:---|:---|
+|--no-ts-import | Do not import timeseries into the input folder. |
+|--no-constraints | Ignore all binding constraints |
+
+- Extras
+
+|command|meaning|
+|:---|:---|
+|--solver=VALUE | Specify the antares-solver location |
+|-s, --swap | Swap mode |
+|--parallel | Enable the parallel computation of MC years |
+|--force-parallel=VALUE | Override the max number of years computed simultaneously |
+|--verbose |Display detailed logs for each simulation to run |
+
+
+**APPENDIX : ATTRIBUTION NOTICES**
+
+**Antares\_Simulator**
+
+**Copyright 2007-2021 RTE - Authors: The Antares\_Simulator Team**
+
+Antares\_Simulator is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
+
+There are special exceptions to the terms and conditions of the license as they are applied to this software. View the full text of the exceptions in file COPYING.txt in the directory of a distribution of the software in source form.
+
+Antares\_Simulator is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
+
+You should have received a copy of the GNU General Public License along with Antares\_Simulator. If not, see <http://www.gnu.org/licenses/ >.
+
+**Antares\_Simulator 8.1.0 uses external libraries and makes extensive use of the following persons' or companies code. Source and binary forms of these programs are distributed along with Antares\_Simulator with NO WARRANTY:**
+
+- Wxwidgets 3.0.2 Copyright (c) 1998-2017 The wxWidget Team
+ license: wxWindows Library License,V3.1 https://spdx.org/licenses/wxWindows.html
+
+- libYuni 1.1.0 https://github.com/libyuni
+ license: Mozilla Public License 2.0 https://spdx.org/licenses/MPL-2.0.html
+
+- Mersenne Twister Copyright (c) 1997-2002 M.Matsumoto and T.Nishimura
+ license: 3-clause BSD https://spdx.org/licenses/BSD-3-Clause.html
+
+- strtod library Copyright (c) 1988-1993 The Regents of the University of California
+ Copyright (c) 1994 Sun Microsystems, Inc
+ license: ISC license https://spdx.org/licenses/ISC.html
+
+- Sirius\_Solver Copyright (c) 2007-2018 RTE
+ https://github.com/rte-france/sirius-solver.git
+ license: Apache 2.0 https://spdx.org/licenses/Apache-2.0.html
+
+- OR-Tools Copyright (c) 2010-2020 Google LLC
+ https://github.com/rte-france/or-tools.git
+ license: Apache 2.0 https://spdx.org/licenses/Apache-2.0.html
+
+
+[1](#sdfootnote1anc)For simplicity's sake, the _**Antares\_Simulator**_ 8.1.0 application will as of now be simply denoted "Antares".
+
+[2](#sdfootnote2anc) A detailed expression of the basic mathematical problem solved in the red box of the following figure can be found in the document "Optimization problems formulation".
+
+[3](#sdfootnote3anc) Many various graphic extensions (under the form of programs written in the R language) are available at :
+
+[https://cran.r-project.org/web/packages/antaresViz/index.html](https://cran.r-project.org/web/packages/antaresViz/index.html)
+
+[4](#sdfootnote4anc)_Weekly optimization performs a more refined unit commitment, especially when the level selected in the "advanced parameters" menu is "accurate"._
+
+[5](#sdfootnote5anc) "Economy" simulations make a full use of Antares optimization capabilities. They require economic as well as technical input data and may demand a lot of computer resources. "Adequacy" simulations are faster and require only technical input data. Their results are limited to adequacy indicators. "Draft" simulations are highly simplified adequacy simulations, in which binding constraints (e.g. DC flow rules) are ignored, while hydro storage is assumed to be able to provide its nominal maximum power whenever needed. As a consequence, draft simulations are biased towards optimism. They are, however, much faster than adequacy and economic simulations.
+
+[6](#sdfootnote6anc)In Economy an Adequacy simulations, these should be chosen so as to make the simulation span a round number of weeks. If not, the simulation span will be truncated: for instance, (1, 365) will be interpreted as (1, 364), i.e. 52 weeks (the last day of the last month will not be simulated). In Draft simulations, the simulation is always carried out on 8760 hours.
+
+[7](#sdfootnote7anc) changing the number of MC years will reset the playlist to its default value ; not available in Draft simulations
+
+[8](#sdfootnote8anc)Not available in Draft simulations
+
+[9](#sdfootnote9anc)KCG : Kirchhoff's constraints generator (see section 7)
+
+[10](#sdfootnote10anc)A typical case is given by the "Flow-Based" framework today implemented in a large portion of the European electricity market.
+
+[11](#sdfootnote11anc)This description applies to both « MC synthesis » files and "Year-by-Year" files, with some simplifications in the latter case
+
+[12](#sdfootnote12anc)Value identical to that defined under the same name in the "Misc Gen" input section.
+
+[13](#sdfootnote13anc)NODU and NP Cost do not appear in "Adequacy" results since these variables are irrelevant in that context
+
+[14](#sdfootnote14anc)This description applies to both « MC synthesis » files and "Year-by-Year" files, with some simplifications in the latter case
+
+[15](#sdfootnote15anc) The number of spanning trees is equal to the absolute value of any cofactor of the graph incidence matrix
+
+[16](#sdfootnote16anc) Mehlhorn K., Michail D. (2005) _Implementing Minimum Cycle Basis Algorithms_. In: Experimental and Efficient Algorithms. WEA 2005. Lecture Notes in Computer Science, vol 3503.
+
+[17](#sdfootnote17anc)As long as the System's list of Areas does not change
+
+[18](#sdfootnote18anc)E.g. : if three playlists A,B,C are defined over 1000 years (A: years 1 to 1000, B: years 1 to 100, C: Years 13,42,57,112), initial reservoir levels in each Area are identical in the playlists' intersection (years 13,42,57)
+
+[19](#sdfootnote19anc)If the playlist is full, these years have numbers # (k-1)B+1 ,…., #kB
+
+[20](#sdfootnote20anc)Described in the note "Optimization Problems Formulation"
+
+[21](#sdfootnote21anc) Options « default » and « swap » do not perform multi-threaded optimizations
+
+[22](#sdfootnote22anc) The « draft » mode is not multi-threaded
+
+[23](#sdfootnote23anc) This hardware characteristic, independent from Antares general parameters and from study parameters, can be checked with the Resources monitor tool ([Commands](#commands))
+
+[24](#sdfootnote24anc)When the number of MC years to run is smaller than the allowance, the parallel run includes all of these years in a single bundle and there is no "reduced allowance" message
+
+[25](#sdfootnote25anc) The Table indicates either the refresh status (No) or the refresh span (the associated refresh status "yes" is implicit)
+
+[26](#sdfootnote26anc) The smallest bundle in this case is the ninth (year number 97 to year number 100). The first 8 bundles involve 12 MC years each
+
+Copyright © RTE 2007-2021 – Version 8.1.0
+
+Last Rev : H. Antoine - 21 SEPT 2021
diff --git a/docs/reference-guide/1-reference-guide_8_1_tocheck.md b/docs/reference-guide/1-reference-guide_8_1_tocheck.md
new file mode 100644
index 0000000000..a651736b8e
--- /dev/null
+++ b/docs/reference-guide/1-reference-guide_8_1_tocheck.md
@@ -0,0 +1,5253 @@
+
+# Antares_Simulator 8.1.0 reference guide
+
+## Introduction
+
+This document describes all of the main features of the
+***Antares\_Simulator*** package, version 8.1.0.
+
+It gives useful general information regarding the way data are handled
+and processed, as well as how the Graphic User Interface (GUI) works. So
+as to keep this documentation as compact as possible, many redundant
+details (how to mouse-select, etc.) are omitted.
+
+Some features described in this guide are not fully operational in 8.1.0
+version. Features not yet available appear in grey in the GUI.
+
+Real-life use of the software involves a learning curve process that
+cannot be supported by a simple reference guide. So as to be able to
+address this basic issue, two kinds of resources may be used:
+
+- The examples library, which is meant as a self-teaching way to learn
+ how to use the software. It is enhanced in parallel to the
+ development of new features. The content of this library may depend
+ on the type of installation package it comes from (general public or
+ members of the users’ club).
+
+- The
+ [https://antares-simulator.org](https://antares-simulator.org)
+ website
+
+Please report misprints or other errors to:
+
+[support@antares-simulator.org](mailto:support@antares-simulator.org)
+
+## General content of Antares\_Simulator sessions
+
+A typical ***Antares\_Simulator*** \[1\]session involves different steps
+that are usually run in sequence, either automatically or with some
+degree of man-in-the-loop control, depending on the kind of study to
+perform.
+
+These steps most often involve:
+
+1) GUI session dedicated to the initialization or to the updating of
+ various input data sections (time-series of many kinds, grid
+ topology, generating fleet description, etc.)
+
+2) GUI session dedicated to the definition of simulation contexts
+ (definition of the number and consistency of the “Monte-Carlo years”
+ to simulate)
+
+3) Simulation session producing actual numeric scenarios following the
+ directives defined in (b)
+
+4) Optimization session aiming at solving all of the optimization
+ problems associated with each of the scenarios produced in (c).
+
+5) GUI session dedicated to the exploitation of the detailed results
+ yielded by (d)
+
+The scope of this document is to give a detailed description of the
+software involved in step (a) to (e) mostly based on a functional
+approach, leaving thereby aside a significant part of the mathematical
+content involved in several of these steps.\[2\]
+
+The following picture gives a functional view of all that is involved in
+steps (a) to (e).
+
+
+
+The number and the size of the individual problems to solve (typically,
+a least-cost hydro-thermal power schedule and unit commitment, with an
+hourly resolution and throughout a week, over a large interconnected
+system) make optimization sessions often computer-intensive.
+
+Depending on user-defined results accuracy requirements, various
+practical options allow to simplify either the formulation of the
+problems or their resolution.
+
+In terms of power studies, the different fields of application Antares
+has been designed for are the following:
+
+- **Generation adequacy problems :** assessment of the need for new
+ generating plants so as to keep the security of supply above a given
+ critical threshold
+
+> What is most important in these studies is to survey a great number of
+> scenarios that represent well enough the random factors that may
+> affect the balance between load and generation. Economic parameters do
+> not play as much a critical role as they do in the other kinds of
+> studies since the stakes are mainly to know if and when supply
+> security is likely to be jeopardized (detailed costs incurred in more
+> ordinary conditions are of comparatively lower importance). In these
+> studies, the default Antares option to use is the “Adequacy”
+> simulation mode, or the “Draft” simulation mode (which is extremely
+> fast but which produces crude results).
+
+- **Transmission project profitability :** assessment of the savings
+ brought by a specific reinforcement of the grid, in terms of
+ decrease of the overall system generation cost (using an assumption
+ of fair and perfect market) and/or improvement of the security of
+ supply (reduction of the loss-of-load expectation).
+
+> In these studies, economic parameters and the physical modeling of the
+> dynamic constraints bearing on the generating units are of paramount
+> importance. Though a thorough survey of many “Monte-Carlo years” is
+> still required, the number of scenarios to simulate is not as large as
+> in generation adequacy studies. In these studies, the default Antares
+> option to use is the “Economy” simulation mode.
+
+The common rationale of the modeling used in all of these studies is,
+whenever it is possible, to decompose the general issue (representation
+of the system behavior throughout many years, with a time step of one
+hour) into a series of standardized smaller problems.
+
+In Antares, the “elementary“ optimization problem resulting from this
+approach is that of the minimization of the overall system operation
+cost over a week, taking into account all proportional and
+non-proportional generation costs, as well as transmission charges and
+“external” costs such as that of the unsupplied energy (generation
+shortage) or, conversely, that of the spilled energy (generation
+excess). In this light, carrying out generation adequacy studies or
+transmission projects studies means formulating and solving a series of
+a great many week-long operation problems (one for each week of each
+Monte-Carlo year), assumed to be independent to some extent (note that,
+however, issues such as the management of hydro resources – or possibly
+other kinds of energy storage facilities- may bring a significant
+coupling between the successive problems, which needs to be addressed
+properly).
+
+## Data organization
+
+In Antares, all input and output data regarding a given study are
+located within a folder named after the study and which should
+preferably be stored within a dedicated library of studies (for
+instance: C/.../A\_name\_for\_an\_Antares\_lib/Study-number-one).
+
+The software has been designed so that all input data may be handled
+(initialized, updated, deleted) through the simulator’s GUI. Likewise,
+all results in the output data can be displayed and analyzed within the
+simulator: its standard GUI is actually meant to be able to provide, on
+a stand-alone basis, all the features required to access input and
+output in a user-friendly way.
+
+In addition to that, the Antares simulator may come\[3\] with or without
+functional extensions that provide additional ways to handle input and
+output data.
+
+These extensions take the form of companion applications whose
+documentation is independent from that of the main simulator. For
+information regarding these tools (***Antares\_Data\_Organizer***,
+***Antares\_Viz*** R packages, …) please refer to the specific relevant
+documents.
+
+Besides, a point of notice is that most of Antares files belong to
+either “.txt” or “.csv” type: as an alternative to the standard GUI,
+they can therefore be viewed and updated by many applications (Windows
+Notepad, Excel, etc.). However, this is not recommended since handling
+data this way may result in fatal data corruption (e.g. as a consequence
+of accidental insertion of special characters).
+
+Direct access to input or output data files should therefore be reserved
+to experienced users.
+
+The input data contained in the study folder describe the whole state of
+development of the interconnected power system (namely: grid, load and
+generating plants of every kind) for a given future year.
+
+As already stated, all of these data may be reviewed, updated, deleted
+through the GUI, whose commands and windows are described in Sections 3
+and 4.
+
+Once the input data is ready for calculation purposes, an Antares
+session may start and involve any or all of the following steps:
+historical time-series analysis, stochastic times-series generation,
+(draft) adequacy simulation, (full) adequacy simulation and economic
+simulation.
+
+The results of the session are stored within the output section of the
+study folder. The results obtained in the different sessions are stored
+side by side and tagged. The identification tag has two components: a
+user-defined session name and the time at which the session was
+launched.
+
+Particular cases are:
+
+1) The outputs of the Antares time-series analyzer are not printed in
+ the general output files but kept within the input files structure
+ (the reason being that they are input data for the Antares time -
+ series generators). The associated data may nonetheless be accessed
+ to be reviewed, updated and deleted at any time through the GUI.
+
+2) Some specific input data may be located outside the study folder:
+ this is the case for the historical times-series to be processed by
+ the time-series analyzer, which may be stored either within the
+ “user” subfolder of the study or anywhere else (for instance, on a
+ remote “historical data” or “Meteorological data” server).
+
+3) > The study folder contains a specific subfolder named “user”, whose
+ > status is particular: Antares is not allowed to delete any files
+ > within it (yet files may be updated on the user’s requirement). As
+ > a consequence, the “user” subfolder is unaffected by the “clean
+ > study” command (see Section 3). This subfolder is therefore a
+ > “private” user space, where all kinds of information can be
+ > stored without any kind of interference with Antares. Note that on
+ > using the “save as” command (described further below), the choice
+ > is given to make or not a copy of this subfolder.
+
+4) The times-series analyzer requires the use of a temporary directory
+ in which intermediate files are created in the course of the
+ analysis and deleted in the end, unless the user wishes to keep them
+ for further examination. Its location is user-defined and should
+ usually be the “user” subfolder if files are to be kept, otherwise
+ any proper temporary space such as `C..../Temp`.
+
+5) If the interconnected system to study is large and/or if the
+ computer is low on RAM, it is possible to run the Monte-Carlo
+ adequacy simulator as well as the Monte-Carlo economic simulator in
+ “Swap” mode. Swap is not handled by the computer’s OS but by an
+ Antares specific swap manager, whose operation requires the
+ definition of a space where the software can store temporary files.
+ This location is user-defined but should never be chosen within the
+ study folder. C/.../Temp may typically be used but an external drive
+ may be preferred if the computer is low on HDD.
+
+6) The outputs of the Antares Kirchhoff’s constraints generator are not
+ printed in the general output files but kept within the input files
+ structure, the reason being that they are input data for the proper
+ Antares simulation. The associated data (so-called binding
+ constraints bearing in their name the prefix “@UTO-“) may
+ nonetheless be accessed to be reviewed, updated and deleted at any
+ time through the GUI.
+
+## Commands
+
+The Antares GUI gives access to a general menu of commands whose name
+and meanings are described hereafter.
+
+### File
+
+**New**
+
+> *Create a new empty study to be defined entirely from scratch (network
+> topology, interconnections ratings, thermal power plants list, fuel
+> costs, hydro inflows stats, wind speed stats, load profiles ,etc.) *
+
+**Open**
+
+> *Load in memory data located in a specified Antares study folder. Once
+> loaded, these data may be reviewed, updated, deleted, and simulations
+> may be performed. If “open” is performed while a study was already
+> opened, the former study will be automatically closed.*
+
+**Quick Open**
+
+> *Same action as open, with a direct access to the recently opened
+> studies*
+
+**Save**
+
+> *Save the current state of the study, if necessary by replacing
+> original files by updated ones. After using this command the original
+> study is no longer available, though some original files may be kept
+> until the ”clean” command is used (see “clean” command )*
+
+**Save as**
+
+> *Save the current state of the study under a different name and / or
+> location. Using this command does not affect the original study. When
+> “saving as”, the user may choose whether he prefers to save input
+> and output data or only input data. Note that Antares does not perform
+> “autosave”: Therefore, the actions performed on the input data during
+> an Antares session (adding an interconnection, removing a plant, etc.)
+> will have no effect until either “save” or “save as” have been used*
+
+**Export Map**
+
+> *Save a picture of the current map as a PNG, JPEG or SVG file *
+>
+> *Default background color and storage location can be changed *
+
+**Open in Windows Explorer**
+
+> *Open the folder containing the study in a standard Windows Explorer
+> window*
+
+**Clean**
+
+> *Remove all junk files that may remain in the study folder if the
+> Antares session has involved lots of sequences such as “create area –
+> add plant –save –rename area – save - rename plant ...” (Antares
+> performs only low level auto-clean for the sake of GUI’s efficiency) *
+
+**Close**
+
+> *Close the study folder. If no “save” or “save as” commands have been
+> performed, all the modifications made on the input data during the
+> Antares session will be ignored*
+
+**Quit**
+
+*Exit from Antares *
+
+### Edit
+
+**Copy**
+
+> *Prepare a copy of elements selected on the current system map. The
+> command is available only if the current active tab (whose name
+> appears at the top line of the subcommand menu) is actually that of
+> the System maps.*
+
+**Paste**
+
+> *Paste elements previously prepared for copy. The command is available
+> only if the current active tab (whose name appears at the top line of
+> the subcommand menu) is actually that of the System maps. Note that
+> copy/paste may be performed either within the same map or between two
+> different maps, attached to the same study or to different studies. To
+> achieve that, launch one instance of Antares to open the “origin”
+> study, select elements on the map and perform copy, launch another
+> instance of Antares to open the destination study, perform paste.
+> Copied elements are stored in an Antares clipboard that remains
+> available for subsequent (multiple) paste as long as the system map is
+> used as active window.*
+
+**Paste Special**
+
+> *Same as Paste, with a comprehensive set of parameterized actions
+> (skip, merge, update, import) that can be defined for each data
+> cluster copied in the clipboard. This gives a high level of
+> flexibility for carrying out complex copy/paste actions. *
+
+**Reverse**
+
+> *The elements currently selected on the system map are no longer
+> selected and are replaced by those not selected beforehand.*
+
+**Unselect All**
+
+> *Unselect all elements currently selected on the system map.*
+
+**Select All**
+
+> *Select all elements on the system map.*
+
+### Input
+
+**Name of the study**
+
+> *Give a reference name to the study. The default name is identical to
+> that of the study’s folder but the user may modify it. The default
+> name of a new study is “no title” *
+
+**Author(s)**
+
+> *Set the study’s author(s) name. Default value is “memory”*
+
+The other “input” subcommands here below are
+used to move from one active window to another. Note that the
+availability of the Wind, Solar and Renewable subcommands depend on the
+advanced parameter Renewable Generation modelling described in section
+8.
+
+**System Maps **
+
+**Simulation**
+
+**User’s Notes**
+
+**Load**
+
+**Solar**
+
+**Wind**
+
+**Renewable**
+
+**Hydro**
+
+**Thermal**
+
+**Misc. Gen.**
+
+**Reserves/DSM**
+
+**Links**
+
+**Binding constraints**
+
+**Economic opt.**
+
+### Output
+
+**\ \< simulation tag\>**
+
+> *For each simulation run for which results have been generated, open a
+> GUI for displaying results. Results may be viewed by multiple
+> selections made on a number of parameters. Note that, since all
+> simulations do not include all kinds of results (depending on user’s
+> choices), some parameters are not always visible. Parameters stand as
+> follows:*
+
+- *Antares area (node)*
+
+- *Antares interconnection (link)*
+
+- *Class of Monte-Carlo results :*
+
+ - *Monte-Carlo synthesis (throughout all years simulated)*
+
+ - *Year-by-Year (detailed results for one specific year)*
+
+- *Category of Monte-Carlo results :*
+
+ - *General values (operating cost, generation breakdown, ...) *
+
+ - *Thermal plants (detailed thermal generation breakdown)*
+
+ - *Renewable generation (per cluster)*
+
+ - *Record years (for each Antares variable, identification of the
+ Monte-Carlo year for which lowest and highest values were
+ encountered)*
+
+- *Span of Monte-Carlo results :*
+
+ - *Hourly *
+
+ - *Daily *
+
+ - *Weekly*
+
+ - *Monthly*
+
+ - *Annual*
+
+> *The interface provides a user-friendly way for the comparison of
+> results between multiple simulations (e.g. “before” and “after”
+> commissioning of a new plant or interconnection):*
+
+- *Use “new tab” button and choose a first set of simulation results*
+
+- *Use again “new tab” and choose a second set of simulation results*
+
+> *The results window will be automatically split so as to show the two
+> series of results in parallel. To the right of the “new tab” button, a
+> symbolic (icon) button gives further means to compare results on a
+> split window (average, differences, minimum, maximum and sum).*
+>
+> *Besides, when the simulation results contain the “year-by-year”
+> class, it is possible to carry out an extraction query on any given
+> specific variable (e.g. “monthly amounts of CO2 tons emitted”)
+> throughout all available years of simulation. *
+>
+> *The results of such queries are automatically stored within the
+> output file structures, so as to be available at very short notice if
+> they have to be examined later in another session (extractions may
+> require a significant computer time when there are many Monte-Carlo
+> years to process). *
+>
+> ***Open in Windows Explorer** *
+>
+> *This command displays the list of available simulation results and
+> allows browsing through the output files structure. The content of
+> these files may be reviewed by tools such as Xcel. File structures are
+> detailed in Section 5. *
+>
+> *
+> *
+
+### Run
+
+**Monte Carlo Simulation**
+
+> *Runs either an economy simulation, an adequacy simulation, or a
+> “draft” simulation, depending on the values of the parameters set in
+> the “simulation” active window (see Section 4). If hardware resources
+> and simulation settings allow it, simulations benefit from full
+> multi-threading (see Section 9) *
+
+**Time-series Generators**
+
+> *Runs any or all of the Antares stochastic time-series generators,
+> depending on the values of the parameters set in the “simulation”
+> active window (see Section 4)*
+
+**Time-series Analyzer**
+
+> *Runs the Antares historical time-series analyzer. The parameters of
+> this module are defined by a specific active window, available only on
+> launching the analyzer (see Section 6)*
+
+**Kirchhoff’s Constraints Generator**
+
+> *Runs the Antares Kirchhoff’s Constraints Generator. The parameters of
+> this module are defined by a specific active window, available only on
+> launching the KCG (see Section 7)*
+
+### Configure
+
+**Thematic Trimming**
+
+> *Opens a window in which a choice can be made regarding the individual
+> output status of the variables defined in Section 5. Each computed
+> variable can either be stored as part of the Output data to produce at
+> the end of the simulation, or trimmed from it. In the latter case, the
+> variable is regularly computed but the printing stage is skipped.
+> Thematic Trimming does not reduce computation time but can bring some
+> benefits on total runtime (smaller files to write). Thematic Trimming
+> can save large amounts of storage space in simulations where only a
+> handful of variables are of interest.*
+
+**Geographic Trimming**
+
+> *Opens an auxiliary window that allows multiple selection of the
+> results to store at the end of a simulation: Choice of areas,
+> interconnections, temporal aggregations (hourly, daily, etc.). Note
+> that in addition to this feature, an alternative access to the
+> function is available (see Section 4, “output profile”). Geographic
+> Trimming does not reduce actual computation time but can bring some
+> benefits on total runtime (fewer files to write). Geographic Trimming
+> can save large amounts of storage space in simulations where only a
+> few Areas and Links are of interest.*
+
+**Regional Districts**
+
+> *Allows selecting a set of areas so as to bundle them together in a
+> “district”. These are used in the course of simulations to aggregate
+> results over several areas. They can be given almost any name (a “@”
+> prefix is automatically added by Antares). Bypassing the GUI is
+> possible (see Section 8).*
+
+**MC Scenario builder**
+
+> *For each Monte-Carlo year of the simulation defined in the
+> “Simulation” window, this command allows to state, for each kind of
+> time-series, whether it should be randomly drawn from the available
+> set (be it ready-made or Antares-generated) **OR** should take a
+> user-defined value (in the former case, the default “rand” value
+> should be kept; in the latter, the value should be the reference
+> number of the time-series to use). Multiple simulation profiles can be
+> defined and archived. The default active profile gives the “rand”
+> status for all time-series in all areas (full probabilistic
+> simulation).*
+>
+> *Regarding Hydro time-series, the scenario builder gives, in addition
+> to the assignment of a specific number to use for the inflows
+> time-series, the ability to define the initial reservoir level to use
+> for each MC year *
+
+**MC Scenario playlist**
+
+> *For each Monte-Carlo year of the simulation defined in the
+> “Simulation” active window, this command allows to state whether a
+> MC year prepared for the simulation should be actually simulated or
+> not. This feature allows, for instance, to refine a previous
+> simulation by excluding a small number of “raw” MC years whose
+> detailed analysis may have shown that they were not physically
+> realistic. A different typical use consists in replaying only a small
+> number of years of specific interest (for instance, years in the
+> course of which Min or Max values of a given variable were encountered
+> in a previous simulation).*
+>
+> *In addition, each MC year* \(i = 1,\ldots,N\ \)*can be given a
+> relative “weight”* \(W_{i}\ \)*in the simulation (default value: 1).
+> The expectation and standard deviation of all random variables will
+> then be computed as if the scenarios simulated were sampled from a
+> probability density function in which MC year* \(i\) *is given the
+> probability* \(\frac{W_{i}}{\sum_{j = 1,N}^{}W_{j}}\)
+
+**Optimization preferences**
+
+> *Defines a set of options related to the optimization core used in the
+> simulations. The set of preferences is study-specific; it can be
+> changed at any time and saved along with study data. Options refer to
+> objects (binding constraints, etc.) that are presented in subsequent
+> sections of this document. *
+>
+> *The values set in this menu overlay the local parameters but do not
+> change their value: for instance, if the LOCAL parameter “set to
+> infinite” is activated for some interconnections, and if the GLOBAL
+> preference regarding transmission capacities is “set to null”, the
+> simulation will be carried out as if there were no longer any grid BUT
+> the local values will remain untouched. If the preference is
+> afterwards set to “local values”, the interconnections will be given
+> back their regular capacities (infinite for those being set on “set to
+> infinite”). *
+
+- *Binding constraints (include / ignore)*
+
+- *Hurdle costs (include / ignore)*
+
+- *Transmission capacities (local values / set to null / set to
+ infinite)*
+
+- *Min Up/down time of thermal plants (include / ignore)*
+
+- *Day-ahead reserve (include / ignore)*
+
+- *Primary reserve (include / ignore)*
+
+- *Strategic reserve (include / ignore)*
+
+- *Spinning reserve (include / ignore)*
+
+- *Export mps (false/true) *
+
+- *Simplex optimization range*\[4\] *(day / week) *
+
+- *Unfeasible problems behavior (Error Dry/ Error Verbose/ Warning
+ Dry/ Warning Verbose*
+
+**Advanced parameters **
+
+> *Advanced Parameters allow to adjust the simulation behavior regarding
+> issues that are more numerical than physical. The set of parameters is
+> study-specific and can be updated at any time.*
+
+- > **Seeds for random number generation**
+
+ - Time-series draws (MC scenario builder)
+
+ - Wind time-series generation
+
+ - Solar time-series generation
+
+ - Hydro time - series generation
+
+ - Load time - series generation
+
+ - Thermal time-series generation
+
+ - Noise on thermal plants costs
+
+ - Noise on unsupplied energy costs
+
+ - Noise on spilled energy costs
+
+ - Noise on virtual hydro cost
+
+ - Initial hydro reservoir levels
+
+- **Spatial time-series correlation**
+
+ - **Numeric Quality : load** \[standard | high\]
+
+ - **Numeric Quality : wind**\[standard | high\]
+
+ - **Numeric Quality : solar**\[standard | high\]
+
+- > **Other preferences **
+
+ - Reservoir Level Initialization \[cold start | hot start\]
+
+ - Hydro Heuristic policy \[accommodate rule curves| maximize
+ generation\]
+
+ - Hydro Pricing mode \[fast|accurate\]
+
+ - Power fluctuations \[free modulations | minimize excursions |
+ minimize ramping\]
+
+ - Shedding policy \[shave peaks | minimize duration\]
+
+ - District marginal prices : \[average | weighed\]
+
+ - Day-ahead reserve management \[global|local\]
+
+ - Unit commitment mode \[fast |accurate\]
+
+ - Simulation cores \[minimum|low|medium|high|maximum\]
+
+ - Renewable Generation modelling \[aggregated | cluster\]
+
+### Tools
+
+**Study manager**
+
+> *Launches the “study manager” external package *
+>
+> *(Please refer to dedicated documentation for this package)*
+
+**Resources monitor**
+
+> *Indicates the amounts of RAM and disk space currently used and those
+> required for a simulation in the available modes (see Section 9). Note
+> that the “disk requirement” amount does not include the footprint of
+> the specific “mps” files that may have to be written aside from the
+> regular output (see previous § “optimization preferences”). Besides,
+> the resources monitor shows the number of CPU cores available on the
+> machine Antares is running on. *
+
+**Configure the swap folder**
+
+> *Defines the location that will be used by Antares to store the
+> temporary files of the MC simulators when the swap mode is activated
+> (this location may also be used by Antares GUI when handling large
+> studies). The default setting is the system temporary folder*
+
+### Window
+
+**Toggle full window**
+
+*Uses the whole window for display *
+
+**Inspector**
+
+> *Opens a window that gives general information on the study and allow
+> quick browsing through various area- or interconnection-related
+> parameters. The Inspector window displays the content of the Antares
+> clipboard, e.g. areas and interconnections selected on the current
+> study map. If the “Geographic Trimming” option of the general
+> simulation dashboard has the value “custom”, the filtering parameters
+> can be defined within the Inspector window. Besides, areas currently
+> selected, displayed in the Inspector window, can be bundled into an
+> “output district” by using the Configure/district command previously
+> described *
+
+**Log viewer**
+
+*Displays the log files regarding every Antares session performed on the
+study*
+
+## Active windows
+
+Data can be reviewed, updated, deleted by selecting different possible
+active windows whose list and content are described hereafter. On
+launching Antares, the default active window is “System Maps”.
+
+### System Maps
+
+> *This window is used to define the general structure of the system,
+> i.e. the list of areas and that of the interconnections. Only the
+> area’s names, location and the topology of the grid are defined at
+> this stage. Different colors may be assigned to different areas. These
+> colors may later be used as sorting options in most windows. They are
+> useful to edit data in a fashion that has a geographic meaning (which
+> the lexicographic order may not have). This window displays
+> copy/paste/select all icons equivalent to the relevant EDIT menu
+> commands. *
+>
+> *The top left side of the window shows a “mouse status” field with
+> three icons. These icons (one for nodes, one for links and one for
+> binding constraints) indicate whether a selection made on the map with
+> the mouse will involve or not the related elements. When a copy/paste
+> action is considered, this allows for instance to copy any combination
+> of nodes, links and binding constraints. Status can be changed by
+> toggling the icons. Default is “on” for the three icons. Two other
+> purely graphic icons/buttons (no action on data) allow respectively to
+> center the map on a given set of (x , y) coordinates, and to prune the
+> “empty” space around the current map. Multiple additional maps may be
+> defined by using the cross-shaped button located top right. A detailed
+> presentation of all system map editor features can be found in the
+> document “System Map Editor Reference Guide”. *
+
+*
+*
+
+### Simulation
+
+> *The main simulation window is divided up in two parts. On the left
+> side are the general parameters while the right side is devoted to the
+> time-series management. *
+>
+> *These two parts are detailed hereafter.*
+
+## LEFT PART: General parameters
+
+### Simulation
+
+> *Mode:* Economy, Adequacy, Draft\[5\]
+>
+> *First day:* First day of the simulation (e.g. 8 for a simulation
+> beginning on the second week of the first month of the year)
+>
+> *Last day:* Last day of the simulation (e.g. 28 for a simulation
+> ending on the fourth week of the first month of the year)\[6\]
+
+### Calendar
+
+> *Horizon:* Reference year (static tag, not used in the calculations)
+>
+> *Year:* Actual month by which the Time-series begin (Jan to Dec, Oct
+> to Sep, etc.)
+>
+> *Leap Year:* (Yes/No) indicates whether February has 28 or 29 days
+>
+> *Week:* In economy or adequacy simulations, indicates the frame (Mon-
+> Sun, Sat-Fri, etc.) to use for the edition of weekly results
+>
+> *1st January:* First day of the year (Mon, Tue, etc.)
+
+### Monte-Carlo scenarios
+
+> *Number:* Number of MC years that should be prepared for the
+> simulation (not always the same as the Number of MC years actually
+> simulated, see “selection mode” below)
+>
+> *Building mode:*
+>
+> (Automatic)
+>
+> For all years to simulate, all time-series will be drawn at random
+>
+> (Custom)
+>
+> The simulation will be carried out on a mix of deterministic and
+> probabilistic conditions, with some time-series randomly drawn and
+> others set to user-defined values. This option allows setting up
+> detailed “what if” simulations that may help to understand the
+> phenomena at work and quantify various kinds of risk indicators. To
+> set up the simulation profile, choose in the main menu: Configure/ MC
+> scenario builder
+>
+> (Derated)
+>
+> All time-series will be replaced by their general average and the
+> number of MC years is set to 1. If the TS are ready-made or
+> Antares-generated but are not to be stored in the INPUT folder, no
+> time-series will be written over the original ones (if any). If the
+> time-series are built by Antares and if it is specified that they
+> should be stored in the INPUT, a single average-out time series will
+> be stored instead of the whole set.
+>
+> *Selection mode:*
+>
+> (Automatic)
+>
+> All prepared MC years will actually be simulated.
+>
+> (Custom)
+>
+> The years to simulate are defined in a list. To set up this list,
+> choose in the main menu: Configure/ MC scenario playlist\[7\].
+
+# Output profile
+
+> *Simulation synthesis:* (True) Synthetic results will be stored in a
+> directory:
+>
+> ***Study\_name*/*OUTPUT/simu\_tag/Economy /mc-all***
+>
+> (False) No general synthesis will be printed out
+>
+> *Year-by-Year*: (False) No individual results will be printed out
+>
+> (True) For each simulated year, detailed results will be
+>
+> printed out in an individual directory\[8\] :
+>
+> ***Study\_name*/*OUTPUT/simu\_tag/Economy /mc-i-number***
+>
+> *Geographic Trimming:* (None) Storage of results for all areas,
+> geographic districts, interconnections as well as all time spans
+> (hourly, daily, etc.)
+>
+> (Custom) Storage of the results selected with the “Geographic
+> Trimming” command of the “Configure” option available in the main
+> menu.
+>
+> Filters on areas, interconnections and time spans may also be defined
+> as follows:
+
+1) On the map, select area(s) and/or interconnection(s)
+
+2) Open the inspector module (Main menu, Windows)
+
+3) Set adequate parameters in the “output print status” group
+
+> *Thematic Trimming:* (None) Storage, for the geographic selection
+> defined previously, of all variables defined in Section 5 for Areas
+> and Links.
+>
+> (Custom) Storage, for the geographic selection defined previously, of
+> the variables selected with the “Thematic Trimming” command of the
+> “Configure” option available in the main menu.
+>
+> *MC Scenarios:* (False) No storage of the time-series numbers (either
+> randomly drawn or user-defined) used to set up the simulation
+>
+> (True) A specific OUTPUT folder will be created to store all of the
+> time-series numbers drawn when preparing the MC years.
+
+###### RIGHT PART: Time-series management
+
+For the different kinds of time-series that Antares manages in a
+non-deterministic way (load, thermal generation, hydro power, wind
+power, solar power or renewable depending on the option chosen):
+
+**1) Choice of the kind of time-series to use**
+
+Either « ready-made » or «stochastic » (i.e. Antares-generated), defined
+by setting the value to either “on” or “off”
+
+**2) For stochastic TS only**:
+
+Number
+
+> Number of TS to generate
+
+Refresh
+
+> (Yes /No)
+>
+> Indicates whether a periodic renewal of TS should be performed or not
+
+Refresh span
+
+> Number of MC years at the end of which the renewal will be performed
+> (if so required)
+
+Seasonal correlation
+
+> (“monthly” or “annual”)
+>
+> Indicates whether the spatial correlation matrices to use are defined
+> month by month or if a single annual matrix for the whole year should
+> rather be used (see Section 6)
+
+Store in input
+
+> (Yes/No)
+>
+> Yes: the generated time-series will be stored in the INPUT in
+> replacement of the original ones (wherever they may come from)
+>
+> No: the original time-series will be kept as they were
+
+Store in output
+
+> (Yes/No)
+>
+> Yes: the generated times-series will be stored as part of the
+> simulation results
+>
+> No: no storage of the generated time-series in the results directories
+
+**3) General rules for building up the MC years **
+
+Intra-modal (Yes)
+
+> For each mode, the same number should be used for all locations (or 1
+> where there is only one TS), but this number may differ from one mode
+> to another. For instance, solar power TS = 12 for all areas, while
+> wind power TS number = 7 for all areas.
+>
+> (No) Independent draws
+
+Inter-modal (Yes)
+
+> For all modes, the same number should be used but may depend on the
+> location (for instance, solar and wind power TS = 3 for area 1, 8 for
+> area 2, 4 for area 3, etc.)
+>
+> (No) Independent draws
+
+A full meteorological correlation (for each MC year, one single number
+for all modes and areas) is, from a theoretical standpoint, accessible
+by activating “intra-modal” and “ inter-modal” for all but the “thermal”
+kind of time-series. The availability of an underlying comprehensive
+multi-dimensional Meteorological data base of ready-made time-series is
+the crux of the matter when it comes to using this configuration.
+
+## User’s Notes
+
+> *A built-in notepad for recording comments regarding the study. Such
+> comments typically help to track successive input data updates
+> (upgrading such interconnection, removing such plant, etc.). Another
+> simple use is to register what has been stored in the “user” subfolder
+> and why. Such notes may prove useful to sort and interpret the results
+> of multiple simulations carried out at different times on various
+> configurations of the power system. *
+
+## Load
+
+> *This window is used to handle all input data regarding load. In
+> Antares load should include transmission losses. It should preferably
+> not include the power absorbed by pumped storage power plants. If it
+> does, the user should neither use the “PSP” array (see window “Misc.
+> Gen”) nor the explicit modeling of PSP plants *
+>
+> *The user may pick any area appearing in the list and is then given
+> access to different tabs:*
+
+- > *The “time-series” tab display the “ready-made” 8760-hour
+ > time-series available for simulation purposes. These data may come
+ > from any origin outside Antares, or be data formerly generated by
+ > the Antares time-series stochastic generator, stored as input data
+ > on the user’s request. Different ways to update data are :*
+
+ - > *direct typing *
+
+ - > *copy/paste a selected field to/from the clipboard*
+
+ - > *load/save all the time-series from/to a file (usually located
+ > in the “user” subfolder) *
+
+ - > *Apply different functions (+,-, \*, /,etc.) to the existing
+ > (possibly filtered) values (e.g. simulate a 2% growth rate by
+ > choosing “ multiply-all-by-1.02”)*
+
+ - > *Handle the whole (unfiltered) existing dataset to either *
+
+ - *Change the number of columns (function name : resize)*
+
+ - *Adjust the values associated with the current first day of
+ the year (function name : shift rows) *
+
+> *Versatile “Filter” functions allow quick access to user-specified
+> sections of data (e.g. display only the load expected in the
+> Wednesdays of January, at 09:00, for time-series \#12 to \#19). Hourly
+> load is expressed in round numbers and in MW. If a smaller unit has to
+> be used, the user should define accordingly ALL the data of the study
+> (size of thermal plants, interconnection capacities, etc.)*
+>
+> *Note that:*
+
+- > *If the “intra-modal correlated draws” option has not been
+ > selected in the **simulation** window, MC adequacy or economy
+ > simulations can take place even if the number of time-series is
+ > not the same in all areas (e.g. 2 , 5 , 1 , 45 ,...)*
+
+- > *If the “intra-modal correlated draws” option has been selected in
+ > the **simulation** window, every area should have either one
+ > single time-series or the same given number (e.g. 25 , 25 , 1 ,
+ > 25...)*
+
+*
+*
+
+ - > *The “spatial correlation” tab gives access to the inter-area
+ > correlation matrices that will be used by the stochastic generator
+ > if it is activated. Different sub-tabs are available for the
+ > definition of 12 monthly correlation matrices and of an overall
+ > annual correlation matrix. *
+
+#### A matrix A must meet three conditions to be a valid correlation matrix:
+
+> *for all i and j { Aii= 100 , -100\<= Aij \<=100 } ; A symmetric ; A
+> positive semi-definite*
+
+#### When given invalid matrices, the TS generator emits an unfeasibility diagnosis
+
+####
+
+- > *The “local data” tab is used to set the parameters of the
+ > stochastic generator. These parameters are presented in four
+ > sub-tabs whose content is presented in Section 6.*
+
+- > *The “digest” tab displays for all areas a short account of the
+ > local data *
+
+## Thermal
+
+> *This window is used to handle all input data regarding thermal
+> dispatchable power.*
+>
+> *The user may pick any area appearing in the area list and is then
+> given access to the list of thermal plants clusters defined for the
+> area (e.g. “CCG 300 MW”, “coal 600”, etc.). Once a given cluster has
+> been selected, a choice can be made between different tabs:*
+
+- > *The “time-series” tab displays the “ready-made” 8760-hour
+ > time-series available for simulation purposes. These data may come
+ > from any origin outside Antares, or be data formerly generated by
+ > the Antares time-series stochastic generator, stored as input data
+ > on the user’s request. Different ways to update data are :*
+
+ - > *direct typing *
+
+ - > *copy/paste a selected field to/from the clipboard*
+
+ - > *load/save all the time-series from/to a file (usually located
+ > in the “user” subfolder)*
+
+ - > *Apply different functions (+,-, \*, /,etc.) to the existing
+ > (possibly filtered) values (e.g. simulate a 2% growth rate by
+ > choosing “ multiply-all-by-1.02”)*
+
+ - > *Handle the whole (unfiltered) existing dataset to either *
+
+ - *Change the number of columns (function name : resize)*
+
+ - *Adjust the values associated with the current first day of
+ the year (function name : shift rows) *
+
+> *Versatile “Filter” functions allow quick access to user-specified
+> sections of data (e.g. display only the generation expected on Sundays
+> at midnight, for all time-series).*
+>
+> *Hourly thermal generation is expressed in round numbers and in MW. If
+> a smaller unit has to be used, the user should define accordingly ALL
+> the data of the study (Wind generation, interconnection capacities,
+> load, hydro generation, solar, etc.)*
+>
+> *Note that:*
+
+- > *If the “intra-modal correlated draws” option has not been
+ > selected in the **simulation** window, MC adequacy or economy
+ > simulations can take place even if the number of time-series is
+ > not the same in all areas (e.g. 2, 5, 1, 45,etc.)*
+
+- > *If the “intra-modal correlated draws” option has been selected in
+ > the **simulation** window, every area should have either one
+ > single time-series or the same given number (e.g. 25, 25, 1, 25,
+ > etc.). Note that, unlike the other time-series (load, hydro,
+ > etc.), which depend on meteorological conditions and are therefore
+ > inter-area-correlated, the thermal plants time-series should
+ > usually be considered as uncorrelated. Using the “correlated
+ > draws” feature makes sense only in the event of having to play
+ > predefined scenarios (outside regular MC scope) *
+
+
+
+- > *The “TS generator” tab is used to set the parameters of the
+ > stochastic generator. These parameters are defined at the daily
+ > scale and are namely, for each day: the average duration of forced
+ > outages (beginning on that day), the forced outage rate, the
+ > duration of planned outages (beginning on that day), the planned
+ > outage rate, planned outages minimum and maximum numbers.
+ > Durations are expressed in days and rates belong to \[0 , 1\]. *
+
+- > *The “Common” tab is used to define the cluster’s techno-economic
+ > characteristics :*
+
+ - *Name*
+
+ - *Fuel used*
+
+ - *Location (Area)*
+
+ - *Activity status *
+
+ - *false: not yet commissioned, moth-balled, etc.*
+
+ - *true : the plant may generate *
+
+ - *Number of units*
+
+ - *Nominal capacity*
+
+ - *Full Must-run status*
+
+ - *false: above a partial “must-run level” (that may exist or
+ not, see infra) plants will be dispatched on the basis of
+ their market bids.*
+
+ - *true: plants will generate at their maximum capacity,
+ regardless of market conditions*
+
+ - *Minimum stable power (MW)*
+
+ - *Minimum Up time (hours)*
+
+ - *Minimum Down time (hours)*
+
+ - *Default contribution to the spinning reserve (% of nominal
+ capacity)*
+
+ - *CO2 tons emitted per electric MWh*
+
+ - *Marginal operating cost (€/MWh)*
+
+ - *Fixed cost (No-Load heat cost) (€ / hour of operation )*
+
+ - *Start-up cost (€/start-up)*
+
+ - *Market bid (€/MWh)*
+
+ - *Random spread on the market bid (€/MWh)*
+
+ - *Seasonal marginal cost variations (gas more expensive in
+ winter, ...)*
+
+ - *Seasonal market bid modulations (assets costs charging strategy
+ ) *
+
+ - *Nominal capacity modulations (seasonal thermodynamic
+ efficiencies, special over-generation allowances, etc.). These
+ modulations are taken into account during the generation of
+ available power time-series*
+
+ - *Minimal generation commitment (partial must-run level) set for
+ the cluster *
+
+> *Note that:*
+
+- *The **optimal dispatch plan** as well as **locational marginal
+ prices** are based on **market bids**, while the assessment of the
+ **operating costs** associated with this optimum are based on **cost
+ parameters**. (In standard “perfect” market modeling, there is no
+ difference of approaches because market bids are equal to marginal
+ costs)*
+
+> *
+> *
+
+## Hydro
+
+> *This section of the GUI is meant to handle all input data regarding
+> hydro power, as well as any other kind of energy storage system of any
+> size (from a small battery to a large conventional hydro-storage
+> reservoir with or without pumping facilities, etc.): Hydro power being
+> historically the first and largest form of power storage, it stood to
+> reason that it should play in Antares the role of a “generic template”
+> for all forms of storable power. This versatility, however, comes at
+> the price of a comparatively more complex data organization than for
+> other objects, which explains the comparatively long length of this
+> chapter. *
+>
+> *In the main Window, the user may pick any area appearing in the list
+> and is then given access to different tabs:*
+
+- > *The “time-series” tab displays the “ready-made” time-series
+ > already available for simulation purposes. There are two
+ > categories of time-series (displayed in two different subtabs):
+ > the Run of River (ROR) time-series on the one hand and the Storage
+ > power (SP) time-series on the other hand. *
+
+> *ROR time-series are defined at the hourly scale; each of the 8760
+> values represents the ROR power expected at a given hour, expressed in
+> round number and in MW. The SP time-series are defined at the daily
+> scale; each of the 365 values represents an overall SP energy expected
+> in the day, expressed in round number and in MWh. These natural
+> inflows are considered to be storable into a reservoir for later use.
+> *
+>
+> *Both types of data may come from any origin outside Antares, or may
+> have been formerly generated by the Antares time-series stochastic
+> generator and stored as input data on the user’s request. Different
+> ways to update data are:*
+
+- > *direct typing *
+
+- > *copy/paste a selected field to/from the clipboard*
+
+- > *load/save all the time-series from/to a file (usually located in
+ > the “user” subfolder)*
+
+- > *Apply different functions (+,-, \*, /,etc.) to the existing
+ > (possibly filtered) values (e.g. simulate a 2% growth rate by
+ > choosing “ multiply-all-by-1.02”)*
+
+- > *Handle the whole (unfiltered) existing dataset to either *
+
+ - *Change the number of columns (function name : resize)*
+
+ - *Adjust the values associated with the current first day of the
+ year (function name : shift rows) *
+
+> *Note that:*
+
+- > *For a given area, the number of ROR time-series and SP
+ > times-series **must** be identical*
+
+- > *If the “intra-modal correlated draws” option was not selected in
+ > the **simulation** window, MC adequacy or economy simulations can
+ > take place even if the number of hydro time-series is not the same
+ > in all areas (e.g. 2 , 5 , 1 , 45 ,...)*
+
+- > *If the “intra-modal correlated draws” option was selected in the
+ > **simulation** window, every area should have either one single
+ > time-series or the same given number (e.g. 25 , 25 , 1 , 25...)*
+
+
+
+- > *The “spatial correlation” tab gives access to an annual
+ > inter-area correlation matrix that will be used by the stochastic
+ > generator if it is activated. Correlations are expressed in
+ > percentages, hence to be valid this matrix must be symmetric,
+ > p.s.d, with a main diagonal of 100s and all terms lying between
+ > (-100 ,+100) *
+
+- > *The “Allocation” tab gives access to an annual inter-area
+ > allocation matrix A(i,j) that may be used during a heuristic hydro
+ > pre-allocation process, regardless of whether the stochastic
+ > time-series generator is used or not. This matrix describes the
+ > weights that are given to the loads of areas (i) in the definition
+ > of the monthly and weekly hydro storage generation profiles of
+ > areas (j). The way this is done in detailed in Section 8. *
+
+- > *The “local data” tab is used to set up the parameters of the
+ > stochastic generator **AND** to define techno-economic
+ > characteristics of the hydro system that are used in Economy and
+ > Adequacy optimizations. For the purpose of versatility (use of the
+ > hydro section to model storage facilities quite different in size
+ > and nature), this “local tab” is itself divided up into four
+ > different subtabs whose list follows and which are further
+ > described:*
+
+ - *Inflow Structure*
+
+ - *Reservoir Levels and water value*
+
+ - *Daily Power and Energy Credits*
+
+ - *Management options*
+
+> Inflow Structure
+
+*This tab contains all of the local parameters used for the stochastic
+generation of hydro time-series. These are namely:*
+
+- *The expectations, standard deviations, minimum and maximum values
+ of monthly energies (expressed in MWh), monthly shares of Run of
+ River within the overall hydro monthly inflow.*
+
+- *The average correlation between the energy of a month and that of
+ the next month (inter-monthly correlation).*
+
+- *The average daily pattern of inflows within each month. Each day is
+ given a relative “weight” in the month. If all days are given the
+ same weight, daily energy time-series will be obtained by dividing
+ the monthly energy in equal days. If not, the ratio between two
+ daily energies will be equal to that of the daily weights in the
+ pattern array.*
+
+*Overall hydro energy is broken down into two parts: Run of River- ROR
+and storage -STOR *
+
+*ROR energy has to be used on the spot, as it belongs to the general
+“must-run” energy category.*
+
+*STOR energy can be stored for use at a later time. The way how stored
+energy may actually be used depends on the options chosen in the
+“management options” Tab and of the values of the parameters defined
+in the other Tabs. *
+
+> Reservoir Levels and Water Values
+
+*Reservoir levels (left side)*
+
+*On the left side are defined 365 values for the minimum, average and
+maximum levels set for the reservoir at the beginning of each day,
+expressed in percentage of the overall reservoir volume. The lower and
+upper level time-series form a pair of so-called lower and upper
+“reservoir rule curves” *
+
+*Depending of the set of parameters chosen in the “management options”
+Tab, these rule curves may be used in different ways in the course of
+both heuristic seasonal hydro pre-allocation process and subsequent
+weekly optimal hydro-thermal unit-commitment and dispatch process. *
+
+*Water values (right side)*
+
+*On the right side is a table of marginal values for the stored energy,
+which depends on the date (365 days) and of the reservoir level (101
+round percentage values ranging from 0% to 100%). These values may have
+different origins; they theoretically should be obtained by a
+comprehensive (dual) stochastic dynamic programming study carried out
+over the whole dataset and dealing simultaneously with all reservoirs. *
+
+*Depending of the set options chosen in the “management options” Tab,
+these values may be used or not in the course of the weekly optimal
+hydro-thermal unit-commitment and dispatch process. *
+
+> Daily Power and Energy Credits
+
+*Standard credits (Bottom part) *
+
+*The bottom part displays two daily time-series (365 values) defined for
+energy generation/storage (hydro turbines or hydro pumps). In each case,
+the first array defines the maximum power (generated or absorbed), and
+the second defines the maximum daily energy (either generated or
+stored).*
+
+*For the sake of clarity, maximum daily energies are expressed as a
+number of hours at maximum power.*
+
+*Credit modulation (Upper part)*
+
+*The upper part displays two level-dependent (101 round percentage
+values ranging from 0% to 100%) time-series of modulation coefficients
+defined for either generating or storing (pumping). *
+
+*These modulations, which can take any positive value, may (depending of
+the options chosen in the management options Tab) be used to increase
+(value \>1) or to decrease (value \<1) the standard credits defined
+previously for the maximum daily power and energies.*
+
+> Management Options
+
+*This Tab is a general dashboard for the definition of how storage
+units, whatever their size or nature, should be managed. It includes 15
+parameters (out of which 7 are booleans) presented hereafter:*
+
+- *“Follow load” (y|n): defines whether an “ideal” seasonal generation
+ profile should somehow follow the load OR an “ideal” seasonal
+ generation profile should remain as close as possible to the natural
+ inflows (i.e. instant generation whenever possible)*
+
+- *“Inter-daily breakdown” and “Inter-monthly breakdown” : parameters
+ used in the assessment, through a heuristic process, of an “ideal”
+ seasonal generation profile, if the use of such a profile is
+ required (the heuristic itself is presented in Section 8) *
+
+- *“Intra-daily modulation”: parameter which represents, for the
+ storage power, the maximum authorized value for the ratio of the
+ daily peak to the average power generated throughout the day. This
+ parameter is meant to allow to simulate different hydro management
+ strategies. Extreme cases are : 1 : generated power should be
+ constant throughout the day 24 : use of the whole daily energy in
+ one single hour is allowed*
+
+- *“Reservoir management” (y|n): defines whether the storage should be
+ explicitly modeled or not. *
+
+> *Choosing “No” implies that available data allow or require that,
+> regardless of the reservoir characteristics: \* The whole amount of
+> STOR energy of each month MUST be used during this month (no long-term
+> storage) \* The actual daily generation should follow, during the
+> month, an “ideal” profile defined by the heuristic defined in Section
+> 8*
+>
+> *Choosing “Yes” implies that available data allow or require explicit
+> modeling of the storage facility, regardless of whether a
+> pre-allocation heuristic is used or not. *
+
+- *“Reservoir capacity”: size of the storage facility, in MWh*
+
+- *“Initialize reservoir level on the 1st of”: date at
+ which the reservoir level should be initialized by a random draw.
+ The “initial level” is assumed to follow a “beta” variable with
+ expectation “average level”, upper bound U=max level, lower bound L=
+ min level, standard deviation = (1/3) (U-L) *
+
+- *“Use Heuristic Target” (y|n): defines whether an “ideal” seasonal
+ generation profile should be heuristically determined or not.*
+
+> *Choosing “No” implies that available data allow or require that full
+> confidence should be put in water values determined upstream (through
+> \[dual\] stochastic dynamic programming) OR that there are no “natural
+> inflows” to the storage facility (battery or PSP,etc.)*
+>
+> *Choosing “Yes” implies that available data allow or require the
+> definition of an “ideal” generation profile, that can be used to
+> complement – or replace- the economic signal given by water values AND
+> that there are “natural inflows” on which a generation heuristic can
+> be based.*
+
+- *“Power-to-Level modulations (y|n)”: defines whether the standard
+ maximum daily energy and power credit should be or not multiplied by
+ level-dependent modulation coefficients.*
+
+- *“Hard bounds on rule curves (y|n)”: states whether, beyond the
+ preliminary heuristic stage (if any), lower and upper reservoir rule
+ curves should still be taken into account as constraints in the
+ hydro-thermal unit commitment and dispatch problems.*
+
+- *“Use leeway (y|n)”, lower bound L, upper bound U: states whether
+ the heuristic hydro ideal target (**HIT**) should be followed
+ exactly or not. *
+
+> *Choosing “No” implies that, in optimization problems, the hydro
+> energy generated throughout the time interval will be subject to an
+> equality constraint, which may include short-term pumping cycles
+> independent from water value: sum{ 1,t,T} (hydro(t)) –sum{1,t,T} (ρ.
+> pump(t))= **HIT** *
+>
+> *Choosing “Yes” , with bounds L and U, implies that, in optimization
+> problems, the hydro energy generated throughout the time span will be
+> subject to inequality constraints: L\***HIT** \<=sum{ 1,t,T}
+> (hydro(t)) \<= U\***HIT** *
+>
+> *Independently, short- or long-term pumping may also take place if
+> deemed profitable in the light of water values. *
+
+- *“Use Water Value (y|n)”: states whether the energy taken from /
+ stored into the reservoir should be given the reference value
+ defined in the ad hoc table OR should be given a zero value. *
+
+- *“Pumping Efficiency Ratio”: setting the value to ρ means that, for
+ the purpose of storing 1 gravitational MWh, pumps will have to use
+ (1/ρ ) electrical MWh.*
+
+*
+*
+
+## Wind
+
+> *This window is used to handle all input data regarding Wind power.*
+>
+> *This window is only accessible when the advanced parameter Renewable
+> Generation modelling is set to "Aggregated”.*
+>
+> *The user may pick any area appearing in the list and is then given
+> access to different tabs:*
+
+- > *The “time-series” tab display the “ready-made” 8760-hour
+ > time-series already available for simulation purposes. These data
+ > may come from any origin outside Antares, or be data formerly
+ > generated by the Antares time-series stochastic generator, stored
+ > as input data on user’s request. Different ways to update data are
+ > :*
+
+ - > *direct typing *
+
+ - > *copy/paste a selected field to/from the clipboard*
+
+ - > *load/save all the time-series from/to a file (usually located
+ > in the “user” subfolder) *
+
+ - > *Apply different functions (+,-, \*, /,etc.) to the existing
+ > (possibly filtered) values (e.g. simulate a 2% growth rate by
+ > choosing “ multiply-all-by-1.02”)*
+
+ - > *Handle the whole (unfiltered) existing dataset to either *
+
+ - *Change the number of columns (function name : resize)*
+
+ - *Adjust the values associated with the current first day of
+ the year (function name : shift rows) *
+
+> *Versatile “Filter” functions allow quick access to user-specified
+> sections of data (e.g. display only the wind generation expected
+> between 17:00 and 21:00 in February, for time-series 1 to 100).*
+>
+> *Hourly wind generation is expressed in round numbers and in MW. If a
+> smaller unit has to be used, the user should define accordingly ALL
+> the data of the study (size of thermal plants, interconnection
+> capacities, load, etc.)*
+>
+> *Note that:*
+
+- > *If the “intra-modal correlated draws” option has not been
+ > selected in the **simulation** window, MC adequacy or economy
+ > simulations can take place even if the number of time-series is
+ > not the same in all areas (e.g. 2, 5, 1,45, ...)*
+
+- > *If the “intra-modal correlated draws” option has been selected in
+ > the **simulation** window, every area should have either one
+ > single time-series or the same given number (e.g. 25, 25, 1, 25,
+ > ...)*
+
+
+
+- > *The “spatial correlation” tab gives access to the inter-area
+ > correlation matrices that will be used by the stochastic generator
+ > if it is activated. Different sub-tabs are available for the
+ > definition of 12 monthly correlation matrices and an overall
+ > annual correlation matrix. *
+
+#### A matrix A must meet three conditions to be a valid correlation matrix:
+
+> *for all i and j { Aii= 100 , -100\<= Aij \<=100 } ; A symmetric ; A
+> positive semi-definite*
+
+####
+
+#### When given invalid matrices, the TS generator emits an unfeasibility diagnosis
+
+####
+
+- > *The “local data” tab is used to set the parameters of the
+ > stochastic generator. These parameters are presented in four
+ > subtabs whose content is presented in Section 6. *
+
+- > *The “digest” tab displays for all areas a short account of the
+ > local data*
+
+**
+**
+
+## Solar
+
+> *This window is used to handle all input data regarding Solar power.
+> Both thermal solar generation and PV solar generation are assumed to
+> be bundled in this data section. *
+>
+> *This window is only accessible when the advanced parameter Renewable
+> Generation modelling is set to "aggregated”.*
+>
+> *The user may pick any area appearing in the list and is then given
+> access to different tabs:*
+
+- > *The “time-series” tab display the “ready-made” 8760-hour
+ > time-series available for simulation purposes. These data may come
+ > from any origin outside Antares, or be data formerly generated by
+ > the Antares time-series stochastic generator, stored as input data
+ > on the user’s request. Different ways to update data are :*
+
+ - > *direct typing *
+
+ - > *copy/paste a selected field to/from the clipboard*
+
+ - > *load/save all the time-series from/to a file (usually located
+ > in the “user” subfolder) *
+
+ - > *Apply different functions (+,-, \*, /,etc.) to the existing
+ > (possibly filtered) values (e.g. simulate a 2% growth rate by
+ > choosing “ multiply-all-by-1.02”)*
+
+ - > *Handle the whole (unfiltered) existing dataset to either *
+
+ - *Change the number of columns (function name : resize)*
+
+ - *Adjust the values associated with the current first day of
+ the year (function name : shift rows) *
+
+> *Versatile “Filter” functions allow quick access to user-specified
+> sections of data (e.g. display only the solar power expected in August
+> at noon, for all time-series).*
+>
+> *Hourly solar power is expressed in round numbers and in MW. If a
+> smaller unit has to be used, the user should define accordingly ALL
+> the data of the study (size of thermal plants, interconnection
+> capacities, etc.)*
+>
+> *Note that:*
+
+- > *If the “intra-modal correlated draws” option was not selected in
+ > the **simulation** window, MC adequacy or economy simulations can
+ > take place even if the number of time-series is not the same in
+ > all areas (e.g. 2 , 5 , 1 , 45 ,...)*
+
+- > *If the “intra-modal correlated draws” option was selected in the
+ > **simulation** window, every area should have either one single
+ > time-series or the same given number (e.g. 25 , 25 , 1 , 25...)*
+
+
+
+- > *The “spatial correlation” tab gives access to the inter-area
+ > correlation matrices that will be used by the stochastic generator
+ > if it is activated. Different sub-tabs are available for the
+ > definition of 12 monthly correlation matrices and of an overall
+ > annual correlation matrix. *
+
+#### A matrix A must meet three conditions to be a valid correlation matrix:
+
+> *for all i and j { Aii= 100 , -100\<= Aij \<=100 } ; A symmetric ; A
+> positive semi-definite*
+
+####
+
+#### When given invalid matrices, the TS generator emits an unfeasibility diagnosis
+
+####
+
+- > *The “local data” tab is used to set the parameters of the
+ > stochastic generator. These parameters are presented in four
+ > subtabs whose content is presented in Section 6. *
+
+- > *The “digest” tab displays for all areas a short account of the
+ > local data *
+
+**
+**
+
+## Renewable
+
+> *This window is used to handle all input data regarding renewable
+> generation.*
+>
+> *This window is only accessible when the advanced parameter Renewable
+> Generation modelling is set to "cluster” (default value).*
+>
+> *The user may pick any area appearing in the area list and is then
+> given access to the list of renewable clusters defined for the area
+> (e.g. “Onshore Wind Farm 200MW”, “Solar Rooftop 50”, etc.). Once a
+> given cluster has been selected, a choice can be made between
+> different tabs:*
+
+- > *The “time-series” tab displays the “ready-made” 8760-hour
+ > time-series available for simulation purposes. These data may come
+ > from any origin outside Antares, or be data formerly generated by
+ > the Antares time-series stochastic generator, stored as input data
+ > on the user’s request. Different ways to update data are :*
+
+ - > *direct typing *
+
+ - > *copy/paste a selected field to/from the clipboard*
+
+ - > *load/save all the time-series from/to a file (usually located
+ > in the “user” subfolder)*
+
+ - > *Apply different functions (+,-, \*, /,etc.) to the existing
+ > (possibly filtered) values (e.g. simulate a 2% growth rate by
+ > choosing “ multiply-all-by-1.02”)*
+
+ - > *Handle the whole (unfiltered) existing dataset to either *
+
+ - *Change the number of columns (function name : resize)*
+
+ - *Adjust the values associated with the current first day of
+ the year (function name : shift rows) *
+
+> *Versatile “Filter” functions allow quick access to user-specified
+> sections of data (e.g. display only the generation expected on Sundays
+> at midnight, for all time-series).*
+>
+> *Hourly thermal generation is expressed in round numbers and in MW. If
+> a smaller unit has to be used, the user should define accordingly ALL
+> the data of the study (Wind generation, interconnection capacities,
+> load, hydro generation, solar, etc.)*
+>
+> *Note that:*
+
+- > *If the “intra-modal correlated draws” option has not been
+ > selected in the **simulation** window, MC adequacy or economy
+ > simulations can take place even if the number of time-series is
+ > not the same in all areas (e.g. 2, 5, 1, 45,etc.)*
+
+- > *If the “intra-modal correlated draws” option has been selected in
+ > the **simulation** window, every area should have either one
+ > single time-series or the same given number (e.g. 25, 25, 1, 25,
+ > etc.). Note that, unlike the other time-series (load, hydro,
+ > etc.), which depend on meteorological conditions and are therefore
+ > inter-area-correlated, the thermal plants time-series should
+ > usually be considered as uncorrelated. Using the “correlated
+ > draws” feature makes sense only in the event of having to play
+ > predefined scenarios (outside regular MC scope) *
+
+
+
+- > *The “TS generator” tab is not accessible for this version.*
+
+- > *The “Common” tab is used to define the cluster’s techno-economic
+ > characteristics :*
+
+ - *Name*
+
+ - *Group. The group can be any one of the following: Wind
+ Onshore, Wind Offshore, Solar Thermal, Solar PV, Solar Rooftop,
+ Other RES 1, Other RES 2, Other RES 3, Other RES 4. If not
+ specified, the renewable cluster will be part of the group Other
+ RES 1.*
+
+ - *Location (Area)*
+
+ - *Timeseries mode: *
+
+ - *Power generation means that the unit of the timeseries is
+ in MW*
+
+ - *Production factor means that the unit of the timeseries is
+ in p.u. (between 0 and 1, 1 meaning the full installed
+ capacity)*
+
+ - *Activity status *
+
+ - *false: not yet commissioned, moth-balled, etc.*
+
+ - *true : the cluster may generate *
+
+ - *Number of units*
+
+## Nominal capacity (in MW per unit)
+Misc. Gen.
+
+> *This window is used to handle all input data regarding miscellaneous
+> non dispatchable generation. *
+>
+> *On picking any area in the primary list, the user gets direct access
+> to all data regarding the area, which amount to **8** ready-made
+> 8760-hour time-series (expressed in MW):*
+
+- *CHP generation*
+
+- *Bio Mass generation*
+
+- *Bio-gas generation *
+
+- *Waste generation*
+
+- *Geothermal generation*
+
+- *Any other kind of non-dispatchable generation*
+
+- *A predefined time-series for the operation of Pumped Storage Power
+ plants, if they are not explicitly modeled. A positive value is
+ considered as an output (generating) to the grid, a negative value
+ is an input (pumping) to the station.*
+
+> *Note that the sum of the 8760 values must be negative, since the
+> pumping to generating efficiency is lower than 1. The user may also
+> use only the negative values (prescribed pumping), while transferring
+> at the same time the matching generating credit on the regular hydro
+> storage energy credit. *
+
+- *ROW balance: the balance with the rest of the world. A negative
+ value is an export to ROW, a positive value is an import from ROW.
+ These values acts as boundary conditions for the model *
+
+> *Different ways to update data are:*
+
+- > *direct typing *
+
+- > *copy/paste a selected field to/from the clipboard*
+
+- > *load/save all the time-series from/to a file (usually located in
+ > the “user” subfolder) *
+
+- > *Apply different functions (+,-, \*, /,etc.) to the existing
+ > (possibly filtered) values (e.g. simulate a 2% growth rate by
+ > choosing “ multiply-all-by-1.02”)*
+
+- > *Handle the whole (unfiltered) existing dataset to either *
+
+ - *Change the number of columns (function name : resize)*
+
+ - *Adjust the values associated with the current first day of the
+ year (function name : shift rows) *
+
+*
+*
+
+## Reserves / DSM
+
+> *This window is used to handle all input data regarding reserves and
+> the potential of “smart” load management (when not modeled using
+> “fake” thermal dispatchable plants). On picking any area in the
+> primary list, the user gets direct access to all data regarding the
+> area, which amount to **four** ready-made 8760-hour time-series
+> (expressed in MW). The first two are used only in “draft” simulations,
+> while the last two are available in either “adequacy” or “economy”
+> simulations:*
+
+- *Primary reserve: must be provided whatever the circumstances, even
+ at the price of some unsupplied energy (Draft simulations only) *
+
+- *Strategic reserve: sets a limit on the backup power that an area is
+ supposed to be able to export to its neighbors. This reserve may
+ represent an actual generation reserve, an energy constraint too
+ complex to model by standard means (e.g. energy policy regarding
+ special reservoirs) or can also be justified by simplifications made
+ in grid modeling. (Draft simulations only).*
+
+- *Day-ahead reserve: power accounted for in setting up the optimal
+ unit-commitment and schedule of the following day(s), which must
+ consider possible forecasting errors or last-minute incidents. If
+ the optimization range is of one day, the reserve will be actually
+ seen as “day-ahead”. If the optimization range is of one week, the
+ need for reserve will be interpreted as “week-ahead”. (Adequacy and
+ Economy simulations) *
+
+- *DSM: power (decrease or increase) to add to the load. A negative
+ value is a load decrease, a positive value is a load increase. Note
+ that an efficient demand side management scheme may result in a
+ negative overall sum (All simulation modes). *
+
+## Links
+
+> *This window is used to handle all input data regarding the
+> interconnections. On picking any interconnection in the primary list,
+> the user gets direct access to all data regarding the link, which are
+> five annual parameters and a set of eight ready-made 8760-hour
+> time-series*
+>
+> *The five parameters, used in economy or adequacy simulations (not in
+> draft), are namely:*
+
+- *“ Hurdle cost ” : set by the user to state whether (linear)
+ transmission fees should be taken into account or not in economy and
+ adequacy simulations*
+
+- *“ Transmission capacities ”: set by the user to state whether the
+ capacities to consider are those indicated in 8760-hour arrays or if
+ zero or infinite values should be used instead (actual values / set
+ to zero / set to infinite)*
+
+- *“Asset type”: set by the user to state whether the link is either
+ an AC component (subject to Kirchhoff’s laws), a DC component, or
+ another type of asset*
+
+- *“Account for loop flows”: set by the KCG*\[9\] *to include (or not)
+ passive loop flows in the formulation of the constraints enforcing
+ Kirchhoff’s laws*
+
+- *“Account for PST”: set by the KCG to include (or not) the settings
+ of phase-shifting transformers in the formulation of the constraints
+ enforcing Kirchhoff’s laws*
+
+> *The eight 8760-hour times-series are: *
+
+- *NTC direct : the upstream-to-downstream capacity, in MW*
+
+- *NTC indirect : the downstream-to-upstream capacity, in MW*
+
+- *Hurdle cost direct : an upstream-to-downstream transmission fee, in
+ €/MWh*
+
+- *Hurdle cost indirect : a downstream-to-upstream transmission fee,
+ in €/MWh*
+
+- *Impedances: used in economy simulations to give a physical meaning
+ to raw outputs, when no binding constraints have been defined to
+ enforce Kirchhoff’s laws (see “Output” section, variable “Flow
+ Quad”) OR used by the Kirchhoff’s constraint generator to build up
+ proper flow constraints (AC flow computed with the classical “DC
+ approximation”). Since voltage levels are not explicitly defined and
+ handled within Antares, all impedances are assumed to be scaled to
+ some reference* \(U_{\text{ref}}\)
+
+- *Loop flow: amount of power flowing circularly though the grid when
+ all “nodes” are perfectly balanced (no import and no export). Such
+ loop flows may be expected on any “simplified” grid in which large
+ regions (or even countries) are modeled by a small number of “macro”
+ nodes, and should accordingly be accounted for. *
+
+- *PST min (denoted* \(Y^{-}\) *in Section 7): lower bound of
+ phase-shifting that can be reached by a PST installed on the link,
+ if any (note : the effect of the active loop flow generated by the
+ PST may be superimposed to that of the passive loop flow)*
+
+- *PST max (denoted* \(Y^{+}\) *in Section 7): upper bound of
+ phase-shifting that can be reached by a PST installed on the link,
+ if any (note : the effect of the active loop flow generated by the
+ PST may be superimposed to that of the passive loop flow)*
+
+> *For the sake of simplicity and homogeneity with the convention used
+> for impedances, PST settings are assumed to be expressed in*
+> \(rad/U_{\text{ref}}^{2}\) **
+> **
+
+## Binding constraints
+
+> *This section of the GUI is used to handle all data regarding special
+> constraints that one may wish to include in the formulation of the
+> optimization problems to solve.*
+>
+> *The set of tabs described hereafter provides for that purpose all the
+> means required to define arbitrary linear constraints on any subset of
+> continuous variables involved in the modeling of the power system. *
+>
+> *Since no limitation is set on the number and content of the
+> constraints that may be defined that way, it is the user’s sole
+> responsibility to make sure that these so-called “binding constraints”
+> are realistic and meaningful, be it from a technical or economic
+> standpoint. *
+>
+> *A typical situation in which this feature proves useful is, for
+> instance, encountered when data at hand regarding the grid include an
+> estimate of the impedances of the interconnections.*
+>
+> *In such cases, assuming that:*
+
+- \(\mathbf{Z}_{\mathbf{l}}\) *denotes the impedance of
+ interconnections* \(\mathbf{l = 1,L}\)
+
+- *A preliminary study of the graph modeling the grid has shown that
+ it can be described by a set of independent meshes*
+ \(\mathbf{c = 1,\ C}\) *(cycle basis of the graph) *
+
+> *Then the DC flow approximation may be implemented, for each time-step
+> of the simulation, by a set of C binding constraints between AC
+> flows*\(\) \(F_{l}\)*: *
+
+\[c = 1,\ldots,\ C\ :\ \sum_{l \in c}^{}{\text{sign}\left( l,c \right)F_{l}Z_{l} = 0\ }\ \]
+
+> *Note that such specific binding constraints can be automatically
+> generated within Antares by using the auxiliary module “Kirchhoff’s
+> Constraints Generator” further described in Section 7.*
+>
+> *Aside from such sets of constraints, which may help to give realistic
+> geographic patterns to the flows, completely different sets of
+> constraints may be also defined, such as those set up by the market
+> organization, which may define precise perimeters for valid commercial
+> flows*\[10\]*.*
+>
+> *More generally, Antares allows to define three categories of binding
+> constraints between transmission flows and/or power generated from
+> generating units:*
+
+- *“hourly” binding constraints, which are applied to instant power
+ (transmitted and/or generated)*
+
+- *“daily” binding constraints, that are applied to daily energies.
+ This class makes more sense for commercial modeling (say : imports
+ and exports from/to such and such area should be comprised between
+ such and such lower bound and upper bound). Daily binding
+ constraints are also commonly used to model specific facilities,
+ such as pumped storage units operated on a daily cycle *
+
+- *“weekly” binding constraints, that are applied to weekly energies.
+ Like the previous ones, these constraints may be used to model
+ commercial contracts or various phenomena, such as the operation of
+ a pumped storage power plant operated on a weekly cycle.*
+
+*
+*
+
+The Binding Constraints section of the GUI involves six main tabs
+described hereafter:
+
+- > *TAB “summary” Creation, edition or removal of a binding
+ > constraint. A binding constraint is here defined by four
+ > macroscopic attributes that can be set by the edit command:*
+
+
+
+- *Name (caption) *
+
+- *Time-range (hourly, daily, weekly)*
+
+- *Numerical type (equality, bounded above, below, on both sides)*
+
+- *Status (active /enabled or inactive/disabled)*
+
+
+
+- > *TAB “weights” Definition of the coefficients given to each flow
+ > variable or generation variable in the formulation of the
+ > constraints. Two sub-tabs make it possible to handle the
+ > coefficients associated with transmission assets (links) and those
+ > associated with generation assets (thermal clusters). In both
+ > cases: *
+
+
+
+- *The lines of the tables show only the components (links or
+ clusters) that are visible on the current map*
+
+- *The columns of the tables show only the constraints that do not
+ have non-zero weights attached to components that are nor visible on
+ the current map*
+
+
+
+- > *TAB “offsets” Definition of the time-lag (in hours) assigned to
+ > each flow variable or generation variable in the formulation of
+ > the constraints. Two sub-tabs make it possible to handle the
+ > offsets associated with transmission assets (links) and those
+ > associated with generation assets (thermal clusters). In both
+ > cases: *
+
+
+
+- *The lines of the tables show only the components (links or
+ clusters) that are visible on the current map*
+
+- *The columns of the tables show only the constraints that do not
+ have non-zero weights attached to components that are nor visible on
+ the current map*
+
+
+
+- > *TAB “=” Definition of the right-hand side of equality
+ > constraints. This RHS has either 8760 values (hourly constraints)
+ > or 365 values (daily or weekly constraints). Depending on the
+ > range actually chosen for the simplex optimization (see section
+ > **Configure** of the main menu), the weekly constraints RHS will
+ > either be represented by the sum of seven daily terms or by a set
+ > of seven daily terms (weekly constraint downgraded to daily
+ > status).*
+
+- > *TAB “\>” Definition of the right-hand side of ”bounded below” and
+ > “bounded on both sides” inequality constraints. This RHS has
+ > either 8760 values (hourly constraints) or 365 values (daily or
+ > weekly constraints). Depending on the range actually chosen for
+ > the simplex optimization (see section **Configure** of the main
+ > menu), the weekly constraints RHS will either be represented by
+ > the sum of seven daily terms or by a set of seven daily terms
+ > (weekly constraint downgraded to daily status).*
+
+- > *TAB “\<” Definition of the right-hand side of ”bounded above” and
+ > “bounded on both sides” inequality constraints. This RHS has
+ > either 8760 values (hourly constraints) or 365 values (daily or
+ > weekly constraints). Depending on the range actually chosen for
+ > the simplex optimization (see section **Configure** of the main
+ > menu), the weekly constraints RHS will either be represented by
+ > the sum of seven daily terms or by a set of seven daily terms
+ > (weekly constraint downgraded to daily status).*
+
+> *When defining binding constraints between (hourly) power, daily or
+> weekly (energy) flows, special attention should be paid to potential
+> conflicts between them or with the “basic “ problem constraints. Lack
+> of caution may result in situations for which the optimization has no
+> solution. Consider for instance a case in which three variables X1,
+> X2, X3 (whatever they physical meaning) are involved in the following
+> binding constraints: *
+>
+> *(T1+T2 \> 5 ; T2 \< -3 ; T3 \> 0 ; T1+T3 \< 7) *
+>
+> *These commitments are obviously impossible to meet and, if the
+> economic simulator is run on a dataset including such a set of
+> constraints, it will produce an unfeasibility diagnosis. *
+>
+> *The advanced preference “Unfeasible Problems Behavior” gives to the
+> user the ability to choose between four different strategies regarding
+> these situations. *
+
+## Economic Opt.
+
+> *This window is used to set the value of a number of area-related
+> parameters that, aside from the costs of each generating plant, define
+> the optimal solution that Antares has to find in economic simulations.
+> These parameters are namely, for each area of the system: *
+
+- *The value of the unsupplied energy (also commonly denoted Value Of
+ Lost Load,VOLL) , in €/MWh. This value should usually be set much
+ higher than the cost of the most expensive generating plant of the
+ area *
+
+- *The random spread within which the nominal unsupplied energy value
+ is assumed to vary*
+
+- *The value of the spilled energy, in € /MWh. This value reflects the
+ specific penalty that should be added to the economic function for
+ each wasted MWh, if any. Note that even if this value is set to zero
+ no energy will be shed needlessly*
+
+- *The random spread within which the nominal unsupplied energy value
+ is assumed to vary*
+
+- *Three parameters named “shedding status” and related to different
+ kinds of generation. If the system cannot be balanced without
+ shedding some generation, these parameters give control on how each
+ kind of generation ("Non dispatchable power",”Dispatchable
+ hydropower” and “Other dispatchable generating plants”) should
+ contribute to the shedding. Depending on the value chosen for the
+ status, the generation can or cannot be shed to find a solution to
+ the load/generation balance problem. Note that enforcing a negative
+ status for all types of plants may lead to simulations scenarios for
+ which there are no mathematical solutions.*
+
+> *On running the economic simulator, such situations produce an
+> unfeasibility diagnosis.*
+
+## Miscellaneous
+
+*In all previous windows showing Input data, the content can be filtered
+so as to reflect only items that are associated with Areas and Links
+defined as “visible” in a particular map. In that regard, binding
+constraints are considered as visible if and only if all of their
+non-zero weight associated objects are visible on the map.*
+
+# 5 Output files
+
+*The general file organization is the same for Economy, Adequacy and
+Draft simulations.*
+
+- *Economy and Adequacy results may be displayed in the GUI ( “Output”
+ in main menu)*
+
+- *Draft results are available only as flat .txt files. They can be
+ viewed with “Tool /csv viewer” in the main menu (As well as any
+ other files, they can also be accessed by Xcel or suchlike)*
+
+*Economy: *
+
+*OUTPUT/ Simu id / Economy /mc-all / grid /... contains a summary file
+"digest.txt"*
+
+*/areas/name/... contains area-related results*
+
+*/links / name/... contains interconnection-related results*
+
+*/mc-ind /\ *
+
+*/areas/name/... contains area-related results*
+
+*/links / name/... contains interconnection-related results*
+
+*(“mc-all” files contain synthetic results over all years, “year-number”
+files contain results for a single year*
+
+*The variables present in each file are detailed in the following
+sections *
+
+*In “Economy” simulations, all variables have a techno-economic meaning*
+
+*Adequacy: *
+
+*OUTPUT/ Simu id / Adequacy /mc-all / grid /... contains a summary file
+"digest.txt"*
+
+*/areas/name/... contains area-related results*
+
+*/links / name/... contains interconnection-related results*
+
+*/mc-ind /\ *
+
+*/areas/name/... contains area-related results*
+
+*/links / name/... contains interconnection-related results*
+
+*(“mc-all” files contain synthetic results over all years, “year-number”
+files contain results for a single year*
+
+*The variables present in each file bear exactly the same name as in
+Economy simulations but do not have the same values *
+
+*The only variables that have a techno-economic meaning are the
+“Adequacy” indicators (unsupplied energy,LOLD,LOLP) *
+
+*Draft: *
+
+*OUTPUT / Simu id / Adequacy-Draft / mc-all /grid/... contains a
+condensed file "digest.txt"*
+
+*/areas/name/... contains area-related results *
+
+*(“mc-all” files contains mostly synthetic results over all years ;
+However, there is (for each area) a “mc-annual.txt” file that gives a
+short view of local results for each simulated year)*
+
+***IMPORTANT** Adequacy and Economy files look the same but their
+content are specific*
+
+*In “Economy” and “Adequacy” simulations, the optimization ignores the
+“primary” and “strategic” reserves (however, it may include the
+\[other\] spinning and day-ahead reserves, depending on the settings
+made in “optimization preferences”). *
+
+*In “Adequacy” simulations, all dispatchable thermal units are given the
+“must-run” status (hence, they will generate at Pmax, regardless of the
+demand). As a consequence the only variables that are actually
+meaningful are the adequacy indicators (unsupplied energy, LOLD,LOLP),
+that may depend on assumptions made regarding the economic values of
+Unsupplied and spilled energies, and on hurdle costs on
+interconnections. *
+
+*As a consequence, both “Adequacy” and “Economy” simulations yield the
+same values for the adequacy indicators under the following conditions:
+if hurdle costs on interconnections are higher than the difference
+between the maximum VOLL and the minimum VOLL assigned to the different
+areas of the system.*
+
+*The files and their content are hereafter described.*
+
+## Economy and Adequacy, area results\[11\]
+
+> ***15** files resulting from the combination of the following
+> attributes:*
+
+***\[values | id | details\] X \[hourly | daily | weekly | monthly |
+annual\]***
+
+- *The second attribute defines the time span over which the results
+ are assessed: hourly detail, daily bundle, weekly bundle, monthly
+ bundle, annual bundle.*
+
+- *The first attribute defines the nature of the results presented in
+ the file :*
+
+> ***Values** Values of different variables (price, load, overall
+> generation issued from coal, etc.), the list of which is common to all
+> areas of the interconnected system. Files of type "values" have
+> therefore the same size for all areas.*
+>
+> *These results appear under the label “general values” in the output
+> GUI *
+>
+> ***details** Values regarding the different dispatchable thermal
+> generating plants of each area (e.g. “older 300 MW coal from the south
+> coast”). The sizes of these files differ from one area to another. *
+>
+> *These results appear under the label “thermal plants” in the output
+> GUI *
+
+***id** Identifier (number) of the Monte-Carlo years for which were
+observed the extreme values of the different variables presented in the
+« values » files *
+
+> *These results appear under the label “record years” in the output
+> GUI*
+
+*The area files that belong to the « values » class display **122**
+fields corresponding to the expectation, standard deviation, minimal and
+maximal values of the variables whose list is given hereafter. *
+
+*OV.COST* *Overall cost = operating cost + unsupplied cost+ spilled
+cost+ hydro cost*
+
+*OP.COST Operating cost = Proportional costs + Non- proportional costs*
+
+*MRG. PRICE* *LMP : overall economic effect of a local 1MW load
+increase*
+
+*CO2 EMIS.* *Amount of CO2 emitted by all dispatchable thermal plants *
+
+*BALANCE* *Overall Import/export balance of the area (positive value :
+export) *
+
+*ROW BAL Import/export with areas outside the modeled system (positive
+value: import)*\[12\]
+
+*PSP User-defined settings for pumping and subsequent generating *
+
+*MISC. NDG Miscellaneous non dispatchable generation *
+
+*LOAD Demand (including DSM potential if relevant) *
+
+*H.ROR Hydro generation, Run-of-river share*
+
+*WIND* *Wind generation (only when using aggregated Renewable generation
+modeling)*
+
+*SOLAR* *Solar generation (thermal and PV) (only when using aggregated
+Renewable generation modeling)*
+
+*NUCLEAR Overall generation of nuclear clusters*
+
+*LIGNITE Overall generation of dispatchable thermal clusters burning
+brown coal*
+
+*COAL Overall generation of dispatchable thermal clusters burning hard
+coal*
+
+*GAS Overall generation of dispatchable thermal clusters burning gas*
+
+*OIL Overall generation of dispatchable thermal clusters using petroleum
+products*
+
+*MIX.FUEL Overall gen. of disp. thermal clusters using a mix of the
+previous fuels *
+
+*MISC.DTG* *Overall gen. of disp. thermal clusters using other fuels*
+
+*MISC.DTG 2* *Overall gen. of disp. thermal clusters using other fuels*
+
+*MISC.DTG 3* *Overall gen. of disp. thermal clusters using other fuels*
+
+*MISC.DTG 4* *Overall gen. of disp. thermal clusters using other fuels*
+
+*WIND OFFSHORE* *Wind Offshore generation (only when using clustered
+Renewable generation modelling)*
+
+*WIND ONSHORE* *Wind Onshore generation (only when using clustered
+Renewable generation modelling)*
+
+*SOLAR CONCRT.* *Concentrated Solar Thermal generation (only when using
+clustered Renewable generation modelling)*
+
+*SOLAR PV* *Solar Photovoltaic generation (only when using clustered
+Renewable generation modelling)*
+
+*SOLAR ROOFT* *Rooftop Solar generation (only when using clustered
+Renewable generation modelling)*
+
+*RENW. 1* *Overall generation of other Renewable clusters (only when
+using clustered Renewable generation modelling)*
+
+*RENW. 2* *Overall generation of other Renewable clusters (only when
+using clustered Renewable generation modelling)*
+
+*RENW. 3* *Overall generation of other Renewable clusters (only when
+using clustered Renewable generation modelling)*
+
+*RENW. 4* *Overall generation of other Renewable clusters (only when
+using clustered Renewable generation modelling)*
+
+*H.STOR Power generated from energy storage units (typically: Hydro
+reservoir) *
+
+*H.PUMP Power absorbed by energy storage units (typically: PSP pumps
+consumption)*
+
+*H.LEV Energy level remaining in storage units (percentage of reservoir
+size) *
+
+*H.INFL External input to the energy storage units (typically: natural
+inflows)*
+
+*H.OVFL Wasted natural inflow overflowing from an already full energy
+storage unit *
+
+*H.VAL Marginal value of stored energy (typically: shadow water value) *
+
+*H.COST Expenses /Income brought by energy storage actions
+(H.STOR,H.PUMP)*
+
+*UNSP. ENRG Unsupplied energy: adequacy indicator (Expected Energy Not
+Served–EENS) *
+
+*SPIL. ENRG Spilled energy (energy produced that cannot be used and has
+to be wasted)*
+
+*LOLD Loss of load duration: adequacy indicator (length of shortfalls)*
+
+*LOLP Loss of Load probability: adequacy indicator (probability of
+shortfalls) *
+
+*AVL DTG Available dispatchable thermal generation (sum of av. power
+over all plants)*
+
+*DTG MRG Disp. Ther. Gen. (AVL DTG – sum of all dispatched thermal
+generation) *
+
+*MAX MRG Maximum margin: operational margin obtained if the hydro
+storage energy of the week were used to maximise margins instead of
+minimizing costs*
+
+*NP COST Non-proportional costs of the dispatchable plants (start-up and
+fixed costs)*
+
+*NODU Number of Dispatched Units*\[13\]*
+*
+
+## Economy and Adequacy, interconnection results\[14\]
+
+> ***10** files resulting from the combination of the following
+> attributes :*
+
+***\[values | id\] X \[hourly | daily | weekly | monthly | annual\]***
+
+- *The second attribute defines the period of time over which the
+ results are assessed : hourly detail, daily bundle, weekly bundle,
+ monthly bundle, annual bundle.*
+
+- *The first attribute defines the nature of the results presented in
+ the file*
+
+***values** values of different variables (flow, congestion rent) the
+list of which is common to all interconnections. The files of type
+"values" have therefore the same size everywhere*
+
+> *These results appear under the label “general values” in the output
+> GUI *
+
+***id** identifier (number) of the Monte-Carlo years for which were
+observed the extreme values of the different variables presented in the
+« values » files *
+
+> *These results appear under the label “record years” in the output
+> GUI*
+
+*The area files that belong to the « values » class display **28**
+fields corresponding to the expectation, standard deviation, minimal and
+maximal values of the variables whose list is given hereafter. *
+
+*FLOW LIN. Flow (signed + from upstream to downstream) assessed by the
+linear optimization. These flows follow Kirchhoff’s law only if these
+laws have been explicitly enforced by the means of suitable binding
+constraints *
+
+*UCAP Used capacity: absolute value of FLOW LIN. This indicator may be
+of interest to differentiate the behavior of interconnectors showing low
+average flows: in some cases this may indicate that the line is little
+used, while in others this may be the outcome of high symmetric flows*
+
+*LOOP FLOW Flow circulating through the grid when all areas have a zero
+import/export balance. This flow, to be put down to the simplification
+of the real grid, is not subject to hurdle costs in the course of the
+optimization*
+
+*FLOW QUAD. Flow computed anew, starting from the linear optimum, by
+minimizing a quadratic function equivalent to an amount of Joule losses,
+while staying within the transmission capacity limits. This calculation
+uses for this purpose the impedances found in the “Links” Input data. If
+congestions occur on the grid, these results are not equivalent to those
+of a DC load flow *
+
+*CONG. FEE ALG Algebraic congestion rent = linear flow \* (downstream
+price – upstream price)*
+
+*CONG. FEE ABS Absolute congestion rent = linear flow\* abs(downstream
+price–upstream price)*
+
+*MARG. COST Decrease of the system’s overall cost that would be brought
+by the optimal use of an additional 1 MW transmission capacity (in both
+directions) *
+
+*CONG PROB + Up\>Dwn Congestion probability = (NC+) / (total number of
+MC years) with: *
+
+> *NC+ = number of years during which the interconnection was congested
+> in the Up\>Dwn way for **any** length of time within the time frame
+> relevant with the file *
+
+*CONG PROB - Dwn\>Up Congestion probability = (NC-) / (total number of
+MC years) with: *
+
+> *NC- = number of years during which the interconnection was congested
+> in the Dwn\>Up way for **any** length of time within the time frame
+> relevant with the file *
+
+*HURD. COST Contribution of the flows to the overall economic function
+through the “hurdles costs” component. For each hour:*
+
+*if (FLOW.LIN –LOOP FLOW) \> 0 *
+
+> *HURD. COST = (hourly direct hurdle cost) \* (FLOW LIN.) *
+>
+> *else HURD.COST = (hourly indirect hurdle cost) \* (-1)\* (FLOW LIN.)
+> *
+
+##
+Economy and Adequacy, other results
+
+> *Depending on the options chosen in the main simulation window, the
+> output folders may also include either, both or none of the following
+> sections:*
+
+- *OUTPUT/ Simu Id / ts-numbers / Load /area names / ...*
+
+> */ Thermal /area names / ...*
+>
+> */ Hydro /area names / ...*
+>
+> */ Wind /area names / ...*
+>
+> */ Solar /area names / ... *
+>
+> *These files contain, for each kind of time-series, the number drawn
+> (randomly or not) in each Monte-Carlo year (files are present if
+> “output profile / MC scenarios” was set to “true”)*
+
+- *OUTPUT/ Simu Id / ts-generator / Load / batch number /area names /
+ ...*
+
+> */ Thermal / batch number /area names / ...*
+>
+> */ Hydro / batch number /area names / ...*
+>
+> */ Wind / batch number /area names / ...*
+>
+> */ Solar / batch number /area names / ...*
+>
+> *These files contain, for each kind of Antares-generated time-series,
+> copies of the whole set of time-series generated. Batch numbers depend
+> on the values set for the “refresh span” parameters of the stochastic
+> generators (files are present if “store in output” was set to “true”)*
+
+## Draft, area results
+
+***1** file « annual » + **6** files resulting from the combination of
+the following attributes :*
+
+*\[with-network | without-network | id\] X \[ hourly | annual\]*
+
+- *The second attribute defines the period of time over which the
+ results are assessed : hourly detail or annual summary.*
+
+- *The first attribute defines the nature of the results presented in
+ the file*
+
+***with network** values of adequacy indices (shortfall duration, loss
+of load probability) assessed while taking into account the effective
+grid capacities. The results in these files bear the suffix –CN
+(connex)*
+
+***without network** values of adequacy indices (shortfall duration,
+loss of load probability) assessed without taking into account any
+interconnection. The results in these files bear the suffix –IS
+(isolated areas)*
+
+***id** identifiers (numbers) of the MC years for which were observed
+the extreme values of the different variables presented in the « w/net »
+and “wo/net” files *
+
+*
+*
+
+*Files « with network » et « without network » present the expectations
+and extreme values observed for the variables whose list is given
+hereafter: *
+
+*LOLD Overall length of time for which there were shortfalls (Loss of
+Load Duration) *
+
+> *(note: the commonly used LOLE index is equivalent to LOLD expectation
+> )*
+
+*LOLP Loss of Load Probability*
+
+*EENS Energy Not Supplied *
+
+*MARG Margin = available generation – (load + primary reserve)*
+
+*When MARG\>0, MARG is a security margin*
+
+*When MARG \<0 , MARG is a curtailment depth*
+
+*The file « annual » has one line per simulated Monte-Carlo year and
+gives, for each year, the following information:*
+
+*LOLD IS Load shedding duration, if the grid capacities are not
+considered as available*
+
+*LOLD CN Load shedding duration, if the grid capacities are actually
+available*
+
+*MAX DEPTH IS Margin available at the most critical hour of the whole MC
+year, w/o grid*
+
+*When MAX DEPTH \>0 , MAX DEPTH is a security margin*
+
+> *When MAX DEPTH \<0,MAX DEPTH is a shortfall depth*
+
+*MAX DEPTH CN Margin available at the most critical hour of the whole MC
+year, w/ grid*
+
+*When MAX DEPTH \>0 , MAX DEPTH is a security margin*
+
+> *When MAX DEPTH \<0,MAX DEPTH is a shortfall depth*
+
+*Remark: In spite of their likenesses, the fields « MARG » of the files
+w/net, wo/net and the fields « MAX DEPTH » of the file mc-details are
+not identical (hence different names): *
+
+- *MARG (expectation, min, max) is related to the whole set of MC
+ years *
+
+- *MAX DEPTH regards one single year.*
+
+*Note that the following relations hold:*
+
+*Min { MC years } MAX DEPTH IS = Min { hours} MARG IS \[MIN\]*
+
+*Min { MC years } MAX DEPTH CN = Min { hours} MARG CN \[MIN\]*
+
+## Miscellaneous
+
+*Alike Input data, output results can be filtered so as to include only
+items that are associated with Areas and Links defined as “visible” in
+the current map. In addition, the output filtering dialog box makes it
+possible to filter according to two special categories (**Districts**
+and **Unknown**) that are not related to standard maps:*
+
+- ***Districts** displays only results obtained for spatial
+ aggregates*
+
+- ***Unknown** displays only results attached to Areas or Links that
+ no longer exist in the Input dataset (i.e. study has changed since
+ the last simulation)*
+
+#
+
+#
+
+#
+
+#
+
+# 6 Time-series analysis and generation
+
+## General
+
+*When ready-made time-series are not available or are too scarce for
+building the required number of Monte-Carlo annual simulation scenarios,
+Antares provides means to generate sets of stochastic time-series to use
+instead. *
+
+*The different categories of time-series call for wholly different
+generation processes:*
+
+- *For thermal power, the generator is based on the animation of a
+ daily three-state Markov chain (available – planned outage – forced
+ outage ) attached to each plant. *
+
+- *For Hydro-power, the generator works out monthly time-series of
+ energies, based on the assumption that they can be modeled by Log
+ Normal variables with known correlations through space and time. So
+ as to keep the model simple, for an interconnected system made of N
+ areas, the user defines, along with the N expectations and N
+ standard deviations of the monthly energies, the N X N correlation
+ matrix R(n,m) of the logs of the annual hydro energies between the
+ areas n,m, and the N average auto-correlations r(k) between one
+ month and the next in each area k. The correlation **C(n,i,m,j)**
+ between the logs of hydro energies in area **n**, month **i** and
+ area **m**, month **j** is taken to be **C(n,i,m,j)=
+ R(n,m)\*sqrt((r(n)\*r(m))^abs(j-i))** This most simplified model
+ asks for considerably fewer data than a comprehensive 12N X 12N
+ time-space matrix. Note that if R is positive semi-definite but C is
+ not, matrix C is automatically transformed into a fitting p.s.d
+ matrix and the data generation keeps going on (however, the log
+ report will show a warning message). If the primary matrix R is not
+ p.s.d, data are considered as corrupted, the generation stops and a
+ fatal error message will be displayed in the log report *
+
+- *For Wind power, Solar power and Load, the required time-series are
+ 8760-hour long and have to emulate as closely as possible the
+ response of the system to variations of wind speed, sunshine and
+ temperature. In all three cases, the rationale of the model is to
+ offer the possibility to consider either the final variable to model
+ (wind power output, solar power output, load) or an underlying
+ intermediate variable (wind speed, nebulosity, deviation between
+ load and the level expected in standard temperature conditions) as a
+ stationary stochastic process, with given marginal laws, given
+ auto-correlation functions and given spatial correlations
+ (eventually, the values of the final variables and those of the core
+ stationary process are tied by diurnal/seasonal rhythms and scaling
+ functions). *
+
+The identification of all relevant parameters can be made outside
+Antares by any appropriate means but can also be made automatically by
+the time-series analyzer, which is then to be fed with the largest
+available set of historical time-series. Note however that, using the
+time-series analyzer, one has to consider whether the time-series at
+hand are statistically meaningful or whether they need some
+pre-processing (for instance, if wind power time-series are gathered for
+a period within which the fleet has been expanded, the time-series to
+analyze should be expressed in % of installed power rather than in MW.
+For Solar power, the relevant variable to model as a stationary
+stochastic process is probably not the raw output of solar power but
+more likely a meteorological indicator related to the sky clarity (for
+instance , time-series of nebulosity expressed on a 0-100 scale may be
+used).
+
+> Once generated by appropriate algorithms, the values of the stationary
+> processes are turned into final values by using a number of parameters
+> that put back in the series the diurnal and seasonal patterns that may
+> have been observed in the course of the historical data analysis and
+> that were temporarily removed to identify the core stationary
+> processes.
+
+##
+
+## Time-series generation (load, wind, solar): principles
+
+*For the generation of wind, solar and load time-series, Antares gives
+access to different marginal laws and autocorrelation functions
+presented hereafter. Note that wind speed modeling should usually be
+based upon a Weibull modeling, while almost all other situations are
+likely to be best modeled by Beta variables. *
+
+*The stationary processes are defined at a monthly scale. For each
+month, there are:*
+
+- *Four parameters for the definition of the marginal law *
+
+| | | | | | | |
+| --------- | ----------------------- | ----- | ----- | ----- | ---------------- | ----------------------------------- |
+| | **TS Gen. Parameters ** | | | | | |
+| ***Law*** | **α** | **β** | **γ** | **δ** | **Expectation** | **Variance** |
+| Uniform | N/A | N/A | \< δ | \>γ | (δ−γ)/2 | (δ−γ)^2 /12 |
+| Beta | \>0 | \>0 | \< δ | \>γ | γ + α(δ−γ)/(α+β) | \[αβ(δ−γ)^2\] / \[(α+β+1)(α+β)^2 \] |
+| Normal | Any | \>0 | N/A | N/A | α | β^2 |
+| Weibull | \>=1 \<50 | \>0 | N/A | N/A | β Γ(1+1/α) | β^2\[ Γ(1+2/α)−Γ(1+1/α)^2)\] |
+| Gamma | \>=1 \<50 | \>0 | N/A | N/A | α∗β | α∗β^2 |
+
+*Uniform : uniform defined on (γ,δ) *
+
+*Beta : Beta(α,β) defined on (γ,δ)*
+
+*Normal : expectation α, standard deviation β*
+
+*Weibull : shape α, scale β, defined on (0,+inf.)*
+
+*Gamma : shape α, scale β, defined on (0, +inf.) *
+
+*In the expressions of expectation and variance, Γ(x) is the standard
+Euler Function*
+
+- *Two parameters for the definition of the autocorrelation function *
+
+#
+
+| | | | |
+| ------------------------------ | ---------------------- | ------------ | ------------------ |
+| | **TS Gen. Parameters** | | |
+| ***Law*** | **θ** | **μ** | **Corr (Xt,Xt+h)** |
+| Pure exponential decay | θ \> 0 | μ =1 | exp( - θh) |
+| Smoothed exponential decay(\*) | θ \> 0 | 1 \< μ \< 24 | Phi(θ,μ,h) |
+
+#
+
+**Phi(θ,μ,h)= (1/A) \*sigma {i=0,μ} \[sigma {j=h,h+μ} (exp(-θ|j-i|))\]**
+
+**with A= μ + 2 sigma{i=1,μ ;j=1,μ ; j\>i } (exp(-θ(j-i))**
+
+*(\*) Obtained by the generation of purely exponentially autocorrelated
+values (parameter θ) followed by a moving average transformation
+(parameter μ). θ and μ should be carefully chosen so as to accommodate
+at best the experimental data at hand. If meaningful historical data are
+available, this identification may be directly made using the Antares
+time-series analyzer*
+
+*
+*
+
+## Time-series generation (load, wind, solar): GUI
+
+*The section of the GUI specific to the generation of wind, solar and
+load time-series comprises:*
+
+1. ***Spatial correlation matrices that are located within the “spatial
+ correlation” tab of each path “ Wind | Solar | Load / \” ***
+
+> *This tab contains a workspace for the description of 12 monthly
+> spatial correlation matrices Ξ and one annual correlation matrix. For
+> the stochastic generators to work properly, these matrices must meet
+> the usual requirements (matrices must be p.s.d, symmetric, with all
+> terms between -100 and +100, and a main diagonal made of 100s). If
+> this is not the case, generators will emit an unfeasibility diagnosis.
+> Matrices can be either set up manually OR automatically filled out by
+> the time-series analyzer (see next paragraph). *
+>
+> *Depending on the choices made in the main “simulation” window, the
+> matrices used will be either the 12 monthly matrices or the annual
+> matrix. Whether to use the first or the second option depends on the
+> quality of the statistical data at hand: with high quality data (for
+> instance, that derived from the analysis of a very large pool of
+> historical data), use of monthly correlations is recommended because
+> monthly differences between matrices have a physical meaning ; with
+> less robust data (derived from a handful of historical data,…), use of
+> the single annual correlation matrix should be preferred because it
+> smooths out the numeric noise which impairs the monthly matrices. *
+
+2. ***Four parameters and four subtabs that are located within the
+ “local” tab of each path “Wind | Solar | Load / \”
+ ***
+
+> ***FOUR PARAMETERS***
+
+- *Capacity : This first parameter is used to scale up time-series
+ generated on the basis of the (α,β,γ,δ,θ,μ) parameters described
+ previously in the “principles” paragraph, together with coefficients
+ characterizing the diurnal pattern (see below) *
+
+
+
+- *Distribution : This second parameter gives the type of marginal
+ distribution of the stationary stochastic processes to generate
+ (Beta, Weibull, Normal, Gamma, Uniform) *
+
+
+
+- *Translation : This third parameter has three possible values :*
+
+ - *Do not use : parameter ignored *
+
+ - *Add before scaling : A specific 8760-hour array is added to the
+ time-series produced by the primary stochastic generator, BEFORE
+ use of the conversion table (optional) followed by the final
+ multiplication by the capacity factor *
+
+ - *Add after scaling : A specific 8760-hour array is added to the
+ time-series produced by the primary stochastic generator, AFTER
+ use of the conversion table (optional) followed by the final
+ multiplication by the capacity factor*
+
+*
+*
+
+ - *Conversion : This fourth parameter has two possible values :*
+
+ - *Do not use : Any transfer function that may be described in the
+ “conversion” subtab (see below) should not be used for the final
+ stage of data elaboration (for instance, if the primary
+ parameters describe the physics of wind speeds, the time-series
+ eventually produced should remain wind speeds and not wind
+ power). *
+
+ - *Use: The time-series produced by the stochastic generators
+ (wind speeds, for instance) are turned into other values (wind
+ power) by using the transfer function described in the
+ “conversion” subtab.*
+
+> ***FOUR SUBTABS***
+
+- *Subtab “Coefficients”*
+
+> *A twelve-month table of values for the primary parameters
+> α,β,γ,δ,θ,μ*
+
+*This table may be either filled out manually or automatically (use of
+the time-series analyzer) *
+
+- *Subtab “Translation”*
+
+> *Contains an 8760-hour array T to add to the time-series generated,
+> prior or after scaling. This array can be either filled out manually
+> or by the time-series analyzer.*
+
+- *Subtab “Daily profile”*
+
+> *A 24\*12 table of hourly / monthly coefficients K(hm) that are used
+> to modulate the values of the stationary stochastic process by which
+> the actual process is approximated. This table can be either filled
+> out manually or by the time-series analyzer.*
+
+- *Subtab “Conversion”*
+
+> *A table of 2 \* N values (with 1\<=N\<=50) that is used to turn the
+> initial time-series produced by the generators (for instance, wind
+> speeds) into final data (for instance, wind power). The transfer
+> function (speed to power, etc.) is approximated by N discrete points
+> whose abscises X(N) an ordinates Y(N) are given by the table. *
+
+*
+*
+
+## Time-series analysis (load, wind, solar)
+
+##
+
+*The time-series analyzer module available in Antares is meant to
+identify the values that should be given to the parameters used in the
+time-series generators (load, solar power, wind power) so as to fit best
+historical time-series at hand*
+
+***IMPORTANT** *
+
+*When the time-series analyzer is used, it automatically updates the
+parameters relevant to the analysis (for instance: analysis of “wind”
+time-series will overwrite all local and global “wind” parameters
+\[correlation matrices\] that may have been previously set manually)*
+
+*The primary TS analyzer window shows two tabs:*
+
+1. ***Tab “Time-series and areas”***
+
+ - *Time-series (load, wind, solar) : class of parameters to be
+ assessed by the analyzer*
+
+ - *Browse: location of the historical time-series files. These are
+ txt files in which 8760-hour time-series must be stored in
+ adjacent columns separated by a tabulation*
+
+ - *For each area :*
+
+ - *Activity status *
+
+ - *yes : parameters will be assessed and updated by the
+ analyzer*
+
+ - *no : the area will be skipped (**local** parameters for
+ the area will remain unchanged, however **spatial**
+ correlation with other areas will be reset to zero) *
+
+ - *Distribution *
+
+ - *Type of distribution to fit (beta, normal, etc.)*
+
+ - *Data*
+
+ - *Raw : data to analyze are the actual historical
+ time-series *
+
+ - *Detrended : data to analyze are the time-series of the
+ deviations to average (for instance: load time-series
+ need to be analyzed in “detrended” mode while wind
+ speeds can be analyzed in “raw” mode)*
+
+ - *File to analyze *
+
+ - *Name of the file that should contain historical
+ time-series to analyze*
+
+ - *Status*
+
+ - *Ready (a file bearing the expected name was found)*
+
+ - *Not found (no file found with the expected name) *
+
+***IMPORTANT** To generate stochastic data similar to the historical
+data analyzed, generation parameters must be kept consistent with the
+results of the analysis, which means, in the generators: *
+
+*Keep the same:*
+
+> *Type of distribution*
+>
+> *Values for α,β,γ,δ and for the diurnal–seasonal pattern (table of 12
+> X 24 values)*
+
+*Value for the “capacity” parameter (the analyzer automatically sets it
+to 1)*
+
+*Besides: “Conversion” option must be set to “no”*
+
+*“Translation” option must be set to “do not use “if data were analyzed
+as “raw”*
+
+> *and to “add after scaling” or “add before scaling” if data were
+> analyzed as “detrended” (both options give the same value in this case
+> because the scaling is 1:1)*
+
+2. ***Tab “Global settings”***
+
+ - *Temporary folder : workspace that can be used for the analysis
+ (cleaned after use)*
+
+ - *Analyzer settings *
+
+ - *Short- term autocorrelation adjustment (%)*
+
+ - *Long – term autocorrelation adjustment (%)*
+
+> *These two parameters are used by Antares as targets for the fitting
+> of θ and μ parameters. For instance, if the historical time-series
+> autocorrelation function is such that Corr(T,T+ 18 hours)=90 % and
+> Corr(T,T+60 hours)= 50%, and if the parameters in the analyzer are (ST
+> = 90%,LT = 50%) , then it will search values of θ and μ matching the
+> historical autocorr.function in two points(18 hours, 60 hours)*
+
+- *Trimming threshold (%)*
+
+> *In the spatial correlation matrices, terms lower than the threshold
+> will be replaced by zeroes *
+
+- *Input data *
+
+ - *Time-series per area (n) *
+
+> *limits the analysis to the first n historical time-series at hand*
+
+- *Upper-bound (Max) *
+
+> *In the analysis, all values above Max in the historical files will be
+> replaced by Max *
+
+- *Lower-bound (Min) *
+
+> *In the analysis, all values below Min in the historical files will be
+> replaced by Min *
+
+***IMPORTANT** For each month, time-series to analyze are assumed to
+represent a stationary stochastic signal modulated by 24 hourly
+shape-factors. All of these shape-factors are expected to be different
+from zero. If the signal is partly masked by sequences of zeroes (for
+instance, if solar power time-series are to be analyzed as such because
+time-series of nebulosity are not available), the analysis is possible
+but is subject to the following restrictions:*
+
+- ***Use of the “detrended” mode in the first Tab is mandatory** (use
+ of the “raw” mode would produce wrong correlation matrices)*
+
+- ***Short- and Long- Term autocorrelation parameters in the second
+ Tab must be identical and set to 99%** (to ensure that
+ auto-correlation be assessed for the shortest possible time lag,
+ i.e. one hour) *
+
+***NOTICE** For the whole year, the analyzer delivers a table of 12x24
+hourly shape-factors consistent with the 12 sets of parameters
+identified for the stationary stochastic processes. The content of the
+table depends on the mode of analysis chosen: *
+
+***“raw”** analysis: for each month, the sum of the 24 hourly
+shape-factors is equal to 24 (i.e. each term is a modulation around the
+daily average).*
+
+***“detrended”** analysis: for the whole year, hourly coefficients are
+expressed relatively to the annual hourly peak of the (zero-mean) signal
+absolute value. (i.e. all factors belong to the \[0,1\] interval)*
+
+## Time-series generation (thermal)
+
+*The stochastic generator for time-series of available dispatchable
+power generation works, for*
+
+*each plant of each set (cluster), with the following parameters : *
+
+- *The nominal plant capacity and a 8760-hour array of modulation
+ coefficients to apply to it (default value : 1)*
+
+- *A 365-day array of forced outages rates (“FOR” , lies in \[0,1\] )*
+
+- *A 365-day array of planned outages rates (“POR” , lies in \[0,1\])
+ *
+
+- *A 365-day array of forced outages average durations (“FOD” in days,
+ integer, lies in \[1,365\])*
+
+- *A 365-day array of planned outages average durations (“POD” in
+ days, integer,lies in \[1,365\] )*
+
+- *A 365-day array of planned outages minimum number (PO Min Nb)*
+
+> *(integer, lies in \[0, PO Max Nb\])*
+
+- *A 365-day array of planned outages maximum number (PO Max Nb)*
+
+> *(integer, lies in \[PO Min Nb, Nb of units in the cluster\]*
+
+- *Two parameters describing how forced outages durations may randomly
+ deviate from their average value (law : uniform or geometric ,
+ volatility : lie in \[0,1\])*
+
+- *Two parameters describing how planned outages durations may
+ randomly deviate from their average value (law : uniform or
+ geometric , volatility : lie in \[0,1\])*
+
+
+
+1. ***Outage duration : meaning and modeling ***
+
+> *In the thermal time-series generator, the concept of outage duration
+> (either forced or planned) is simple enough: for any given plant
+> affected by such an event, it is the duration of a single outage,
+> expressed in days.*
+>
+> *The fact that 365 different values can be used to describe what may
+> happen in the course of a year (for each kind of outages) means that
+> the average outage duration may depend on the day the outage begins
+> on. For instance, very short outages may be sometimes be planned on
+> week-ends. Likewise, historical statistics can show that forced
+> outages do not last the same average time in winter and summer, etc.*
+>
+> *In complement to the average value of the duration D of outages
+> beginning on a particular day, the time-series generator allows to set
+> two parameters that describe how the actual outage durations may
+> deviate from the calendar-related average value. *
+
+- *The first parameter (law) can take either the value “uniform” or
+ “geometric” :*
+
+> *Uniform: the actual outage duration will be randomly drawn (one draw
+> per outage), according to a **uniform distribution** centred on the
+> average value **D**. The width of the interval \[min duration, max
+> duration\] will depend on the value of the second parameter
+> (volatility)*
+>
+> *Geometric : the actual outage duration will be expressed as the sum
+> of a fixed value F and a randomly drawn (one draw per outage) variable
+> following a **geometric distribution** of expectation G, with
+> **F+G=D**. The ratio of F to G will depend on the value of the second
+> parameter (volatility).*
+
+- *The second parameter (volatility) can take any value within \[0,1\]
+ *
+
+> *0: The outage duration does not show any stochastic fluctuation at
+> all. *
+>
+> *Therefore, regardless of the chosen distribution law: *
+>
+> ***actual duration = D ***
+>
+> *1: The variability of the actual outage duration is as high as the
+> chosen distribution law makes it possible, which means respectively
+> that:*
+>
+> *If choice = “uniform”: **1 \<= actual duration \<= 2D-1***
+>
+> *If choice = “geometric” **: F=0 and G = D** *
+>
+> *(which in turn implies 1\<=actual duration \<= \#4D ) *
+>
+> *0\ the ratio **σ / D** of its standard deviation to its expectation has a
+> value that depends on **V** , on **D** and on the chosen distribution
+> law. More precisely:*
+>
+> *If choice = “uniform”: **σ / D = \[1/3^0.5\] \* V \* (D-1) / D***
+>
+> *and*
+>
+> ***Duration min = D (1-V) + V***
+>
+> ***Duration max = D (1+V) - V***
+>
+> *If choice = “geometric”: **σ / D = V \* \[ (D-1) / D \]^0.5***
+>
+> *and*
+>
+> ***Duration min = F ***
+>
+> ***Duration max \# 4D-3F***
+>
+> *with F = D – G*
+>
+> *G = 2z /\[ (1+4z)^0.5 - 1\]*
+>
+> *z = (V^2) \* D \* (D-1) *
+>
+> ***NOTE:** The calculation time required for the generation of
+> time-series does not depend of the kind of chosen law but depends on
+> the fact that the volatility is null or not (it is minimal for
+> zero-volatility).*
+>
+> ***NOTE:** A geometric law associated with a volatility parameter V
+> yielding a characteristic parameter F (according to the previous
+> formulas) will produce a distribution summarized by: *
+
+- *63 % of values in the interval \[ F , D\]*
+
+- *23 % of values in the interval \[ D , 2D-F\]*
+
+- *12 % of values in the interval \[2D-F , 4D-3F\]*
+
+- *2 % of values in the interval \[4D-3F , infinite )*
+
+> ***Remark:** Antares is able to provide these options because it
+> involves more than a simple Markov chain mechanism (intrinsically
+> limited to : law = geometric, volatility = 1) *
+
+2. ***Outage rates : meaning and modeling***
+
+> *The concept of outage rate is not always clearly distinguished from
+> the notion of failure rate, to which it is closely related.*
+>
+> *Outage rates OR represent the average **proportion** of time during
+> which a plant is unavailable (for instance, OR = 5.2%). *
+>
+> *Failure rates FR represent the average **number** of outages
+> **starting** during a period of time of a given length (for instance,
+> FR = 1.5 per year). If the time step is short enough (typically one
+> day, which is the value used in Antares), the failure rates are always
+> lower than 1 (for instance, FR = (1.5 / 365) per day). *
+>
+> *When this condition is met and if the physical outage process can be
+> modelled by a Poisson process, failure rates can be interpreted as
+> probabilities. *
+>
+> *In Antares the following relation between failure rates FR, outage
+> rates OR and outage durations OD is used: *
+>
+> ***FR = OR / \[OR+ OD \* ( 1 – OR )\]***
+>
+> *To determine whether a plant available on day D is still available on
+> day D+1, the Antares stochastic generator therefore makes draws based
+> on the failure rates equivalent to the data provided in the form of
+> outage rates and outage durations. *
+>
+> *Since two processes may be described in the GUI, consecutive draws
+> are made for each process so as to determine whether:*
+
+- *An outage of the first category begins (it will last for the
+ specified duration)*
+
+- *An outage of the second category begins (it will last for the
+ specified duration)*
+
+- *No outage occurs, the plant is still available on D+1*
+
+> *Whether to describe the “planned outage” process as a random process
+> or not depends of the kind of data at hand, which is often related to
+> the horizon of the studies to carry out: when actual overhauls plans
+> are known, the PO rates can be set at 1 when the plant is deemed to be
+> unavailable and to zero on the other days. *
+>
+> *For long term studies in which only general patterns are known,
+> season-, month- or week- modulated rates and duration may be used to
+> describe the “planned” process as a stochastic one. Another possible
+> use of the model is to incorporate the overhauls plans in the “nominal
+> capacity modulation” array, and consider the stochastic “planned
+> outage” processor as a simulator for a second modality of forced
+> outage (longer or shorter than the main component)*
+>
+> ***NOTE:** Once the outage duration and outage rate are defined, the
+> failure rate is completely determined. For the sake of clarity, the
+> Antares GUI displays still another parameter often used in reliability
+> analysis, which is the MTBF (Mean Time Between Failure). Relations
+> between MTBF, FR and OR are:*
+>
+> ***FR= 1 / ( MTBF+1 ) OR = OD / ( MTBF+OD )***
+>
+> ***NOTE:** When two stochastic processes of outages (forced and
+> planned, or forced-type-1 and forced-type-2) are used, the overall
+> resulting outage rate OOR is not equal to the sum of the two rates FOR
+> and POR. Instead, the following relation holds:*
+>
+> ***OOR = ( FOR + POR – 2\*FOR\*POR ) / (1 - FOR\*POR)***
+>
+> *The explanation of this formula lies in the definition of the
+> different outages rates:*
+>
+> *Over a long period of operation, FOR represents the ratio of the time
+> spent in forced outages to the overall time not spent in planned
+> outages. *
+>
+> *Likewise, POR represents the ratio of the time spent in planned
+> outages to the overall time not spent in forced outages. *
+>
+> *OOR represents the ratio of the time spent in either forced or
+> planned outages to the overall operation period.*
+>
+> *The period of operation can be broken down into three categories of
+> hours : *
+>
+> *F hours spent in forced outages*
+>
+> *P hours spent in planned outages*
+>
+> *A hours of availability*
+>
+> *The following relations hold and explain the previous formula:*
+>
+> *FOR = F/(A+F)*
+>
+> *POR=P/(A+P)*
+>
+> *OOR=(F+P)/(A+F+P)*
+
+3. ***Planned Outages Minimum and Maximum Numbers***
+
+> *In the description given so far regarding how outages are modeled, no
+> true difference was made between “forced” and “planned” outages, i.e.
+> both relied on unconstrained random draws. This is satisfactory only
+> if the process to model through the “planned” data is actually little
+> constrained, or not at all. *
+>
+> *In all other occurences, it makes sense to define a general framework
+> for the maintenance schedule. In Antares this is defined at the
+> cluster scale by two specific 365-day arrays :*
+>
+> *PO Min Nb and PO Max Nb. *
+>
+> *These parameters are used by the time-series generator as constraints
+> that **cannot be** **violated**, regardless of the raw outcome of
+> regular random draws. To meet these constraints, the generator may
+> have to anticipate or delay “planned” outages yielded by the primary
+> random draws stage. If data regarding planned outage rates and planned
+> outage Max and Min numbers are not consistent, the Max and Min Numbers
+> take precedence.*
+>
+> *Exemples (for simplicity’sake, they are described here with only one
+> value instead of 365) :*
+>
+> *Cluster size = 100 PO rate =10% PO Min Nb=0 PO Max Nb= 100 *
+
+- *Actual number in \[0,100\], average = 10, wide fluctuations
+ (unconstrained) *
+
+> *Cluster size = 100 PO rate =10% PO Min Nb=7 PO Max Nb= 11 *
+
+- *Actual number in \[7,11\], average = 10 (to remain within the
+ bounds, some outages will be anticipated, while others will be
+ delayed)*
+
+> *Cluster size = 100 PO rate =0% PO Min Nb=10 PO Max Nb= 10 *
+
+- *Actual number =10 (to remain within the bounds, outages are set up
+ even if none come from random draws)*
+
+##
+
+##
+Time-series analysis (thermal)
+
+> *The stochastic generator for time-series of available dispatchable
+> power generation needs to be given assumptions regarding forced &
+> planned outages rates & durations. Depending on the quality and
+> quantity of statistics at hand, these estimates can be either
+> described as “flat” (same constant values used from the beginning to
+> the end of the year) or as more or less modulated signals, with the
+> possibility of choosing different values for each day of the year. *
+>
+> *Different ways can be considered to work out values for
+> FOR,POR,FOD,POD from historical data regarding outages. For any
+> (family of) plant(s) to study, notations have to be defined with
+> respect to the “calendar accuracy” chosen by the user. For the sake of
+> clarity, assume from now on that the user wants to assess weekly rates
+> and durations, that is to say: describe the whole year with 52 values
+> for rates and durations, for both forced and planned outages (within
+> any given week, identical values will therefore be assigned to the
+> seven days of the week). *
+>
+> *With the following notations: *
+>
+> *D(w) = Overall cumulated statistical observation time available for
+> week (w)*
+>
+> *for instance, for w = 1= first week of January : D(w) = 3500 days
+> coming from 10 years of observation of 50 identical plants*
+>
+> *Df(w) = Within D(w), overall time spent in forced outages, either
+> beginning*
+>
+> *during week w or before (for instance , Df(1) = 163 days) *
+
+*Dp(w) = Within D(w), overall time spent in planned outages, either
+beginning *
+
+*during week w or before (for instance, Dp(1) = 22 days)*
+
+*Kf(w) = Number of forced outages beginning during week (w)*
+
+> *(for instance, Kf(1) = 26) *
+>
+> *Kp(w) = Number of planned outages beginning during week (w)*
+>
+> *(for instance, Kp(1) = 3) *
+>
+> *FOT(w) = Overall cumulated time (expressed in days) spent in forced
+> outages beginning during week (w) (for instance, FOT(1)= 260) *
+>
+> *Note that if outages last more than one week FOT(w) necessarily
+> includes days from weeks w+1, w+2,…*
+>
+> *POT(w) = Overall cumulated time (expressed in days) spent in planned
+> outages beginning during week (w) (for instance, POT(1) = 84) *
+>
+> *Note that if outages last more than one week POT(w) necessarily
+> includes days from weeks w+1, w+2,…*
+>
+> *The following formulas can be used :*
+>
+> ***FOD (w) = FOT(w) / Kf(w)***
+>
+> ***POD (w) = POT(w) / Kp(w)***
+>
+> ***FOR(w) = FOD(w) / \[ FOD(w) + ( (D(w) - Dp(w)) / Kf(w)) \]***
+>
+> ***POR(w) = POD(w) /\[ POD(w) + ( (D(w) - Df(w))) / Kp(w)) \]***
+>
+> *For the examples given above, the estimated parameters would
+> therefore be : *
+>
+> *FOD(1) = 10 (days)*
+>
+> *POD(1) = 28 (days)*
+>
+> *FOR(1) = 0.0695 \# 7 %*
+>
+> *POR(1) = 0.0245 \# 2.5 % *
+>
+> *These values should eventually (using the GUI or other means) be
+> assigned to the first seven days of January. *
+>
+> *
+> *
+
+## Time-series generation and analysis (hydro)
+
+> *The stochastic hydro generator assesses monthly time-series of
+> energies, based on the assumption that they can be modeled by Log
+> Normal variables. The values generated are interpreted as monthly
+> amounts of hydro energies generated (sum of Run of River – ROR – and
+> hydro storage – HS) or as amounts of hydro inflows, depending on the
+> modeling chosen for the area (straightforward estimate of energies
+> generated or explicit management of reservoirs).*
+>
+> *The historical data to work from depend on the kind of modeling
+> chosen (statistics of monthly generation in the first case, or
+> statistics of monthly inflows in the second case). *
+>
+> *In both cases, assuming that a large number of historical time-series
+> of energies are available, the rationale of the assessment of
+> parameters is the following (from now on, “energies” mean either “ROR
+> and HS energies generated” or “inflows to ROR and HS”), *
+
+1) *For each area n, build up annual energy time-series **A(n)** by
+ aggregation of the original monthly energy time-series **M(n)**. For
+ each pair of areas (n,m) , assess the correlation **R(n,m)** between
+ the random variables **Log(A(n))** and **Log(A(m))**. Expressed in
+ percentage, matrix **R** should be used to fill out the “spatial
+ correlation tab” of in the active window “hydro” *
+
+2) *For each area n, build up two monthly time-series derived from the
+ original array **M(n)**, by proceeding as follows. Assuming that
+ **M(n)** has K elements (for instance, K= 180 if 15 years of
+ statistics are available): *
+
+ - ***M’(n)** = time-series of K-1 elements obtained by deleting
+ the first element of the time-series Log(M(n))*
+
+ - ***M’’(n)** = time-series of K-1 elements obtained by deleting
+ the last element of the time-series Log(M(n)) *
+
+> *Assess the correlation **IMC(n)** between the random variables
+> **M’(n)** and **M’’(n)**. This value (lying in \[-1,1\]) should be
+> used to fill out the field “inter-monthly correlation value” of the
+> “local data” tab in the “hydro” active window*
+
+3) *For each area n, build up 12 monthly energy time-series derived
+ from the original array **M(n)** by extracting from **M(n)** the
+ values related to each month of the year ( **M1(n)** = time-series
+ of energies in January,…, **M12(n)** = time-series of energies in
+ December.) *
+
+> *Assess the expectations and standard deviations of the 12 random
+> variables **M1(n)**,…,**M12(n)**. These values should be used to fill
+> out the fields “expectation” and “std deviation” of the “local data”
+> tab in the “hydro” active window.*
+>
+> *Aside from expectation and standard deviations, minimum and maximum
+> bounds can be freely set on the monthly overall energies (ROR + HS).
+> Whether to assess these bounds by examination of historical data or on
+> the basis of other considerations depends on the context of the
+> studies to carry out*
+
+4) *For each area n, extract from the 12 monthly overall energy
+ time-series **M1(n)**,…,**M12(n)** the contribution of the 12
+ monthly time-series of ROR energies **R1(n),…, R12(n)**.*
+
+> *Assess the expectations of the 12 random variables **R1(n)/M1(n),….,
+> R12(n)/M12(n)**. These values should be used to fill out the fields
+> “ROR share” of the “local data” tab in the “hydro” active window.*
+
+# 7 Kirchhoff’s Constraints Generator
+
+*Binding Constraints introduced in Section 4 can take many forms
+(hourly, daily, weekly), involve flows or thermal generated power, etc.
+Sets of binding constraints of special interest are those which can be
+used to model and enforce Kirchhoff’s second law on the AC flows. *
+
+*In other words, it is possible to make Antares work as a genuine DC
+OPF, provided that consistent binding constraints are written down for
+each cycle belonging to any cycle basis of the graph made out from all
+AC components of the power system (V vertices, E edges).*
+
+*The declaration of binding constraints can be made manually through the
+regular GUI. However, it is preferable not to carry out this task that
+way because there are many different possible formulations, among which
+some are better than others:*
+
+- *In a fully connected graph (V, E), there are as many binding
+ constraints to write down as there are cycles in any cycle basis of
+ the graph, which amounts to (E+1-V). The number of different
+ possible basis is equal to that of spanning trees, which can be
+ assessed by the Kirchhoff’s theorem*\[15\]
+
+- *Among all cycle basis, some should be preferred to others because
+ they lead to a sparser constraint matrix. *
+
+*To get around this issue, the KCG is an autonomous Antares module (much
+like the time-series analyzer) which automatically instantiates a set of
+adequate binding constraints that will enforce Kirchhoff’s law on the AC
+subgraph of the power system. The graph cycle basis associated with the
+generated constraints is optimal, in that sense that it leads to a
+constraint matrix as sparse as possible. *
+
+*To achieve that, the KCG implements an efficient algorithm yielding a
+minimal cycle basis*\[16\] *and, for all cycles of the chosen basis,
+generates constraints of the form:*
+
+\[c = 1,\ldots,\ C\ :\ \sum_{l \in c}^{}{\text{sign}\left( l,c \right)F_{l}Z_{l} = 0\ }\]
+
+*Where* \(Z_{l}\) *are the impedances (parameters)
+and*\(\text{\ \ }F_{l}\) *are the flows (variables). *
+
+*
+*
+
+*Beyond this basic purpose, the KCG is meant to provide additional
+modeling capacities, so as to allow the representation of two important
+phenomena:*
+
+- *As a rule, the power system graph represented in Antares in not
+ fully detailed, it is usually more a “backbone” approximation, in
+ which “vertices” are not equivalent to individual bus-bars. More
+ likely, vertices of the graph stand for whole regions, or even
+ countries: as a consequence, it is highly possible that when all
+ Areas/Vertices have a zero-balance (neither import, nor export),
+ there are real physical flows between them, so-called “loop flows”.
+ If assessments of the level of these loop flows* \(\varphi_{l}\)
+ *are available (and filled out as link input data), the KCG may
+ include them (on user’s request) in the binding constraints
+ formulation, which becomes:*
+
+\[c = 1,\ldots,\ C\ :\ \sum_{l \in c}^{}{\text{sign}\left( l,c \right)F_{l}Z_{l} = \sum_{l \in c}^{}{\text{sign}\left( l,c \right)\varphi_{l}Z_{l}\ }\ }\]
+
+- *To mitigate the effects of actual loop flows, or more generally to
+ allow the transmission assets to give the maximum of their
+ potential, the power system may include components such as
+ phase-shifting transformers, whose function can be modeled by
+ changing the formulation of the binding constraints. Provided that
+ estimates of the shifting capacities (* \(Y_{l}^{-},\ Y_{l}^{+}\)*)
+ of the installed PST are known and filled out in the link data
+ section, the KCG will (on user’s request) automatically reformulate
+ the binding constraints as:*
+
+\[c = 1,\ldots,\ C\ :\ \boxed{Y_{c}^{-}} + \ \sum_{l \in c}^{}{\text{sign}\left( l,c \right)\left( \varphi_{l}Z_{l}\ \right)\ \leq}\sum_{l \in c}^{}{\text{sign}\left( l,c \right)F_{l}Z_{l} \leq \ \boxed{Y_{c}^{+}} + \sum_{l \in c}^{}{\text{sign}\left( l,c \right)\left( \varphi_{l}Z_{l}\ \right)\ }\ }\]
+
+\[\ with\ \ :\]
+
+\[\ \boxed{Y_{c}^{-}} = \ \sum_{l \in c}^{}{\text{Min}{(sign\left( l,c \right)Y_{l}^{-}\ ,\ sign\left( l,c \right)Y_{l}^{+}\ \ )}\ }\]
+
+\[\boxed{Y_{c}^{+}} = \ \sum_{l \in c}^{}{\text{Max}{(sign\left( l,c \right)Y_{l}^{-}\ ,\ sign\left( l,c \right)Y_{l}^{+}\ \ )}\ }\]
+
+*Besides, the KCG takes into account the fact that the “best estimates”
+of all critical data (loop flows, phase-shifting ratings, or even
+impedances) may vary in time: In such cases, the KCG formulates as many
+different binding constraints as necessary to model this operating
+context diversity, and relax them when appropriate (by setting the right
+hand sides of the equation to +/- infinite)*
+
+*From a practical standpoint, assessments of* \(Y^{+},\ Y^{+}\) *should
+be derived from knowledge about the actual components installed on the
+grid, while*\(\ Z_{l}\) *and* \(\varphi_{l}\) *can be estimated by
+various methods. *
+
+*In addition to the previous functionalities, the KCG’s GUI also
+includes the following options: *
+
+- *Choice a specific period of time for which the constraints should
+ be applied, while completely relaxed at other moments*
+
+- *Before actual generation of binding constraints, preview of the
+ “minimal length” spanning tree used as starting point for the
+ optimal basis algorithm (left column of the table – links displayed
+ with “0” do not belong to the tree)*
+
+- *Before actual generation of binding constraints, preview of the
+ “optimal cycle basis” used as starting point for constraints
+ generation (right column of the table – links displayed with “n”
+ appear in n different cycles of the basis)*
+
+*
+*
+
+# 8 Miscellaneous
+
+## Antares at one glance
+
+*This section gives a summary of the whole simulation process followed
+by Antares in Economy simulations (Adequacy and Draft simulations being
+simplified variants of it) *
+
+1) *Load or Generate \[stochastic generators\] Time-series of every
+ kind for all system areas*
+
+2) *For each Monte-Carlo year , pick up at random or not \[scenario
+ builder\] one time-series of each kind for each area*
+
+3) *For each area and each reservoir : *
+
+ 1. *Split up the annual overall hydro storage inflows into monthly
+ hydro storage generation, taking into account reservoir
+ constraints, hydro management policy and operation conditions
+ (demand, must-run generation, etc.) \[heuristic + optimizer \] *
+
+ 2. *For every day of each month, break down the monthly hydro
+ energy into daily blocks, taking into account hydro management
+ policy and operation conditions (demand, must-run generation,
+ etc.) \[heuristic + optimizer \]. Aggregate daily blocks back
+ into weekly hydro storage energy credits (used if the final
+ optimization is run with full weekly 168-hour span) *
+
+ 3. *For each week of the year (daily/weekly hydro energy credits
+ are now known in every area), run a three-stage 168-hour
+ optimization cycle (or seven 24-hour optimizations, if the
+ optimization preference is set to “daily”). This aim of this
+ cycle is to minimize the sum of all costs throughout the
+ optimization period. This sum may include regular proportional
+ fuel costs, start-up and no-load heat costs, unsupplied and
+ spilled energy costs, and hurdle costs on interconnection. The
+ solution has to respect minimum and maximum limits on the power
+ output of each plant, minimum up and down durations, as well as
+ interconnection capacity limits and “binding constraints” at
+ large (which may be technical – e.g. DC flow rules – or
+ commercial – e.g. contracts). Note that an accurate resolution
+ of this problem requires mixed integer linear programming
+ (because of dynamic constraints on thermal units). A simplified
+ implementation of this approach is used when the advanced
+ parameter “Unit commitment” is set on “accurate”. This high
+ quality option may imply long calculation times. This is why,
+ when “Unit commitment” is set on “fast”, Antares makes further
+ simplifications that save a lot of time (starting costs are not
+ taken into account within the optimization step but are simply
+ added afterwards, units within a thermal cluster are subject to
+ starting up/shutting down constraints more stringent than the
+ minimum up/down durations). In both cases, the general
+ optimization sequence is as follows: *
+
+ 1. *Minimization of the overall system cost throughout the week
+ in a continuous relaxed linear optimization. Prior to the
+ optimization, an 8760-hourly vector of operating reserve R3
+ (see next section) may be added to the load vector (this
+ will lead in step (ii) to identify plants that would not be
+ called if there were no reserve requirements. Their actual
+ output will be that found in step (iii), wherein the load
+ used in the computations takes back its original value)*
+
+ 2. *So as to accommodate the schedule resulting from (i),
+ search for integer values of the on/off variables that
+ satisfy the dynamic constraints with the smallest possible
+ cost increase. *
+
+ 3. *Take into account the integer variables found in (ii) and
+ solve again the optimal schedule problem for the week.
+ *
+
+## Operating reserves modeling
+
+*Many definitions may be encountered regarding the different operating
+reserves (spinning / non spinning, fast / delayed,
+primary-secondary-tertiary, frequency containment reserve - frequency
+restoration reserve – replacement reserve, etc.). *
+
+*Besides, all of them need not be modeled with the same level of
+accuracy in a simulator such as Antares. Furthermore, the best way to
+use the concept is not always quite the same in pure Adequacy studies
+and in Economy studies. *
+
+*Several classes of reserves may therefore be used in Antares; how to
+use them at best depend on the kind and quality of operational data at
+hand, and on the aim of the studies to carry out; though all kinds of
+reserves may always be defined in the INPUT dataset, the set of reserves
+that will effectively be used depends on the kind of simulations to run.
+Note that any or all classes of reserves may be ignored in a given
+simulation (without being removed from the INPUT dataset) by setting the
+matching “optimization preference” to “ignore reserve X”:*
+
+- ***Pre-allocated reserve on dispatchable thermal plants (R0)***
+
+> *This reserve (which corresponds to the parameter “spinning” attached
+> to the thermal plants) is expressed as a percentage of the nominal
+> capacity of the plants. It is simply used as a derating parameter: for
+> instance, a 1000 MW plant with a 2.5% spinning parameter will not be
+> able to generate more than 975 MW. It is important to notice that, if
+> the plant is not scheduled on, it will NOT contribute to the spinning
+> reserve (to be effectively available, the 25 MW of reserve would need
+> the plant to be started). This first class of reserve is available for
+> **Adequacy** as well as for **Economy** simulations but is not taken
+> into account in **Draft** simulations. *
+
+- ***Primary and strategic reserves (R1,R2):***
+
+> *These two reserves may be used in **Draft** simulations, with the
+> following meaning:*
+
+- *Primary reserve must be supplied by local generation and has a
+ higher priority than load: for instance, if overall load L=43.6 GW,
+ overall generation G=44.0 GW, primary reserve = 0.7 GW, then an
+ adequacy analysis will show 300 MW of unsupplied energy. The primary
+ reserve is in essence a frequency containment reserve. *
+
+- *The strategic reserve is an amount of power that should remain
+ available for balancing domestic load, i.e. cannot be exported
+ regardless of the load/generation balance of the neighboring areas.
+ For instance, if loads in area A and B are LA= 45 GW and LB= 50 GW,
+ if available generations are GA= 49 GW and GB = 47 GW, and if there
+ is a 1.5 GW strategic reserve to be kept in A, then an adequacy
+ analysis will show 500 MW of unsupplied energy in B. The strategic
+ reserve may include amounts of power known to be unavailable for
+ actual exports (for instance, because of grid limitations not
+ thoroughly modeled in the Antares study dataset). *
+
+*
+*
+
+ - ***Day-ahead reserve (R3):***
+
+> *This reserve is available in **Adequacy** and **Economy**
+> simulations, with the following meaning:*
+>
+> *“For any day D, so as to be able to accommodate last-minute random
+> variations of the expected demand and/or generation (as they were seen
+> from day D -1), a certain amount of power (R3) should be ready to be
+> available at short notice” *
+>
+> *In actual operating terms, R3 is a complex (spinning/non spinning)
+> mix as well as (hydro/thermal) mix. It may involve or not part of the
+> primary and secondary power/frequency regulation reserves. R3 may
+> represent as much as the overall amount of frequency containment
+> reserve, frequency restoration reserve and replacement reserve
+> required for operation on day D, as seen from day D-1. *
+>
+> *In the simulations, R3 is construed as a “virtual” increase of the
+> load to serve, which influences the optimal unit commitment and
+> dispatch (because of minimum stable power levels and minimum On / Down
+> times). *
+>
+> *IMPORTANT: *
+>
+> *The optimization makes sure that, should the need arise, reserve R3
+> will actually be available where it is needed **BUT** there is no
+> commitment regarding whether this service should be provided by an
+> increase of local generation, a decrease of exports or even an
+> increase of imports: the optimizer will choose the mix leading to the
+> minimal cost for the system. *
+>
+> *Note that this “standard” feature of Antares makes it possible to
+> assess the potential value of keeping some headroom in
+> interconnections for the purpose of transferring operating reserves,
+> when “remote” reserves are less expensive than domestic ones. *
+>
+> *The table below gives an overview of the different reserves available
+> in Antares *
+
+| | *Economy* | *Adequacy* | *Draft* |
+| ---- | --------- | ---------- | ------- |
+| *R0* | *Yes* | *Yes* | *No* |
+| *R1* | *No* | *No* | *Yes* |
+| *R2* | *No* | *No* | *Yes* |
+| *R3* | *Yes* | *Yes* | *No* |
+
+**
+**
+
+## The heuristic for seasonal hydro pre-allocation
+
+*This heuristic, first introduced in broad terms in Section 4, chapter
+“hydro”, is fully detailed in this paragraph. *
+
+*Basically, the seasonal hydro pre-allocation process comprises two
+stages carried out two times (first time: monthly scale; second time:
+daily scale).*
+
+- *Stage 1: Definition of an **a**llocation **i**deal **m**odulation
+ profile, which may be based (or not) on local and/or remote load
+ profiles*
+
+- *Stage 2: Mitigation of the previous raw profile to obtain a
+ feasible **h**ydro **i**deal **t**arget , compatible as much as
+ possible with reservoir rule curves*
+
+*The description given hereafter makes use of the following local
+notations, not be confused with those of the document “optimization
+problem formulation” (dedicated to the optimal hydro-thermal
+unit-commitment and dispatch problem): *
+
+\(Z\) *Number of Areas (zones* \(z\) *) in the system *
+
+\(M_{\text{zh}}\text{\ \ }\) *Hourly time-series of cumulated
+must-generation of all kinds for zone*\(\text{\ z}\)
+
+\(M_{\text{zd}}\text{\ \ }\) *Daily time-series of cumulated
+must-generation of all kinds for zone*\(\text{\ z}\) *(sum of*
+\(M_{\text{zh}}\text{\ \ }\)*)*
+
+\(M_{\text{zm}}\text{\ \ }\) *Monthly time-series of cumulated
+must-generation of all kinds for zone*\(\text{\ z}\) *(sum of*
+\(M_{\text{zd}}\text{\ \ }\)*)*
+
+\(M_{\text{z.}}\text{\ \ }\) *Either* \(M_{\text{zd}}\text{\ \ }\) *or*
+\(M_{\text{zm}}\) *, relevant time index “.” is defined by the context*
+
+\(L_{\text{z.}}\text{\ \ }\) *Time-series of “natural” load for
+zone*\(\text{\ z}\)
+
+\(\text{A\ \ }\) *Inter-area hydro-allocation matrix (dimension*
+\(\times Z\) *)* \(A_{\text{uv}}\text{\ \ }\)*is a weight given to the
+load of area* \(u\) *in the definition of the monthly and daily primary
+hydro generation target of area* \(v\)
+
+*Extreme cases are: **A is the identity matrix ***
+
+> *The hydro storage energy monthly and weekly profiles of each zone z
+> depend only on the local demand and must-run generation in z *
+>
+> ***A has a main diagonal of zeroes ***
+>
+> *The hydro storage energy monthly and weekly profiles of each zone z
+> do not depend at all on the local demand and must-run generation in z
+> *
+
+\(L_{\text{z.}}^{*}\text{\ \ }\) *Time-series of “net” load for
+zone*\(\text{\ z}\) *, defined as:*
+\(L_{\text{z.}}^{*} = \ L_{\text{z.}} - \ M_{\text{z.}}\)
+
+\(L_{\text{z.}}\text{\ \ }\) *Time-series of “weighted” load for
+zone*\(\text{\ z}\) *, defined as:*
+\(L_{\text{z.}} = \ A^{t}\text{\ \ }\ L_{\text{z.}}^{*}\text{\ \ \ \ }\)
+
+*All following parameters are related to the
+generic zone* \(z\)
+
+*α “inter-monthly generation breakdown” parameter*
+
+*β “inter-daily generation breakdown” parameter*
+
+*ϕ “follow-load” parameter*
+
+*μ “reservoir-management” parameter*
+
+*Σ Reservoir size *
+
+\(\overline{S_{d}}\text{\ \ }\) *Reservoir maximum level at the end of
+day d, expressed as a fraction of Σ (rule curve)*
+
+\(\text{\ \ }\) *Reservoir minimum level at the end of day d, expressed
+as a fraction of Σ (rule curve)*
+
+\(S_{0}\text{\ \ }\) *Reservoir initial level at the beginning of the
+first day of the “hydro-year”*
+
+\(I_{d}\text{\ \ }\) *Natural inflow of energy to the reservoir during
+day d*
+
+\(I_{m}\text{\ \ }\) *Natural inflow of energy to the reservoir during
+month m (sum of* \(I_{d}\)*)*
+
+\({\overline{W}}_{d}\text{\ \ }\) *Maximum energy that can be generated
+on day d (standard credit)*
+
+*All following variables, defined for both
+stages, are related to the generic zone* \(z\)
+
+\(S_{d}^{k}\text{\ \ }\) *Reservoir level at the end of day d, at the
+end of stage k of pre-allocation *
+
+\(S_{m}^{k}\text{\ \ }\) *Reservoir level at the end of month m, at the
+end of stage k of pre-allocation *
+
+\(O_{d}^{k}\text{\ \ }\) *Overflow from the reservoir on day d, at the
+end of stage k of pre-allocation (inflow in excess to an already full
+reservoir)*
+
+\(W_{d}^{k}\text{\ \ }\) *Energy to generate on day d, at the end of
+stage k of pre-allocation*
+
+\(W_{m}^{k}\) *Energy to generate on month m, at the end of stage k of
+pre-allocation *
+
+*Following variables* \(\text{Var}\) *and parameters are local to linear
+optimization problems M & D(m) solved within the heuristic. For the sake
+of clarity, the same generic index* \(t\) *is used for all time steps,
+knowing that in M there are 12 monthly time-steps, while in D(m) there
+are from 28 to 31 daily time-steps. Costs* \(\gamma_{\text{Var}}\)
+*given to these variables are chosen so as to enforce a logical
+hierarchy of penalties (letting the reservoir overflow is worse than
+violating rule curves, which is worse than deviating from the generation
+objective assessed in stage 1, etc.)*
+
+\(Y\) *Generation deficit at the end of the period, as compared to the
+objective aimed at *
+
+\(O_{t}\) *Overflow from the reservoir on time step t *
+
+\(G_{t},{\overline{G}}_{t}\) *Optimal generation and maximum generation
+on time step t *
+
+\(T_{t}\) *Generation objective assessed in the first stage, for time
+step t (*\(W_{m}^{1}\) *or* \(W_{d}^{1})\)
+
+\(S_{t},\ {\overline{S}}_{t},{}_{t}\) *Optimal stock level, maximum
+level, minimum level at the end of time step t *
+
+\(I_{t}\) *Natural inflow on time step t *
+
+\(D_{t}\) *Deviation (absolute difference) between target reached and
+initial aim*
+
+\(\mathrm{\Delta}\) *Maximum deviation throughout the period*
+
+\(V_{t}^{+}\) *Amplitude of the violation of the upper rule curve at
+time step t *
+
+\(V_{t}^{-}\) *Amplitude of the violation of the lower rule curve at
+time step t *
+
+\(Y\) *Maximum violation of lower rule curve throughout the period *
+
+**General heuristic for each zone **
+
+\[\text{Begin}\]
+
+\[\text{if\ }\left( \text{not.\ m} \right)\ \{\ S \leftarrow \infty\ ;\ \ \ \ \ \leftarrow 0\ ;\overline{\text{\ \ }S_{d}}\ \leftarrow S\ ;\ S_{0}\ \ \leftarrow \ S/2\}\ \ \ \ \ \ \ \ \]
+
+\[M1:\ \]
+
+\(\text{if\ }\left( \text{j\ \ and\ μ} \right)\ \ :\ for\left( \mathbf{m}:1,12 \right):\{\ W_{\mathbf{m}}^{1} \leftarrow {L_{\mathbf{m}}}^{\alpha}.\ (\sum_{m}^{}{I_{m})}/(\sum_{m}^{}{L_{m}}^{\alpha})\}\ \)
+
+\[else\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ :\ for\left( \mathbf{m}:1,12 \right):\{\ W_{\mathbf{m}}^{1} \leftarrow I_{m}\}\]
+
+\[M2:\ \]
+
+\(\text{for}\left( \mathbf{m}:1,12 \right):\ \ W_{\mathbf{m}}^{2} \leftarrow \ Solution\ of\ linear\ problem\ \)
+*M*
+
+\[D1:\ \]
+
+\(\text{if}\left( \text{\ j} \right)\ \ \ :\ for\left( \mathbf{d}:1,31 \right):\ \ \ \{\ W_{\mathbf{d}}^{1} \leftarrow {L_{\mathbf{d}}}^{\beta}.\ \ (W_{\mathbf{m}}^{2})\ \ /(\sum_{d \in m}^{}{L_{d}}^{\beta})\ \}\)
+
+\(else\ \ \ \ \ :\ \ for\left( \mathbf{d}:1,31 \right):\ \ \ \ \{\ W_{\mathbf{d}}^{1} \leftarrow I_{d}\ \ \ .\ \ (W_{\mathbf{m}}^{2})\ \ /(\sum_{d \in m}^{}\text{\ I}_{d})\ \ \ \}\)
+
+\[D2:\ \]
+
+\(\text{for}\left( m:1,12 \right):\ W_{\mathbf{d \in m}}^{2} \leftarrow \ Solution\ of\ linear\ problem\ \)
+*D(m) *
+
+\[\text{End}\]
+
+*Note: In the formulation of the optimal hydro-thermal unit-commitment
+and dispatch problem (see dedicated document), the reference hydro
+energy* \(\text{HIT}\) *used to set the right hand sides of hydro-
+constraints depends on the value chosen for the optimization preference
+“simplex range” and is defined as follows:*
+
+- *Daily : for each day* \(\mathbf{d}\) *of week*
+ \(\mathbf{\text{ω\ }}\)*:* \(HIT = \ W_{\mathbf{d}}^{2}\)
+
+- *Weekly : for week* \(\mathbf{\omega}\)*:*
+ \(HIT = \ \sum_{\mathbf{d \in \omega}}^{}W_{\mathbf{d}}^{2}\)
+
+**Optimization problem *M***
+
+\[\min_{G_{t},\ S_{t,\ \ }\ldots.}{\left( \gamma_{\mathrm{\Delta}}\mathrm{\Delta} + \gamma_{Y}\ Y\ + \ \sum_{t}^{}{(\ {\gamma_{D}D}_{t}} + \gamma_{V +}\text{\ V}_{t}^{+} + \gamma_{V -}\ \text{\ V}_{t}^{-}) \right)\ }\]
+
+s.t
+
+\(S_{t} \geq 0\)
+
+\(S_{t} \leq S\ \)
+
+\[S_{t} + \ G_{t} - \ S_{t - 1} = \ I_{t}\ \ \ (see\ note\ )\]
+
+\(\text{\ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ }\sum_{t}^{}G_{t} = \ \sum_{t}^{}T_{t}\)
+
+\(\text{\ \ \ \ G}_{t} - D_{t}\ \leq \ \ T_{t}\)
+
+\(\text{\ \ \ \ G}_{t} + D_{t}\ \geq T_{t}\text{\ \ }\)
+
+\(\text{\ V}_{t}^{-} + \ S_{t}\ \geq \ {}_{t}\)
+
+\(\text{\ V}_{t}^{+} - \ S_{t} \geq - {\overline{S}}_{t}\)
+
+\(Y\ - \text{\ V}_{t}^{-} \geq \ 0\)
+
+**Optimization problems *D(m)***
+
+\(\min_{G_{t},\ S_{t,\ \ }\ldots.}{\left( \gamma_{\mathrm{\Delta}}\mathrm{\Delta} + \gamma_{Y}\ Y + \gamma_{Y}\ Y\ + \sum_{t}^{}{(\ {\gamma_{D}D}_{t}} + \gamma_{V -}\ \text{\ V}_{t}^{-} + \gamma_{O}\ O_{t} + \ \gamma_{S}S_{t}\ ) \right)\text{\ \ }}\)
+
+s.t
+
+\(S_{t} \geq 0\)
+
+\(\ S_{t} \leq S\ \)
+
+\(G_{t} \geq 0\ \)
+
+\(G_{t} \leq {\overline{G}}_{t}\)
+
+\[S_{t} + \ G_{t} + O_{t} - \ S_{t - 1} = \ I_{t}\ \ \ (see\ note\ )\]
+
+\(\sum_{t}^{}G_{t} + Y = \ \sum_{t}^{}T_{t} + \ Y\left( m - 1 \right)\ (value\ of\ \ Y\ previously\ found\ in\ solving\ \)*D(m-1)*
+\(\ )\ \)
+
+\(G_{t} - D_{t} \leq \ T_{t}\ \)
+
+\(G_{t} + D_{t} \geq \ \ T_{t}\)
+
+\(\mathrm{\Delta} - D_{t}\ \ \geq 0\)
+
+\(\text{\ V}_{t}^{-} + \ S_{t} \geq \ {}_{t}\)
+
+\(Y\ - \text{\ V}_{t}^{-} \geq \ 0\)
+
+##
+
+##
+Conventions regarding colors and names
+
+- *Names for areas, thermal plants, etc. *
+
+> *Name length should not exceed 256 characters. *
+>
+> *Characters must belong to:*
+>
+> *{ A-Z , a-z , 0-9 , - , \_ , ( , ) , & , comma , space }*
+
+- *Colors: *
+
+> *After being entered in the GUI, some numeric fields can see their
+> color change. The meaning of that is: *
+
+- *Turn to red: invalid value. Saving the study in this state is
+ possible, but the field will have to be corrected at some point in
+ the future. Should the simulator be launched on the dataset, it will
+ detect an error and stop.*
+
+- *Turn to orange: value is valid, though unusual (user may want to
+ double-check data).*
+
+
+
+- *Abbreviations :*
+
+> *Fields requiring to be filled out with “YES” or “NO” can
+> alternatively accept “Y” , “1” or “N” , ”0”*
+>
+> *Fields requiring to be filled out with “ON” or “ OFF” can
+> alternatively accept “true”, “1” or “false”, ”0”*
+>
+> *Fields requiring to be filled out with “annual” or “monthly” can
+> alternatively accept “a” or “m”*
+>
+> *Fields requiring to be filled out with:*
+>
+> *“Raw” ,“Detrended”,” Beta”, ”Normal”, ”Uniform”, “ Gamma”, “ Weibull”
+> can alternatively accept: “R”, “D”, “ B”, “N”, “U”, “G”, “W”*
+
+##
+Definition of regional districts
+
+> *Typical uses of the “district” feature are:*
+>
+> *1) On a large system, define an "all system" zone to get an overall
+> synthesis on all of the system nodes *
+>
+> *2) In a study involving different countries modeled by different
+> regions, define "country" macro-nodes to aggregate regional results to
+> the national level.*
+>
+> *3) In a study using some specific modeling such as PSP modeling with
+> fake nodes, define a local cluster involving all the relevant real and
+> fake nodes to simplify the edition of results. *
+>
+> *Hereafter is described the process to follow to bypass the GUI for
+> the definition of districts. *
+>
+> *It is based on the edition of a special "sets.ini" file. *
+>
+> *IMPORTANT : *
+
+- *Make sure that the sets.ini file is ready for use before opening
+ the Antares study. Attempts to update the sets.ini file while the
+ study is opened will not be effective *
+
+- *Definition of meaningless districts (references to nodes that do
+ not exist,…) will generate warnings in the GUI log files *
+
+> ***HOW TO UPDATE / CREATE the file** : Use Notepad (or equivalent)*
+>
+> ***WHERE TO FIND / STORE THE FILE** : INPUT/areas/sets.ini*
+>
+> *PRINCIPLE: *
+>
+> *The file is divided in consecutive sections, one for each district to
+> define.*
+>
+> *A section contents:*
+>
+> *a) A header line that gives its name to the district. The header
+> syntax is: \[district\_name\] *
+>
+> *To avoid confusion with the real area names, the results regarding
+> this macro-area will later be found in the OUTPUT files under a name
+> bearing the prefix "@", i.e. @district\_name *
+>
+> *b) A list of parametrized building rules to be processed in their
+> apparition order*
+>
+> *The different elementary rules are: *
+>
+> *+= area\_name : add the area "area\_name" to the district *
+>
+> *-= area\_name : remove the area "area\_name" from the district*
+>
+> *apply-filter = add-all : add all areas to the district*
+>
+> *apply-filter = remove-all : remove all areas (clear the district)*
+>
+> *c) A special "output" parameter that defines whether the results for
+> the district will actually be computed or not (this latter option
+> allows to inactivate parts of the sets.ini without altering the file)*
+>
+> *The syntax is: "output=false" or "output= true"*
+
+*
+*
+
+> ***EXAMPLES OF SETS.INI FILES***
+>
+> *a) File defining a single district named "set1" involving three areas
+> named "area1, area3, area42":*
+>
+> *\[set1\]*
+>
+> *+ = area1*
+>
+> *+ = area3*
+>
+> *+ = area42*
+>
+> *output = true*
+>
+> *b) File defining a district gathering all areas but five : *
+>
+> *\[most of the system\]*
+>
+> *apply-filter = add-all*
+>
+> *- = country 1*
+>
+> *- = neighbour 2*
+>
+> *- = fake antenna 12*
+>
+> *- = region 1*
+>
+> *- = region 32*
+>
+> *output = true*
+>
+> *c) File defining two districts, the current simulation will ignore
+> the second one :*
+>
+> *\[All countries\]*
+>
+> *apply-filter= add-all*
+>
+> *output=true*
+>
+> *\[All but one \]*
+>
+> *apply-filter = add-all*
+>
+> *-= special region 12*
+>
+> *output=false *
+
+- *
+*
+
+## The Annual System Cost Output file
+
+*In addition to the general files introduced in Section 5, the Output
+folder of each economic or adequacy simulation includes, at its root, a
+file “Annual\_System\_Cost.txt” It presents the metrics of a global
+Monte-Carlo variable further denoted ASC*
+
+*The value of ASC for any given simulated year is defined as the sum,
+over all areas and links, of the annual values of the area-variable
+“OV.COST” and of the link-variable “HURD. COST”.*
+
+*The metrics displayed in the “Annual system cost” file take the form of
+four values:*
+
+*Expectation EASC *
+
+*Standard deviation SASC*
+
+*Minimum LASC*
+
+*Maximum UASC*
+
+*As with all other random variables displayed in the Antares Output
+section, the computed standard deviation of the variable can be used to
+give a measure of the confidence interval attached to the estimate of
+the expectation. For a number of Monte-Carlo years N, the law of large
+numbers states for instance that there is a 95 % probability for the
+actual expectation of ASC to lie within the interval:*
+
+***EASC +/- 1.96 (SASC / sqrt(N))***
+
+*There is also a 99.8 % probability that it lies within the interval:*
+
+***EASC +/- 3 (SASC / sqrt(N))***
+
+##
+
+## The “export mps” optimization preference
+
+> *This preference can be set either on “false” or “true”. Choosing
+> either value does not influence the way calculations are carried out,
+> nor does it change their results. *
+>
+> *The effect of this preference is that, if the “true” value is
+> selected, Antares will produce and store in the simulation output
+> folder two files for every linear problem solved in the whole
+> simulation.*
+>
+> *The first file (“problem” file) contains a standardized description
+> of the mathematical problem solved by Antares’ built-in linear solver.
+> The format standard used in this file is known as “mps”. *
+>
+> *The second file (“criterion” file) contains the value of the optimal
+> (minimum) value found for the objective function of the optimization
+> problem (overall system cost throughout a day or a week)*
+>
+> *All commercial as well as Open Source linear solvers are able to
+> process mps files. As a consequence, tests aiming at comparing
+> Antares’ solver with other commercial solutions can be easily
+> carried out: all that has to be done is to submit the mps problem to
+> the solver at hand and measure its performances (calculation time,
+> criterion value) with those of Antares.*
+>
+> *Note that this kind of comparisons brings no information regarding
+> the quality of the physical modelling on which the simulation is
+> based. It is useful, however, to gather evidence on mathematical
+> grounds. *
+>
+> *File names are structured as follows:*
+
+- *When the optimization preference “simplex range” is set on “week”:*
+
+> *Problem-MC year-week number-date-time.mps*
+>
+> *Criterion-MC year-week number-date-time.txt*
+
+- *When the optimization preference “simplex range” is set on “day”:*
+
+> *Problem-MC year-week number-date-time-day number.mps*
+>
+> *Criterion-MC year-week number-date-time-day number.txt*
+>
+> *Besides, each economic problem generally demands to be solved through
+> two successive optimization problems. Files related to these two
+> problems will bear almost the same name, the only difference being the
+> “time” suffix. The files related to the second optimization (final
+> Antares results) are those that bear the latest tag.*
+>
+> *Finally, it is possible that, on special occasions (very small
+> files), the files attached to the two optimization rounds begin to be
+> printed within the same second. In that case, an additional suffix is
+> added before the mps or txt extension.*
+>
+> ***Note that: ***
+
+- *The disk space used to store mps file is not included in the disk
+ resources assessment displayed in the resources monitor menu *
+
+- *The extra runtime and disk space resulting from the activation of
+ the “mps” option may be quite significant. This option should
+ therefore be used only when a comparison of results with those of
+ other solvers is actually intended.*
+
+## The “Unfeasible Problems Behavior” optimization preference
+
+> *This preference can take any of the four values: *
+>
+> *Error Dry, Error Verbose, Warning Dry, Warning Verbose*
+>
+> *If “Error Dry” or “Error Verbose” is selected, the simulation will
+> stop right after encountering the first mathematically unfeasible
+> optimization (daily or weekly) problem. No output will be produced
+> beyond this point. Should the dataset contain several unfeasible
+> problems (i.e. regarding different weeks of different MC years), it is
+> possible that successive runs of the same simulation stop at different
+> points (if parallel computation is used, the triggering problem may
+> differ from one run to the other).*
+>
+> *If “Warning Dry” or “Warning Verbose” is selected, the simulation
+> will skip all mathematically unfeasible optimization (daily or weekly)
+> problems encountered, fill out all results regarding these problems
+> with zeroes and resume the simulation. The hydro reservoir levels used
+> for resuming the simulation are those reached at the end of the last
+> successful week. *
+>
+> *With “Dry” options no specific data are printed regarding the faulty
+> problem(s). With “Verbose” options, the full expression of the faulty
+> problem(s) is printed in the standard “mps” format, thus allowing
+> further analysis of the unfeasibility issue. *
+
+*
+*
+
+## The “Reservoir Level Initialization” advanced parameter
+
+> *This parameter can take the two values “cold start” or “hot start”.
+> \[default: cold start\]. Simulations results may in some circumstances
+> be heavily impacted by this setting, hence proper attention should be
+> paid to its meaning before considering changing the default value.*
+>
+> ***General: ***
+>
+> *This parameter is meant to define the initial reservoir levels that
+> should be used, in each system area, when processing data related to
+> the hydro-power storage resources to consider in each specific
+> Monte-Carlo year (see Section 4)*
+>
+> *As a consequence, Areas which fall in either of the two following
+> categories are not impacted by the value of the parameter: *
+
+- *No hydro-storage capability installed*
+
+- *Hydro-storage capability installed, but the “reservoir management”
+ option is set to “False” *
+
+> *Areas that have some hydro-storage capability installed and for which
+> explicit reservoir management is required are concerned by the
+> parameter. The developments that follow concern only this category of
+> Areas. *
+>
+> ***Cold Start: ***
+>
+> *On starting the simulation of a new Monte-Carlo year, the reservoir
+> level to consider in each Area on the first day of the initialization
+> month (see Section 4) is randomly drawn between the extreme levels
+> defined for the Area on that day.*
+>
+> *More precisely:*
+
+- *The value is drawn according to the probability distribution
+ function of a “Beta” random variable, whose four internal parameters
+ are set so as to adopt the following behavior:*
+
+> *Lower bound: Minimum reservoir level.*
+>
+> *Upper bound: Maximum reservoir level*
+>
+> *Expectation: Average reservoir level*
+>
+> *Standard Deviation: (1/3) (Upper bound-Lower bound) *
+
+- *The random number generator used for that purpose works with a
+ dedicated seed that ensures that results can be reproduced*\[17\]
+ *from one run to another, regardless of the simulation runtime mode
+ (sequential or parallel) and regardless of the number of Monte-Carlo
+ years to be simulated*\[18\]*. *
+
+*
+*
+
+> ***Hot Start: ***
+>
+> *On starting the simulation of a new Monte-Carlo year, the reservoir
+> level to consider in each Area on the first day of the initialization
+> month is set to the value reached at the end of the previous simulated
+> year, if three conditions are met:*
+
+- *The simulation calendar is defined throughout the whole year, and
+ the simulation starts on the day chosen for initializing the
+ reservoir levels of all Areas *
+
+- *The Monte-Carlo year considered is not the first to simulate, or
+ does not belong to the first batch of years to be simulated in
+ parallel. In sequential runtime mode, that means that year \# N may
+ start with the level reached at the end of year \#(N-1). In parallel
+ runtime mode, if the simulation is carried out with batches of B
+ years over as many CPU cores, years of the k-th batch*\[19\] *may
+ start with the ending levels of the years processed in the (k-1)-th
+ batch.*
+
+- *The parallelization context (see Section 9) must be set so as to
+ ensure that the M Monte-Carlo years to simulate will be processed in
+ a round number of K consecutive batches of B years in parallel (i.e.
+ M = K\*B and all time-series refresh intervals are exact multiple of
+ B). *
+
+> *The first year of the simulation, and more generally years belonging
+> to the first simulation batch in parallel mode, are initialized as
+> they would be in the cold start option. *
+>
+> ***Note that: ***
+
+- *Depending on the hydro management options used, the amount of
+ hydro-storage energy generated throughout the year may either match
+ closely the overall amount of natural inflows of the same year, or
+ differ to a lesser or greater extent. In the case of a close match,
+ the ending reservoir level will be similar to the starting level. If
+ the energy generated exceeds the inflows (either natural or pumped),
+ the ending level will be lower than the starting level (and
+ conversely, be higher if generation does not reach the inflow
+ credit). Using the “hot start” option allows to take this phenomenon
+ into account in a very realistic fashion, since the consequences of
+ hydro decisions taken at any time have a decisive influence on the
+ system’s long term future.*
+
+- *When using the reservoir level “hot start” option, comparisons
+ between different simulations make sense only if they rely on the
+ exact same options, i.e. either sequential mode or parallel mode
+ over the same number of CPU cores. *
+
+- *More generally, it has to be pointed out that the “hydro-storage”
+ model implemented in Antares can be used to model “storable”
+ resources quite different from actual hydro reserves: batteries, gas
+ subterraneous stocks, etc. *
+
+*
+*
+
+## The “Hydro Heuristic policy” advanced parameter
+
+> *This parameter can take the two values “Accommodate rule curves” or
+> “Maximize generation” \[default: Accommodate rule curves\]*
+>
+> ***General: ***
+>
+> *This parameter is meant to define how the reservoir level should be
+> managed throughout the year, with emphasis put either on the respect
+> of rule curves or on the maximization of the use of natural inflows *
+>
+> ***Accommodate rule curves: ***
+>
+> *Upper and lower rule curves are accommodated in both monthly and
+> daily heuristic stages (described page 58). In the second stage,
+> violations of the lower rule curve are avoided as much as possible
+> (penalty cost on Ψ. higher than penalty cost on Y). This policy may
+> result in a restriction of the overall yearly energy generated from
+> the natural inflows. *
+>
+> ***Maximize generation: ***
+>
+> *Upper and lower rule curves are accommodated in both monthly and
+> daily heuristic stages (described page 58). In the second stage,
+> incomplete use of natural inflows is avoided as much as possible
+> (penalty cost on Y higher than penalty cost on Ψ) . This policy may
+> result in violations of the lower rule curve. *
+
+*
+*
+
+##
+
+## The “Hydro Pricing mode” advanced parameter
+
+> *This parameter can take the two values “fast” or “accurate”.
+> \[default: fast\]. *
+>
+> *Simulations carried out in “accurate” mode yield results that are
+> theoretically optimal as far as the techno-economic modelling of hydro
+> (or equivalent) energy reserves is concerned. It may, however, require
+> noticeably longer computation time than the simpler “fast” mode. *
+>
+> *Simulations carried out in “fast” mode are less demanding in computer
+> resources. From a qualitative standpoint, they are expected to lead to
+> somewhat more intensive (less cautious) use of stored energy.*
+>
+> ***General: ***
+>
+> *This parameter is meant to define how the reservoir level difference
+> between the beginning and the end of an optimization week should be
+> reflected in the hydro economic signal (water value) used in the
+> computation of optimal hourly generated /pumped power during this
+> week. *
+>
+> ***Fast: ***
+>
+> *The water value is taken to remain about the same throughout the
+> week, and a constant value equal to that found at the date and for the
+> level at which the week **begins** is used in the course of the
+> optimization. A value interpolated from the reference table for the
+> exact level reached at each time step within the week is used ex-post
+> in the assessment of the variable “H.COST” (positive for generation,
+> negative for pumping) defined in Section 5. This option should be
+> reserved to simulations in which computation resources are an issue or
+> to simulations in which level-dependent water value variations
+> throughout a week are known to be small. *
+>
+> ***Accurate: ***
+>
+> *The water value is considered as variable throughout the week. As a
+> consequence, a different cost is used for each ”layer” of the stock
+> from/to which energy can be withdrawn/injected, in an internal hydro
+> merit-order involving the 100 tabulated water-values found at the date
+> at which the week **ends**. A value interpolated from the reference
+> table for the exact level reached at each time step within the week is
+> used ex-post in the assessment of the variable “H.COST” (positive for
+> generation, negative for pumping) defined in Section 5. This option
+> should be used if computation resources are not an issue and if
+> level-dependent water value variations throughout a week must be
+> accounted for.*
+
+*
+*
+
+## The “Unit Commitment mode” advanced parameter
+
+> *This parameter can take the two values “fast” or “accurate”.
+> \[default: fast\]. *
+>
+> *Simulations carried out in “accurate” mode yield results that are
+> expected to be close to the theoretical optimum as far as the
+> techno-economic modelling of thermal units is concerned. They may,
+> however, require much longer computation time than the simpler “fast”
+> mode. *
+>
+> *Simulations carried out in “fast” mode are less demanding in computer
+> resources. From a qualitative standpoint, they are expected to lead to
+> a more costly use of thermal energy. This potential bias is partly due
+> to the fact that in this mode, start-up costs do not participate as
+> such to the optimization process but are simply added ex post.*
+>
+> ***General: ***
+>
+> *In its native form*\[20\]*, the weekly optimization problem belongs
+> to the MILP (Mixed Integer Linear Program) class. The Integer
+> variables reflect, for each time step, the operational status (running
+> or not) of each thermal unit. Besides, the amount of power generated
+> from each unit can be described as a so-called semi-continuous
+> variable (its value is either 0 or some point within the interval
+> \[Pmin , Pmax\]). Finally, the periods during which each unit is
+> either generating or not cannot be shorter than minimal (on- and off-)
+> thresholds depending on its technology. *
+>
+> *The Unit Commitment mode parameter defines two different ways to
+> address the issue of the mathematical resolution of this problem. In
+> both cases, two successive so-called “relaxed” LP global optimizations
+> are carried out. In-between those two LPs, a number of local IP (unit
+> commitment of each thermal cluster) are carried out. *
+>
+> *Besides, dynamic thermal constraints (minimum on- and off- time
+> durations) are formulated on time-indices rolling over the week; this
+> simplification brings the ability to run a simulation over a short
+> period of time, such as one single week extracted from a whole year,
+> while avoiding the downside (data management complexity, increased
+> runtime) of a standard implementation based on longer simulations
+> tiled over each other (illustration below).*
+>
+> ***Fast: ***
+>
+> *In the first optimization stage, integrity constraints are removed
+> from the problem and replaced by simpler continuous constraints. *
+>
+> *For each thermal cluster, the intermediate IP looks simply for an
+> efficient unit-commitment compatible with the operational status
+> obtained in the first stage, with the additional condition (more
+> stringent than what is actually required) that on- and off- periods
+> should be exact multiple of the higher of the two thresholds specified
+> in the dataset. *
+>
+> *In the second optimization stage, the unit commitment set by the
+> intermediate IPs is considered as a context to use in a new
+> comprehensive optimal hydro-thermal schedule assessment. The amount of
+> day-ahead (spinning) reserve, if any, is added to the demand
+> considered in the first stage and subtracted in the second stage.
+> Start-up costs as well as No-Load Heat costs are assessed in
+> accordance with the unit-commitment determined in the first stage and
+> are added ex post. *
+>
+> ***Accurate: ***
+>
+> *In the first optimization stage, integrity constraints are properly
+> relaxed. Integer variables describing the start-up process of each
+> unit are given relevant start-up costs, and variables attached to
+> running units are given No-Load Heat costs (if any), regardless of
+> their generation output level. Fuel costs / Market bids are attached
+> to variables representing the generation output levels.*
+>
+> *For each thermal cluster, the intermediate IP looks for a
+> unit-commitment compatible with the integrity constraints in the
+> immediate neighborhood of the relaxed solution obtained in the first
+> stage. In this process, the dynamic thresholds (min on-time, min
+> off-time) are set to their exact values, without any additional
+> constraint. *
+>
+> *In the second optimization stage, the unit commitment set by the
+> intermediate IP is considered as a context to use in a new
+> comprehensive optimal hydro-thermal schedule assessment. The amount of
+> day-ahead (spinning) reserve, if any, is added to the demand
+> considered in the first stage and subtracted in the second stage. *
+
+*
+*
+
+> ***The “Renewable
+> Generation modelling” advanced parameter***
+>
+> *This parameter can take the two values “aggregated” or “cluster”. For
+> a new study, it will default to cluster. For a legacy (Antares version
+> \<8.1.0) study it will default to aggregated.*
+>
+> *If the parameter is set to "aggregated”, the user will have access to
+> the Wind & Solar windows, but not the Renewable window. When the
+> parameter is set to “cluster", the Renewable window will be available,
+> but not the Wind nor the Solar windows. The data stored in the windows
+> that are not available will always be conserved. However, only
+> Renewable data (and not the wind and solar data) will be considered
+> for the calculations when the parameter is set to “cluster”. And only
+> the wind and solar data (and not the renewable data) will be
+> considered for the calculations when the parameter is set to
+> “aggregated”.*
+>
+> *The Renewable window can be filled out with the different renewable
+> clusters inside each node. Each renewable cluster needs to have a
+> group specified or will default to the* « Other RES 1» group.
+> Production Timeseries can be filled out much like the Thermal
+> production ones. Note that unlike thermal clusters, negative
+> production values are allowed. The Renewable window is described in
+> more details in the “4. Active Windows” section. In the Simulation
+> window, only “Ready-made” timeseries can be selected for renewables
+> for now. This should be modified in a future release. The MC scenario
+> builder for Renewables works the same way as for Thermal Clusters.
+
+*
+*
+
+# 9 System requirements
+
+## Operating system
+
+> *Antares\_Simulator code is cross-platform (Windows/Linux/Unix) and
+> installation packages for various versions of these OS are available
+> at:
+> [https://antares-simulator.org](https://antares-simulator.org)
+> *
+
+## Hard drive disk
+
+> *Installed alone, the Antares simulator does not require a lot of HDD
+> space (less than 1 GB). Installation packages including companion
+> tools (study manager, graph editor) are however significantly heavier.
+> The proper storage of data (i.e. both Input and Output folders of
+> Antares studies) may require a large amount of space. The disk
+> footprint of any individual study mainly depends on:*
+
+- *The size of the power system modeled (number of Areas, Links,
+ Thermal clusters, etc.)*
+
+- *The number of ready-made Time-Series and the number of Time-Series
+ to be generated at runtime and stored afterwards*
+
+- *The activation of output filters (Geographic Trimming and / or
+ Thematic Trimming)*
+
+- *The number of Monte-Carlo years involved in the simulation session
+ (if the storage of detailed year-by-year results is requested)*
+
+- *The status of the “export mps” optimization preference*
+
+> *At any moment, the amount of disk resources required for a simulation
+> is accessible through the Tools/resources monitor menu*
+
+## Memory
+
+> *The amount of RAM required for a simulation depends on:*
+
+- *The size of the power system modeled (number of Areas, Links,
+ Thermal clusters, etc.)*
+
+- *The number of ready-made Time-Series and that of Time-Series to be
+ generated at runtime *
+
+- *The simulation mode (draft, adequacy, economy with “fast” or
+ “accurate” unit commitment) *
+
+- *The execution mode (swap, default, parallel)*
+
+> *At any moment, the amount of RAM resources required for a simulation
+> is accessible through the Tools/resources monitor menu*
+
+## Multi-threading
+
+> *The GUI of Antares and all I/O operations on Input / Output files
+> automatically benefit from full multi-threading on the local machine’s
+> CPU cores. Multi-threading is also available on the proper calculation
+> side, on a user-defined basis.*
+>
+> *Provided that hardware resources are large enough, this mode may
+> reduce significantly the overall runtime of heavy simulations.*
+>
+> *To benefit from multi-threading, the simulation must be run in the
+> following context: *
+
+- *In the “run” window, the option “parallel” must be selected*\[21\]
+
+- *The simulation mode must be either “Adequacy” or “Economy”*\[22\]
+
+> *When the “parallel” solver option is used, each Monte-Carlo year is
+> dispatched as an individual process on the available CPU cores. *
+>
+> *The number of such individual processes depends on the
+> characteristics of the local hardware and on the value given to the
+> study-dependent “**simulation cores**” advanced parameter. This
+> parameter can take five different values (Minimum, Low, Medium, High,
+> Maximum). The number of independent processes resulting from the
+> combination (local hardware + study settings) is given in the
+> following table, which shows the CPU allowances granted in the
+> different configurations.*
+
+
+
+
+
+
+
+ |
+Minimum |
+Low |
+Medium |
+Large |
+Maximum |
+
+
+| 1 |
+1 |
+1 |
+1 |
+1 |
+1 |
+
+
+| 2 |
+1 |
+1 |
+1 |
+2 |
+2 |
+
+
+| 3 |
+1 |
+2 |
+2 |
+2 |
+3 |
+
+
+| 4 |
+1 |
+2 |
+2 |
+3 |
+4 |
+
+
+| 5 |
+1 |
+2 |
+3 |
+4 |
+5 |
+
+
+| 6 |
+1 |
+2 |
+3 |
+4 |
+6 |
+
+
+| 7 |
+1 |
+2 |
+3 |
+5 |
+7 |
+
+
+| 8 |
+1 |
+2 |
+4 |
+6 |
+8 |
+
+
+| 9 |
+1 |
+3 |
+5 |
+7 |
+8 |
+
+
+| 10 |
+1 |
+3 |
+5 |
+8 |
+9 |
+
+
+| 11 |
+1 |
+3 |
+6 |
+8 |
+10 |
+
+
+| 12 |
+1 |
+3 |
+6 |
+9 |
+11 |
+
+
+| S >12 |
+1 |
+Ceil(S/4) |
+Ceil(S/2) |
+Ceil(3S/4) |
+S-1 |
+
+
+
+
+> ***CPU allowances in parallel mode ***
+>
+> ***Note**: The number of independent threads actually launched by
+> Antares in parallel mode may appear smaller than that shown in the
+> table above. In this case, the resources monitor menu and the
+> dashboard displayed on starting the simulation indicates: *
+>
+> *simulation cores: **nn** reduced to **pp***
+>
+> ***nn** is the regular allowance and **pp** is the practical value
+> that the solver has to work with. Allowance reduction may occur if the
+> built-in Time-Series generators are activated, their “refresh” status
+> is set to “Yes” and the values given to the “refresh span” parameters
+> are not appropriate (parallel execution demand that refresh operations
+> do not take place within a bundle of parallel years). Optimal use of
+> the “parallel” execution mode is obtained when all activated built-in
+> time –series generators are set up in either of the two following
+> ways:*
+
+- *Refresh status : **No***
+
+- *Refresh status : **Yes**, refresh span = **Ki \* (CPU allowance)**
+ , with **Ki \>=1***
+
+> *Examples of reduction from an initial allowance of 12 cores are given
+> hereafter. The reduced allowance is the size of the **smallest**
+> bundle of parallel years between two consecutive “refresh” (it
+> indicates the slowest point of the simulation*\[24\]*). Note that RAM
+> requirements displayed in the resources monitor are, contrariwise,
+> assessed on the basis on the **largest** bundle of parallel years
+> encountered in the simulation). *
+
+| *Built-in TS generators status / refresh span*\[25\] | ***Reduced Allowance (from 12)*** | | | | | |
+| ---------------------------------------------------- | --------------------------------- | -------- | -------- | -------- | ------------------ | --------------- |
+| *Load* | *Thermal* | *Hydro* | *Wind* | *Solar* | *MC Years : 80* | *MC years: 400* |
+| *50* | *1* | *50* | *50* | *50* | *1* | *1* |
+| *No* | *10* | *50* | *No* | *No* | *10 * | *10* |
+| *No* | *11* | *50* | *No* | *No* | *5* | *1* |
+| *No* | *100* | *100* | *100* | *100* | ***No reduction*** | *4*\[26\] |
+| ***No*** | ***12*** | ***12*** | ***12*** | ***No*** | ***No reduction*** | |
+| ***12*** | ***24*** | ***48*** | ***48*** | ***36*** | ***No reduction*** | |
+
+# 10 Using the command line
+
+*Several executable parts of Antares\_Simulator can be run in command
+line from a console. The list and general syntax of these components is
+given hereafter. *
+
+*In all cases, arguments “ –h” or “–help” can be used to get help*
+
+**antares-8.1-solver**
+
+**antares-8.1-solver-swap** (simulation in low-RAM swap mode)
+
+Simulation
+
+\-i, --input Study folder
+
+\--expansion Force the simulation in expansion mode
+
+\--economy Force the simulation in economy mode
+
+\--adequacy Force the simulation in adequacy mode
+
+\--draft Force the simulation in adequacy-draft mode
+
+\--parallel Enable the parallel computation of MC years
+
+\--force-parallel=VALUE Override the max number of years computed
+simultaneously
+
+Parameters
+
+\-n, --name=VALUE Set the name of the new simulation to VALUE
+
+\-g, --generators-only Run the time-series generators only
+
+\-c, --comment-file=VALUE Specify the file to copy as comments of the
+simulation
+
+\-f, --force Ignore all warnings at loading
+
+\--no-output Do not write the results in the output folder
+
+\-y, --year=VALUE Override the number of MC years
+
+\--year-by-year Force the writing the result output for each year
+
+(economy only)
+
+\--derated Force the derated mode
+
+Optimization
+
+\--optimization-range Force the simplex optimization range ('day' or
+'week')
+
+\--no-constraints Ignore all binding constraints
+
+\--no-ts-import Do not import timeseries into the input folder.
+
+> (This option may be useful for running old studies without upgrade)
+
+\--mps-export Export weekly or daily optimal UC+dispatch linear
+
+Misc.
+
+\--progress Display the progress of each task
+
+\--swap-folder=VALUE Folder where the swap files will be written. This
+
+option has effect only in swap mode (swap files are only
+
+available for 'antares-solver-swap')
+
+\-p, --pid=VALUE Specify the file where to write the process ID
+
+\-v, --version Print the version of the solver and exit
+
+\-h, --help Display this help and exit
+
+\--use-ortools --ortools-solver= Sirius Use the standard Antares solver
+through the OR-Tools modelling library
+
+\--use-ortools --ortools-solver= Coin Use the Coin solver through the
+OR-Tools modelling library
+
+*
+*
+
+**antares-8.1-study-updater**
+
+\-i, --input=VALUE Add an input folder where to look for studies
+
+This argument is mandatory.
+
+\-c, --clean Clean all studies found
+
+\--remove-generated-timeseries
+
+Remove time-series which will be regenerated by
+
+the ts-generators
+
+\-d, --dry List the study folders which may be upgraded and do nothing
+else
+
+\--force-readonly Force read-only mode for all studies found
+
+\-v, --version Print the version and exit
+
+\-h, --help Display this help and exit
+
+**antares-8.1-study-finder**
+
+*-i, --input=VALUE Add an input folder where to look for studies.*
+
+*When no input folder is given, the current working dir is used.*
+
+*-e, --extra Print the version of the study*
+
+*--csv Print in a CSV format (semicolon)*
+
+*-v, --version Print the version and exit*
+
+*-h, --help Display this help and exit*
+
+**antares-8.1-study-cleaner**
+
+*-i, --input=VALUE An input folder where to look for studies*
+
+*--dry List the folder only and do nothing*
+
+*--mrproper Suppress the outputs and logs files*
+
+*-v, --version Print the version and exit*
+
+*-h, --help Display this help and exit*
+
+**antares-8.1-config**
+
+*-*p, --print Print the current configuration
+
+\-v, --version Print the version and exit
+
+\-h, --help Display this help and exit
+
+**antares-8.1-batchrun**
+
+Studies
+
+\-i, --input=VALUE The input folder, where to look for studies on which
+to run simulations
+
+Simulation mode
+
+\--expansion Force the simulation(s) in expansion mode
+
+\--economy Force the simulation(s) in economy mode
+
+\--adequacy Force the simulation(s) in adequacy mode
+
+Parameters
+
+\-n, --name=VALUE Set the name of the new simulation outputs
+
+\-y, --year=VALUE Override the number of MC years
+
+\-f, --force Ignore all warnings at loading
+
+\--no-output Do not write the results in the output folder
+
+\--year-by-year Force the writing of the result output for each year
+
+Optimization
+
+\--no-ts-import Do not import timeseries into the input folder.
+
+**--**no-constraints Ignore all binding constraints
+
+Extras
+
+\--solver=VALUE Specify the antares-solver location
+
+\-s, --swap Swap mode
+
+\--parallel Enable the parallel computation of MC years
+
+\--force-parallel=VALUE Override the max number of years computed
+simultaneously
+
+\--verbose Display detailed logs for each simulation to run
+
+*
+**APPENDIX : ATTRIBUTION NOTICES***
+
+> ***Antares\_Simulator ***
+>
+> ***Copyright 2007-2021 RTE - Authors: The Antares\_Simulator Team***
+>
+> *Antares\_Simulator is free software: you can redistribute it and/or
+> modify it under the terms of the GNU General Public License as
+> published by the Free Software Foundation, either version 3 of the
+> License, or (at your option) any later version.*
+>
+> *There are special exceptions to the terms and conditions of the
+> license as they are applied to this software. View the full text of
+> the exceptions in file COPYING.txt in the directory of a distribution
+> of the software in source form.*
+>
+> *Antares\_Simulator is distributed in the hope that it will be useful,
+> but WITHOUT ANY WARRANTY; without even the implied warranty of
+> MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+> General Public License for more details.*
+>
+> *You should have received a copy of the GNU General Public License
+> along with Antares\_Simulator. If not, see
+> \.*
+>
+> **Antares\_Simulator 8.1.0 uses external libraries and makes extensive
+> use of the following persons' or companies code. Source and binary
+> forms of these programs are distributed along with Antares\_Simulator
+> with NO WARRANTY:**
+>
+> *Wxwidgets 3.1.3 Copyright (c) 1998-2017 The wxWidget Team*
+>
+> [*https://github.com/wxWidgets/wxWidgets.git*](https://github.com/wxWidgets/wxWidgets.git)
+>
+> *license: wxWindows Library License,V3.1
+> https://spdx.org/licenses/wxWindows.html*
+>
+> *libCurl 7.68.0 Copyright (c) 1996-2017 Daniel Stenberg et al *
+>
+> [*https://github.com/curl/curl.git*](https://github.com/curl/curl.git)
+>
+> *license: curl license https://spdx.org/licenses/curl.html*
+>
+> *OpenSSL 1.1.1g Copyright (c) 1998-2016 The OpenSSL Project*
+>
+> [*https://github.com/openssl/openssl.git*](https://github.com/openssl/openssl.git)
+>
+> *"This product includes software developed by the OpenSSL Project*
+>
+> *for use in the OpenSSL Toolkit (http://www.openssl.org/)"*
+>
+> *"This product includes software written by Tim Hudson
+> (tjh@cryptsoft.com)" *
+>
+> *license: OpenSSL license and SSLeay license
+> https://spdx.org/licenses/OpenSSL.html*
+>
+> *libYuni 1.1.0
+> [https://github.com/libyuni](https://github.com/libyuni)*
+>
+> *license: Mozilla Public License 2.0
+> https://spdx.org/licenses/MPL-2.0.html*
+>
+> *Mersenne Twister Copyright (c) 1997-2002 M.Matsumoto and T.Nishimura
+> *
+>
+> *license: 3-clause BSD https://spdx.org/licenses/BSD-3-Clause.html*
+>
+> *strtod library Copyright (c) 1988-1993 The Regents of the University
+> of California*
+>
+> *Copyright (c) 1994 Sun Microsystems, Inc*
+>
+> *license: ISC license https://spdx.org/licenses/ISC.html*
+>
+> *Sirius\_Solver Copyright (c) 2007-2020 RTE*
+>
+> [*https://github.com/rte-france/sirius-solver.git*](https://github.com/rte-france/sirius-solver.git)
+>
+> *license: Apache 2.0 https://spdx.org/licenses/Apache-2.0.html*
+>
+> *OR-Tools Copyright © 2010-2020 Google LLC *
+>
+> [*https://github.com/rte-france/or-tools.git*](https://github.com/rte-france/or-tools.git)
+>
+> *license: Apache 2.0 https://spdx.org/licenses/Apache-2.0.html*
+
+1. For simplicity’s sake, the ***Antares\_Simulator*** 8.1.0
+ application will as of now be simply denoted “Antares”.
+
+2. A detailed expression of the basic mathematical problem solved in
+ the red box of the following figure can be found in the document
+ “Optimization problems formulation”.
+
+3. Many various graphic extensions (under the form of programs written
+ in the R language) are available at :
+
+ [https://cran.r-project.org/web/packages/antaresViz/index.html](https://cran.r-project.org/web/packages/antaresViz/index.html)
+
+4. *Weekly optimization performs a more refined unit commitment,
+ especially when the level selected in the “advanced parameters” menu
+ is “accurate”.*
+
+5. *”Economy” simulations make a full use of Antares optimization
+ capabilities. They require economic as well as technical input data
+ and may demand a lot of computer resources. “Adequacy” simulations
+ are faster and require only technical input data. Their results are
+ limited to adequacy indicators. “Draft” simulations are highly
+ simplified adequacy simulations, in which binding constraints (e.g.
+ DC flow rules) are ignored, while hydro storage is assumed to be
+ able to provide its nominal maximum power whenever needed. As a
+ consequence, draft simulations are biased towards* optimism. They
+ are, however, much faster than adequacy and economic simulations.
+
+6. In Economy an Adequacy simulations, these should be chosen so as to
+ make the simulation span a round number of weeks. If not, the
+ simulation span will be truncated: for instance, (1, 365) will be
+ interpreted as (1, 364), i.e. 52 weeks (the last day of the last
+ month will not be simulated). In Draft simulations, the simulation
+ is always carried out on 8760 hours.
+
+7. changing the number of MC years will reset the playlist to its
+ default value ; not available in Draft simulations
+
+8. Not available in Draft simulations
+
+9. KCG : Kirchhoff’s constraints generator (see section 7)
+
+10. A typical case is given by the “Flow-Based” framework today
+ implemented in a large portion of the European electricity market*.
+ *
+
+11. This description applies to both « MC synthesis » files and
+ “Year-by-Year” files, with some simplifications in the latter case
+
+12. Value identical to that defined under the same name in the “Misc
+ Gen” input section.
+
+13. NODU and NP Cost do not appear in “Adequacy” results since these
+ variables are irrelevant in that context
+
+14. This description applies to both « MC synthesis » files and
+ “Year-by-Year” files, with some simplifications in the latter case
+
+15. The number of spanning trees is equal to the absolute value of any
+ cofactor of the graph incidence matrix
+
+16. Mehlhorn K., Michail D. (2005) *Implementing Minimum Cycle Basis
+ Algorithms*. In: Experimental and Efficient Algorithms. WEA 2005.
+ Lecture Notes in Computer Science, vol 3503.
+
+17. *As long as the System’s list of Areas does not change*
+
+18. *E.g. : if three playlists A,B,C are defined over 1000 years (A:
+ years 1 to 1000, B: years 1 to 100, C: Years 13,42,57,112), initial
+ reservoir levels in each Area are identical in the playlists’
+ intersection (years 13,42,57) *
+
+19. *If the playlist is full, these years have numbers \# (k-1)B+1 ,….,
+ \#kB*
+
+20. Described in the note “Optimization Problems Formulation”
+
+21. Options « default » and « swap » do not perform multi-threaded
+ optimizations
+
+22. The « draft » mode is not multi-threaded
+
+23. This hardware characteristic, independent from Antares general
+ parameters and from study parameters, can be checked with the
+ Resources monitor tool (Section 3)
+
+24. *When the number of MC years to run is smaller than the allowance,
+ the parallel run includes all of these years in a single bundle and
+ there is no “reduced allowance” message *
+
+25. The Table indicates either the refresh status (No) or the refresh
+ span (the associated refresh status “yes” is implicit)
+
+26. The smallest bundle in this case is the ninth (year number 97 to
+ year number 100). The first 8 bundles involve 12 MC years each
diff --git a/docs/reference-guide/2-modeling.md b/docs/reference-guide/2-modeling.md
new file mode 100644
index 0000000000..f6b8737666
--- /dev/null
+++ b/docs/reference-guide/2-modeling.md
@@ -0,0 +1,439 @@
+# Formulation of the optimisation problems
+
+**_Antares\_Simulator Modeling and Optimization_**
+
+**Document available on : [https://antares-simulator.org](https://antares-simulator.org/)**
+
+
+## 1 Introduction
+
+The purpose of this document is to give every user of the **Antares\_Simulator** model (regardless of its version number), a detailed and comprehensive formulation of the main optimization problems solved by the application's inner optimization engine.
+
+The aim of the information presented hereafter is to provide a transparent access to the inner workings of the software from a **formal** standpoint. Note that, aside from this conceptual transparency, the software itself offers an option that makes it possible for the user to print, in a standardized format, any or all of the optimization problems actually solved in the course of an **Antares\_Simulator** session
+
+Used together with the elements developed in the next pages, this **practical** access to the internal model implemented the tool allows fair and open benchmarking with comparable software. Besides, another important issue regarding transparency is addressed by the release of **Antares\_Simulator** as an Open Source Gnu GPL 3.0 application.
+
+So as to delimit the scope of the present document with as much clarity as possible, it is important to notice that a typical **Antares\_Simulator** session involves different steps that are usually run in sequence, either automatically or with some degree of man-in-the-loop control, depending on the kind of study to perform.
+
+These steps most often involve:
+
+1. GUI session dedicated to the initialization or to the updating of various input data sections (load time-series, grid topology, wind speed probability distribution, etc.)
+2. GUI session dedicated to the definition of simulation contexts (definition of the number and consistency of the ";Monte-Carlo years"; to simulate)
+3. Simulation session producing actual numeric scenarios following the directives defined in (b)
+4. Optimization session aiming at solving all of the optimization problems associated with each of the scenarios produced in (c).
+5. GUI session dedicated to the exploitation of the detailed results yielded by (d)
+
+The scope of this document is exclusively devoted to step (d). Note that equivalent information regarding the other steps may be found in other documents made available either:
+
+- Within the application itself, in the "; ?"; menu
+- On the **Antares\_Simulator** website (download section) : [https://antares-simulator.org](https://antares-simulator.org/)
+- In technical publications referenced in the bibliography section of the website
+
+The following picture gives a functional view of all that is involved in steps (a) to (e). In this illustration, Step (d), whose goal is to solve the problems introduced in this document, is materialized by the red box.
+
+The number and the size of the individual problems to solve (a least-cost hydro-thermal unit-commitment and power schedule, with an hourly resolution and throughout a week, over a large interconnected system) make optimization sessions often computer-intensive. Note that the content of the blue ";hydro energy manager"; box appearing on the previous figure, whose purpose is to deal with energy storage issues at the seasonal scale, is not detailed in the present document but in the ";General Reference Guide";.
+
+Depending on user-defined results accuracy requirements, various practical options allow to simplify either the formulation of the weekly UC & dispatch problems (e.g. do not account for constraints associated with operational reserves) or their resolution (i.e. find, for the native MILP, an approximate solution based on two successive LPs). For the sake of simplicity and clarity, the way these options are used to revise the primary problem formulation is not detailed hereafter. Likewise, many simplifications are introduced to keep notations as light as possible. This is why, for instance, the overall sum of load, wind power generation, solar power generation, run of the river generation, and all other kinds of so-called ";must-run"; generation is simply denoted ";load"; in the present document.
+
+## 2 Typology of the problems solved
+
+In terms of power studies, the different fields of application Antares has been designed for are the following:
+
+- **Generation adequacy problems :** assessment of the need for new generating plants so as to keep the security of supply above a given critical threshold
+
+What is most important in these studies is to survey a great number of scenarios that represent well enough the random factors that may affect the balance between load and generation. Economic parameters do not play as much a critical role as they do in the other kinds of studies, since the stakes are mainly to know if and when supply security is likely to be jeopardized (detailed costs incurred in more ordinary conditions are of comparatively lower importance). In these studies, the default Antares option to use is the ";Adequacy"; simulation mode, or the ";Draft"; simulation mode (which is extremely fast but which produces crude results).
+
+- **Transmission project profitability :** assessment of the savings brought by a specific reinforcement of the grid, in terms of decrease of the overall system generation cost (using an assumption of fair and perfect market) and/or improvement of the security of supply (reduction of the loss-of-load expectation).
+
+In these studies, economic parameters and the physical modeling of the dynamic constraints bearing on the generating units are of paramount importance. Though a thorough survey of many ";Monte-Carlo years"; is still required, the number of scenarios to simulate is not as large as in generation adequacy studies. In these studies, the default Antares option to use is the ";Economy"; simulation mode.
+
+- **Generation and/or Transmission expansion planning:** rough assessment of the location and consistency of profitable reinforcements of the generating fleet and/or of the grid at a given horizon, on the basis of relevant reference costs and taking into account feasibility local constraints (bounds on the capacity of realistic reinforcements).
+
+These long term studies clearly differ from the previous ones in the sense that the generation and transmission assets that define the consistency of the power system are no longer passive parameters but are given the status of active problem variables. In the light of both the nature and the magnitude of the economic stakes, there is comparatively a lesser need than before for an accurate physical modeling of fine operational constraints or for an intensive exploration of a great many random scenarios. The computer intensiveness of expansion studies is, however, much higher than that of the other types because the generic optimization problem to address happens to be much larger.
+
+The common rationale of the modeling used in all of these studies is, whenever it is possible, to decompose the general issue (representation of the system behavior throughout many years, with a time step of one hour) into a series of standardized smaller problems.
+
+In **Antares\_Simulator**, the ";elementary "; optimization problem resulting from this approach is that of the minimization of the overall system operation cost over a week, taking into account all proportional and non-proportional generation costs, as well as transmission charges and ";external"; costs such as that of the unsupplied energy (generation shortage) or, conversely, that of the spilled energy (generation excess).
+
+In this light, carrying out generation adequacy studies or transmission projects studies means formulating and solving a series of a great many week-long operation problems (one for each week of each Monte-Carlo year ), assumed to be independent. This generic optimization problem will be further denoted **,** where is an index encompassing all weeks of all Monte-Carlo years.
+
+Note that this independency assumption may sometimes be too lax, because in many contexts weekly problems are actually coupled to some degree, as a result of energy constraints (management of reservoir-type hydro resources, refueling of nuclear power plants, etc.). When appropriate, these effects are therefore dealt with before the actual decomposition in weekly problems takes place, this being done either of the following way (depending on simulation options):
+
+1. Use of an economic signal (typically, a shadow ";water value";) yielded by an external preliminary stochastic dynamic programming optimization of the use of energy-constrained resources.
+2. Use of heuristics that provide an assessment of the relevant energy credits that should be used for each period, fitted so as to accommodate with sufficient versatility different operational rules.
+
+Quite different is the situation that prevails in expansion studies, in which weekly problems cannot at all be separated from a formal standpoint, because new assets should be paid for all year-long, regardless of the fact that they are used or not during such or such week : the generic expansion problem encompasses therefore all the weeks of all the Monte-Carlo years at the same time. It will be further denoted \\(\mathcal{P}\\).
+
+The next sections of this document develop the following subjects:
+
+- Notations used for \\(\mathcal{P}^k\\) and \\(\mathcal{P}\\)
+
+- Formulation of \\(\mathcal{P}^k\\)
+
+- Formulation of \\(\mathcal{P}\\)
+
+- Complements to the standard problems (how to make **Antares\_Simulator** work as a SCOPF )
+
+- Miscellaneous complements to the standard problems
+
+## 3 Notations
+
+### 3.1 General notations
+**TODO : add units**
+
+| Notation | Explanation |
+| ------------ | ------------- |
+| \\( k \in K \\) | optimization periods (weeks) over which \\(P\\) and \\(P^k\\) are defined (omitted for simplicity) |
+| \\(t \in T\\) | individual time steps of any optimization period \\( k\in K\\) (hours of the week) |
+| \\(G(N,L)\\) | undirected graph of the power system (connected) |
+| \\(n \in N\\) | vertices of \\(G\\), \\(N\\) is an ordered set |
+| \\(l \in L\\) | edges of \\(G\\) |
+| \\(A\\) | incidence matrix of \\(G\\), dimension \\(N\times L\\) |
+| \\(g\\) | spanning tree of \\(G\\) |
+| \\(C_g\\) | cycle basis associated with \\(g\\), dimension \\(L\times (L+1-N)\\) |
+| \\(L_n^+\subset L\\) | set of edges for which \\(n\\) is the upstream vertex |
+| \\(L_n^-\subset L\\) | set of edges for which \\(n\\) is the downstream vertex |
+| \\(u_l \in N\\) | vertex upstream from \\(l\\) |
+| \\(d_l \in N\\) | vertex downstream from \\(l\\) |
+| \\(u \cdot v\\) | inner product of vectors \\(u\\) and \\(v\\) |
+| \\(u_\uparrow^p\\) | vector resulting from the permutation on \\(u \in \mathbb{R}^s\\) : $$ u\_\uparrow^p(i)=u(i+p\, \mathrm{mod}\,s)$$ |
+
+
+### 3.2 Grid
+**TODO : add units**
+
+| Notation | Explanation |
+| ------------ | ------------- |
+| \\(C_l^+ \in \mathbb{R}^T_+\\) | initial transmission capacity from \\(u_l\\) to \\(d_l\\) (variable of \\(P\\) and \\(P^k\\)) |
+| \\( \overline{C}\_l^+ \in \mathbb{R}^T\_+ \\) | maximum transmission capacity from \\(u_l\\) to \\(d_l\\) (variable of \\(P\\), not used in \\(P^k\\)) |
+| \\(C_l^- \in \mathbb{R}^T_+\\) | initial transmission capacity from \\(d_l\\) to \\(u_l\\) (variable of \\(P\\) and \\(P^k\\)) |
+| \\( \overline{C}^{-}\_l\in \mathbb{R}^T\_{+} \\) | maximum transmission capacity from \\(d_l\\) to \\(u_l\\) (variable of \\(P\\), not used in \\(P^k\\)) |
+| \\(\Psi_l \in \mathbb{R}_+\\) | weekly cost of a maximum capacity investment |
+| \\(x_l \in [0,1]\\) | transmission capacity investment level |
+| \\(F_l^+ \in \mathbb{R}^T_+\\) | power flow through \\(l\\), from \\(u_l\\) to \\(d_l\\) |
+| \\(F_l^- \in \mathbb{R}^T_+\\) | power flow through \\(l\\), from \\(d_l\\) to \\(u_l\\) |
+| \\(F_l\in \mathbb{R}^T\\) | total power flow through \\(l\\), \\(F_l=F_l^+-F_l^-\\) |
+| \\(\tilde{F}_t \in \mathbb{R}^T\\) | system flow snapshot at time \\(t\\) |
+| \\(\gamma_l^+\in \mathbb{R}^T\\) | transmission cost through \\(l\\), from \\(u_l\\) to \\(d_l\\). Proportional to the power flow |
+| \\(\gamma_l^-\in \mathbb{R}^T\\) | transmission cost through \\(l\\), from \\(d_l\\) to \\(u_l\\). Proportional to the power flow |
+| \\(Z_l \in \mathbb{R}\_+\\) | overall impedance of \\(l\\) |
+
+### 3.3 Thermal units
+**TODO : add units**
+
+| Notation | Explanation |
+| ------------ | ------------- |
+| \\(\theta \in \Theta_n\\) | thermal clusters (sets of identical units) installed in node \\(n\\) |
+| \\(\Theta\\) | set of all thermal clusters of the power system \\(\Theta = \cup_{n\in N} \Theta_n\\) |
+| \\(\overline{P}\_\theta \in \mathbb{R}^T_+\\) | maximum power output from cluster \\(\theta\\), depends on units availability |
+| \\(\underline{P}\_\theta \in \mathbb{R}^T_+\\) | mimimum power output from cluster \\(\theta\\), units availability allowing |
+| \\(P_\theta \in \mathbb{R}^T_+\\) | power output from cluster \\(\theta\\) |
+| \\(\chi_\theta \in \mathbb{R}^T\\) | power output from cluster \\(\theta\\) |
+| \\(\sigma_\theta^+ \in \mathbb{R}^T\\) | startup cost of a single unit in cluster \\(\theta\\) |
+| \\(\tau_\theta \in \mathbb{R}^T\\) | running unit in \\(\theta\\) : cost independent from output level (aka NoLoadHeatCost) |
+| \\(l_\theta \in \mathbb{R}_+\\) | unit in \\(\theta\\) : minimum stable power output when running |
+| \\(u_\theta \in \mathbb{R}_+\\) | unit in \\(\theta\\) : maximum net power output when running |
+| \\(\Delta_\theta^+ \in \lbrace 1,\dots, \|T\|\rbrace\\) | unit in \\(\theta\\) : minumum on time when running |
+| \\(\Delta_\theta^- \in \lbrace 1,\dots, \|T\|\rbrace\\) | unit in \\(\theta\\) : minumum off time when not running |
+| \\(\Delta_\theta = \max(\Delta_\theta^-, \Delta_\theta^+) \\) | duration above which both state changes are allowed |
+| \\(M_\theta \in \mathbb{N}^T\\) | number of running units in cluster \\(\theta\\) |
+| \\(\overline{M}_\theta \in \mathbb{N}^T\\) | maximum number of running units in cluster \\(\theta\\) |
+| \\(\underline{M}_\theta \in \mathbb{N}^T\\) | minimum number of running units in cluster \\(\theta\\) |
+| \\(M_\theta^+ \in \mathbb{N}^T\\) | number of units in cluster changing from state off to state on in cluster \\(\theta\\) |
+| \\(M_\theta^- \in \mathbb{N}^T\\) | number of units in cluster changing from state on to state off in cluster \\(\theta\\) |
+| \\(M_\theta^{--} \in \mathbb{N}^T\\) | number of units in cluster changing from state on to state outage cluster \\(\theta\\) |
+
+### 3.4 Reservoir-type hydropower units (or other power storage facilities)
+**TODO : add units**
+
+| Notation | Explanation |
+| ------------ | -------------
+| \\(\lambda \in \Lambda_n\\) | reservoirs connected to node \\(n\\) |
+| \\(\Sigma_\lambda \in \mathbb{R}_+\\) | size of reservoir \\(\lambda\\) : amount of energy that can be stored in \\(\lambda\\) |
+| \\(Q\in \mathbb{N}\\) | number of discrete levels defined in reservoir |
+| \\(\overline{W}\_\lambda \in \mathbb{R}_+\\) | maximum energy output from \\(\lambda\\) throughout the optimization period |
+| \\(\underline{W}\_\lambda \in \mathbb{R}_+\\) | minimum energy output from \\(\lambda\\) throughout the optimization period |
+| \\(\overline{H}\_\lambda \in \mathbb{R}_+^T\\) | maximum power output from reservoir \\(\lambda\\). Note : \\(\sum_{t\in T} \overline{H}\_{\lambda\_t} \geq \underline{W}\_\lambda\\) |
+| \\(\underline{H}\_\lambda \in \mathbb{R}_+^T\\) | minimum power output from reservoir \\(\lambda\\). Note : \\(\sum_{t\in T} \underline{H}\_{\lambda\_t} \leq \overline{W}\_\lambda\\) |
+| \\(H\_\lambda \in \mathbb{R}_+^T\\) | power output from reservoir \\(\lambda\\) |
+| \\(r\_\lambda \in \mathbb{R}_+\\) | maximum ratio between output power daily peak and daily average (\\(1 \leq r\_\lambda \leq 24\\)) |
+| \\(\varepsilon\_\lambda \in \mathbb{R}\\) | reference water value associated with the reservoir's initial state (date, level) |
+| \\(\varepsilon^*\_\lambda \in \mathbb{R}\\) | random component added to the water value (dispatch smoothing effect) |
+| \\(\eta\_\lambda \in \mathbb{R}^Q\\) | reference water value associated with the reservoir's final state (date) |
+| \\(\rho\_\lambda \in \mathbb{R}_+\\) | efficiency ratio of pumping units (or equivalent devices) available in reservoir \\(\lambda\\) |
+| \\(\overline{\Pi}\_\lambda \in \mathbb{R}_+^T\\) | maximum power absorbed by pumps of reservoir \\(\lambda\\) |
+| \\(\Pi\_\lambda \in \mathbb{R}_+^T\\) | power absorbed by pumps of reservoir \\(\lambda\\) |
+| \\(I\_\lambda \in \mathbb{R}^T_+\\) | natural power inflow to reservoir \\(\lambda\\) |
+| \\(O\_\lambda \in \mathbb{R}_+^T\\) | power overflowing from reservoir \\(\lambda\\) : part of inflow that cannot be stored |
+| \\(\overline{R}\_\lambda \in \mathbb{R}_+^T\\) | upper bound of the admissible level in reservoir \\(\lambda\\) |
+| \\(\underline{R}\_\lambda \in \mathbb{R}_+^T\\) | lower bound of the admissible level in reservoir \\(\lambda\\) |
+| \\(R\_\lambda \in \mathbb{R}^T_+\\) | stored energy level in reservoir \\(\lambda\\) |
+| \\(\mathfrak{R}\_{\lambda_q} \in \mathbb{R}_+\\) | filling level of reservoir layer \\(q\\) at time \\(T\\) (end of the week) |
+
+### 3.5 Binding constraints
+
+In both \\(\mathcal{P}^k\\) and \\(\mathcal{P}\\), the need for a versatile modelling of the power system calls for the introduction of an arbitrary number of linear binding constraints between system's variables throughout the grid, expressed either in terms of hourly power, daily energies or weekly energies.
+These constraints may bind together synchronous flows as well as thermal units power outputs. They may be related to synchronous values or bear on different times.
+Herebelow, the generic notation size is used for the relevant dimension of the set to which parameters belong.
+
+These dimensions stand as follow
+
+\\(\mathrm{size}=T=168\\) : applicable to lower and upper bounds of constraints between hourly powers
+\\(\mathrm{size}=\frac{T}{7}=24\\) : applicable to lower and upper bounds of constraints between daily energies
+\\(\mathrm{size}=\frac{T}{168}=1\\) : applicable to lower and upper bounds of constraints between weekly energies
+
+Generic notations for binding constraints :
+
+| Notation | Explanation |
+| ------------ | ------------- |
+| \\(e \in E\\) | set of all grid interconnections and thermal clusters. \\(E = L \cup \Theta\\) |
+| \\(b \in B\\) | binding constraints |
+| \\(B_h \subset B\\) | subset of \\(B\\) containing the binding constraints between hourly powers |
+| \\(B_d \subset B\\) | subset of \\(B\\) containing the binding constraints between daily energies |
+| \\(B_w \subset B\\) | subset of \\(B\\) containing the binding constraints between weekly energies |
+| \\(\alpha_e^b \in \mathbb{R}\\) | weight of \\(e\\) (flow within \\(e\\) or output from \\(e\\)) in the expression of constraint \\(b\\) |
+| \\(o_e^b \in \mathbb{N}\\) | time offset of \\(e\\) (flow within \\(e\\) or output from \\(e\\)) in the expression of constraint \\(b\\) |
+| \\(u^b \in \mathbb{R}^{\mathrm{size}}\\) | upper bound of binding constraint \\(b\\) |
+| \\(l^b \in \mathbb{R}^{\mathrm{size}}\\) | lower bound of binding constraint \\(b\\) |
+
+### 3.6 Demand, security uplift, unsupplied and spilled energies
+| Notation | Explanation |
+| ------------ | ------------- |
+| \\(D_n \in \mathbb{R}^T\\) | net power demand expressed in node \\(n\\), including must-run generation |
+| \\(S_n \in \mathbb{R}^T_+\\) | demand security uplift to be faced in node \\(n\\), by activation of security reserves |
+| \\(\delta_n^+ \in \mathbb{R}^T\\) | normative unsupplied energy value in node \\(n\\). Value of lost load - VOLL |
+| \\(G_n^+ \in \mathbb{R}^T_+\\) | unsupplied power in the nominal state |
+| \\(\delta_n^- \in \mathbb{R}^T\\) | normative spilled energy value in node \\(n\\) (value of wasted energy) |
+| \\(G_n^- \in \mathbb{R}^T_+\\) | spilled power in the nominal state |
+
+
+## 4 Formulation of problem \\(\mathcal{P}^k\\)
+
+Superscript k is implicit in all subsequent notations of this section (omitted for simplicity's sake)
+
+## 4.1 Objective
+$$
+ \min\_{M\_\theta \in \mathrm{Argmin} \Omega\_{\mathrm{unit com}}}(\Omega\_{\mathrm{dispatch}})
+$$
+
+
+with
+
+
+\\(
+\displaystyle \Omega\_{\mathrm{dispatch}} = \Omega\_{\mathrm{transmission}}+\Omega\_{\mathrm{hydro}}+\Omega\_{\mathrm{thermal}}+\Omega\_{\mathrm{unsupplied}}+\Omega\_{\mathrm{spillage}}
+\\)
+
+
+\\(
+\displaystyle \Omega\_{\mathrm{transmission}}=\sum_{l \in L} \gamma_l^+ \cdot F_l^+ + \gamma_l^- \cdot F_l^-
+\\)
+
+
+\\(
+\displaystyle \Omega\_{\mathrm{hydro}} = \sum\_{n \in N} \sum\_{\lambda in \Lambda\_n} (\varepsilon\_\lambda + \varepsilon^*\_\lambda)\cdot(H\_\lambda - \rho\_\lambda \Pi\_\lambda + O\_\lambda) - \sum\_{n \in N} \sum\_{\lambda \in \Lambda\_n}\sum\_{q=1}^Q \eta\_{\lambda\_q} \mathfrak{R}\_{\lambda_q}
+\\)
+
+
+\\(
+\displaystyle \Omega\_{\mathrm{thermal}}=\sum\_{n \in N} \sum\_{\theta \in \Theta\_n} \chi\_\theta \cdot P\_\theta + \sigma\_\theta^+ \cdot M\_\theta^+ + \tau\_\theta \cdot M\_\theta
+\\)
+
+
+\\(
+\displaystyle \Omega\_{\mathrm{unsupplied}}=\sum\_{n \in N} \delta_n^+ \cdot G_n^+
+\\)
+
+
+\\(
+\displaystyle \Omega\_{\mathrm{spillage}}=\sum\_{n \in N} \delta_n^- \cdot G_n^-
+\\)
+
+\\(\Omega\_{\mathrm{unit com}}\\) is the expression derived from \\(\Omega\_{\mathrm{dispatch}}\\) by replacing all variables that depend on the system's state by their equivalent in the uplifted state.
+
+## 4.2 Constraints related to the nominal system state
+
+Balance between load and generation:
+
+First Kirchhoff's law:
+
+\\(
+\displaystyle \forall n \in N, \sum\_{l \in L\_n^+} F_l - \sum\_{l \in L\_n^-} F_l = \left( G\_n^+ + \sum\_{\lambda \in \Lambda\_n}(H\_\lambda - \Pi\_\lambda) + \sum\_{\theta \ \in \Theta\_n} P\_\theta\right)-(G\_n^-+D\_n)
+\\)
+
+
+On each node, the unsupplied power is bounded by the net positive demand:
+
+\\(
+\displaystyle \forall n \in N, 0 \leq G\_n^+ \leq \max(0, D_n)
+\\)
+
+On each node, the spilled power is bounded by the overall generation of the node (must-run + dispatchable power):
+
+\\(
+\displaystyle \forall n \in N, 0 \leq G_n^- \leq -\min(0, D_n) + \sum\_{\lambda \in \Lambda\_n}H\_\lambda + \sum\_{\theta \ \in \Theta\_n} P\_\theta
+\\)
+
+Flows on the grid:
+
+\\(
+\displaystyle \forall l \in L, 0 \leq F\_l^+ \leq C\_l^+ +(\overline{C}^{+}\_l - C\_l^+)x\_l
+\\)
+
+\\(
+\displaystyle \forall l \in L, 0 \leq F\_l^- \leq C\_l^- +(\overline{C}^{-}\_l - C\_l^-)x\_l
+\\)
+
+\\(
+\displaystyle \forall l \in L, F\_l = F\_l^+ - F\_l^-
+\\)
+
+Flows are bounded by the sum of an initial capacity and of a complement brought by investment
+
+Binding constraints :
+
+\\(
+\displaystyle \forall b \in B\_h, l^b \leq \sum\_{e \in E} \alpha\_e^b (F\_e)\_{\uparrow}^{o\_e^b} \leq u^b
+\\)
+
+\\(
+\displaystyle \forall b \in B\_d, \forall k \in \lbrace 0,\dots,6\rbrace, l^b \leq \sum\_{e \in E} \alpha\_e^b \sum\_{t \in \lbrace 1,\dots,24\rbrace} (F\_e)\_{\uparrow {24k+t}}^{o\_e^b} \leq u^b
+\\)
+
+\\(
+\displaystyle \forall b \in B\_w, l^b \leq \sum\_{e \in E} \alpha\_e^b \sum\_{t \in T} F\_{e\_t} \leq u^b
+\\)
+
+Reservoir-type Hydro power:
+
+The energy generated throughout the optimization period is bounded
+
+\\(
+\displaystyle \forall n \in N, \forall \lambda \in \Lambda\_n, \underline{W}\_{\lambda} \ leq \sum\_{t\in T} H\_{\lambda\_t} \leq \overline{W}\_{\lambda}
+\\)
+
+FIXME : RHS
+\\(
+\displaystyle \forall n \in N, \forall \lambda \in \Lambda\_n, \sum\_{t\in T} H\_{\lambda\_t} - \sum\_{t\in T} \rho\_t \Pi\_{\lambda\_t} = \overline{W}\_{\lambda}
+\\)
+
+Instantaneous generating power is bounded
+
+\\(
+\displaystyle \forall n \in N, \forall \lambda \in \Lambda\_n, \underline{H}\_{\lambda} \leq H\_{\lambda} \leq \overline{H}\_{\lambda}
+\\)
+
+Intra-daily power modulations are bounded
+
+\\(
+\displaystyle \forall n \in N, \forall \lambda \in \Lambda\_n, \forall k \in \lbrace 1, \ldots, 6 \rbrace, \frac{\max\_{t \in \lbrace 24k+1,\ldots, 24k+24 \rbrace} H\_{\lambda\_t}}{\sum\_{t \in \lbrace 24k+1,\ldots, 24k+24 \rbrace} H\_{\lambda\_t}} \leq r\_{\lambda}
+\\)
+
+Instantaneous pumping power is bounded
+
+\\(
+\displaystyle \forall n \in N, \forall \lambda \in \Lambda\_n, 0 \leq \Pi\_{\lambda} \leq \overline{\Pi}\_{\lambda}
+\\)
+
+Reservoir level evolution depends on generating power, pumping power, pumping efficiency, natural inflows and overflows
+
+Reservoir level is bounded by admissible lower and upper bounds (rule curves)
+
+Thermal units :
+
+Power output is bounded by must-run commitments and power availability
+
+The number of running units is bounded
+
+Power output remains within limits set by minimum stable power and maximum capacity thresholds
+
+Minimum running and not-running durations contribute to the unit-commitment plan. Note that this modeling requires that one at least of the following conditions is met:
+
+### 4.3 Constraints related to the uplifted system state (activation of security reserves)
+
+All constraints to previously defined for regular operation conditions are repeated with replacement of all variables by their twins when they exist.
+
+Besides, in the expression of constraints , all occurrences of are replaced by
+
+## 5 Formulation of problem
+
+### 5.1 Objective
+FIXME
+
+### 5.2 Constraints
+
+## 6 Antares as a SCOPF ("FB model")
+
+When problems and do not include any instance of so-called ";binding constraints"; and if no market pools are defined, the flows within the grid are only committed to meet the bounds set on the initial transmission capacities, potentially reinforced by investments (problem ).In other words, there are no electrical laws enforcing any particular pattern on the flows, even though hurdles costs and may influence flow directions through an economic signal.
+
+In the general case, such a raw backbone model is a very simplified representation of a real power system whose topology and consistency are much more complex. While the full detailed modeling of the system within Antares is most often out of the question, it may happen that additional data and/or observations can be incorporated in the problems solved by the software.
+
+In a particularly favorable case, various upstream studies, taking account the detailed system characteristics in different operation conditions (generating units outages and/or grid components outages N, N-1 , N-k,…) may prove able to provide a translation of all relevant system limits as a set of additional linear constraints on the power flowing on the graph handled by Antares.
+
+These can therefore be readily translated as ";hourly binding constraints";, without any loss of information. This kind of model will be further referred to as a "FB model". Its potential downside is the fact that data may prove to be volatile in short-term studies and difficult to assess in long-term studies.
+
+## 7 Antares as a SCOPF ("KL model")
+
+When a full FB model cannot be set up (lack of robust data for the relevant horizon), it remains possible that classical power system studies carried on the detailed system yield sufficient information to enrich the raw backbone model. An occurrence of particular interest is when these studies show that the physics of the active power flow within the real system can be valuably approached by considering that the edges of behave as simple impedances .This model can be further improved if a residual (passive) loop flow is to be expected on the real system when all nodes have a zero net import and export balance (situation typically encountered when individual nodes actually represent large regions of the real system). This passive loop flow should therefore be added to the classical flow dictated by Kirchhoff's rules on the basis of impedances . This model will be further referred to as a "KL model". Different categories of binding constraints, presented hereafter, make it possible to implement this feature in and
+
+### 7.1 Implementation of Kirchhoff's second law
+
+The implementation ofKirchhoff's second law for the reference state calls for the following additional hourly binding constraints:
+
+### 7.2 Implementation of a passive loop flow
+
+In cases where a residual passive loop flow should be incorporated in the model to complete the enforcement of regular Kirchhoff's rules, the binding constraints mentioned in 7.1 should be replaced by:
+
+### 7.3 Modelling of phase-shifting transformers
+
+In cases where the power system is equipped with phase-shifting transformers whose ratings are known, ad hoc classical power studies can be carried out to identify the minimum and maximum flow deviations and phase-shift that each component may induce on the grid. The following additional notations are in order:
+
+The enhancement of the model with a representation of the phase-shifting components of the real system then requires to re-formulate as follows the binding constraints defined in 7.2:
+
+### 7.4 Modelling of DC components
+
+When the power system graph contains edges that represent DC components, additional notations need be defined:
+
+The proper modeling of the system then requires that all constraints identified in 7.1, 7.2, 7.3 be formulated using notations instead of
+
+### 7.5 Implementation of security rules N-1,..., N-k
+
+Upstream power system classical calculations on the detailed system are assumed to have provided appropriate estimates for line outage distribution factors (LODFs) for all components involved in the contingency situations to consider. The following additional notations will be further used:
+
+The implementation of security rules for the chosen situations requires the following additional binding constraints:
+
+## 8 Antares as a SCOPF (";KL+FB model";)
+
+If the information context is rich enough, it is possible to set up a hybrid model based on both previous approaches: on the one hand, a ";KL layer"; makes use of the best available estimates for grid impedances and loop flows, so as to instantiate physically plausible flow patterns; on the other hand, a ";FB layer"; sets multiple kinds of limits on the admissible flow amplitudes, as a result of various operation commitments.
+
+To work appropriately, such a hybrid model needs an additional auxiliary layer that performs a mapping between the two ";twin"; FB and KL grid layers.
+
+## 9 Miscellaneous
+
+### 9.1 Modelling of generation investments in
+
+The assessment of the desired level of expansion of any segment of the generating fleet can be carried out with a model in which the potential reinforcements of the fleet are assumed to be actually commissioned from the start but located on virtual nodes connected to the real system through virtual lines with a zero initial capacity. Relevant generation assets costs and capacities should then be assigned to the virtual connections, and the investment in new generation can be optimized ";by proxy"; through the identification of the optimal expansion of the virtual connections.
+
+### 9.2 Modelling of pumped storage power plants
+
+A number of specific equipments, as well as particular operation rules or commercial agreements, can be modelled with appropriate use of binding constraints. A typical case is that of a pumped storage power plant operated with a daily or weekly cycle. Such a component can be modelled as a set of two virtual nodes connected to the real grid through one-way lines. On one node is attached a virtual load with zero VOLL, which may absorb power from the system. On the other node is installed a virtual generating unit with zero operation cost, which may send power to the system. The flows on the two virtual lines are bound together by a daily or weekly constraint (depending on the PSP cycle duration), with a weight set to fit the PSP efficiency ratio. Besides, time offsets may be included in the constraints to take into account considerations regarding the volume of the PSP reservoir (additional energy constraint).
+
+[1](#sdfootnote1anc) The development of the product is a continuous process resulting in the dissemination of a new version each year. As a rule, version N brings various improvements on the code implemented in version N-1 and enhances the functional perimeter of the tool. This document presents the general optimization problem formulation as it is formalized so far in the last version of disseminated version of **Antares\_Simulator** (V7).
+
+[2](#sdfootnote2anc) Reference guide , section « optimization preferences : ";export mps problems";
+
+[3](#sdfootnote3anc) For the sake of simplicity, the **Antares\_Simulator** application will be further denoted « Antares »
+
+[4](#sdfootnote4anc)See «hydro» sections of the General Reference Guide (";hydro"; standing as a generic name for all types of energy storage facilities)
+
+[5](#sdfootnote5anc)This does not actually limit the model's field of application: all datasets can easily be put in a format that meets this commitment
+
+[6](#sdfootnote6anc) FB stands for « flow-based », denomination used in the framework given to the internal electricity market of western Europe
+
+[7](#sdfootnote7anc) KL stands for ";Kirchhoff- and-Loop";. Such a model was used in the European E-Highway project ([http://www.e-highway2050.eu](http://www.e-highway2050.eu/))
+
+[8](#sdfootnote8anc) A common situation is that KL and FB are defined at different spatial scales and describe different topologies: the KL layer has typically a fairly large number of small-sized regions, while the FB layer consists of fewer wide market zones. The role of the auxiliary layer is to implement the appropriate relationship between physical regions and trade zones.
+
+Copyright © RTE 2007-2019 – Version 7.1.0
+
+Last Rev : M. Doquet - 16 OCT 2019
diff --git a/docs/reference-guide/Antares_Implementation.png b/docs/reference-guide/Antares_Implementation.png
new file mode 100644
index 0000000000..c1caaf4ee0
Binary files /dev/null and b/docs/reference-guide/Antares_Implementation.png differ
diff --git a/docs/reference-guide/Antares_Process.png b/docs/reference-guide/Antares_Process.png
new file mode 100644
index 0000000000..60500cd411
Binary files /dev/null and b/docs/reference-guide/Antares_Process.png differ
diff --git a/docs/reference-guide/Standard_Implementation.png b/docs/reference-guide/Standard_Implementation.png
new file mode 100644
index 0000000000..f5a9cd0a61
Binary files /dev/null and b/docs/reference-guide/Standard_Implementation.png differ
diff --git a/docs/stylesheets/extra.css b/docs/stylesheets/extra.css
new file mode 100644
index 0000000000..f778681ac1
--- /dev/null
+++ b/docs/stylesheets/extra.css
@@ -0,0 +1,11 @@
+[data-md-color-scheme="antares"] {
+ --md-primary-fg-color: #002a5e;
+ --md-primary-fg-color--light: #00a3ca;
+ --md-primary-fg-color--dark: #112446;
+ --md-typeset-a-color: #00a3ca; /* text link color*/
+ --md-accent-fg-color: #ff9800; /* link color on hover*/
+}
+[data-md-color-scheme="slate"] {
+ --md-hue: 213; /* [0, 360] */
+ --md-accent-fg-color: #ff9800;
+}
diff --git a/mkdocs.yml b/mkdocs.yml
new file mode 100644
index 0000000000..7fa5e8c149
--- /dev/null
+++ b/mkdocs.yml
@@ -0,0 +1,68 @@
+docs_dir: docs
+site_name: Antares Simulator Documentation
+repo_url: https://github.com/AntaresSimulatorTeam/Antares_Simulator
+edit_uri: edit/doc/docs/
+
+theme:
+ name: material
+ logo: assets/logo.png
+ favicon: assets/Icone.png
+ prev_next_buttons_location: none
+ features:
+ - navigation.instant
+ - navigation.top
+ - navigation.expand
+ # - navigation.sections
+ # - header.autohide
+ # - toc.separate
+ palette:
+ - media: "(prefers-color-scheme: light)"
+ scheme: antares
+ toggle:
+ icon: material/toggle-switch-off-outline
+ name: Switch to dark mode
+ - media: "(prefers-color-scheme: dark)"
+ scheme: slate
+ toggle:
+ icon: material/toggle-switch
+ name: Switch to light mode
+
+nav:
+ - 'Home': index.md
+ - 'Antares ecosystem' : 'https://antares-doc.readthedocs.io'
+ - 'User guide':
+ # - 'Reference guide': 'reference-guide/1-reference-guide.md'
+ - 'Optimisation problem' : 'reference-guide/2-modeling.md'
+ - 'Build':
+ - 'Introduction': 'build/0-INSTALL.md'
+ - 'Windows': 'build/INSTALL-windows.md'
+ - 'Ubuntu': 'build/INSTALL-ubuntu.md'
+ - 'CentOS': 'build/INSTALL-centos.md'
+ - 'OR-tools integration' : 'build/ortools-integration.md'
+ - 'Changelog': 'CHANGELOG.md'
+
+plugins:
+ - search
+
+extra_css:
+ - stylesheets/extra.css
+
+extra_javascript:
+ - https://code.jquery.com/jquery-3.6.0.min.js
+ - https://polyfill.io/v3/polyfill.min.js?features=es6
+ - https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.0/MathJax.js?config=TeX-AMS-MML_HTMLorMML
+
+markdown_extensions:
+ - attr_list
+ - toc:
+ permalink: true
+ toc_depth: 3
+ - pymdownx.emoji:
+ emoji_index: !!python/name:materialx.emoji.twemoji
+ emoji_generator: !!python/name:materialx.emoji.to_svg
+ - admonition
+ - pymdownx.details
+ - pymdownx.superfences
+ - pymdownx.tabbed
+
+copyright: Copyright © 2007 - 2021 RTE
\ No newline at end of file
diff --git a/readthedocs.yml b/readthedocs.yml
new file mode 100644
index 0000000000..e6c09bb5bd
--- /dev/null
+++ b/readthedocs.yml
@@ -0,0 +1,9 @@
+version: 2
+
+python:
+ version: 3.7
+ install:
+ - requirements: requirements-doc.txt
+
+mkdocs:
+ configuration: mkdocs.yml
diff --git a/requirements-doc.txt b/requirements-doc.txt
new file mode 100644
index 0000000000..80491f6f5b
--- /dev/null
+++ b/requirements-doc.txt
@@ -0,0 +1,4 @@
+mkdocs
+mkdocs-material
+sphinx
+myst-parser
diff --git a/src/changelog.mdown b/src/changelog.mdown
deleted file mode 100644
index a96e1bbb55..0000000000
--- a/src/changelog.mdown
+++ /dev/null
@@ -1,1256 +0,0 @@
-Antares Changelog
-=================
-
-v8.1.0 (09/2021)
---------------------
-
-### New features
- - Allow up to 9 RES groups (off-shore wind, on-shore wind, rooftop solar, PV solar, etc.) as opposed to wind and solar previously. This allows the user to distinguish between more renewable energy sources. When creating a new study, renewable generation modelling is set to "clusters" by default. This change does not affect opening an existing study. Note that TS generation is not available for these new RES groups.
- - Add 3 thermal groups, named other, other 2, other 3 and other 4.
-
-### Bug fixes
- - When a binding constraint is marked as skipped in the GUI, disable it in the solver #366
-
-### GUI
- - Keep selection on thermal/renewable cluster when its group changes #360
- - Dialogs "Thematic trimming" and "User playlist" are now resizable
-
-### For developers
- - Add non-regression tests on each release
- - Fix vcpkg on Github Actions
- - Add build cache for Github Actions to speed up the build (Linux only)
-
-v8.0.3 (05/2021)
---------------------
-
-### Bug fixes
-
- - Fix calculation of average for variable "congestion probability"
- - Fix NODU when unit number is not an integer i.e has decimals
- - GUI: allow decimal nominal capacity for thermal clusters
- - GUI: Linux: use xdg-open to open pdf files instead of gnome-open
-
-### For developers
-
- - Remove code related to licence management
- - Remove openssl and libcurl dependencies
- - Remove dead code
-
-v8.0.2 (04/2021)
---------------------
-
-### Bug fixes
-
- - Fix GUI freeze when area color is changed but user don't validate new color
- - Correction of MC year weight use for PSP and MISC NDG
-
-v8.0.1 (03/2021)
---------------------
-### Features
-
- - Add "Continue Offline" button at startup if antares metric server is unreachable
-
-### Bug fixes
-
- - Error with hydro start when using scenario playlist and stochastic TS refresh span
- - Files needed for antares-xpansion not exported when using scenario playlist with first year disabled
- - Correction of crash if user define a stochastic TS refresh span of 0 : minimum value is now 0
- - Correction of MC years playlist weight write when sum of weight was equal to number oy years (no MC years playlist export in .ini)
-
-### For developers
-
- - Add a GitHub action to check if branch name will launch CI
- - Add shared dll in windows .zip archive
-
-v8.0.0 (03/2021)
---------------------
-
-### Features
-
- - OR-Tools integration :
- - add command line option in antares-solver to define OR-Tools use and OR-Tools solver (option --use-ortools and --ortools-solver='solver')
- - add GUI option in run simulation to define antares-solver launch with OR-Tools option
-
-- Add advanced hydro allocation feature. The default and existing behavior is to accomodate the guide curves, the new behavior is to maximize generation, even if it means that the reservoir level goes beyond the guide curves.
-
-- Add indication on how to disable anonymous metrics
-
- - antares-xpansion :
- - add option `include-exportstructure` in `generaldata.ini` to export .txt files needed for antares-xpansion
-
- - Scenario builder and hydraulic level :
- Adding an hydraulic starting level tab in the scenario builder.
- For each MC year and area, a starting level can be defined, that is a 0-100 value.
- When the scenario builder is enabled, these levels get priority upon hot-start mode.
-
- - Binding constraints (BC) and thermal clusters :
- If a must-run or disabled cluster is involved in a binding constraint :
- - the cluster is marked as "N/A" in the BC formula (GUI > Binding constraint > Summary)
- - the cluster is marked as must-run/disabled in the Weights or Offsets tabs.
-
- If a BC involves only zero weighted clusters/links or must-run/disabled clusters, the BC is :
- - marked with a red bullet in the Summary tab
- - marked as Skipped in the Weights and Offsets tabs
-
- - MC Scenario Playlist :
- Add possibility to define a weight for each MC years in the synthetis results.
- See : GUI > Configure > MC scenario playlist.
- By default, a MC year's weight is 1, but can be set by user to more or less.
- After simulation, the MC year have a contribution to averages or standard deviations in synthesis results
- depending on the weight it was given.
-
-### Bug fixes
-
- - Selecting an area and then, from the inspector, trying to select a thermal cluster or a link of this area in the dependencies
- section causes a crash. The inspector's cluster/link selection was removed.
- - Scenario builder :
- - It makes no sense for the user to access the scenario builder Configure menu item whereas the Building mode parameter is set
- to Automatic or Derated. In the previous cases, the Configute menu item is disabled.
- - If a disabled thermal cluster is given a time series number in a non active rule of the scenario builder, a warning should not be
- triggered. If the disabled cluster is given a number for many MC years in the active rule, a single summary warning should be raised,
- not a warning per year.
-
-### For developers
-
- - External dependencies :
- - use of new repository [antares-deps](https://github.com/AntaresSimulatorTeam/antares-deps) for external dependencies compilation
-
-- Fix several compilation warnings
-- Remove unused `COUT_TRANSPORT` constant
-- Add code formatting with clang-format
-- Remove PNE dead code
-
-- docker image :
- - create of dockerfile for docker image creation
-
- - continuous integration :
- - use docker images in CI
- - use of antares-deps release artifact in CI
- - push of docker image to dockerHub in [antaresrte/rte-antares repository](https://hub.docker.com/repository/docker/antaresrte/rte-antares)
- - add Centos7 support
-
- - Unit tests :
- - Adding an end-to-end test in memory (see simple-study.cpp) :
- This test calls high level functions to build a simple study and runs it.
- It then checks if some elements of results match associated expected values.
- During this process, file system is not involved : everything takes place in RAM
- - Adding pytest scripts to check reference output values
- - Add pytest scripts related to unfeasible problems
-
-v7.2.0 (06/2020)
---------------------
-
-### Features
-
- - Simulation dashboard: A new "Geographic Trimming" option
- is now available in the "Configure" menu. This option makes
- it possible to filter the simulation's output content so as
- to include only results regarding Areas and Links of interest
-
- - Optimization: a new parameter "Unfeasible Problems Behavior"
- is available in the "advanced preferences" section of the
- "Configure" menu, with four possible values:
- (Error Dry, Error Verbose, Warning Dry, Warning Verbose)
- The first two options make the simulation stop right after
- encountering the first mathematically unfeasible problem, if any
- The last two options make the simulation skip all unfeasible
- problems, if any
- "Verbose" options print faulty problems in the “mps” format
- "Dry" options only report the time frame (MC year, week) for which
- an unfeasible problem was detected
-
- - Compilation and cmake tree :
- Updates were made for more modern CMake use.
- Git submodules (extern dependencies : curl, openssl, wxwidget) are no more in use.
- These external dependencies can be retrieved :
- - either from a library manager : vcpkg for Windows, classic package
- repositories for Linux. With this way to proceed, an installation of external
- dependencies is required once for all.
- - or thanks to an automatic download : at Antares' cmake configure step,
- all needed downloads, compilation and installation are done.
-
- - Unit tests :
- unit tests around class Matrix are now available.
- They can be compiled (on demand) during Antares' cmake build step
- and run either with ctest or in the classic way.
- Boost.Test is required and can be priorily retrieved and installed in the
- same way as the other external dependencies.
-
- - Continuous integration : yaml files for github actions allow the run of
- all build chain and unit tests on several environment (Windows and Ubuntu).
- The 2 ways of getting external dependencies are also tested.
-
- - Documentation: updated reference guide
-
- - Usage metrics: added reference key for this version
-
-### Bug fixes
-
- - GUI of the "Thematic trimming" option: Window size is naturally readjusted
- to improve readability by upgrading wxwidgets (3.1.3 and above).
-
- - Auxiliary "Batchrun" tool: two options previously missing in the
- command line syntax have been introduced and now make it possible
- to launch a sequence of simulations to run in parallel
-
-v7.1.0 (12/2019)
---------------------
-
-### Features
-
- - Simulation Dashboard: A new option "Thematic Trimming"
- is available in the "Output Profile" Section. This option
- now makes it possible to define precisely the content of
- output files so as to include only variables of interest
-
- - Optimization: a new parameter "Hydro Pricing mode" is
- available in the "advanced parameters" section, with two
- possible values (fast, accurate):
- In mode "fast", water value is, in the course of optimization,
- taken to be constant throughout the (daily or weekly)
- optimization period, and equal to that found for the exact
- day and level at which the optimization begins. Water values
- are reassessed afterwards, for each hour, on the basis of
- relevant time and level.
- In mode "accurate", the variations of water value along with
- the reservoir level are taken into account in the course of
- the (weekly) optimization. Reference (level-dependent) values
- are those attached to the end of the week. Water values
- are reassessed afterwards, for each hour, on the basis of
- relevant time and level.
-
- - Documentation: updated reference guide
-
- - Documentation: updated optimization problem formulation
- (modelling of hydro pricing options)
-
- - Usage metrics: added reference key for this version
-
-### Bug fixes
-
- - Output file "mc-all/grid/digest.txt": replaced "NaN" values
- by zeroes, where appropriate
-
- - Output file "mc-all/grid/digest.txt": replaced "0" values
- by N/A, where appropriate (especially, hydro reservoir-related
- variables, when the "reservoir management" area attribute is set
- to "No")
-
- - Output GUI: fixed a display bug regarding missing items in the
- "links" panel, in the case where simulation parameters are set
- so as not to produce synthetic results
-
- - Links GUI: improved integrity control regarding hurdle costs.
- Negative values are allowed in either direct or indirect
- orientation, provided that the sum of both is non-negative
-
- - General GUI: removed redundant items and renamed option menu
- "Geographic District" as "Regional District" to avoid confusion
- with new "Trimming" options
-
- - Output: when simulation results are trimmed so as not to produce
- any data for given Areas or Links, avoid creation of empty folders
- named after said Areas or Links
-
-v7.0.1 (04/2019)
---------------------
-
-### Features
-
- - Time-series analysis: in "detrended mode", extended perimeter
- to raw data including periods with no meaningful signal
- (e.g. solar production at night)
- - Hydro-storage modelling: added ability to optimize pumping along
- with generation in mode "use heuristic target without leeway"
-
-v7.0.0 (12/2018)
---------------------
-
-### Features
-
- - GPL release: updated companion files (README,...)
- - GPL release: updated project Icons
- - GPL release: insertion of license headers
- - GPL release: translation of comments
- - GPL release: removal of license control
- - GPL release: code restructuring to separate Antares and Sirius
- - Examples library: upgraded and added 16 new examples
- - Documentation: updated reference guide
- - Documentation: updated map editor guide
- - Documentation: updated optimization problem formulation
- - Documentation: updated examples library
-
-v7.0.0-rc (12/2018)
---------------------
-
-### Features
-
- - Improved code for linux compilation with gcc 7
-
-### Bugs
-
- - Fixed various issues in GUI
- - Fixed RHS of constraints generated by the KCG when
- min and max values of PST settings are strictly equal
- and constraints are generated for the whole year
-
-v6.5.1 (11/2018)
-----------------
-
-### Bugs
-
- - Fixed index in hydro heuristic engine
- - Hydro GUI: added scrollbars for correct display on laptops
- - Output: improved presentation of results for incomplete calendar-based weeks
- - Kirchhoff's constraint generator: fixed several GUI issues
- - Districts GUI: improved syntax control
-
-v6.5.0 (11/2018)
-----------------
-
-### Features
-
- - Implementation of Kirchhoff's laws (DC approximation),
- modeling of phase-shifters and representation of passive
- loop flows (to account for on highly reduced gris): a
- dedicated Kirchhoff's constraints generator is now available
- It makes use of both classical input data (impedances)
- and new input data. Its results are specific binding
- constraints whose names begin by @UTO-, storable in the
- INPUT folder after user's validation ("save")
-
- New or modified input data for link L (8760 hourly values):
- Impedances (moved from col.3 to col.5)(Ohms at ref. voltage U)
- Loop flow (passive) (MW)
- Min Tap of phase-shifter (MW*Ohms/U2 along any AC cycle including L)
- Max Tap of phase-shifter (MW*Ohms/U2 along any AC cycle including L)
- New link parameters (one value)
- Asset type (AC,DC,Gas,Virtual,Other) : KCG deals only with AC links
- "account for loop flow" toggle
- "tune PST" toggle
- KCG generating directives:
- Working map to use for generation
- Calendar to use for constraints activation (relaxation outside)
- Status of passive loop flow in constraints RHS (included or not)
- Status or PST settings in constraints RHS (included or not)
- Auto-check of nodal loop flow balance (activated or not)
- Definition of the "infinite" to use for constraints relaxation
- KCG results:
- For AC Links involved in the generation process: The KCG sets the
- values of the two input data toggles related to loop flows and
- PST settings, in accordance with the current generation directives
-
- Identification of an optimal (minimum-weight) cycle basis for the
- formulation of constraints
-
- Generation of all relevant constraints (equality, inequalities, with
- or without relaxation)
-
- - Reservoir-type hydro and other energy storage facilities:
- interface, input and output data structure, functionalities,
- have been completely redesigned. As a consequence, a number
- of new items (variables & parameters) are introduced in both
- input and output, while a few input variables are redefined
- or deprecated:
-
- Deprecated hydro variables:
- Pmax hydro "min", Pmax hydro "max"
- Redefined hydro variables and parameters:
- Hydro-storage time-series : redefined at the daily scale
- Bounds for Reservoir levels: redefined at the daily scale
- Res.level initialization date: redefined at the monthly scale
- New hydro variables and parameters:
- Input : max daily hydro generating energy
- max daily hydro pumping energy and power
- monthly-to-daily inflow breakdown pattern
- water value (time, level)
- modulation of max generating power (level)
- modulation of max pumping power (level)
- pumping efficiency
- +many "storage management options" parameters
- Output: Reservoir level (H.LEV)
- Water value (H.VAL)
- Pumping power (H.PUMP)
- Natural Inflow (H.INFL)
- Forced Overflow (H.OVFL)
- Cost of Gen+Pumping (H.COST)
- Optimization preferences:
- "Hot/Cold start" (year N may start or not at the final N-1 level)
-
- - GUI: Districts may now be defined from within the interface
- (notepad tab connected to the Inspector's clipboard)
-
- - Time-series generation (solar, wind, load) : increased speed
- when "high accuracy" option is selected, in the special case
- where all diffusion processes produce "Normal" variables
-
- - Example library: upgraded to 6.5 (without extension)
-
-### Bug fixes
-
- - Time-series generation: the storage (Input folder)
- of time-series generated for thermal clusters either in the
- "disabled" or "must-run" state did not work properly
-
- - Time-series analysis: when short- and long-term levels
- defined for auto-correlation assessment are identical, the
- analyzer now performs a pure exponential fitting
-
- - Time-series analysis: monthly time-series containing no
- non-zero value are no longer rejected by the analyzer
-
- - Output: the link-variable "MARG.COST" was rounded to an integer
- value (changed to 2 decimal accuracy)
-
-
-v6.1.3 (06/2018)
-----------------
-
-### Features
-
- - Output: added a new file at the root of simulation results,
- displaying a short summary of the overall system economic
- performance throughout all Monte-Carlo years
-
- - Log file: added new info messages on the size of optimization
- problems
-
- - Updater (standalone): added new options and improved
- help messages
-
- - Expansion mode: presolve stage replaced by hot start
-
-### Bug fixes
-
- - Simulation: In the "accurate" Unit Commitment mode, the
- optimization preference "thermal Clusters Min Up/Down Time"
- can now be turned to "ignore"
-
- - Simulation: removed remaining debug traces
-
- - Simulation: zero-reset on interconnection marginal costs
- was sometimes missing in optimization final stage
-
- - Example library : upgraded to 6.1 and extended
-
-
-v6.1.2 (11/2017)
-----------------
-
-### Features
-
- - Solver, Simplexe package: Improvement of the Scaling stage
- (Matrix, right hand side, costs)
-
-
-v6.1.1 (11/2017)
-----------------
-
-### Features
-
- - Solver: Light changes in Presolve stage
-
-
- v6.1.0 (09/2017)
-----------------
-
-### Features
-
- - GUI and simulation: "binding constraints" objects may now involve
- not only flows on interconnections but also power generated from
- thermal clusters. Alike flows, generation from thermal clusters may
- be handled either on an hourly, daily or weekly basis and may be
- associated with arbitrary offsets (time-lags expressed in hours).
-
-
-v6.0.6 (07/2017)
-----------------
-
-### Features
-
- - GUI: Binding constraint parameters tables (weights and offsets) are trimmed
- line-wise so as to fit exactly with the content of the selected working map
-
- - Solver: strenghtening of the final admissibility check step in the "accurate"
- commitment mode
-
-
-
-v6.0.5 (07/2017)
-----------------
-
-### Bug fixes
-
- - Solver: Pruning of redundant messages in simulations launched from command line
-
- - Solver: Removal of misprints in command line help messages
-
- - Files: Fixed issues (detected as of 6.0.1) regarding storage of thermal time-series files
-
- - Study Cleaner: Unwarranted removal of the graphic multi-map lay-out could occur when
- cleaning datasets (detected as of 6.0.0)
-
-
-v6.0.4 (06/2017)
-----------------
-
-### Bug fixes
-
- - GUI: The "variable per variable" view of the output files allows
- to display the power generated by each thermal cluster
-
- - Simulation: Negative "ROW Balance" is properly included in
- unsupplied energy allowances
-
-
-v6.0.3 (06/2017)
-----------------
-
-### Features
-
- - GUI: The number of system maps that could be stored in a given study
- was limited to 19. This number is now unbounded.
-
-### Bug fixes
-
- - GUI: The list of thermal clusters displayed for a given Area in the
- current map was sometimes wrongly initialized (Area considered
- selected though not explicitly clicked on yet)
-
- - GUI: The order in which binding constraint terms are shown in the
- "summary" Window could depend on the execution platform used
-
- - GUI: The Antares study icon could not be properly copied in some
- circumstances
-
-
-v6.0.2 (06/2017)
-----------------
-
-### Features
-
- - Optimization : To help discriminate between equivalent economic
- solutions, random noises on hydro hourly prices are more regularly
- spread out (absolute values) in the interval (5 e-4 ,1 e-3)Euros/MWh
-
-### Bug fixes
-
- - Simulation : The identification of the Monte-Carlo year numbers
- in which the smallest/greatest values of random variables are
- reached could be ambiguous when identical results are found for
- two years ore more.
-
-
-v6.0.1 (05/2017)
-----------------
-
-### Features
-
- - Thermal Time-series generation: Data regarding all thermal clusters
- are generated and stored in the same way, regardless of their activity
- status (unabled/disabled). This makes easier to check data consistency
-
- - Simulation: Upper bounds for spilled power and unsupplied power are
- actually set to their maximum theoretical value(i.e. if economic
- conditions make it justified: spill all power or shed all demand)
- So far, spillage of power that could be absorbed by the local demand
- was not allowed
-
- - Simulation: a silent "Expansion" mode has been added to the regular
- modes "Economy/Adequacy/Draft". The three differences with the
- "Economy" mode are:
- a) In "accurate" unit commitment, integrity constraints are relaxed
- in the core optimization problem.
- b) Day-ahead reserve is no more subtracted from the initial demand
- to get back to "standard" conditions
- c) The values of all optimal criteria are printed in ad hoc files
- The use of this mode should be restricted to well-designed scripted
- automatic simulation sequences taking into account the simplifications
- listed above
-
-
-v6.0.0 (04/2017)
-----------------
-
-### Features
-
- - GUI: A new interface makes it possible to define several views (maps) of
- the Power System modelled in an Antares study. These maps are meant to give
- the user the ability to set different layouts in which each Antares Area
- or Link can be either shown or remain hidden. Accordingly, all input and
- output data windows can now adapt the information displayed so as to match
- exactly the content of any given map. Copy/Paste functions have been
- extended so as to work between different maps of different studies opened
- in multiple Antares sessions
-
- - Simulation: Introduction of a flexible multi-threaded mode for the processing
- of heavy problems: Antares "Monte-Carlo years" can be be distributed on a
- number of CPU cores freely set by the user. This parameter appears as a new
- tunable item of the "advanced parameters" list attached to any Antares Study.
- Five values are available in the [1, N] interval, N being the number of CPU
- cores of the machine (virtual or physical) Antares is run on
-
- - License control through the internet: a new system has been developed for
- accommodating situations where users wish to operate Antares on a large
- fleet of machines among which a limited set of commercial license tokens
- can float freely
-
- - Data organizer: Antares studies often include a great number of files of
- all sizes, which may take long to process when multiple copies are needed.
- Likewise, the management of the HDD space required for regular storage of
- all of the studies involved in a complex study workflow may turn out to be
- a demanding and heavy task. To save both time and hardware resources, the
- Antares Data Organizer, now provided as a companion tool to the Antares
- Simulator, brings the ability to schedule basic data management tasks
- such as study archiving/expansion (use of a specific compressed format),
- copy to backup folders, registering of studies and archives in catalogues.
-
-
-v5.0.9-SE (04/2017)
-----------------
-
-### Bug fixes
-
- - Random noises on thermal clusters costs now include the zero-cost
- "must-run" clusters (as a consequence, noises assumptions do not vary
- with the cluster status)
-
- - Fixing an initialization issue that could sporadically affect the
- minimum number of committed thermal units (+1 or -1 deviation,
- "accurate" mode only)
-
-v5.0.7-SE (04/2017)
-----------------
-
-### Features
-
- - License control : management of SSL certificates encrypted through SHA-256 algorithm
-
-
-v5.0.7 (12/2016)
-----------------
-
-### Bug fixes
-
- - Fixing a packaging error
-
-
-v5.0.6 (12/2016)
-----------------
-
-### Bug fixes
-
- - Results processing: For full "must-run" thermal clusters, the NODU variable
- could be wrongly assessed in the "accurate" unit commitment simulation mode
-
- - GUI: when the scenario builder feature is active, saving right after deleting
- a thermal cluster could result in a partial dataset corruption (references to
- the deleted object were kept alive in the scenario builder context)
-
-
-### Features
-
- - Unsupplied energy control: if the actual economic optimization requires it, load
- shedding is now allowed to occur in areas where the available thermal generation
- is higher than the local demand (e.g. if local VOLL < local thermal costs)
-
- - Linear solver, hot starting of weekly problems: in the "fast" unit commitment
- mode, optimal bases are flushed at the beginning of each Monte-Carlo year. This
- comes as a pre-requirement for the next versions of Antares, which will be
- fully multi-threaded
-
- - Simulation results: code segments processing all variables attached to spatial
- aggregates, and the variable representing the number of running thermal units
- on the first hour of the year, were re-written to be compatible with the next
- versions of Antares, which will be fully multi-threaded
-
-
-
-v5.0.5 (08/2016)
-----------------
-
-### Bug fixes
-
- - No-Load Heat costs and Start-up costs: in the "fast" unit commitment options,
- the result was slightly below the actual optimal possible cost for some
- datasets (i.e. datasets in which the thermal cluster coming last in alphabetic
- order had a minimum stable power equal to zero).
-
- - Spilled energy control: the three parameters defining how energy in excess should
- be split between the different possible sources when there is a choice to make
- can work properly again (feature inhibited in previous 5.0.x versions)
-
-
-### Features
-
- - License control throughout the internet: all combinations of UTF8 characters can
- now be used within proxy ids and passwords
-
- - Economic optimization: in an area where the amount of available thermal power
- exceeds that of load, the fact that the demand should necessarily be served
- is locally expressed as a constraint of the optimization problem (LOLE=0)
-
-
-v5.0.4 (05/2016)
-----------------
-
-### Bug fixes
-
- - Errors occured on loading the "min gen modulation" time-series of thermal clusters
-
-### Features
-
- - Better estimate of the number of thermal units dispatched in "fast" unit commitment mode
- - Nodal Marginal Prices and Marginal yield on interconnections are now available in
- "accurate" unit commitment mode
- - Binding constraints including offset parameters: unbounded positive or
- negative values can be used for all classes of constraints (hourly, daily, weekly)
-
-
-v5.0.3 (05/2016)
-----------------
-
-### Bug fixes
-
- - Crashes occured when the "full must-run status" parameter was set on
- "true" for thermal clusters
-
-
-v5.0.2 (04/2016)
-----------------
-
-### Bug fixes
-
- - Removed debug information that should not be displayed in release mode
-
-### Features
-
- - The optimization criterion used to assess the hydro energies to generate throughout
- each month incorporates heavier penalization terms for the 12 deviations from the
- theoretical monthly targets (formerly, only the largest deviation was penalized).
-
-
-v5.0.1 (04/2016)
-----------------
-
-### Bug fixes
-
- - Adequacy mode: fixed a memory allocation bug that forced the post-simulation
- output files processing to be interrupted
-
- - In the previous version, additional logs were added. That could lower the simulation
- performances in some cases. This problem is now solved.
-
-
-v5.0.0 (03/2016)
-----------------
-
-### Bug fixes
-
- - GUI, system map: copy /paste of binding constraints could alter the activity status or
- the names of the duplicated binding constraints in some instances
-
- - GUI, system map: some conflicts in copy/paste actions were not always properly raised
- (e.g. attempt to copy three nodes and paste them on two other nodes)
-
- - Thermal clusters: Improved checking of time-series generation parameters (improper use of a
- nominal capacity modulation factor lower than the minimum stable power is no longer possible)
-
- - Thermal clusters: Improved checking of ready-made time-series. If the user-chosen time-series
- are not consistent with the parameters set in the GUI, warnings are issued in log files
-
- - Output , LOLD variable: in some instances, the values assessed in "economic" simulation mode and in
- "adequacy" simulation mode could slightly differ because of sporadic rounding side-effects.
- rounding convention is now set uniformly to : 0 < X < 0.5 -> (X=0)
-
- - Output, MISC.NDG and PSP variable: values were not properly edited for the specific category
- "geographic districts, "year-by-year results"
-
- - Output, OV. COST, OP. COST, NP. COST variables: values were not properly edited for the last
- hour of the last day of the simulation
-
- - Output, File comparison functions: calendar marks were not properly displayed in some views
-
- - Output, File comparison functions: "Max" operator has been added
-
-
-### Features
-
- - Optimization: introduction of a new unit-commitment mode based on a MILP approach slower but more
- accurate than the former one. An option lets the user choose which mode should be used (fast/accurate)
-
- - Optimization: in "accurate" unit-commitment mode, incorporation of thermal start-up costs and
- no-load heat costs within the global objective function to minimize. In "fast" unit-commitment
- mode, start-up costs and no-load heat costs are minimized independently from the main objective
-
- - Optimization: in both unit-commitment modes, improvement of the inter-weekly start-up strategies
- (seamless reformulation of the optimization results obtained beforehand)
-
- - Thermal clusters: definition of separate minimum up/down durations to be used for unit-commitment
-
- - Thermal clusters: definition of a minimum amount of power (hourly time-series) to be generated
- by the units of the cluster, regardless of economic considerations (partial must-run commitment)
-
- - Thermal clusters: start-up cost can now be set from -5000000 to 5000000 (was from -50000 to 50000)
-
- - Binding constraints: introduction of new "offset" parameters which make it possible to define
- constraints whose terms can refer to different times (e.g. 2 X(t) - 1.5 Y(t-4) + 3 Z(t+1) <10)
-
- - Benchmarking: so as to allow transparent comparisons with other software, the user may demand
- that all optimization problems solved by Antares be printed in a standardized "mps" format
- along with the values of the optimized criterion.
-
- - GUI, System map : new button available in the tool bar for centring the map on a (x,y) location
-
- - GUI, System map : new button available in the tool bar for map trimming around used space
-
- - Output: In synthetic Monte-Carlo results,year-by-year results and cluster-by-cluster results,
- Addition of a field "Number of dispatched units" (NODU)
-
-
-
-v4.5.4 (03/2015)
-----------------
-
-### Bug fixes
-
- - License checking: internet proxys for which no login and/or password have been
- defined can now be used
-
- - Upgrade to 4.5 format of datasets edited in 4.4 format or lower, in which the "scenario builder"
- feature was activated: the conversion to 4.5 format could fail sometimes.
-
-v4.5.3 (02/2015)
-----------------
-
-### Features
-
- - Start-up and fixed thermal costs: the interpretation of the unit-commitment strategy
- (starting-up and shutting-down times of each thermal unit) includes the explicit
- minimization of the total sum of start-up costs and fixed costs (in previous versions,
- units were called on as late as possible and called off as soon as possible)
-
-
- - Various improvements in the linear solver yielding some speed increase in hard cases
-
-
- - Control of license validity through the internet (setting up of a dedicated server)
-
-
-### Bug fixes
-
- - Scenario builder: indices not subject to random draws could be mixed up in areas
- including both "must-run" units and "regular" units (bug circumscribed to the thermal
- time-series section)
-
- - Spillage management, when numerous binding constraints are active: an excessive leeway
- could be observed regarding the level of hydro power allowed to be curtailed
-
-v4.5.2 (06/2014)
-----------------
-
-### Bug fixes
-
- - In the previous version, the average values of interconnection-related variables were multiplied by two
- and this error was propagated to the standard deviation of the same variables
-
-v4.5.1 (06/2014)
-----------------
-
-### Features
-
- - Start-up and fixed thermal costs: the contribution of each thermal cluster to the operating
- cost is now explicitly displayed in the results (field : "non proportional cost")
-
-
- - Load time-series : negative values are now authorized
-
-
-
-
-### Bug fixes
-
- - Creation of a thermal cluster : the default value of the NPOMAX parameter is set to 100
-
-
- - Hydro energy spatial allocation matrix : values are displayed more clearly in the GUI
-
-
- - Copy/paste of nodes : the field "spread on unsupplied energy cost" was not pasted
-
-
-v4.5.0 (04/2014)
-----------------
-
-### Features
-
- - Simplex solver: acceleration regarding the control of the admissibility of the solution
- in the dual stages. This brings a significant improvement of the calculation time for
- large problems in which the relative scale of system costs is very wide
-
-
- - Identical upper and lower bounds have been set for the absolute values of all
- non-zero system costs ( max = 5 10^4 Euros/MWh ; min = 5 10^-3 Euros/MWh)
-
-
-### Bug fixes
-
- - Hydro Time-series generation : the GUI did not react properly when forbidden
- values (negative) were seized for energy expectation and/or standard deviation
-
-
- - Unit commitment of thermal plants: the time of the first activation of a plant
- within a week was not fully optimized
-
-
-v4.4.1 (05/2013)
-----------------
-
-### Bug fixes
-
- - Creation of a new binding constraint: the operation needed to be confirmed twice
- (double click on "create button") and the study had to be "saved as" and reloaded before
- proceeding further.
-
- - Time-series analyzer : due to round-off errors, spatial correlation of 100 %
- (perfectly identical sets of time-series in different locations) could sometimes
- be casted to 99%. Exact 100% correlations are now properly displayed.
-
-
-
-
-v4.4.0 (04/2013)
-----------------
-
-### Features
-
- - Antares licenses can be either static or floating. Floating tokens are managed and
- distributed by the Flexnet product, version 11.9.
-
- - Thermal plants time-series generator : availability parameters (outage rates and duration)
- corresponding to a Mean Time Between Failure (MTBF) < 1 day are now allowed. Though unusual,
- such sets of parameters may prove useful when it comes to modelling specific situations
-
- - Thermal plants time-series generator : it is possible to model the duration of each kind
- of outages as 365-day random arrays instead of 365-day constant arrays. Two parameters
- are available for the description of the probability distribution function of each component.
- A first parameter allows to set the variable law to either "uniform" or "geometric".
- A second parameter allows to set the ratio of the variable standard deviation to
- its expectation to a particular value
-
- - Thermal plants time-series generator : The planned outage process is now committed to meet a
- set of constraints defined by two 365-day arrays (PO Min Nb, PO Max Nb). For every day of
- each Monte-Carlo year, the actual number of overhauls is kept within the [Min,Max] interval,
- the exact value being determined by regular random draws based on outage rates and durations
-
- - As a consequence of the introduction of these new features, Monte-Carlo time-series
- of available thermal power generated with Antares 4.4 may differ from those generated with
- previous versions. Though differences may be observed draw by draw, the statistical
- properties of the generated time-series are strictly preserved when datasets are identical.
-
- - Hydro storage optimization : when the maximum available power of a given day is not high
- enough to allow the full use of the daily hydro storage energy credit, the energy in excess
- is levelled on the other days of the month with a flatter pattern.
-
-
-### Bug fixes
-
- - On creation of a new link, the transmission capacity status parameter is set
- to `Use transmission capacities` instead of `Set to null`.
-
-
-
-v4.3.7 (02/2013)
-----------------
-
-### Features
-
- - Performance improvements for graphical display of large tables
-
-
-### Bug fixes
-
- - The binding constraint data might not be written properly in some cases
- when the constraint was renamed.
-
-
-
-V4.3.6 (12/2012)
-----------------
-
-### Bug fixes
-
- - Windows only: fixed potential crash which could happen when exiting
- a simulation in adequacy mode with import of generated time-series
-
- - Windows only: improved free disk space assessment, which now takes into
- consideration user- and folder-related quotas
-
-
-V4.3.5 (10/2012)
-----------------
-
-### Features
-
- - The calendar field "year" is now available in the simulation main screen
- (allows not only simulations from JAN to DEC but also from OCT to SEP, etc.)
-
- - The attribute "Leap year" is now available in the simulation main screen
-
- - The attribute "Week" is now available in the main simulation screen
- (weekly results may be defined not only from MON to SUN but also from SAT to FRI,etc.)
-
- - Time-series screens: a new function is available for hourly and daily time-series
- (shift rows until #date#)
-
- - Linear solver: new version slightly more accurate than the previous one.
- Note that when a daily or weekly optimization has multiple equally optimal solutions,
- the ultimate choice may differ from that of the previous version
-
-
-### Bug fixes
-
- - Reference numbers of the time-series used in the course of a simulation:
- When the simulation is based on a user-defined scenario (building mode: custom)
- and when a printout of the reference numbers of the time-series used in the simulation
- is asked for (MC scenarios: true), the numbers printed for thermal clusters running
- under the "must-run" status were wrong
-
- - Interconnection results, marginal costs:
- For a congested interconnection whose transmission capacities are not symmetric,
- and in presence of hurdle costs, a zero could sometimes be delivered instead of
- the actually expected value
-
- - Districts: when the Monte-Carlo synthesis edition is skipped, the results regarding
- districts were not accessible via the output viewer.
-
-
-
-V4.2.6 (07/2012)
-----------------
-
-### Features
-
- - The field "MAX MRG" (last of the nodal results) is now available in the output files
-
- - The Monte-Carlo synthesis edition can be skipped when year-by-year results are asked for
-
-
-### Bug fixes
-
- - Binding constraints: in the filter available for the weight matrix, removal of
- redundant options
-
- - Copy/Paste nodes on the general map: "print status" parameters can now be copied like
- any other data
-
- - Upgrade of studies in 3.8 format: negative hurdle costs were not correctly transposed
-
- - Thermal plants time-series generator: outages lasting N days, starting on day D, were
- considered as outages lasting N days starting on D+1 (corrected by removal of the
- one-day shift)
-
- - Advanced parameters, option "shave peaks" used along with the "weekly" simplex range:
- the maximum intra-daily hydro storage limit on power could occasionally be overcome during
- the unsupplied energy levelling process (corrected by a slight lessening of the authorized
- levelling)
-
-
-
-
-v4.1.0 (06/2012)
-----------------
-
-### Features
-
- - Hydro storage energy management : each nodal policy of use can be tuned so as to
- accommodate simultaneously the net load of several nodes
-
- - Hydro storage energy modelling : monthly time-series of inflows and reference trajectories
- for reservoir levels can be used instead of monthly time-series of generated energies.
-
- - Load shedding strategies : when unsupplied energy is unavoidable, a choice is now possible
- between two policies : minimize the duration of sheddings or "shave" the load curve.
-
- - When multiple mathematically equivalent solutions exist a the first order for the
- economic optimization problem, a choice can be made at the second order between three
- ramping strategies
-
-
-
-
-v3.8.0 (12/2011)
-----------------
-
-### Features
-
- - The simulation mode `Adequacy` is renamed `Draft`.
-
- - A new simulation mode `Adequacy` is available. In this mode, all thermal plants are
- considered as must-run zero-cost units.
-
- - New possibilities are given regarding the filtering of simulation results (selection
- of nodes, of interconnections, etc.)
-
- - Automatic spatial aggregation of results is possible through the use of the new
- "district" object (a district is a sort of macro-node gathering several regions)
-
- - Nodal costs of unsupplied energy and of spilled energy : a small additive stochastic
- noise around the reference values can be introduced to help discriminate between
- theoretically equivalent solutions
-
-
-
-V3.7.4 (08/2011)
-----------------
-
-### Features
-
- - New version of the dual simplex engine (speed is about twice that of 3.6 version)
-
- - Economic optimizations now encompass a full week (168 hours) span. Traditional
- day-long optimizations can still be carried out (ad hoc "preference" parameter)
-
- - Binding constraints can be defined at the weekly scale in addition to the
- daily and hourly scales
-
- - Several other "optimization preferences" are made available to allow the quick examination
- of variants used in sensitivity analyses
-
- - A new graphic interface is available for the consultation of all simulation results
- (except those obtained in draft mode)
-
- - Extraction of data regarding any given variable from the whole Monte-Carlo year-by-year
- set of results is now possible
-
- - New variables are introduced in the economic output files : the overall available dispatchable
- thermal generation (AVL DTG) and the thermal margin (DTG MRG = AVL DTG - dispatched power)
-
-
-
-
-V3.6.4 (04/2011)
-----------------
-
-### Features
-
- - The "scenario builder" is now available. With this builder it is possible to define
- precisely the simulation context (for any given year, random numbers drawn for each
- kind of time-series can be replaced by user-defined numbers). This feature allows
- simulations to be carried out in a versatile "What If" mode.
-
-
-
-
-
-V3.5.3 (03/2011)
-----------------
-
-### Features
-
- - Addition of the fuel category "lignite" to the regular options available
- for the description of thermal plants.
-
- - Improvement of the presentation of the 365-day arrays "market bid modulation"
- and "marginal cost modulation".
-
- - Automatic processing of the inter-monthly & inter-regional hydro correlation hydro
- energy matrix to meet the feasibility constraints (the matrix has to be positive
- semi-definite). User should check in the simulation log file that no warning such as :
- "info : hydro correlation not positive semi-definite : shrink by factor x " appears.
-
-
-
-
-V3.4.4 (02/2011)
-----------------
-
-### Features
-
- - The names of nodes, thermal clusters and binding constraints can be extended to
- 128 characters. Authorized characters are : `a-z, A-Z,0-9,-,_, space`
-
-
-
-
-v3.4.3 (10/2010)
-----------------
-
-### Features
-
- - Two calculations modes are now available (in the "run" window):
-
- "regular": the software tries to hold all simulation data in RAM
- this mode is faster than the second one when datasets are small but
- can get dramatically slow when RAM limits are close
-
- "swap" : a dedicated memory management module loads in RAM amounts
- of data as small as possible. This mode should be prefered to the
- other when datasets are large.
-
- Note that in "regular" mode, the maximum amount of data loaded is
- limited by the OS to 2 Go on 32-bit machines, regardless of the
- memory installed. The integrality of installed memory can be used
- on 64-bit machines.
-
- - A new module (time-series analyzer) is available to help set the
- parameters of the stochastic time-series generators for wind power,
- solar power and load. The analyzer determines, on sets of historical
- 8760-hour time-series the relevant parameters for different kinds of
- random laws (uniform, normal,Weibull, Beta, Gamma), along with a
- description of the auto-correlation dynamic (two parameters)
- and a full spatial correlation matrix
-
-
-
-
-
-v3.3.2 (07/2010)
-----------------
-
-### Features
-
- - Improvement of the wind power time-series generator (faster calculations)
-
- - Introduction of new stochastic time-series generators for
- solar power and load
-
- - Introduction of an explicit modelling of wind-to-power curves.
- As a consequence, wind power time-series can now be generated
- either through a direct approach (by analysis of historical
- time-series of power) or through an indirect (more physical)
- approach, based on the analysis of historical time-series of
- wind speed
-
- - Introduction of a new 8760-hour power array for each node,
- representing the day-ahead reserve that should be made available
- (either on-site or at distance) to face last-minute incidents
- and/or forecasts errors.
-
- - Introduction of so-called hurdles costs on interconnection.
-
-
-
-
-v3.1.0 (01/2010)
-----------------
-
-### Features
-
- - Breakdown of monthly hydro storage energy credits in daily credits:
- The pilot curve is now the net load (i.e. load - all must-run generation)
- instead of the gross load
-
- - New functionalities available for datasets management (stucy cleaner,
- Log file wiewer)
-
- - New info is given for simulation context (available & required amounts
- of RAM & HDD space)
-
-
-
-From V1 to V2 (all versions)
-----------------------------
-
- - Refer to project development archives (TRAC thread)
-
diff --git a/src/cmake/changelog.cmake b/src/cmake/changelog.cmake
index b937b58f05..5f62c40077 100644
--- a/src/cmake/changelog.cmake
+++ b/src/cmake/changelog.cmake
@@ -1,4 +1,4 @@
# Copy the changelog
-file(READ "changelog.mdown" changelog_content)
+file(READ "../docs/CHANGELOG.md" changelog_content)
file(WRITE "distrib/changelog.txt" "${changelog_content}")