diff --git a/README.md b/README.md index d89922a..727007f 100755 --- a/README.md +++ b/README.md @@ -14,8 +14,8 @@ ### Documentation -* [Usage](https://axavier.org/projects/UnitCommitment.jl/usage/) -* [Data Format](https://axavier.org/projects/UnitCommitment.jl/format/) +* [Usage](https://anl-ceeesa.github.io/UnitCommitment.jl/0.1/usage/) +* [Data Format](https://anl-ceeesa.github.io/UnitCommitment.jl/0.1/format/) ### Authors * **Alinson Santos Xavier** (Argonne National Laboratory) diff --git a/mkdocs.yml b/mkdocs.yml index b54e6c2..b238d71 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -1,5 +1,8 @@ site_name: UnitCommitment.jl -theme: cinder +theme: + name: cinder + hljs_languages: + - julia copyright: "Copyright © 2020, UChicago Argonne, LLC. All Rights Reserved." repo_url: https://github.com/ANL-CEEESA/unitcommitment.jl edit_uri: edit/dev/src/docs/ @@ -12,6 +15,7 @@ plugins: markdown_extensions: - admonition - mdx_math + - fenced_code extra_javascript: - https://cdnjs.cloudflare.com/ajax/libs/mathjax/2.7.0/MathJax.js?config=TeX-AMS-MML_HTMLorMML - js/mathjax.js diff --git a/src/docs/format.md b/src/docs/format.md index 4dcd6fa..5d3af0f 100644 --- a/src/docs/format.md +++ b/src/docs/format.md @@ -1,6 +1,8 @@ Data Format =========== +## 1. Input Data Format + Instances are specified by JSON files containing the following main sections: * [Parameters](#parameters) @@ -13,7 +15,7 @@ Instances are specified by JSON files containing the following main sections: Each section is described in detail below. For a complete example, see [case14.json](https://github.com/ANL-CEEESA/UnitCommitment.jl/blob/dev/instances/matpower-24h/case14.json). -## Parameters +### 1.1 Parameters This section describes system-wide parameters, such as power balance penalties, and optimization parameters, such as the length of the planning horizon. @@ -23,7 +25,7 @@ This section describes system-wide parameters, such as power balance penalties, | `Power balance penalty ($/MW)` | Penalty for system-wide shortage or surplus in production (in $/MW). This is charged per time period. For example, if there is a shortage of 1 MW for three time periods, three times this amount will be charged. | `1000.0` | Y -### Example +#### Example ```json { "Parameters": { @@ -33,7 +35,7 @@ This section describes system-wide parameters, such as power balance penalties, } ``` -## Buses +### 1.2 Buses This section describes the characteristics of each bus in the system. @@ -42,7 +44,7 @@ This section describes the characteristics of each bus in the system. | `Load (MW)` | Fixed load connected to the bus (in MW). | Required | Y -### Example +#### Example ```json { "Buses": { @@ -62,7 +64,7 @@ This section describes the characteristics of each bus in the system. ``` -## Generators +### 1.3 Generators This section describes all generators in the system, including thermal units, renewable units and virtual units. @@ -82,7 +84,7 @@ This section describes all generators in the system, including thermal units, re | `Must run?` | If `true`, the generator should be committed, even that is not economical (Boolean). | `false` | Y | `Provides spinning reserves?` | If `true`, this generator may provide spinning reserves (Boolean). | `true` | Y -### Production costs and limits +#### Production costs and limits Production costs are represented as piecewise-linear curves. Figure 1 shows an example cost curve with three segments, where it costs 1400, 1600, 2200 and 2400 dollars to generate, respectively, 100, 110, 130 and 135 MW of power. To model this generator, `Production cost curve (MW)` should be set to `[100, 110, 130, 135]`, and `Production cost curve ($)` should be set to `[1400, 1600, 2200, 2400]`. Note that this curve also specifies the production limits. Specifically, the first point identifies the minimum power output when the unit is operational, while the last point identifies the maximum power output. @@ -93,14 +95,14 @@ Note that this curve also specifies the production limits. Specifically, the fir
-**Additional remarks:** +#### Additional remarks: * For time-dependent production limits or time-dependent production costs, the usage of nested arrays is allowed. For example, if `Production cost curve (MW)` is set to `[5.0, [10.0, 12.0, 15.0, 20.0]]`, then the unit may generate at most 10, 12, 15 and 20 MW of power during time periods 1, 2, 3 and 4, respectively. The minimum output for all time periods is fixed to at 5 MW. * There is no limit to the number of piecewise-linear segments, and different generators may have a different number of segments. * If `Production cost curve (MW)` and `Production cost curve ($)` both contain a single element, then the generator must produce exactly that amount of power when operational. To specify that the generator may produce any amount of power up to a certain limit `P`, the parameter `Production cost curve (MW)` should be set to `[0, P]`. * Production cost curves must be convex. -### Example +#### Example ```json { @@ -131,7 +133,7 @@ Note that this curve also specifies the production limits. Specifically, the fir } ``` -## Price-sensitive loads +### 1.4 Price-sensitive loads This section describes components in the system which may increase or reduce their energy consumption according to the energy prices. Fixed loads (as described in the `buses` section) are always served, regardless of the price, unless there is significant congestion in the system or insufficient production capacity. Price-sensitive loads, on the other hand, are only served if it is economical to do so. @@ -142,7 +144,7 @@ This section describes components in the system which may increase or reduce the | `Demand (MW)` | Maximum amount of power required by this load. Any amount lower than this may be served. | Required | Y -### Example +#### Example ```json { "Price-sensitive loads": { @@ -155,7 +157,7 @@ This section describes components in the system which may increase or reduce the } ``` -## Transmission Lines +### 1.5 Transmission Lines This section describes the characteristics of transmission system, such as its topology and the susceptance of each transmission line. @@ -169,7 +171,7 @@ This section describes the characteristics of transmission system, such as its t | `Emergency flow limit (MW)` | Maximum amount of power (in MW) allowed to flow through the line when the system is in degraded state (for example, after the failure of another transmission line). | `+inf` | Y | `Flow limit penalty ($/MW)` | Penalty for violating the flow limits of the transmission line (in $/MW). This is charged per time period. For example, if there is a thermal violation of 1 MW for three time periods, three times this amount will be charged. | `5000.0` | Y -### Example +#### Example ```json { @@ -188,7 +190,7 @@ This section describes the characteristics of transmission system, such as its t ``` -## Reserves +### 1.6 Reserves This section describes the hourly amount of operating reserves required. @@ -197,7 +199,7 @@ This section describes the hourly amount of operating reserves required. | :-------------------- | :------------------------------------------------- | --------- | :----: | `Spinning (MW)` | Minimum amount of system-wide spinning reserves (in MW). Only generators which are online may provide this reserve. | `0.0` | Y -### Example +#### Example ```json { @@ -212,7 +214,7 @@ This section describes the hourly amount of operating reserves required. } ``` -## Contingencies +### 1.7 Contingencies This section describes credible contingency scenarios in the optimization, such as the loss of a transmission line or generator. @@ -221,7 +223,7 @@ This section describes credible contingency scenarios in the optimization, such | `Affected generators` | List of generators affected by this contingency. May be omitted if no generators are affected. | `[]` | `Affected lines` | List of transmission lines affected by this contingency. May be omitted if no lines are affected. | `[]` -### Example +#### Example ```json { @@ -237,9 +239,9 @@ This section describes credible contingency scenarios in the optimization, such } ``` -## Additional remarks +### 1.8 Additional remarks -### Time series parameters +#### Time series parameters Many numerical properties in the JSON file can be specified either as a single floating point number if they are time-independent, or as an array containing exactly `T` elements, where `T` is the length of the planning horizon, if they are time-dependent. For example, both formats below are valid when `T=3`: @@ -250,8 +252,13 @@ Many numerical properties in the JSON file can be specified either as a single f } ``` -### Current limitations +#### Current limitations * All reserves are system-wide (no zonal reserves) * Network topology remains the same for all time periods * Only N-1 transmission contingencies are supported. Generator contingencies are not supported. +* Time-varying minimum production amounts are not currently compatible with ramp/startup/shutdown limits. + +## 2. Output Data Format + +The output data format is also JSON-based, but it is not currently documented since we expect it to change significantly in a future version of the package. \ No newline at end of file diff --git a/src/docs/index.md b/src/docs/index.md index a27cd18..5ef804b 100644 --- a/src/docs/index.md +++ b/src/docs/index.md @@ -1,6 +1,6 @@ # UnitCommitment.jl -**UnitCommitment.jl** (UC.jl) is an optimization package for the Security-Constrained Unit Commitment Problem (SCUC), a fundamental optimization problem in power systems used, for example, to clear the day-ahead electricity markets. The package provides benchmark instances for the problem and JuMP implementations of state-of-the-art mixed-integer programming formulations. +**UnitCommitment.jl** (UC.jl) is a Julia optimization package for the Security-Constrained Unit Commitment Problem (SCUC), a fundamental optimization problem in power systems used, for example, to clear the day-ahead electricity markets. The package provides benchmark instances for the problem and Julia/JuMP implementations of state-of-the-art mixed-integer programming formulations. ### Package Components diff --git a/src/docs/isf.md b/src/docs/isf.md deleted file mode 100644 index 4d46ff3..0000000 --- a/src/docs/isf.md +++ /dev/null @@ -1,19 +0,0 @@ -Linear Sensitivity Factors -========================== - -UnitCommitment.jl includes a number of functions to compute typical linear sensitivity -factors, such as [Injection Shift Factors](@ref) and [Line Outage Distribution Factors](@ref). These sensitivity factors can be used to quickly compute DC power flows in both base and N-1 contigency scenarios. - -Injection Shift Factors ------------------------ -Given a network with `B` buses and `L` transmission lines, the Injection Shift Factors (ISF) matrix is an `L`-by-`B` matrix which indicates much power flows through a certain transmission line when 1 MW of power is injected at bus `b` and withdrawn from the slack bus. For example, `isf[:l7, :b5]` indicates the amount of power (in MW) that flows through line `l7` when 1 MW of power is injected at bus `b5` and withdrawn from the slack bus. -This matrix is computed based on the DC linearization of power flow equations and does not include losses. -To compute the ISF matrix, the function `injection_shift_factors` can be used. It is necessary to specify the set of lines, buses and the slack bus: -```julia -using UnitCommitment -instance = UnitCommitment.load("ieee_rts/case14") -isf = UnitCommitment.injection_shift_factors(lines = instance.lines, - buses = instance.buses, - slack = :b14) -@show isf[:l7, :b5] -``` \ No newline at end of file diff --git a/src/docs/model.md b/src/docs/model.md deleted file mode 100644 index c874cc9..0000000 --- a/src/docs/model.md +++ /dev/null @@ -1,90 +0,0 @@ -Benchmark Model -=============== - -UnitCommitment.jl includes a reference Mixed-Integer Linear Programming -(MILP), built with [JuMP](https://github.com/JuliaOpt/JuMP.jl), which can -either be used as-is to solve instances of the problem, or be extended to -build more complex formulations. - -Building and Solving the Model -------------------------------- - -Given an instance and a JuMP optimizer, the function `build_model` can be used to -build the reference MILP model. For example: - -```julia -using UnitCommitment, JuMP, Cbc -instance = UnitCommitment.load("ieee_rts/case118") -model = build_model(instance, with_optimizer(Cbc.Optimizer)) -``` - -The model enforces all unit constraints described in [Unit Commitment -Instances](@ref), including ramping, minimum-up and minimum-down times. Some -system-wide constraints, such as spinning reserves, are also enforced. The -model, however, does not enforce transmission or N-1 security constraints, -since these are typically generated on-the-fly. - -A reference to the JuMP model is stored at `model.mip`. After constructed, the model can -be optimized as follows: - -```julia -optimize!(model.mip) -``` - -Decision Variables ------------------- - -References to all decision variables are stored at `model.vars`. -A complete list of available decision variables is as follows: - -| Variable | Description -| :---------------------------- | :--------------------------- -| `model.vars.production[gi,t]` | Amount of power (in MW) produced by unit with index `gi` at time `t`. -| `model.vars.reserve[gi,t]` | Amount of spinning reserves (in MW) provided by unit with index `gi` at time `t`. -| `model.vars.is_on[gi,t]` | Binary variable indicating if unit with index `gi` is operational at time `t`. -| `model.vars.switch_on[gi,t]` | Binary variable indicating if unit with index `gi` was switched on at time `t`. That is, the unit was not operational at time `t-1`, but it is operational at time `t`. -| `model.vars.switch_off[gi,t]` | Binary variable indicating if unit with index `gi` was switched off at time `t`. That is, the unit was operational at time `t-1`, but it is no longer operational at time `t`. -| `model.vars.unit_cost[gi,t]` | The total cost to operate unit with index `gi` at time `t`. Includes start-up costs, no-load costs and any other production costs. -| `model.vars.cost[t]` | Total cost at time `t`. -| `model.vars.net_injection[bi,t]` | Total net injection (in MW) at bus with index `bi` and time `t`. Net injection is defined as the total power being produced by units located at the bus minus the bus load. - - -Accessing the Solution ----------------------- -To access the value of a particular decision variable after the -optimization is completed, the function `JuMP.value(var)` can be used. The -following example prints the amount of power (in MW) produced by each unit at time 5: - -```julia -for g in instance.units - @show value(model.vars.production[g.index, 5]) -end -``` - -Modifying the Model -------------------- - -Prior to being solved, the reference model can be modified by using the variable references -above and conventional JuMP macros. For example, the -following code can be used to ensure that at most 10 units are operational at time 4: - -```julia -using UnitCommitment, JuMP, Cbc -instance = UnitCommitment.load("ieee_rts/case118") -model = build_model(instance, with_optimizer(Cbc.Optimizer)) - -@contraint(model.mip, - sum(model.vars.is_on[g.index, 4] - for g in instance.units) <= 10) - -optimize!(model.mip) -``` - -It is not currently possible to modify the constraints included in the -reference model. - -Reference ---------- -```@docs -UnitCommitment.build_model -``` \ No newline at end of file diff --git a/src/docs/usage.md b/src/docs/usage.md index f452694..5272f5c 100644 --- a/src/docs/usage.md +++ b/src/docs/usage.md @@ -1,6 +1,8 @@ -# Installation Guide +# Usage -This package was tested and developed with [Julia 1.5](https://julialang.org/). To install Julia, please follow the [installation guide on their website](https://julialang.org/downloads/platform.html). To install `UnitCommitment.jl`, run the Julia interpreter, type `]` to open the package manager, then type: +## 1. Installation + +UnitCommitment.jl was tested and developed with [Julia 1.5](https://julialang.org/). To install Julia, please follow the [installation guide on the official Julia website](https://julialang.org/downloads/platform.html). To install UnitCommitment.jl, run the Julia interpreter, type `]` to open the package manager, then type: ```text pkg> add https://github.com/ANL-CEEESA/UnitCommitment.jl.git @@ -12,7 +14,91 @@ To test that the package has been correctly installed, run: pkg> test UnitCommitment ``` -If all tests pass, the package should now be ready to be used by any Julia script on the machine. To try it out in the julia interpreter hit `backspace` to return to the regular interpreter, and type the following command: +If all tests pass, the package should now be ready to be used by any Julia script on the machine. + +To solve the optimization models, a mixed-integer linear programming (MILP) solver is also required. Please see the [JuMP installation guide](https://jump.dev/JuMP.jl/stable/installation/) for more instructions on installing a solver. Typical open-source choices are [Cbc](https://github.com/JuliaOpt/Cbc.jl) and [GLPK](https://github.com/JuliaOpt/GLPK.jl). In the instructions below, Cbc will be used, but any other MILP solver listed in JuMP installation guide should also be compatible. + +## 2. Typical Usage + +### 2.1 Solving user-provided instances + +The first step to use UC.jl is to construct a JSON file describing your unit commitment instance. See the [data format page]() for a complete description of the data format UC.jl expects. The next steps, as shown below, are to read the instance from file, construct the optimization model, run the optimization and extract the optimal solution. + +```julia +using Cbc +using UnitCommitment + +# Read instance +instance = UnitCommitment.read("/path/to/input.json") + +# Construct optimization model +model = UnitCommitment.build_model(instance, Cbc.Optimizer) + +# Solve model +UnitCommitment.optimize!(model) + +# Extract solution and write it to a file +solution = UnitCommitment.get_solution(model) +open("/path/to/output.json", "w") do file + JSON.print(file, solution, 2) +end +``` + +### 2.2 Solving benchmark instances + +As described in the [instances page](), UnitCommitment.jl contains a number of benchmark instances collected from the literature. To solve one of these instances individually, instead of constructing your own, the function `read_benchmark` can be used: + +```julia +using UnitCommitment +instance = UnitCommitment.read_benchmark("matpower/case3375wp/2017-01-01") +``` + +## 3. Advanced usage + + +### 3.1 Modifying the formulation + +For the time being, the recommended way of modifying the MILP formulation used by UC.jl is to create a local copy of our git repository and directly modify the source code of the package. In a future version, it will be possible to switch between multiple formulations, or to simply add/remove constraints after the model has been generated. + +### 3.2 Generating initial conditions + + +When creating random unit commitment instances for benchmark purposes, it is often hard to compute, in advance, sensible initial conditions for all generators. Setting initial conditions naively (for example, making all generators initially off and producing no power) can easily cause the instance to become infeasible due to excessive ramping. Initial conditions can also make it hard to modify existing instances. For example, increasing the system load without carefully modifying the initial conditions may make the problem infeasible or unrealistically challenging to solve. + +To help with this issue, UC.jl provides a utility function which can generate feasible initial conditions by solving a single-period optimization problem, as shown below: + +```julia +using Cbc +using UnitCommitment + +# Read original instance +instance = UnitCommitment.read("instance.json") + +# Generate initial conditions (in-place) +UnitCommitment.generate_initial_conditions!(instance, Cbc.Optimizer) + +# Construct and solve optimization model +model = UnitCommitment.build_model(instance, Cbc.Optimizer) +UnitCommitment.optimize!(model) +``` + +!!! warning + The function `generate_initial_conditions!` may return different initial conditions after each call, even if the same instance and the same optimizer is provided. The particular algorithm may also change in a future version of UC.jl. For these reasons, it is recommended that you generate initial conditions exactly once for each instance and store them for later use. + +### 3.3 Verifying solutions + +When developing new formulations, it is very easy to introduce subtle errors in the model that result in incorrect solutions. To help with this, UC.jl includes a utility function that verifies if a given solution is feasible, and, if not, prints all the validation errors it found. The implementation of this function is completely independent from the implementation of the optimization model, and therefore can be used to validate it. The function can also be used to verify solutions produced by other optimization packages, as long as they follow the [UC.jl data format](format.md). + ```julia +using JSON using UnitCommitment + +# Read instance +instance = UnitCommitment.read("instance.json") + +# Read solution (potentially produced by other packages) +solution = JSON.parsefile("solution.json") + +# Validate solution and print validation errors +UnitCommitment.validate(instance, solution) ```