diff --git a/docs/README.md b/docs/README.md index c2774db3c2..afb4b16617 100644 --- a/docs/README.md +++ b/docs/README.md @@ -82,6 +82,7 @@ root of the project and running: cd docs/pdf-doc-generation-with-sphinx bash create_pdf_doc.sh user-guide.pdf ``` +(You'll have to install these dependencies first: latexmk texlive-latex-recommended texlive-formats-extra). Sphinx will create a `user-guide.pdf` file in `docs/pdf-doc-generation-with-sphinx`. ### Doxygen diff --git a/docs/developer-guide/3-Build.md b/docs/developer-guide/3-Build.md index da65327e10..9bcd97e789 100644 --- a/docs/developer-guide/3-Build.md +++ b/docs/developer-guide/3-Build.md @@ -67,10 +67,10 @@ Here is a list of mandatory or optional CMake configuration options: | `CMAKE_TOOLCHAIN_FILE` | no | Path to VCPKG toolchain file, allows to integrate VCPKG with cmake build | `../vcpkg/scripts/buildsystems/vcpkg.cmake` | | | `VCPKG_TARGET_TRIPLET` | no | Define VCPKG triplet (build type for dependencies etc.) | `x64-windows-antares` / `x64-linux-antares` | | -> ๐Ÿ’ก **Disable the UI build to make builds faster** +> ๐Ÿ’ก **Disable the UI build to make builds faster** > The UI takes up a good chunk of compilation time. It is enabled by default, but you can disable it by turning off `BUILD_UI` -> ๐Ÿ’ก **Use Ninja to speed up target generation by CMake** +> ๐Ÿ’ก **Use Ninja to speed up target generation by CMake** > At configure time, you may specify Ninja for generation instead of traditional Make. This will speed up the update > step after you make small changes to the code. > ``` diff --git a/docs/developer-guide/Architecture/Dynamic-modeler-architecture.md b/docs/developer-guide/Architecture/Dynamic-modeler-architecture.md index 17ce09800e..96f6d2b9b8 100644 --- a/docs/developer-guide/Architecture/Dynamic-modeler-architecture.md +++ b/docs/developer-guide/Architecture/Dynamic-modeler-architecture.md @@ -1,7 +1,7 @@ # Dynamic modeler architecture ## Models -(for details about these concepts, see [this page](../../user-guide/solver/dynamic-modeler/05-model.md)) +(for details about these concepts, see [this page](../../user-guide/modeler/05-model.md)) ```plantuml @startuml @@ -85,7 +85,7 @@ ModelLibraryRepository "1" *-- "0:N" ModelLibrary ``` ## Components -(for details about these concepts, see [this page](../../user-guide/solver/dynamic-modeler/05-model.md)) +(for details about these concepts, see [this page](../../user-guide/modeler/05-model.md)) ```plantuml @startuml diff --git a/docs/user-guide/00-index.md b/docs/user-guide/00-index.md index 892cf400b5..8b2119f5b5 100644 --- a/docs/user-guide/00-index.md +++ b/docs/user-guide/00-index.md @@ -6,7 +6,8 @@ 02-install.md 03-getting_started.md solver/00-index.md -ts-analyzer-generator/00-index.md +modeler/00-index.md +ts-generator/00-index.md other-features/00-index.md 04-migration-guides.md 05-attribution-notices.md diff --git a/docs/user-guide/01-overview.md b/docs/user-guide/01-overview.md index 6482a1df56..b5b73503f3 100644 --- a/docs/user-guide/01-overview.md +++ b/docs/user-guide/01-overview.md @@ -34,7 +34,7 @@ the random factors that may affect the balance between load and generation. Econ 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`](solver/static-modeler/04-parameters.md#mode) simulation mode. +[`adequacy`](solver/04-parameters.md#mode) simulation mode. ### Transmission project profitability [//]: # (TODO: explain what "fair and perfect market" means) @@ -45,7 +45,7 @@ and/or improvement of the security of supply (reduction of the loss-of-load expe 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`](solver/static-modeler/04-parameters.md#mode) simulation mode. +In these studies, the default *Antares* option to use is the [`economy`](solver/04-parameters.md#mode) simulation mode. ## Performance considerations Typically, *Antares* has to solve a least-cost hydro-thermal power schedule and unit commitment problem, with an hourly @@ -54,7 +54,7 @@ The large number and the size of the individual problems to solve often make opt Depending on user-defined results accuracy requirements, various practical options[^2] allow to simplify either the formulation of the problems, or their resolution. -[^2]: See [hydro-pricing-mode](solver/static-modeler/04-parameters.md#hydro-pricing-mode), [unit-commitment-mode](solver/static-modeler/04-parameters.md#unit-commitment-mode) +[^2]: See [hydro-pricing-mode](solver/04-parameters.md#hydro-pricing-mode), [unit-commitment-mode](solver/04-parameters.md#unit-commitment-mode) [//]: # (TODO: list in [^2] the other parameters that have impact on performance) @@ -73,4 +73,4 @@ operation problems (one for each week of each Monte-Carlo year), assumed to be i Note that, however, dependency issues such as the management of hydro stock (or any other kind of energy storage facility) may bring a significant coupling between the successive problems, which needs to be addressed properly[^3]. -[^3]: See how *Antares* addresses stock dependency between successive problems [here](solver/static-modeler/06-hydro-heuristics.md#seasonal-hydro-pre-allocation). \ No newline at end of file +[^3]: See how *Antares* addresses stock dependency between successive problems [here](solver/06-hydro-heuristics.md#seasonal-hydro-pre-allocation). \ No newline at end of file diff --git a/docs/user-guide/02-install.md b/docs/user-guide/02-install.md index c72c3e8da0..907b6f595c 100644 --- a/docs/user-guide/02-install.md +++ b/docs/user-guide/02-install.md @@ -22,10 +22,10 @@ Installed alone, the Antares simulator does not require a lot of HDD space (less - The number of ready-made Time-Series and the number of Time-Series to be generated at runtime and stored afterward (see [these parameters](ts-generator/04-parameters.md#time-series-parameters)). - The activation of output filters - (see [thematic-trimming](solver/static-modeler/04-parameters.md#thematic-trimming) and [geographic-trimming](solver/static-modeler/04-parameters.md#geographic-trimming) parameters). + (see [thematic-trimming](solver/04-parameters.md#thematic-trimming) and [geographic-trimming](solver/04-parameters.md#geographic-trimming) parameters). - The number of Monte-Carlo years involved in the simulation session, if the storage of detailed - [year-by-year results](solver/static-modeler/04-parameters.md#year-by-year) is activated -- Whether [MPS export](solver/static-modeler/04-parameters.md#include-exportmps) is activated + [year-by-year results](solver/04-parameters.md#year-by-year) is activated +- Whether [MPS export](solver/04-parameters.md#include-exportmps) is activated If you encounter space issues, consider tweaking the aforementioned parameters or reducing your study size. @@ -35,8 +35,8 @@ The amount of RAM required for a simulation depends on: - The size of the power system model (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](solver/static-modeler/04-parameters.md#mode) -- The [unit commitment resolution mode](solver/static-modeler/04-parameters.md#unit-commitment-mode) +- The simulation [mode](solver/04-parameters.md#mode) +- The [unit commitment resolution mode](solver/04-parameters.md#unit-commitment-mode) - If the [multi-threading](solver/optional-features/multi-threading.md) option is used If you encounter memory issues, consider tweaking the aforementioned parameters or reducing your study size. diff --git a/docs/user-guide/03-getting_started.md b/docs/user-guide/03-getting_started.md index 6930298a40..939319f3f9 100644 --- a/docs/user-guide/03-getting_started.md +++ b/docs/user-guide/03-getting_started.md @@ -56,16 +56,16 @@ These steps most often involve: 1. Initializing or updating the input data (time-series, grid topology, fleet description, etc.). *In this step, the user is expected to provide all the input data they have, except the time-series that are - supposed to be [automatically generated](solver/static-modeler/04-parameters.md#generate) by *Antares* (see step (3)).* + supposed to be [automatically generated](solver/04-parameters.md#generate) by *Antares* (see step (3)).* *As stated above, it is highly recommended to use robust tools to produce input data, such as [Antares Web](https://antares-web.readthedocs.io) or [Antares Extensions](#using-extensions).* 2. Defining the simulation contexts (definition of the "Monte-Carlo years" to simulate) -3. *(Optional)* If some time-series are supposed to be [automatically generated](solver/static-modeler/04-parameters.md#generate), +3. *(Optional)* If some time-series are supposed to be [automatically generated](solver/04-parameters.md#generate), running a simulation to produce actual numeric scenarios, following the directives defined in (2). *In this step, the [ts-generator](ts-generator/01-overview-tsgenerator.md) tool should be used.* 4. Running the optimization, to solve all the optimization problems associated with each of the scenarios produced in (3). *In this step, the main [solver](solver/01-overview-solver.md) tool should be used.* -5. Exploiting the detailed [results](solver/static-modeler/03-outputs.md) yielded by (4). +5. Exploiting the detailed [results](solver/03-outputs.md) yielded by (4). *In this step, we recommend using [Antares Web](https://antares-web.readthedocs.io) or [Antares Extensions](#using-extensions).* diff --git a/docs/user-guide/solver/dynamic-modeler/00-index.md b/docs/user-guide/modeler/00-index.md similarity index 79% rename from docs/user-guide/solver/dynamic-modeler/00-index.md rename to docs/user-guide/modeler/00-index.md index e49906698f..e48de21efe 100644 --- a/docs/user-guide/solver/dynamic-modeler/00-index.md +++ b/docs/user-guide/modeler/00-index.md @@ -1,10 +1,10 @@ [//]: # (Index used by Sphinx to generate correct PDF tree) -# Dynamic Modeler +# Modeler ```{toctree} :hidden: -01-overview-new-solver.md +01-overview-modeler.md 02-inputs.md 03-outputs.md 04-parameters.md @@ -12,4 +12,5 @@ 06-heuristics.md 07-standard-library.md 08-hybrid-studies.md +09-command-line.md ``` \ No newline at end of file diff --git a/docs/user-guide/solver/dynamic-modeler/01-overview-dynamic-modeler.md b/docs/user-guide/modeler/01-overview-modeler.md similarity index 84% rename from docs/user-guide/solver/dynamic-modeler/01-overview-dynamic-modeler.md rename to docs/user-guide/modeler/01-overview-modeler.md index 095c0a9711..7f29fac9e8 100644 --- a/docs/user-guide/solver/dynamic-modeler/01-overview-dynamic-modeler.md +++ b/docs/user-guide/modeler/01-overview-modeler.md @@ -1,6 +1,6 @@ # Overview -_**Disclaimer: please note that the new Antares dynamic modeler is still under development, and that some of the +_**Disclaimer: please note that the new Antares modeler is still under development, and that some of the features described in this section may still be unavailable**_ The new Antares dynamic modeler allows more flexibility in the definition of physical models used in the simulation. diff --git a/docs/user-guide/modeler/02-inputs.md b/docs/user-guide/modeler/02-inputs.md new file mode 100644 index 0000000000..72e498f375 --- /dev/null +++ b/docs/user-guide/modeler/02-inputs.md @@ -0,0 +1,398 @@ +# Input files + +## Study structure +Like the Antares [solver](../solver), the Antares modeler input is a directory, that should be organized by the user as follows: + +- _**root directory with any name**_ + - **input**: a directory that contains all input files + - **model-libraries**: a directory that contains all [model libraries](#model-libraries) needed by the study + - **data-series**: a directory that contains all [data series](#data-series) needed by the study + - **system.yml**: the [system file](#system-file) describing the simulated energy system + - **parameters.yml**: the [parameters](04-parameters.md) file + +Note that Antares will automatically create an **output** directory to write the modeler [outputs](03-outputs.md). + +## Model libraries +The model libraries directory shall contain all the model library files needed to run the study. +A model library is a collection of [models](05-model.md#models) that are published together in one source. +The study can rely on only one library, or can mix models from different libraries. + +Currently, Antares modeler supports libraries that are each defined in a single yml file. + +The header of the yml file must contain exactly one "library" key at the root level. +The **library** object contains one **id**, one **description**, one **port-types** collection, and one **models** collection. +Unless stated otherwise, all listed fields are mandatory. +### ID & description +Example: +~~~yaml +library: + id: my_library_id + description: my library is great! +~~~ + +- **id**: the unique ID for you library. Beware that if you are using many libraries in your study, every library must + have a unique ID. This ID will be used inside the [system description file](#system-file) in order to reference the + library's objects. It must respect [these rules](#rules-for-ids). +- **description** _(optional)_: a free description of your library. Has no effect on the simulation. + +### Port types +The **port-types** collection lists the possible types of [ports](05-model.md#ports-and-connections) inside the library, +that can be used by models/components to communicate with each-other. +This field is optional: you can develop a library with no ports, even though this would have limited interest (the +models would not be able to communicate with each-other). +Example: +~~~yaml +port-types: + - id: dc_port + description: A port which transfers power flow value + fields: + - id: flow + - id: ac_port + description: A port which transfers power flow and voltage angle values + fields: + - id: flow + - id: angle +~~~ + +- **id**: the ID for the port type. Must be unique inside the scope of the library, and respect [these rules](#rules-for-ids). +- **description** _(optional)_: a free description of your port type. Has no effect on the simulation. +- **fields**: a collection of coherent fields that transit through this port type. A field holds a single floating number. + - **id**: the ID of the field. Must be unique in the scope of the port type, and respect [these rules](#rules-for-ids). + +### Models +The **models** collection lists all the [models](05-model.md#models) that can be instantiated using your library. +Example: +~~~yaml +models: + - id: generator_dc + description: A simple DC model of a generator + parameters: + - id: min_active_power_setpoint + time-dependent: false + scenario-dependent: false + - id: max_active_power_setpoint + time-dependent: true + scenario-dependent: true + - id: proportional_cost + time-dependent: false + scenario-dependent: true + variables: + - id: is_on + variable-type: boolean + lower-bound: 0 + upper-bound: 1 + - id: active_power + variable-type: continuous + lower-bound: 0 + upper-bound: max_active_power_setpoint + constraints: + - id: respect_min_p + expression: active_power >= is_on * min_active_power_setpoint + objective: active_power * proportional_cost + ports: + - id: injection + type: dc_port + port-field-definitions: + - port: injection + field: flow + definition: power + - id: node + description: A balance node with injections (productions and loads) + ports: + - id: injections + type: dc_port + binding-constraints: + - id: balance + expression: sum_connections(injections.flow) = 0 +~~~ + +- **id**: an ID for the model. Must be unique inside the scope of the library, and respect [these rules](#rules-for-ids). +- **description** _(optional)_: a free description of the model. Has no effect on the simulation. +- **parameters** _(optional)_: a collection of parameters for the model. The values for these parameters will be set in the [system file](#system-file). + - **id**: an ID for the parameter. Must be unique inside the scope of the model, and respect [these rules](#rules-for-ids). + - **time-dependent**: `true` or `false`, indicates whether the parameter depends on time or is constant across the whole simulation horizon. + - **scenario-dependent**: `true` or `false`, indicates whether the parameter changes depending on the simulated scenario, or is the same for all scenarios. +- **variables** _(optional)_: a collection of optimization variables that are defined for this model + - **id**: an ID for the variable. Must be unique inside the scope of the model, and respect [these rules](#rules-for-ids). + - **variable-type**: `continuous`, `integer`, or `binary` + - **lower-bound**: an [expression](#expressions) representing the lower bound of the variable. Must use scalars and/or parameters only. + - **upper-bound**: an [expression](#expressions) representing the upper bound of the variable. Must use scalars and/or parameters only. +- **constraints** _(optional)_: a collection of "internal" optimization constraints set by the model + - **id**: an ID for the constraint. Must be unique inside the scope of the model, and respect [these rules](#rules-for-ids). + - **expression**: an [expression](#expressions) representing the constraint. Can use scalars, parameters, internal variables, time and scenario operators. + Must contain exactly one comparison operator (**=**, **<=**, or **>=**). +- **binding-constraints** _(optional)_: a collection of "external" optimization constraints set by the model, that use ports. While these have no + real difference with "internal constraints", it is best practice to separate internal and external constraints in order to make the model more readable. + - **id**: an ID for the constraint. Must be unique inside the scope of the model, and respect [these rules](#rules-for-ids). + - **expression**: an [expression](#expressions) representing the constraint. Can use scalars, parameters, internal variables, ports, and time, scenario, and port operators. +- **objective** _(optional)_: an [expression](#expressions) representing the (additive) participation of the model to the optimization objective. + Note that **minimization** is implied. The expression can use scalars, parameters and variables of the model. +- **ports** _(optional)_: a collection of ports exposed by the model, either as input or output + - **id**: an ID for the port. Must be unique in the scope of the model, and respect [these rules](#rules-for-ids). + - **type**: the type of the port. Must refer to the ID of a port type defined in the [port types](#port-types) section. +- **port-field-definitions** _(optional)_: a collection of definitions for ports output by this model. Note that if the + model is to define a port, then it must define all fields of this port. + - **port**: the ID of a port exposed by the model (defined in the **ports** section above) + - **field**: the field to define (refers to a field ID defined in the port type) + - **definition**: an [expression](#expressions) representing the definition of the field. Can use scalars, parameters, and variables of the model. + + +### Expressions +An expression is a human-readable equation that allows a large flexibility in defining objects of optimization. + +#### Arithmetic operators +The following operators are allowed between two elements: + +- **+**: addition of two elements +- **-**: subtraction +- __*__: multiplication +- **/**: division +- **=**: equality, only allowed for constraint definitions +- **<=**: less or equal to, only allowed for constraint definitions +- **>=**: greater or equal to, only allowed for constraint definitions + +#### Scalars +You can use simple floating-point scalars anywhere. The character `.` represents the floating point. +Example: +~~~yaml +expression: 3 * 67.43 - 5 / 3.14 +~~~ + +#### Parameters +You can use a parameter by using its ID. Note that if the parameter is time-dependent (resp. scenario-dependent), then +it can be used only for variables or constraints that are time-dependent (resp. scenario-dependent), and that its values +will be implicitly unfolded during the interpretation of the expression. +Example: +~~~yaml +expression: 3 * parameter_1 + 6.345 / parameter_2 +~~~ + +#### Variables +You can use a parameter by using its ID. Note that if the variable is time-dependent (resp. scenario-dependent), then +it can be used only for constraints that are time-dependent (resp. scenario-dependent), and that its values +will be implicitly unfolded during the interpretation of the expression. +Example: +~~~yaml +expression: 3 * parameter_1 * variable_a + variable_b + 56.4 <= variable_4 * 439 +~~~ +Also note that all expressions must be linear with respect to variables. +Examples of prohibited expressions: +~~~yaml +(X) expression: variable_a * variable_b +~~~ +~~~yaml +(X) expression: 3 / variable_a +~~~ + +#### Ports +You can use a port field in the expression, using its ID composed by: **port_ID.field_ID**. Note that if the +port is time-dependent (resp. scenario-dependent), which is deduced from the variables defining it, then +it can be used only for constraints that are time-dependent (resp. scenario-dependent), and that its values +will be implicitly unfolded during the interpretation of the expression. Unless, of course, you use time (resp. scenario) +aggregators to aggregate it into a time-constant (resp. scenario-constant) value. +Example: +~~~yaml +expression: 45.4 * port_3.field_6 + 5.4 * variable_6 - 9 +~~~ +Note that, like with variables, all expressions must be linear with respect to ports. + +#### Time operators +For time-dependent parameters, variables, and port fields, you can use these time operators: + +- **[t]** suffix: this operator is implied, but can be used if you like to explicit your intent +- **[N]** suffix: where N is any expression resolving to an integer (using only scalars and parameters), this selects the value of the element at the N-th timestamp. +- **[t+N]** suffix: where N is any expression resolving to an integer (using only scalars and parameters), this is a forward shift operator of N timestamps. +- **[t-N]** suffix: where N is any expression resolving to an integer (using only scalars and parameters), this is a backward shift operator of N timestamps. +- **sum(X)** aggregator: where X is the time-dependent operand, this operator sums the operand on the whole optimization horizon. +- **sum(S .. E, X)** aggregator: where X is the time-dependent operand, this operator sums the operand between S and E (included), where: + - **S** represents the first timestamp, either as an expression resolving to an integer, or a time-shift expression like the ones defined above + - **E** represents the last timestamp, either as an expression resolving to an integer, or a time-shift expression like the ones defined above + +Examples: +~~~yaml +expression: a[t] + b[t + 5] * c[t - 3 - 65 * parameter_1] - sum(a) +~~~ +~~~yaml +expression: sum(4 .. 87, c) - sum(t - 3 * parameter_15 + 5 .. t, d) +~~~ + +#### Scenario operators +For scenario-dependent parameters, variables, and port fields, you can use this operator: + +- **expec(X)** aggregator: where X is the scenario-dependent operand, this operator computes its expected value (i.e. its scenario-wise average). + +#### Port operators +You can aggregate incoming ports using the following operator: + +- **sum_connections(port.field)**: where "port" is the port ID and "field" is the field ID, this operator computes the + sum of values of this port field, on all incoming connections from other models. + Note that the resulting sum can be time-dependent and/or scenario-dependent, depending on the port definition. + +Examples: +~~~yaml +expression: sum(dc_port.flow) = 0 +~~~ + +## System file +The system file describes the energy system that is to be simulated, by listing the [components](05-model.md#components) +and the [port connections](05-model.md#ports-and-connections). +Currently, Antares modeler supports importing the system from a yaml file. + +The header of the yml file must contain exactly one "system" key at the root level. +The **system** object contains one **id**, one **description**, one **model-libraries** collection, one **components** collection. +Unless stated otherwise, all listed fields are mandatory. + +### ID, description, and model libraries +Example: +~~~yaml +system: + id: my_system + description: my system is even greater! + model-libraries: my_library_id, my_other_library_id +~~~ + +- **id**: an ID for your system. Has no effect on the simulation. +- **description** _(optional)_: a free description of your system. Has no effect on the simulation. +- **model-libraries**: a collection of model libraries needed for your system. Must contain at least one element, and + refer to IDs of model libraries found in the **input/model-libraries" directory. Beware that the ID of the library is + one defined in its header, not the name of the file. + +### Components +The **components** section lists all the [components](05-model.md#components) of your simulated system. +Example: +~~~yaml +components: + - id: generator1 + model: my_lib_id.dc_generator + scenario-group: thermal_group + parameters: + - id: min_active_power_setpoint + time-dependent: false + scenario-dependent: false + value: 100 + - id: max_active_power_setpoint + time-dependent: true + scenario-dependent: true + value: generator1_max_p + - id: proportional_cost + time-dependent: false + scenario-dependent: true + value: generator1_cost + - id: generator2 + model: my_lib_id.dc_generator + scenario-group: hydro_group + parameters: + - id: min_active_power_setpoint + time-dependent: false + scenario-dependent: false + value: 20 + - id: max_active_power_setpoint + time-dependent: true + scenario-dependent: false + value: generator2_max_p + - id: proportional_cost + time-dependent: false + scenario-dependent: false + value: 0.5 + - id: node1 + model: my_lib_id.node +~~~ + +- **id**: an ID for the component. Must be unique in the scope of the system, and respect [these rules](#rules-for-ids). +- **model**: the ID of the model to use for the component, composed as "library_id.model_id", where "library_id" is the + ID of the model library (must be listed in the [required model libraries](#id-description-and-model-libraries)), and + "model_id" is the ID of the model as it is defined inside the [model library](#models). +- **scenario-group** _(only needed if the model has scenario-dependent parameters)_: the ID of the scenario group this + component belongs to. Must be correctly configured in the [scenario builder](#scenario-builder), and respect [these rules](#rules-for-ids). +- **parameters** _(not needed if model has no parameters)_: a collection of values for the model's parameters. Note that + all the parameters of the model should have their values assigned by the component. + - **id**: the ID of the parameter, as defined by the [model](#models) + - **time-dependent**: `true` or `false`, indicates whether the parameter depends on time or is constant across the + whole simulation horizon. If the model parameter is not time-dependent, this can't be set to true. + - **scenario-dependent**: `true` or `false`, indicates whether the parameter changes depending on the simulated + scenario, or is the same for all scenarios. If the model parameter is not scenario-dependent, this can't be set to true. + - **value**: the value of the parameter: + - If the parameter is constant, then this is a numerical value (using a data-series ID is not allowed in this case) + - If the parameter is time-dependent, then this is the ID of a time-dependent [data serie](#data-series) + - If the parameter is scenario-dependent, then this is the ID of a scenario-dependent [data serie](#data-series) + - If the parameter is time and scenario-dependent, then this is the ID of a time-and-scenario-dependent [data serie](#data-series) + +### Port connections +The **connections** section lists the port connections between components. +Example: +~~~yaml +connections: + - component1: generator1 + port1: injection + component2: node1 + port2: injections + - component1: generator2 + port1: injection + component2: node1 + port2: injections +~~~ + +- **component1**, **component2**: the IDs of the components to connect together +- **port1**, **port2**: the IDs of the respective ports to connect (as defined by the two models). Note that exactly one + of the two models must define the port (in the "port-field-definition" section). + +## Data series +The **input/data-series** directory contains all data-series needed by the [system description](#system-file) to define +component parameter values. + +Currently, Antares modeler supports defining data-series using tab-seperated-values files. Values must be separated +using tabs, and the character `.` represents the floating point. + +### Naming +TSV files inside the directory should respect the "XXX.tsv" or the "XXX.csv" naming template, where "XXX" is the ID of +the data-series. Thus, this ID **must be unique**, and is the one to be used in the [system file](#system-file). + +### Time-dependent series +To define a time-dependent series, define a column vector, where every timestamp is represented by a row. +Example file for a simulation with 6 timestamps: +~~~ +10 +15 +34 +56 +34 +65 +~~~ +Note that Antares modeler currently does not conduct quality checks on data-series, and that it is up to you to ensure +that the rows cover the [time horizon](04-parameters.md#horizon) of the simulation. + +### Scenario-dependent series +To define a parameter value that changes depending on the scenario, define a row vector, where every data set is +represented by a column. +Currently, Antares modeler does not support scenario building. Thus, please ensure that every scenario you want to +simulate has an associated column in the scenario-dependent series file. +In the future, you will be able to use the [scenario builder](#scenario-builder) to map different scenarios to the data +sets, in order to avoid duplicating data. +Example file for a simulation with 4 scenarios: +~~~ +54 67.5 23.652 253 +~~~ + +### Time and scenario-dependent series +Use the two methods described above. +Example file for a simulation with 2 timestamps and 3 scenarios: +~~~ +2345 1243 123 +2378 748 0 +~~~ + +## Rules for IDs +All IDs in the model library and system file must respect the following: + +- Alphanumeric characters are allowed, as well as the underscore (`_`) character +- All other characters are prohibited +- Only lower-case is allowed + +## Scenario builder +_**This feature is under development**_ +This feature allows you to map, for different scenario groups of components, all scenarios to a limited number of data +sets. This prevents duplication of data when some data-series are "less" scenario-dependent than others. +For now, "scenario-groups" are ignored and scenario indices map to data set indices. + +## Full examples +You can find some simple to more complex studies in our [test base here](https://github.com/AntaresSimulatorTeam/Antares_Simulator/tree/develop/src/tests/resources/modeler). \ No newline at end of file diff --git a/docs/user-guide/modeler/03-outputs.md b/docs/user-guide/modeler/03-outputs.md new file mode 100644 index 0000000000..d5067e418b --- /dev/null +++ b/docs/user-guide/modeler/03-outputs.md @@ -0,0 +1,58 @@ +# Output files + +_**This feature is under development**_ + +Antares modeler automatically creates an **output** directory under the study root directory, to write output files into it. +Currently, Antares modeler only outputs two file, one containing optimal values of the objective function and all the +optimization problem's variables, and one containing the optimization model. + +## Optimization results + +### Description + +The optimization results are written under **output/solution.tsv**. +The file is in TSV format, with values seperated by a tab, and the floating point represented by the `.` character. + +The first column contains "objective" or the ID of a variable, composed by **componentID.variableID_s_t**, where: + +- **componentID** is the ID of the component as defined in the [system file](02-inputs.md#system-file) +- **variableID** is the ID of the variable as defined in the component's [model](02-inputs.md#models) +- **s** is the index of the scenario (starts at 0), if the variable is scenario-dependent +- **t** is the index of the timestamp (starts at 0), if the variable is time-dependent + +The second column contains optimal variable values. + +### Example +Output file for a simulation with 2 scenarios and 3 timestamps. +~~~ +objective 1565 +generator1.is_on_0_0 1 +generator1.is_on_0_1 1 +generator1.is_on_0_2 1 +generator1.is_on_1_0 1 +generator1.is_on_1_1 0 +generator1.is_on_1_2 0 +generator1.active_power_0_0 10 +generator1.active_power_0_1 510 +generator1.active_power_0_2 340.5 +generator1.active_power_1_0 100 +generator1.active_power_1_1 0 +generator1.active_power_1_2 0 +generator2.is_on_0_0 0 +generator2.is_on_0_1 1 +generator2.is_on_0_2 1 +generator2.is_on_1_0 1 +generator2.is_on_1_1 1 +generator2.is_on_1_2 1 +generator2.active_power_0_0 0 +generator2.active_power_0_1 1023 +generator2.active_power_0_2 45 +generator2.active_power_1_0 23 +generator2.active_power_1_1 562 +generator2.active_power_1_2 10.6534 +~~~ + +## Optimization model + +The optimization model solved by Antares modeler is written in the human-readable LP format, +under **output/problem.lp**. It is only meant to be used for debugging. \ No newline at end of file diff --git a/docs/user-guide/modeler/04-parameters.md b/docs/user-guide/modeler/04-parameters.md new file mode 100644 index 0000000000..0f6a4e721f --- /dev/null +++ b/docs/user-guide/modeler/04-parameters.md @@ -0,0 +1,62 @@ +# Parameters + +The modeler parameters are currently held in a **parameters.yml** file under the study root directory. + +## Solver parameters + +### solver +- **Expected value:** one of the following (case-sensitive): + - `sirius` + - `scip` + - `coin` + - `xpress` +- **Required:** **no** +- **Default value:** `sirius` +- **Usage:** the solver to use for optimization problem resolution + +### solver-logs +- **Expected value:** `true` or `false` +- **Required:** no +- **Default value:** `false` +- **Usage:** whether to activate solver output in the logs (useful for debugging) + +### solver-parameters +- **Expected value:** string that must be comprehensible by the [OR-Tools-MPSolver](https://developers.google.com/optimization/lp/mpsolver) + implementation of the selected [solver](#solver) +- **Required:** no +- **Default value:** empty +- **Usage:** Set solver-specific parameters, for instance `THREADS 1 PRESOLVE 1` for XPRESS or + `parallel/maxnthreads 1, lp/presolving TRUE` for SCIP. Syntax is solver-dependent, and only supported for SCIP & XPRESS. + +## Horizon + +### first-time-step +- **Expected value:** positive integer (0 accepted) +- **Required:** yes +- **Usage:** first timestamp to include in the simulation horizon. Must be included in the definition of + [data-series](02-inputs.md#data-series) that are time-dependent. + +### last-time-step +- **Expected value:** positive integer (0 accepted) +- **Required:** yes +- **Usage:** last timestamp to include in the simulation horizon. Must be included in the definition of + [data-series](02-inputs.md#data-series) that are time-dependent. + +## Outputs + +### no-output +- **Expected value:** `true` or `false` +- **Required:** no +- **Default value:** `false` +- **Usage:** whether to generate [output files](03-outputs.md) at the end of the simulation + + +## Full example +~~~yaml +solver: xpress +solver-logs: false +solver-parameters: THREADS 1 +no-output: false +first-time-step: 0 +last-time-step: 2 +~~~ diff --git a/docs/user-guide/solver/dynamic-modeler/05-model.md b/docs/user-guide/modeler/05-model.md similarity index 100% rename from docs/user-guide/solver/dynamic-modeler/05-model.md rename to docs/user-guide/modeler/05-model.md diff --git a/docs/user-guide/solver/dynamic-modeler/06-heuristics.md b/docs/user-guide/modeler/06-heuristics.md similarity index 100% rename from docs/user-guide/solver/dynamic-modeler/06-heuristics.md rename to docs/user-guide/modeler/06-heuristics.md diff --git a/docs/user-guide/solver/dynamic-modeler/07-standard-library.md b/docs/user-guide/modeler/07-standard-library.md similarity index 100% rename from docs/user-guide/solver/dynamic-modeler/07-standard-library.md rename to docs/user-guide/modeler/07-standard-library.md diff --git a/docs/user-guide/solver/dynamic-modeler/08-hybrid-studies.md b/docs/user-guide/modeler/08-hybrid-studies.md similarity index 100% rename from docs/user-guide/solver/dynamic-modeler/08-hybrid-studies.md rename to docs/user-guide/modeler/08-hybrid-studies.md diff --git a/docs/user-guide/modeler/09-command-line.md b/docs/user-guide/modeler/09-command-line.md new file mode 100644 index 0000000000..06aaec4baf --- /dev/null +++ b/docs/user-guide/modeler/09-command-line.md @@ -0,0 +1,20 @@ +--- +hide: + - toc +--- + +# Command-line instructions + +**Executable**: antares-modeler + +The modeler takes only one argument: the path to the [study directory](02-inputs.md#study-structure). + +Example for Windows users: +~~~ +antares-modeler.exe C:\path\to\my\study +~~~ + +For Linux users: +~~~ +antares-modeler /path/to/my/study +~~~ \ No newline at end of file diff --git a/docs/user-guide/solver/00-index.md b/docs/user-guide/solver/00-index.md index ad9273f951..ab37357d21 100644 --- a/docs/user-guide/solver/00-index.md +++ b/docs/user-guide/solver/00-index.md @@ -5,9 +5,13 @@ ```{toctree} :hidden: 01-overview-solver.md -static-modeler/00-index.md -dynamic-modeler/00-index.md -02-command-line.md +02-inputs.md +03-outputs.md +04-parameters.md +05-model.md +06-hydro-heuristics.md +07-thermal-heuristic.md +08-appendix.md +09-command-line.md optional-features/00-index.md -03-appendix.md -``` +``` \ No newline at end of file diff --git a/docs/user-guide/solver/01-overview-solver.md b/docs/user-guide/solver/01-overview-solver.md index 6457b65bcc..d620960a25 100644 --- a/docs/user-guide/solver/01-overview-solver.md +++ b/docs/user-guide/solver/01-overview-solver.md @@ -2,20 +2,63 @@ _**This section is under construction**_ -The *Solver* is *Antares Simulator*'s main feature. -It covers modelling & solving the adequacy optimization problem. - -As of 2024, the modelling feature is being overhauled to allow more flexibility in the definition of physical models. - -- The existing modeler will still be maintained for a few years, you can find its - documentation under the ["static modeler" section](static-modeler/01-overview-static-modeler). -- The new modeler will be gradually enriched to cover all existing features, you can find its - documentation under the ["dynamic modeler" section](dynamic-modeler/01-overview-dynamic-modeler). -- It will be possible, for a few transitional years, to define "hybrid" studies, - mixing [static models](static-modeler/05-model.md) with [dynamic models](dynamic-modeler/05-model.md). This is - documented [here](dynamic-modeler/08-hybrid-studies.md). - -As a consequence, you will be able to use the solver with three types of studies: legacy studies, new studies, and -hybrid studies. -All these possibilities are offered by the same "antares-solver" executable ; it is able to adapt to the different input -files. Its usage is documented [here](02-command-line.md). +The *Solver* is *Antares Simulator*'s main feature. + +**Monte Carlo Simulation** Runs either an economy simulation or an adequacy simulation +depending on the values of the [parameters](04-parameters.md). +If hardware resources and simulation settings allow it, simulations can benefit from [multi-threading](optional-features/multi-threading.md). + + +## Antares at one glance + +This section gives a summary of the whole simulation process followed by Antares in Economy simulations (Adequacy being simplified variant 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/link + +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: + + i. 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) + + ii. 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. + + iii. 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**. + +- **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_ | +|------|-----------|------------| +| _R0_ | _Yes_ | _Yes_ | +| _R3_ | _Yes_ | _Yes_ | \ No newline at end of file diff --git a/docs/user-guide/solver/static-modeler/02-inputs.md b/docs/user-guide/solver/02-inputs.md similarity index 98% rename from docs/user-guide/solver/static-modeler/02-inputs.md rename to docs/user-guide/solver/02-inputs.md index a2f6c5f003..56c67d04e1 100644 --- a/docs/user-guide/solver/static-modeler/02-inputs.md +++ b/docs/user-guide/solver/02-inputs.md @@ -49,7 +49,7 @@ It is based on the edition of a special "sets.ini" file. - 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** : using any text editor, or, better yet, [using Antares extensions](../../03-getting_started.md#using-extensions). +**HOW TO UPDATE / CREATE the file** : using any text editor, or, better yet, [using Antares extensions](../03-getting_started.md#using-extensions). **WHERE TO FIND / STORE THE FILE** : INPUT/areas/sets.ini @@ -157,7 +157,7 @@ The user may pick any area appearing in the list and is then given access to dif - 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](../../ts-generator/01-overview-tsgenerator.md). + [Time-series analysis and generation](../ts-generator/01-overview-tsgenerator.md). - The "digest" tab displays for all areas a short account of the local data @@ -233,8 +233,8 @@ a choice can be made between different tabs: - Fuel efficiency (%) - Cost generation [Set manually / Use cost timeseries] - Marginal operating cost (โ‚ฌ/MWh) - - Volatility (forced): a parameter between 0 and 1, see section [Time-series generation (thermal)](../../ts-generator/05-algorithm.md#time-series-generation-thermal) - - Volatility (planned): a parameter between 0 and 1, see section [Time-series generation (thermal)](../../ts-generator/05-algorithm.md#time-series-generation-thermal) + - Volatility (forced): a parameter between 0 and 1, see section [Time-series generation (thermal)](../ts-generator/05-algorithm.md#time-series-generation-thermal) + - Volatility (planned): a parameter between 0 and 1, see section [Time-series generation (thermal)](../ts-generator/05-algorithm.md#time-series-generation-thermal) - Law (forced): Probabilistic law used for the generation of the forced outage time-series, can be set to either uniform or geometric - Law (planned): Probabilistic law used for the generation of the planned outage time-series, can be set to either uniform or geometric - Generate TS: Parameter to specify the behavior of this cluster for TS generation. **This cluster-wise parameter takes priority over the study-wide one.** It can hold three values: @@ -499,7 +499,7 @@ The user may pick any area appearing in the list and is then given access to dif 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](../../ts-generator/04-parameters.md). +- 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](../ts-generator/04-parameters.md). - The "digest" tab displays for all areas a short account of the local data @@ -542,7 +542,7 @@ The user may pick any area appearing in the list and is then given access to dif 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](../../ts-generator/04-parameters.md). +- 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](../ts-generator/04-parameters.md). - The "digest" tab displays for all areas a short account of the local data @@ -663,9 +663,9 @@ This window is used to handle all input data regarding the interconnections. On - 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](../../other-features/kirchhoff-constraints-builder.md)): 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 min (denoted $Y^-$ in [Kirchhoff Constraints Generator](../other-features/kirchhoff-constraints-builder.md)): 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](../../other-features/kirchhoff-constraints-builder.md)): 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) + - PST max (denoted $Y^+$ in [Kirchhoff Constraints Generator](../other-features/kirchhoff-constraints-builder.md)): 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} $ @@ -712,7 +712,7 @@ Then the DC flow approximation may be implemented, for each time-step of the sim $$ 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](../../other-features/kirchhoff-constraints-builder.md)._ +_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](../other-features/kirchhoff-constraints-builder.md)._ 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]. diff --git a/docs/user-guide/solver/static-modeler/03-outputs.md b/docs/user-guide/solver/03-outputs.md similarity index 99% rename from docs/user-guide/solver/static-modeler/03-outputs.md rename to docs/user-guide/solver/03-outputs.md index e6ec1f0222..ad4947a8f4 100644 --- a/docs/user-guide/solver/static-modeler/03-outputs.md +++ b/docs/user-guide/solver/03-outputs.md @@ -205,7 +205,7 @@ Alike Input data, output results can be filtered so as to include only items tha [^13]: NODU and NP Cost do not appear in "Adequacy" results since these variables are irrelevant in that context -[^adqp]: Please note that this output variable is only available in the economy mode, when the adequacy patch is activated (see [Adequacy Patch](../optional-features/adequacy-patch.md)) +[^adqp]: Please note that this output variable is only available in the economy mode, when the adequacy patch is activated (see [Adequacy Patch](optional-features/adequacy-patch.md)) [^14]: This description applies to both ยซ MC synthesis ยป files and "Year-by-Year" files, with some simplifications in the latter case diff --git a/docs/user-guide/solver/static-modeler/04-parameters.md b/docs/user-guide/solver/04-parameters.md similarity index 96% rename from docs/user-guide/solver/static-modeler/04-parameters.md rename to docs/user-guide/solver/04-parameters.md index 8e11763544..5a18e4057f 100644 --- a/docs/user-guide/solver/static-modeler/04-parameters.md +++ b/docs/user-guide/solver/04-parameters.md @@ -24,11 +24,11 @@ These parameters are listed under the `[general]` section in the `.ini` file. - **Default value:** `economy` - **Usage:** this parameter sets the study mode for Antares - `economy/economic`: Antares simulator will try to ensure balance between load and generation, while minimizing the - economical cost of the grid's operation (more on this [here](../../01-overview.md#transmission-project-profitability)). "Economy" simulations make a full use of + economical cost of the grid's operation (more on this [here](../01-overview.md#transmission-project-profitability)). "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`: in this mode, all power plants' operational cost is considered zero. Antares' only objective is to ensure - balance between load and generation (more on this [here](../../01-overview.md#generation-adequacy-problems)). "Adequacy" simulations are faster and require only + balance between load and generation (more on this [here](../01-overview.md#generation-adequacy-problems)). "Adequacy" simulations are faster and require only technical input data. Their results are limited to adequacy indicators. - `expansion`: Antares simulator will optimize the investments on the grid, minimizing both investments and operational costs. @@ -431,7 +431,7 @@ _**This section is under construction**_ - `optim-2`: export MPS for second step of the optimization - `both-optims` or `true`: export MPS for both steps of the optimization -> _**Note:**_ You can find more information on this parameter [here](../03-appendix.md#details-on-the-include-exportmps-parameter). +> _**Note:**_ You can find more information on this parameter [here](08-appendix.md#details-on-the-include-exportmps-parameter). --- #### include-export-solutions @@ -480,7 +480,7 @@ _**This section is under construction**_ - `ERROR_DRY`: stop simulation - `ERROR_MPS`: stop simulation, and export the MPS of the unfeasible problem -> _**Note:**_ You can find more information on this parameter [here](../03-appendix.md#details-on-the-include-unfeasible-problem-behavior-parameter). +> _**Note:**_ You can find more information on this parameter [here](08-appendix.md#details-on-the-include-unfeasible-problem-behavior-parameter). --- #### linear-solver-parameters @@ -500,7 +500,7 @@ _**This section is under construction**_ --- ## Adequacy-patch parameters -Defines a set of options related to the [adequacy patch](../optional-features/adequacy-patch.md). +Defines a set of options related to the [adequacy patch](optional-features/adequacy-patch.md). The set of preferences is study-specific; it can be changed at any time and saved along with study data. These parameters are listed under the `[adequacy patch]` section in the `.ini` file. @@ -509,7 +509,7 @@ These parameters are listed under the `[adequacy patch]` section in the `.ini` f - **Expected value:** `true` or `false` - **Required:** no - **Default value:** `false` -- **Usage:** set this parameter to `true` if you want to enable the [Adequacy Patch](../optional-features/adequacy-patch.md) algorithm. +- **Usage:** set this parameter to `true` if you want to enable the [Adequacy Patch](optional-features/adequacy-patch.md) algorithm. --- #### set-to-null-ntc-from-physical-out-to-physical-in-for-first-step @@ -596,7 +596,7 @@ These parameters are listed under the `[other preferences]` section in the `.ini - `cold start` - `hot start` -> _**Note:**_ You can find more information on this parameter [here](../03-appendix.md#details-on-the-initial-reservoir-levels-parameter). +> _**Note:**_ You can find more information on this parameter [here](08-appendix.md#details-on-the-initial-reservoir-levels-parameter). --- #### hydro-heuristic-policy @@ -610,7 +610,7 @@ These parameters are listed under the `[other preferences]` section in the `.ini - `accommodate rule curves` - `maximize generation` -> _**Note:**_ You can find more information on this parameter [here](../03-appendix.md#details-on-the-hydro-heuristic-policy-parameter). +> _**Note:**_ You can find more information on this parameter [here](08-appendix.md#details-on-the-hydro-heuristic-policy-parameter). --- #### hydro-pricing-mode @@ -624,7 +624,7 @@ These parameters are listed under the `[other preferences]` section in the `.ini - `fast` - `accurate`: Note that this mode is significantly slower than the `fast` mode. -> _**Note:**_ You can find more information on this parameter [here](../03-appendix.md#details-on-the-hydro-pricing-mode-parameter). +> _**Note:**_ You can find more information on this parameter [here](08-appendix.md#details-on-the-hydro-pricing-mode-parameter). --- #### power-fluctuations @@ -666,7 +666,7 @@ These parameters are listed under the `[other preferences]` section in the `.ini - `accurate`: Heuristic in which 2 LP problems are solved. Explicit modelling for the number of ON/OFF units. Slower than `fast`. - `milp`: A single MILP problem is solved, with explicit modelling for the number of ON/OFF units. Slower than `accurate`. -> _**Note:**_ You can find more information on this parameter [here](../03-appendix.md#details-on-the-unit-commitment-mode-parameter). +> _**Note:**_ You can find more information on this parameter [here](08-appendix.md#details-on-the-unit-commitment-mode-parameter). --- #### number-of-cores-mode @@ -678,7 +678,7 @@ These parameters are listed under the `[other preferences]` section in the `.ini - `maximum` - **Required:** no - **Default value:** `medium` -- **Usage:** use this parameter to configure [multi-threading](../optional-features/multi-threading.md). +- **Usage:** use this parameter to configure [multi-threading](optional-features/multi-threading.md). --- #### renewable-generation-modelling @@ -692,7 +692,7 @@ These parameters are listed under the `[other preferences]` section in the `.ini - `aggregated` - `clusters` -> _**Note:**_ You can find more information on this parameter [here](../03-appendix.md#details-on-the-renewable-generation-modelling-parameter). +> _**Note:**_ You can find more information on this parameter [here](08-appendix.md#details-on-the-renewable-generation-modelling-parameter). --- #### day-ahead-reserve-management diff --git a/docs/user-guide/solver/static-modeler/05-model.md b/docs/user-guide/solver/05-model.md similarity index 99% rename from docs/user-guide/solver/static-modeler/05-model.md rename to docs/user-guide/solver/05-model.md index b05bb39509..0554a06d4b 100644 --- a/docs/user-guide/solver/static-modeler/05-model.md +++ b/docs/user-guide/solver/05-model.md @@ -31,7 +31,7 @@ The scope of this document is exclusively devoted to step (4). Note that equival The following picture gives a functional view of all that is involved in steps (1) to (5). In this illustration, Step (4), whose goal is to solve the problems introduced in this document, is materialized by the red box. -![Antares_Process](../img/Antares_Process.png) +![Antares_Process](img/Antares_Process.png) 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 @@ -564,7 +564,7 @@ Finally, upstream of the proper optimization, there is a last set of hydro-relat The following diagram summarizes the situation regarding both random and epsilon numbers defined and used within Antares. They are meant to build up, along with the regular description of the power system (physical limits and standard costs), an optimization framework that is up to the complex tasks at hand: balanced Monte- Carlo draws, reproducible simulations exploring the whole span of optimal operating configurations. -![Random_Parameters](../img/Random_Parameters.png) +![Random_Parameters](img/Random_Parameters.png) | Random Epsilons | Minimum absolute value | Maximum absolute value | |-----------------|-------------------------|--------------------------| diff --git a/docs/user-guide/solver/static-modeler/06-hydro-heuristics.md b/docs/user-guide/solver/06-hydro-heuristics.md similarity index 100% rename from docs/user-guide/solver/static-modeler/06-hydro-heuristics.md rename to docs/user-guide/solver/06-hydro-heuristics.md diff --git a/docs/user-guide/solver/static-modeler/07-thermal-heuristic.md b/docs/user-guide/solver/07-thermal-heuristic.md similarity index 97% rename from docs/user-guide/solver/static-modeler/07-thermal-heuristic.md rename to docs/user-guide/solver/07-thermal-heuristic.md index e43dbf0b77..d34213f553 100644 --- a/docs/user-guide/solver/static-modeler/07-thermal-heuristic.md +++ b/docs/user-guide/solver/07-thermal-heuristic.md @@ -12,7 +12,7 @@ Please note that this content is only relevant in case the user chooses a linear The linearised resolution of the weekly adequacy problem[^1] is summarized in the diagram below: -![Global diagram](../img/global_diagram.png){ .add-padding-and-white-bg } +![Global diagram](img/global_diagram.png){ .add-padding-and-white-bg } The general principle of the linear resolution is that two iterations of the weekly optimisation problem will be solved: - A first resolution in which integer variables are either linearised, or completely removed, depending on the "unit commitment mode" chosen (step 1). @@ -42,7 +42,7 @@ The first resolution of the problem is then run, and provides hourly power outpu #### Step 2: fast mode heuristic In step 2, for each cluster, a parameter $\Delta_{adjust,\theta} = max(\Delta_\theta^+, \Delta_\theta^-)$ is then calculated, which is the maximum of the minimum on and off durations. Hence, they are approximated to be of the same duration. For each week and each thermal cluster, the week is then divided in intervals of length $\Delta_{adjust,\theta}$. The week is supposed to be cyclic (hour 1 is the timestep followin hour 168), just like in the weekly optimization problem solved by Antares. Within each interval, the NODU of the cluster is increased to the maximum value of $M_{\theta, t}^{guide}$ during this period. This process is run several time by shifting the intervals timestep by timestep until all the possible week splits have been performed. Finally, the solution which minimizes the number of adjustments of the NODU is used as the solution of step 2 $M_{\theta,t}^{heuristic}$. -![Step 2 of the "fast" thermal mode](../img/thermal_heuristic_fast_step_2.png){ .add-padding-and-white-bg } +![Step 2 of the "fast" thermal mode](img/thermal_heuristic_fast_step_2.png){ .add-padding-and-white-bg }

Illustration of step 2 of the fast mode, with $\Delta_{adjust,\theta}$ equal to 2. Here, both solutions are acceptable as they involve 3 NODU adjustments.

#### Step 3: second resolution @@ -77,7 +77,7 @@ with $\sigma_\theta^+$ the startup cost of a unit of cluster $\theta$, and ${\ta The smoothing heuristic may then choose to increase the NODU in certain clusters when it identifies that a shut-down/start-up sequence lasted shorter than duration d. The new NODU cannot exceed the maximum accepted NODU to respect the production plan, which is equal to $floor(\frac{P_\theta}{\underline{P_\theta}})$. -![Step 4: smoothing heuristic](../img/thermal_smoothing_heuristic.png). +![Step 4: smoothing heuristic](img/thermal_smoothing_heuristic.png). [^1]: The formulation of the weekly optimization problem is described in the ["Formulation of the optimisation problems"](05-model.md) section. \ No newline at end of file diff --git a/docs/user-guide/solver/03-appendix.md b/docs/user-guide/solver/08-appendix.md similarity index 96% rename from docs/user-guide/solver/03-appendix.md rename to docs/user-guide/solver/08-appendix.md index 90dc6ca020..7f9ef21497 100644 --- a/docs/user-guide/solver/03-appendix.md +++ b/docs/user-guide/solver/08-appendix.md @@ -6,7 +6,7 @@ [//]: # (TODO: specify where the MPS files are written) -This [parameter](static-modeler/04-parameters.md#include-exportmps) does not influence the way calculations are carried +This [parameter](04-parameters.md#include-exportmps) does not influence the way calculations are carried out, nor does it change their results. The effect of this preference is that, if the parameter is activated, *Antares* will produce and store in the @@ -27,10 +27,10 @@ simulation is based. It is useful, however, to gather evidence on mathematical g File names are structured as follows: -- When the optimization parameter [simplex-range](static-modeler/04-parameters.md#simplex-range) is set on `week`: +- When the optimization parameter [simplex-range](04-parameters.md#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 parameter [simplex-range](static-modeler/04-parameters.md#simplex-range) is set on `day`: +- When the optimization parameter [simplex-range](04-parameters.md#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 @@ -50,7 +50,7 @@ txt extension. ## Details on the "include-unfeasible-problem-behavior" parameter -This [parameter](static-modeler/04-parameters.md#include-unfeasible-problem-behavior) can take one of the four values: +This [parameter](04-parameters.md#include-unfeasible-problem-behavior) can take one of the four values: `ERROR_DRY`, `ERROR_MPS`, `WARNING_DRY`, `WARNING_MPS` If `ERROR_DRY` or `ERROR_MPS` is selected, the simulation will stop right after encountering the first mathematically @@ -201,7 +201,7 @@ The water value is taken to remain about the same throughout the week, and a con 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](static-modeler/03-outputs.md). This +in [Output Files](03-outputs.md). 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. @@ -211,7 +211,7 @@ The water value is considered as variable throughout the week. As a consequence, 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](static-modeler/03-outputs.md). This option +positive for generation, negative for pumping) defined in [Output Files](03-outputs.md). 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. diff --git a/docs/user-guide/solver/02-command-line.md b/docs/user-guide/solver/09-command-line.md similarity index 66% rename from docs/user-guide/solver/02-command-line.md rename to docs/user-guide/solver/09-command-line.md index 526f54b6f8..ac6bf10eea 100644 --- a/docs/user-guide/solver/02-command-line.md +++ b/docs/user-guide/solver/09-command-line.md @@ -9,36 +9,36 @@ hide: ## Simulation -| command | usage | -|:-----------------------|:----------------------------------------------------------------------------------------------------------------------------------| -| -i, --input | Study folder | -| --expansion | Force the simulation in [expansion](static-modeler/04-parameters.md#mode) mode | -| --economy | Force the simulation in [economy](static-modeler/04-parameters.md#mode) mode | -| --adequacy | Force the simulation in [adequacy](static-modeler/04-parameters.md#mode) mode | -| --parallel | Enable [parallel](optional-features/multi-threading.md) computation of MC years | -| --force-parallel=VALUE | Override the max number of years computed [simultaneously](optional-features/multi-threading.md) | -| --linear-solver=VALUE | The optimization solver to use for linear problems. Possible values are: `sirius` (default), `coin`, `xpress`, `scip` | +| command | usage | +|:-----------------------|:--------------------------------------------------------------------------------------------------| +| -i, --input | Study folder | +| --expansion | Force the simulation in [expansion](04-parameters.md#mode) mode | +| --economy | Force the simulation in [economy](04-parameters.md#mode) mode | +| --adequacy | Force the simulation in [adequacy](04-parameters.md#mode) mode | +| --parallel | Enable [parallel](optional-features/multi-threading.md) computation of MC years | +| --force-parallel=VALUE | Override the max number of years computed [simultaneously](optional-features/multi-threading.md) | +| --linear-solver=VALUE | The optimization solver to use for linear problems. Possible values are: `sirius` (default), `coin`, `xpress`, `scip` | | --quadratic-solver=VALUE | The optimization solver to use for quadratic problems. Possible values are: `sirius` (default), `pdlp` | ## Parameters -| command | usage | -|:-------------------------|:----------------------------------------------------------------------------------------------------------------| -| -n, --name=VALUE | Set the name of the new simulation | -| -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](static-modeler/04-parameters.md#nbyears) | -| --year-by-year | Force the [writing the result output for each year](static-modeler/04-parameters.md#year-by-year) (economy only) | -| --derated | Force the [derated](static-modeler/04-parameters.md#derated) mode | -| -z, --zip-output | Write the results into a single zip archive | +| command | usage | +|:-------------------------|:--------------------------------------------------------------------------------------------------| +| -n, --name=VALUE | Set the name of the new simulation | +| -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](04-parameters.md#nbyears) | +| --year-by-year | Force the [writing the result output for each year](04-parameters.md#year-by-year) (economy only) | +| --derated | Force the [derated](04-parameters.md#derated) mode | +| -z, --zip-output | Write the results into a single zip archive | ## Optimization | command | usage | |:-------------------------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| --optimization-range | Force the [simplex optimization range](static-modeler/04-parameters.md#simplex-range) ('day' or 'week') | +| --optimization-range | Force the [simplex optimization range](04-parameters.md#simplex-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) | | -m, --mps-export | Export anonymous MPS, weekly or daily optimal UC+dispatch linear (MPS will be named if the problem is infeasible) | diff --git a/docs/user-guide/solver/dynamic-modeler/02-inputs.md b/docs/user-guide/solver/dynamic-modeler/02-inputs.md deleted file mode 100644 index f0eff54ca7..0000000000 --- a/docs/user-guide/solver/dynamic-modeler/02-inputs.md +++ /dev/null @@ -1,3 +0,0 @@ -# Input files - -_**This section is under construction**_ \ No newline at end of file diff --git a/docs/user-guide/solver/dynamic-modeler/03-outputs.md b/docs/user-guide/solver/dynamic-modeler/03-outputs.md deleted file mode 100644 index 447b91809d..0000000000 --- a/docs/user-guide/solver/dynamic-modeler/03-outputs.md +++ /dev/null @@ -1,3 +0,0 @@ -# Output files - -_**This feature is under development**_ \ No newline at end of file diff --git a/docs/user-guide/solver/dynamic-modeler/04-parameters.md b/docs/user-guide/solver/dynamic-modeler/04-parameters.md deleted file mode 100644 index ce619350b6..0000000000 --- a/docs/user-guide/solver/dynamic-modeler/04-parameters.md +++ /dev/null @@ -1,3 +0,0 @@ -# Parameters - -_**This feature is under development**_ diff --git a/docs/user-guide/solver/static-modeler/00-index.md b/docs/user-guide/solver/static-modeler/00-index.md deleted file mode 100644 index 1b8d1f07e3..0000000000 --- a/docs/user-guide/solver/static-modeler/00-index.md +++ /dev/null @@ -1,14 +0,0 @@ -[//]: # (Index used by Sphinx to generate correct PDF tree) - -# Legacy Solver - -```{toctree} -:hidden: -01-overview-legacy-solver.md -02-inputs.md -03-outputs.md -04-parameters.md -05-model.md -06-hydro-heuristics.md -07-thermal-heuristic.md -``` \ No newline at end of file diff --git a/docs/user-guide/solver/static-modeler/01-overview-static-modeler.md b/docs/user-guide/solver/static-modeler/01-overview-static-modeler.md deleted file mode 100644 index 728296c45e..0000000000 --- a/docs/user-guide/solver/static-modeler/01-overview-static-modeler.md +++ /dev/null @@ -1,64 +0,0 @@ -# Overview - -_**This section is under construction**_ - -The *Solver* is *Antares Simulator*'s main feature. - -**Monte Carlo Simulation** Runs either an economy simulation or an adequacy simulation -depending on the values of the [parameters](04-parameters.md). -If hardware resources and simulation settings allow it, simulations can benefit from [multi-threading](../optional-features/multi-threading.md). - - -## Antares at one glance - -This section gives a summary of the whole simulation process followed by Antares in Economy simulations (Adequacy being simplified variant 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/link - -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: - - i. 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) - - ii. 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. - - iii. 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**. - -- **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_ | -|------|-----------|------------| -| _R0_ | _Yes_ | _Yes_ | -| _R3_ | _Yes_ | _Yes_ | \ No newline at end of file diff --git a/docs/user-guide/ts-generator/01-overview-tsgenerator.md b/docs/user-guide/ts-generator/01-overview-tsgenerator.md index 67349f7654..fd8c2bbe3a 100644 --- a/docs/user-guide/ts-generator/01-overview-tsgenerator.md +++ b/docs/user-guide/ts-generator/01-overview-tsgenerator.md @@ -4,6 +4,6 @@ _**This section is under construction**_ The Time-Series Generator tool is intended to be used before running an *Antares* simulation if you do not dispose of all the needed input data. -This tool can be used to generate automatically [any or all](../solver/static-modeler/04-parameters.md) stochastic input data +This tool can be used to generate automatically [any or all](../solver/04-parameters.md) stochastic input data (such as renewable energy production time-series) -and put them automatically inside the *Antares* [solver](../solver/static-modeler/02-inputs.md)'s input directory. +and put them automatically inside the *Antares* [solver](../solver/02-inputs.md)'s input directory. diff --git a/docs/user-guide/ts-generator/04-parameters.md b/docs/user-guide/ts-generator/04-parameters.md index 6da36c8ece..debe1465cc 100644 --- a/docs/user-guide/ts-generator/04-parameters.md +++ b/docs/user-guide/ts-generator/04-parameters.md @@ -167,7 +167,7 @@ These parameters are listed under the `[input]` section in the `.ini` file. should be exported into the input files (in replacement of the original ones). > _**Note:**_ -> you can also use [archives](../solver/static-modeler/04-parameters.md#archives) to store the time-series in the output folder. +> you can also use [archives](../solver/04-parameters.md#archives) to store the time-series in the output folder. --- ## Seeds - Mersenne Twister parameters diff --git a/mkdocs.yml b/mkdocs.yml index 14b203357d..b7f0a3a738 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -38,29 +38,29 @@ nav: - 'Getting started': 'user-guide/03-getting_started.md' - 'Solver': - 'Overview': 'user-guide/solver/01-overview-solver.md' - - 'Static Modeler': - - 'Overview': 'user-guide/solver/static-modeler/01-overview-static-modeler.md' - - 'Input files': 'user-guide/solver/static-modeler/02-inputs.md' - - 'Output files': 'user-guide/solver/static-modeler/03-outputs.md' - - 'Parameters': 'user-guide/solver/static-modeler/04-parameters.md' - - 'Optimization model': 'user-guide/solver/static-modeler/05-model.md' - - 'Hydro heuristics': 'user-guide/solver/static-modeler/06-hydro-heuristics.md' - - 'Thermal heuristics': 'user-guide/solver/static-modeler/07-thermal-heuristic.md' - - 'Dynamic Modeler': - - 'Overview': 'user-guide/solver/dynamic-modeler/01-overview-dynamic-modeler.md' - - 'Input files': 'user-guide/solver/dynamic-modeler/02-inputs.md' - - 'Output files': 'user-guide/solver/dynamic-modeler/03-outputs.md' - - 'Parameters': 'user-guide/solver/dynamic-modeler/04-parameters.md' - - 'Optimization model': 'user-guide/solver/dynamic-modeler/05-model.md' - - 'Heuristics': 'user-guide/solver/dynamic-modeler/06-heuristics.md' - - 'Standard library': 'user-guide/solver/dynamic-modeler/07-standard-library.md' - - 'Hybrid studies': 'user-guide/solver/dynamic-modeler/08-hybrid-studies.md' - - 'Command-line instructions': 'user-guide/solver/02-command-line.md' + - 'Input files': 'user-guide/solver/02-inputs.md' + - 'Output files': 'user-guide/solver/03-outputs.md' + - 'Parameters': 'user-guide/solver/04-parameters.md' + - 'Optimization model': 'user-guide/solver/05-model.md' + - 'Hydro heuristics': 'user-guide/solver/06-hydro-heuristics.md' + - 'Thermal heuristics': 'user-guide/solver/07-thermal-heuristic.md' + - 'Appendix': 'user-guide/solver/08-appendix.md' + - 'Command-line interface': 'user-guide/solver/09-command-line.md' - 'Optional features': - 'Multi-threading': 'user-guide/solver/optional-features/multi-threading.md' - 'Adequacy patch': 'user-guide/solver/optional-features/adequacy-patch.md' - 'Usage with FICOยฎ Xpress Optimizer': 'user-guide/solver/optional-features/xpress.md' - 'Appendix': 'user-guide/solver/03-appendix.md' + - 'Modeler': + - 'Overview': 'user-guide/modeler/01-overview-dynamic-modeler.md' + - 'Input files': 'user-guide/modeler/02-inputs.md' + - 'Output files': 'user-guide/modeler/03-outputs.md' + - 'Parameters': 'user-guide/modeler/04-parameters.md' + - 'Optimization model': 'user-guide/modeler/05-model.md' + - 'Heuristics': 'user-guide/modeler/06-heuristics.md' + - 'Standard library': 'user-guide/modeler/07-standard-library.md' + - 'Hybrid studies': 'user-guide/modeler/08-hybrid-studies.md' + - 'Command-line interface': 'user-guide/modeler/09-command-line.md' - 'Time-series generation': - 'Overview': 'user-guide/ts-generator/01-overview-tsgenerator.md' - 'Input files': 'user-guide/ts-generator/02-inputs.md'