Implement MIPLearn solution method

Remove unused 'reactance' field
Minor correction to ISF definition
2025-12-06 00:08:52 -06:00 · 2024-01-09 14:27:46 -06:00 · 2023-08-01 12:31:19 -05:00 · 2023-08-01 12:21:22 -05:00 · 2023-07-27 12:02:13 -05:00 · 2023-07-27 11:49:47 -05:00
344 changed files with 8947 additions and 2655 deletions
--- a/.github/workflows/test.yml
+++ b/.github/workflows/test.yml
@@ -1,4 +1,4 @@
-name: Tests
+name: Build & Test
 on:
  push:
  pull_request:
@@ -6,19 +6,30 @@ on:
    - cron: '45 10 * * *'
 jobs:
  test:
+    name: Julia ${{ matrix.version }} - ${{ matrix.os }} - ${{ matrix.arch }}
    runs-on: ${{ matrix.os }}
    strategy:
      matrix:
-        julia-version: ['1.4', '1.5', '1.6']
-        julia-arch: [x64]
-        os: [ubuntu-latest, windows-latest, macOS-latest]
-        exclude:
-          - os: macOS-latest
-            julia-arch: x86
+        version: ['1.6', '1.7', '1.8', '1.9']
+        os:
+          - ubuntu-latest
+        arch:
+          - x64
    steps:
      - uses: actions/checkout@v2
-      - uses: julia-actions/setup-julia@latest
+      - uses: julia-actions/setup-julia@v1
        with:
-          version: ${{ matrix.julia-version }}
-      - uses: julia-actions/julia-buildpkg@latest
-      - uses: julia-actions/julia-runtest@latest
+          version: ${{ matrix.version }}
+          arch: ${{ matrix.arch }}
+      - name: Run tests
+        shell: julia --color=yes --project=test {0}
+        run: |
+          using Pkg
+          Pkg.develop(path=".")
+          Pkg.update()
+          using UnitCommitmentT
+          try
+            runtests()
+          catch
+            exit(1)
+          end
--- a/.gitignore
+++ b/.gitignore
@@ -1,21 +1,38 @@
 *.bak
 *.gz
-*.lastrun
-*.so
-*.mps
 *.ipynb
+*.lastrun
+*.mps
+*.so
+*/Manifest.toml
+.AppleDB
+.AppleDesktop
+.AppleDouble
+.DS_Store
+.DocumentRevisions-V100
+.LSOverride
+.Spotlight-V100
+.TemporaryItems
+.Trashes
+.VolumeIcon.icns
+._*
+.apdisk
+.com.apple.timemachine.donotpresent
+.fseventsd
 .ipy*
+.vscode
+Icon
+Manifest.toml
+Network Trash Folder
+TODO.md
+Temporary Items
 benchmark/results
 benchmark/runs
 benchmark/tables
 benchmark/tmp.json
 build
+docs/_build
 instances/**/*.json
 instances/_source
 local
 notebooks
-TODO.md
-docs/_build
-.vscode
-Manifest.toml
-*/Manifest.toml
--- a/.zenodo.json
+++ b/.zenodo.json
@@ -0,0 +1,27 @@
+{
+    "creators": [
+      {
+        "orcid": "0000-0002-5022-9802",
+        "affiliation": "Argonne National Laboratory",
+        "name": "Santos Xavier, Alinson"
+      },
+      {
+        "affiliation": "University of Florida",
+        "name": "Kazachkov, Aleksandr M."
+      },
+      {
+        "affiliation": "Technische Universität Berlin",
+        "name": "Yurdakul, Ogün"
+      },
+      {
+        "affiliation": "Purdue University",
+        "name": "He, Jun"
+      },
+      {
+        "affiliation": "Argonne National Laboratory",
+        "name": "Qiu, Feng"
+      }
+    ],
+    "title": "UnitCommitment.jl: A Julia/JuMP Optimization Package for Security-Constrained Unit Commitment",
+    "description": "<b>UnitCommitment.jl</b> (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 Julia/JuMP implementations of state-of-the-art mixed-integer programming formulations."
+  }
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -11,6 +11,21 @@ All notable changes to this project will be documented in this file.
 [semver]: https://semver.org/spec/v2.0.0.html
 [pkjjl]: https://pkgdocs.julialang.org/v1/compatibility/#compat-pre-1.0

+## [0.3.0] - 2022-07-18
+### Added
+- Add support for multiple reserve products and zonal reserves.
+- Add flexiramp reserve products, following WanHob2016's formulation (@oyurdakul, #21).
+- Add 365 variations for each MATPOWER instance, corresponding to each day of the year.
+
+### Changed
+- To support multiple/zonal reserves, the input data format has been modified as follows:
+    - In `Generators`, replace `Provides spinning reserves?` by `Reserve eligibility`
+    - In `Parameters`, remove `Reserve shortfall penalty`
+    - Revise `Reserves` section
+- To allow new versions of UnitCommitment.jl to read old instance files, a new required field `Version` has been added to the `Parameters` section. To load v0.2 files in v0.3, please add `{"Parameters":{"Version":"0.2"}}` to the file.
+- Benchmark test cases are now downloaded on-the-fly as needed, instead of being stored in our GitHub repository. Test cases can also be directly downloaded from: https://axavier.org/UnitCommitment.jl/
+
+
 ## [0.2.2] - 2021-07-21
 ### Fixed
 - Fix small bug in validation scripts related to startup costs
--- a/LICENSE.md
+++ b/LICENSE.md
@@ -1,4 +1,4 @@
-Copyright © 2020, UChicago Argonne, LLC
+Copyright © 2020-2022, UChicago Argonne, LLC

 All Rights Reserved

--- a/20
+++ b/20
@@ -2,22 +2,10 @@
 # Copyright (C) 2020, UChicago Argonne, LLC. All rights reserved.
 # Released under the modified BSD license. See COPYING.md for more details.

-VERSION := 0.2
-
-clean:
-	rm -rfv build
+VERSION := 0.3

 docs:
-	cd docs; make clean; make dirhtml
-	rsync -avP --delete-after docs/_build/dirhtml/ ../docs/$(VERSION)/
+	cd docs; julia --project=. make.jl; cd ..
+	rsync -avP --delete-after docs/build/ ../docs/$(VERSION)/
 	
-format:
-	cd deps/formatter; ../../juliaw format.jl
-
-test: test/Manifest.toml
-	./juliaw test/runtests.jl
-
-test/Manifest.toml: test/Project.toml
-	julia --project=test -e "using Pkg; Pkg.instantiate()"
-
-.PHONY: docs test format install-deps
+.PHONY: docs
--- a/Project.toml
+++ b/Project.toml
@@ -2,7 +2,7 @@ name = "UnitCommitment"
 uuid = "64606440-39ea-11e9-0f29-3303a1d3d877"
 authors = ["Santos Xavier, Alinson <axavier@anl.gov>"]
 repo = "https://github.com/ANL-CEEESA/UnitCommitment.jl"
-version = "0.2.2"
+version = "0.3.0"

 [deps]
 DataStructures = "864edb3b-99cc-5e75-8d2d-829cb0a9cfe8"
@@ -13,18 +13,24 @@ JSON = "682c06a0-de6a-54ab-a142-c8b1cf79cde6"
 JuMP = "4076af6c-e467-56ae-b986-b466b2749572"
 LinearAlgebra = "37e2e46d-f89d-539d-b4ee-838fcccc9c8e"
 Logging = "56ddb016-857b-54e1-b83d-db4d58db5568"
+MPI = "da04e1cc-30fd-572f-bb4f-1f8673147195"
 MathOptInterface = "b8f27783-ece8-5eb3-8dc8-9495eed66fee"
 PackageCompiler = "9b87118b-4619-50d2-8e1e-99f35a4d4d9d"
 Printf = "de0858da-6303-5e67-8744-51eddeeeb8d7"
 Random = "9a3f8284-a2c9-5f02-9a11-845980a1fd5c"
+Requires = "ae029012-a4dd-5104-9daa-d747884805df"
 SparseArrays = "2f01184e-e22b-5df5-ae63-d93ebab69eaf"
+Suppressor = "fd094767-a336-5f1f-9728-57cf17d0bbfb"
+TimerOutputs = "a759f4b9-e2f1-59dc-863e-4aeb61b1ea8f"

 [compat]
 DataStructures = "0.18"
 Distributions = "0.25"
 GZip = "0.5"
 JSON = "0.21"
-JuMP = "0.21"
-MathOptInterface = "0.9"
+JuMP = "1"
+MPI = "0.20"
+MathOptInterface = "1"
 PackageCompiler = "1"
+TimerOutputs = "0.5"
 julia = "1"
--- a/README.md
+++ b/README.md
@@ -87,19 +87,22 @@ UnitCommitment.write("/tmp/output.json", solution)

 ## Documentation

-1. [Usage](https://anl-ceeesa.github.io/UnitCommitment.jl/0.2/usage/)
-2. [Data Format](https://anl-ceeesa.github.io/UnitCommitment.jl/0.2/format/)
-3. [Instances](https://anl-ceeesa.github.io/UnitCommitment.jl/0.2/instances/)
-4. [JuMP Model](https://anl-ceeesa.github.io/UnitCommitment.jl/0.2/model/)
+1. [Usage](https://anl-ceeesa.github.io/UnitCommitment.jl/0.3/usage/)
+2. [Data Format](https://anl-ceeesa.github.io/UnitCommitment.jl/0.3/format/)
+3. [Instances](https://anl-ceeesa.github.io/UnitCommitment.jl/0.3/instances/)
+4. [JuMP Model](https://anl-ceeesa.github.io/UnitCommitment.jl/0.3/model/)
+5. [API Reference](https://anl-ceeesa.github.io/UnitCommitment.jl/0.3/api/)

 ## Authors
 * **Alinson S. Xavier** (Argonne National Laboratory)
 * **Aleksandr M. Kazachkov** (University of Florida)
+* **Ogün Yurdakul** (Technische Universität Berlin)
+* **Jun He** (Purdue University)
 * **Feng Qiu** (Argonne National Laboratory)

 ## Acknowledgments

-* We would like to **Yonghong Chen** (Midcontinent Independent System Operator), **Feng Pan** (Pacific Northwest National Laboratory) for valuable feedback on early versions of this package.
+* We would like to thank **Yonghong Chen** (Midcontinent Independent System Operator), **Feng Pan** (Pacific Northwest National Laboratory) for valuable feedback on early versions of this package.

 * Based upon work supported by **Laboratory Directed Research and Development** (LDRD) funding from Argonne National Laboratory, provided by the Director, Office of Science, of the U.S. Department of Energy under Contract No. DE-AC02-06CH11357

@@ -109,15 +112,15 @@ UnitCommitment.write("/tmp/output.json", solution)

 If you use UnitCommitment.jl in your research (instances, models or algorithms), we kindly request that you cite the package as follows:

-* **Alinson S. Xavier, Aleksandr M. Kazachkov, Feng Qiu**. "UnitCommitment.jl: A Julia/JuMP Optimization Package for Security-Constrained Unit Commitment". Zenodo (2020). [DOI: 10.5281/zenodo.4269874](https://doi.org/10.5281/zenodo.4269874).
+* **Alinson S. Xavier, Aleksandr M. Kazachkov, Ogün Yurdakul, Feng Qiu**. "UnitCommitment.jl: A Julia/JuMP Optimization Package for Security-Constrained Unit Commitment (Version 0.3)". Zenodo (2022). [DOI: 10.5281/zenodo.4269874](https://doi.org/10.5281/zenodo.4269874).

-If you use the instances, we additionally request that you cite the original sources, as described in the [instances page](docs/instances.md).
+If you use the instances, we additionally request that you cite the original sources, as described in the documentation.

 ## License

 ```text
 UnitCommitment.jl: A Julia/JuMP Optimization Package for Security-Constrained Unit Commitment
-Copyright © 2020-2021, UChicago Argonne, LLC. All Rights Reserved.
+Copyright © 2020-2022, UChicago Argonne, LLC. All Rights Reserved.

 Redistribution and use in source and binary forms, with or without modification, are permitted
 provided that the following conditions are met:
--- a/benchmark/run.jl
+++ b/benchmark/run.jl
@@ -126,9 +126,13 @@ formulations = Dict(

 # Solution methods
 # -----------------------------------------------------------------------------
+const gap_limit = parse(Float64, args["--gap"])
+const time_limit = parse(Float64, args["--time-limit"])
 methods = Dict(
-    "default" =>
-        XavQiuWanThi2019.Method(time_limit = 3600.0, gap_limit = 1e-4),
+    "default" => XavQiuWanThi2019.Method(
+        time_limit = time_limit,
+        gap_limit = gap_limit,
+    ),
 )

 # MIP solvers
@@ -154,8 +158,6 @@ end
 if !isempty(args["--solver"])
    optimizers = filter(p -> p.first in args["--solver"], optimizers)
 end
-const time_limit = parse(Float64, args["--time-limit"])
-const gap_limit = parse(Float64, args["--gap"])
 const ntrials = parse(Int, args["--trials"])

 # Print benchmark settings
--- a/deps/formatter/Project.toml
+++ b/deps/formatter/Project.toml
@@ -1,5 +0,0 @@
-[deps]
-JuliaFormatter = "98e50ef6-434e-11e9-1051-2b60c6c9e899"
-
-[compat]
-JuliaFormatter = "0.14.4"
--- a/deps/formatter/format.jl
+++ b/deps/formatter/format.jl
@@ -1,9 +0,0 @@
-using JuliaFormatter
-format(
-    [
-        "../../src", 
-        "../../test",
-        "../../benchmark/run.jl",
-    ],
-    verbose=true,
-)
--- a/docs/Makefile
+++ b/docs/Makefile
@@ -1,14 +0,0 @@
-SPHINXOPTS    ?=
-SPHINXBUILD   ?= sphinx-build
-SOURCEDIR     = .
-BUILDDIR      = _build
-
-help:
-	@$(SPHINXBUILD) -M help "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
-
-.PHONY: help Makefile
-
-# Catch-all target: route all unknown targets to Sphinx using the new
-# "make mode" option.  $(O) is meant as a shortcut for $(SPHINXOPTS).
-%: Makefile
-	@$(SPHINXBUILD) -M $@ "$(SOURCEDIR)" "$(BUILDDIR)" $(SPHINXOPTS) $(O)
--- a/docs/Project.toml
+++ b/docs/Project.toml
@@ -0,0 +1,9 @@
+[deps]
+Documenter = "e30172f5-a6a5-5a46-863b-614d45cd2de4"
+Glob = "c27321d9-0574-5035-807b-f59d2c89b15c"
+HiGHS = "87dc4568-4c63-4d18-b0c0-bb2238e4078b"
+JSON = "682c06a0-de6a-54ab-a142-c8b1cf79cde6"
+JuMP = "4076af6c-e467-56ae-b986-b466b2749572"
+MPI = "da04e1cc-30fd-572f-bb4f-1f8673147195"
+Revise = "295af30f-e4ad-537b-8983-00126c2a3abe"
+UnitCommitment = "64606440-39ea-11e9-0f29-3303a1d3d877"
--- a/docs/_static/custom.css
+++ b/docs/_static/custom.css
@@ -1,49 +0,0 @@
-h1.site-logo {
-    font-size: 30px !important;
-}
-
-h1.site-logo small {
-    font-size: 20px !important;
-}
-
-h1.site-logo {
-    font-size: 30px !important;
-}
-
-h1.site-logo small {
-    font-size: 20px !important;
-}
-
-tbody, thead, pre {
-    border: 1px solid rgba(0, 0, 0, 0.25);
-}
-
-table td, th {
-    padding: 8px;
-}
-
-table p {
-    margin-bottom: 0;
-}
-
-table td code {
-    white-space: nowrap;
-}
-
-table tr,
-table th {
-    border-bottom: 1px solid rgba(0, 0, 0, 0.1);
-}
-
-table tr:last-child {
-    border-bottom: 0;
-}
-
-pre {
-    box-shadow: inherit !important;
-    background-color: #fff;
-}
-
-.text-align\:center {
-    text-align: center;
-}
--- a/docs/conf.py
+++ b/docs/conf.py
@@ -1,16 +0,0 @@
-project = "UnitCommitment.jl"
-copyright = "2020-2021, UChicago Argonne, LLC"
-author = ""
-release = "0.2"
-extensions = ["myst_parser"]
-templates_path = ["_templates"]
-exclude_patterns = ["_build", "Thumbs.db", ".DS_Store"]
-html_theme = "sphinx_book_theme"
-html_static_path = ["_static"]
-html_css_files = ["custom.css"]
-html_theme_options = {
-    "repository_url": "https://github.com/ANL-CEEESA/UnitCommitment.jl/",
-    "use_repository_button": True,
-    "extra_navbar": "",
-}
-html_title = f"UnitCommitment.jl<br/><small>{release}</small>"
--- a/docs/example/out.json
+++ b/docs/example/out.json
--- a/docs/example/s1.json
+++ b/docs/example/s1.json
@@ -0,0 +1,495 @@
+{
+    "Parameters": {
+	"Version": "0.3",
+        "Time horizon (h)": 4
+    },
+    "Generators": {
+        "g1": {
+            "Bus": "b1",
+            "Production cost curve (MW)": [
+                100,
+                110,
+                130,
+                135
+            ],
+            "Production cost curve ($)": [
+                1400,
+                1600,
+                2200,
+                2400
+            ],
+            "Startup delays (h)": [
+                1,
+                2,
+                3
+            ],
+            "Startup costs ($)": [
+                1000.0,
+                1500.0,
+                2000.0
+            ],
+            "Initial status (h)": -100,
+            "Initial power (MW)": 0
+        },
+        "g2": {
+            "Bus": "b2",
+            "Production cost curve (MW)": [
+                0,
+                47,
+                94,
+                140
+            ],
+            "Production cost curve ($)": [
+                0,
+                2256.00,
+                4733.37,
+                7395.39
+            ],
+            "Startup delays (h)": [
+                1,
+                4
+            ],
+            "Startup costs ($)": [
+                3000.0,
+                4000.0
+            ],
+            "Ramp up limit (MW)": 98.0,
+            "Ramp down limit (MW)": 98.0,
+            "Startup limit (MW)": 98.0,
+            "Shutdown limit (MW)": 98.0,
+            "Minimum uptime (h)": 4,
+            "Minimum downtime (h)": 4,
+            "Maximum daily energy (MWh)": null,
+            "Maximum daily starts": null,
+            "Initial status (h)": -8,
+            "Initial power (MW)": 0,
+            "Reserve eligibility": [
+                "r1"
+            ]
+        },
+        "g3": {
+            "Bus": "b3",
+            "Production cost curve (MW)": [
+                0,
+                33,
+                66,
+                100
+            ],
+            "Production cost curve ($)": [
+                0,
+                1113.75,
+                2369.07,
+                3891.54
+            ],
+            "Startup delays (h)": [
+                1,
+                4,
+                8
+            ],
+            "Startup costs ($)": [
+                1000.0,
+                2000.0,
+                3000.0
+            ],
+            "Ramp up limit (MW)": 70.0,
+            "Ramp down limit (MW)": 70.0,
+            "Startup limit (MW)": 70.0,
+            "Shutdown limit (MW)": 70.0,
+            "Must run?": true,
+            "Minimum uptime (h)": 1,
+            "Minimum downtime (h)": 1,
+            "Maximum daily energy (MWh)": null,
+            "Maximum daily starts": null,
+            "Initial status (h)": -6,
+            "Initial power (MW)": 0,
+            "Reserve eligibility": [
+                "r1"
+            ]
+        },
+        "g4": {
+            "Bus": "b6",
+            "Production cost curve (MW)": [
+                33,
+                66,
+                100
+            ],
+            "Production cost curve ($)": [
+                1113.75,
+                2369.07,
+                3891.54
+            ],
+            "Initial status (h)": -100,
+            "Initial power (MW)": 0,
+            "Reserve eligibility": [
+                "r1"
+            ]
+        },
+        "g5": {
+            "Bus": "b8",
+            "Production cost curve (MW)": [
+                33,
+                66,
+                100
+            ],
+            "Production cost curve ($)": [
+                1113.75,
+                2369.07,
+                3891.54
+            ],
+            "Initial status (h)": -100,
+            "Initial power (MW)": 0,
+            "Reserve eligibility": [
+                "r1"
+            ]
+        },
+        "g6": {
+            "Bus": "b8",
+            "Production cost curve (MW)": [
+                100
+            ],
+            "Production cost curve ($)": [
+                10000.00
+            ],
+            "Initial status (h)": -100,
+            "Initial power (MW)": 0,
+            "Reserve eligibility": [
+                "r1"
+            ]
+        }
+    },
+    "Buses": {
+        "b1": {
+            "Load (MW)": 0.0
+        },
+        "b2": {
+            "Load (MW)": [
+                26.01527,
+                24.46212,
+                23.29725,
+                22.90897
+            ]
+        },
+        "b3": {
+            "Load (MW)": [
+                112.93263,
+                106.19039,
+                101.1337,
+                99.44814
+            ]
+        },
+        "b4": {
+            "Load (MW)": [
+                57.30552,
+                53.88429,
+                51.31838,
+                50.46307
+            ]
+        },
+        "b5": {
+            "Load (MW)": [
+                9.11134,
+                8.56738,
+                8.15941,
+                8.02342
+            ]
+        },
+        "b6": {
+            "Load (MW)": [
+                13.42723,
+                12.62561,
+                12.02439,
+                11.82398
+            ]
+        },
+        "b7": {
+            "Load (MW)": 0.0
+        },
+        "b8": {
+            "Load (MW)": 0.0
+        },
+        "b9": {
+            "Load (MW)": [
+                35.36638,
+                33.25495,
+                31.67138,
+                31.14353
+            ]
+        },
+        "b10": {
+            "Load (MW)": [
+                10.78974,
+                10.14558,
+                9.66246,
+                9.50141
+            ]
+        },
+        "b11": {
+            "Load (MW)": [
+                4.19601,
+                3.9455,
+                3.75762,
+                3.69499
+            ]
+        },
+        "b12": {
+            "Load (MW)": [
+                7.31305,
+                6.87645,
+                6.549,
+                6.43985
+            ]
+        },
+        "b13": {
+            "Load (MW)": [
+                16.18461,
+                15.21837,
+                14.49368,
+                14.25212
+            ]
+        },
+        "b14": {
+            "Load (MW)": [
+                17.86302,
+                16.79657,
+                15.99673,
+                15.73012
+            ]
+        }
+    },
+    "Transmission lines": {
+        "l1": {
+            "Source bus": "b1",
+            "Target bus": "b2",
+            "Reactance (ohms)": 0.05917000000000001,
+            "Susceptance (S)": 29.496860773945063,
+            "Normal flow limit (MW)": 300.0,
+            "Emergency flow limit (MW)": 400.0,
+            "Flow limit penalty ($/MW)": 1000.0
+        },
+        "l2": {
+            "Source bus": "b1",
+            "Target bus": "b5",
+            "Reactance (ohms)": 0.22304000000000002,
+            "Susceptance (S)": 7.825184953346168
+        },
+        "l3": {
+            "Source bus": "b2",
+            "Target bus": "b3",
+            "Reactance (ohms)": 0.19797,
+            "Susceptance (S)": 8.816129979261149
+        },
+        "l4": {
+            "Source bus": "b2",
+            "Target bus": "b4",
+            "Reactance (ohms)": 0.17632,
+            "Susceptance (S)": 9.898645939169292
+        },
+        "l5": {
+            "Source bus": "b2",
+            "Target bus": "b5",
+            "Reactance (ohms)": 0.17388,
+            "Susceptance (S)": 10.037550333530765
+        },
+        "l6": {
+            "Source bus": "b3",
+            "Target bus": "b4",
+            "Reactance (ohms)": 0.17103,
+            "Susceptance (S)": 10.204813494675376
+        },
+        "l7": {
+            "Source bus": "b4",
+            "Target bus": "b5",
+            "Reactance (ohms)": 0.04211,
+            "Susceptance (S)": 41.44690695783257
+        },
+        "l8": {
+            "Source bus": "b4",
+            "Target bus": "b7",
+            "Reactance (ohms)": 0.20911999999999997,
+            "Susceptance (S)": 8.346065665619404
+        },
+        "l9": {
+            "Source bus": "b4",
+            "Target bus": "b9",
+            "Reactance (ohms)": 0.55618,
+            "Susceptance (S)": 3.1380654680037567
+        },
+        "l10": {
+            "Source bus": "b5",
+            "Target bus": "b6",
+            "Reactance (ohms)": 0.25201999999999997,
+            "Susceptance (S)": 6.92536009838239
+        },
+        "l11": {
+            "Source bus": "b6",
+            "Target bus": "b11",
+            "Reactance (ohms)": 0.1989,
+            "Susceptance (S)": 8.774908255376218
+        },
+        "l12": {
+            "Source bus": "b6",
+            "Target bus": "b12",
+            "Reactance (ohms)": 0.25581,
+            "Susceptance (S)": 6.8227561549365925
+        },
+        "l13": {
+            "Source bus": "b6",
+            "Target bus": "b13",
+            "Reactance (ohms)": 0.13027,
+            "Susceptance (S)": 13.397783465067395
+        },
+        "l14": {
+            "Source bus": "b7",
+            "Target bus": "b8",
+            "Reactance (ohms)": 0.17615,
+            "Susceptance (S)": 9.908198989465395
+        },
+        "l15": {
+            "Source bus": "b7",
+            "Target bus": "b9",
+            "Reactance (ohms)": 0.11001,
+            "Susceptance (S)": 15.865187273832648
+        },
+        "l16": {
+            "Source bus": "b9",
+            "Target bus": "b10",
+            "Reactance (ohms)": 0.0845,
+            "Susceptance (S)": 20.65478404727017
+        },
+        "l17": {
+            "Source bus": "b9",
+            "Target bus": "b14",
+            "Reactance (ohms)": 0.27038,
+            "Susceptance (S)": 6.4550974628091184
+        },
+        "l18": {
+            "Source bus": "b10",
+            "Target bus": "b11",
+            "Reactance (ohms)": 0.19207,
+            "Susceptance (S)": 9.08694357262628
+        },
+        "l19": {
+            "Source bus": "b12",
+            "Target bus": "b13",
+            "Reactance (ohms)": 0.19988,
+            "Susceptance (S)": 8.73188539120637
+        },
+        "l20": {
+            "Source bus": "b13",
+            "Target bus": "b14",
+            "Reactance (ohms)": 0.34802,
+            "Susceptance (S)": 5.0150257226433235
+        }
+    },
+    "Contingencies": {
+        "c1": {
+            "Affected lines": [
+                "l1"
+            ]
+        },
+        "c2": {
+            "Affected lines": [
+                "l2"
+            ]
+        },
+        "c3": {
+            "Affected lines": [
+                "l3"
+            ]
+        },
+        "c4": {
+            "Affected lines": [
+                "l4"
+            ]
+        },
+        "c5": {
+            "Affected lines": [
+                "l5"
+            ]
+        },
+        "c6": {
+            "Affected lines": [
+                "l6"
+            ]
+        },
+        "c7": {
+            "Affected lines": [
+                "l7"
+            ]
+        },
+        "c8": {
+            "Affected lines": [
+                "l8"
+            ]
+        },
+        "c9": {
+            "Affected lines": [
+                "l9"
+            ]
+        },
+        "c10": {
+            "Affected lines": [
+                "l10"
+            ]
+        },
+        "c11": {
+            "Affected lines": [
+                "l11"
+            ]
+        },
+        "c12": {
+            "Affected lines": [
+                "l12"
+            ]
+        },
+        "c13": {
+            "Affected lines": [
+                "l13"
+            ]
+        },
+        "c15": {
+            "Affected lines": [
+                "l15"
+            ]
+        },
+        "c16": {
+            "Affected lines": [
+                "l16"
+            ]
+        },
+        "c17": {
+            "Affected lines": [
+                "l17"
+            ]
+        },
+        "c18": {
+            "Affected lines": [
+                "l18"
+            ]
+        },
+        "c19": {
+            "Affected lines": [
+                "l19"
+            ]
+        },
+        "c20": {
+            "Affected lines": [
+                "l20"
+            ]
+        }
+    },
+    "Price-sensitive loads": {
+        "ps1": {
+            "Bus": "b3",
+            "Revenue ($/MW)": 100.0,
+            "Demand (MW)": 50.0
+        }
+    },
+    "Reserves": {
+        "r1": {
+            "Type": "Spinning",
+            "Amount (MW)": 100.0,
+            "Shortfall penalty ($/MW)": 1000.0
+        }
+    }
+}
--- a/docs/example/s2.json
+++ b/docs/example/s2.json
@@ -0,0 +1,495 @@
+{
+    "Parameters": {
+	"Version": "0.3",
+        "Time horizon (h)": 4
+    },
+    "Generators": {
+        "g1": {
+            "Bus": "b1",
+            "Production cost curve (MW)": [
+                100,
+                110,
+                130,
+                135
+            ],
+            "Production cost curve ($)": [
+                1400,
+                1600,
+                2200,
+                2400
+            ],
+            "Startup delays (h)": [
+                1,
+                2,
+                3
+            ],
+            "Startup costs ($)": [
+                1000.0,
+                1500.0,
+                2000.0
+            ],
+            "Initial status (h)": -100,
+            "Initial power (MW)": 0
+        },
+        "g2": {
+            "Bus": "b2",
+            "Production cost curve (MW)": [
+                0,
+                47,
+                94,
+                140
+            ],
+            "Production cost curve ($)": [
+                0,
+                2256.00,
+                4733.37,
+                7395.39
+            ],
+            "Startup delays (h)": [
+                1,
+                4
+            ],
+            "Startup costs ($)": [
+                3000.0,
+                4000.0
+            ],
+            "Ramp up limit (MW)": 98.0,
+            "Ramp down limit (MW)": 98.0,
+            "Startup limit (MW)": 98.0,
+            "Shutdown limit (MW)": 98.0,
+            "Minimum uptime (h)": 4,
+            "Minimum downtime (h)": 4,
+            "Maximum daily energy (MWh)": null,
+            "Maximum daily starts": null,
+            "Initial status (h)": -8,
+            "Initial power (MW)": 0,
+            "Reserve eligibility": [
+                "r1"
+            ]
+        },
+        "g3": {
+            "Bus": "b3",
+            "Production cost curve (MW)": [
+                0,
+                33,
+                66,
+                100
+            ],
+            "Production cost curve ($)": [
+                0,
+                1113.75,
+                2369.07,
+                3891.54
+            ],
+            "Startup delays (h)": [
+                1,
+                4,
+                8
+            ],
+            "Startup costs ($)": [
+                1000.0,
+                2000.0,
+                3000.0
+            ],
+            "Ramp up limit (MW)": 70.0,
+            "Ramp down limit (MW)": 70.0,
+            "Startup limit (MW)": 70.0,
+            "Shutdown limit (MW)": 70.0,
+            "Must run?": true,
+            "Minimum uptime (h)": 1,
+            "Minimum downtime (h)": 1,
+            "Maximum daily energy (MWh)": null,
+            "Maximum daily starts": null,
+            "Initial status (h)": -6,
+            "Initial power (MW)": 0,
+            "Reserve eligibility": [
+                "r1"
+            ]
+        },
+        "g4": {
+            "Bus": "b6",
+            "Production cost curve (MW)": [
+                33,
+                66,
+                100
+            ],
+            "Production cost curve ($)": [
+                1113.75,
+                2369.07,
+                3891.54
+            ],
+            "Initial status (h)": -100,
+            "Initial power (MW)": 0,
+            "Reserve eligibility": [
+                "r1"
+            ]
+        },
+        "g5": {
+            "Bus": "b8",
+            "Production cost curve (MW)": [
+                33,
+                66,
+                100
+            ],
+            "Production cost curve ($)": [
+                1113.75,
+                2369.07,
+                3891.54
+            ],
+            "Initial status (h)": -100,
+            "Initial power (MW)": 0,
+            "Reserve eligibility": [
+                "r1"
+            ]
+        },
+        "g6": {
+            "Bus": "b8",
+            "Production cost curve (MW)": [
+                100
+            ],
+            "Production cost curve ($)": [
+                10000.00
+            ],
+            "Initial status (h)": -100,
+            "Initial power (MW)": 0,
+            "Reserve eligibility": [
+                "r1"
+            ]
+        }
+    },
+    "Buses": {
+        "b1": {
+            "Load (MW)": 0.0
+        },
+        "b2": {
+            "Load (MW)": [
+                26.01527,
+                24.46212,
+                23.29725,
+                22.90897
+            ]
+        },
+        "b3": {
+            "Load (MW)": [
+                112.93263,
+                106.19039,
+                101.1337,
+                99.44814
+            ]
+        },
+        "b4": {
+            "Load (MW)": [
+                57.30552,
+                53.88429,
+                51.31838,
+                50.46307
+            ]
+        },
+        "b5": {
+            "Load (MW)": [
+                9.11134,
+                8.56738,
+                8.15941,
+                8.02342
+            ]
+        },
+        "b6": {
+            "Load (MW)": [
+                13.42723,
+                12.62561,
+                12.02439,
+                11.82398
+            ]
+        },
+        "b7": {
+            "Load (MW)": 0.0
+        },
+        "b8": {
+            "Load (MW)": 0.0
+        },
+        "b9": {
+            "Load (MW)": [
+                35.36638,
+                33.25495,
+                31.67138,
+                31.14353
+            ]
+        },
+        "b10": {
+            "Load (MW)": [
+                10.78974,
+                10.14558,
+                9.66246,
+                9.50141
+            ]
+        },
+        "b11": {
+            "Load (MW)": [
+                4.19601,
+                3.9455,
+                3.75762,
+                3.69499
+            ]
+        },
+        "b12": {
+            "Load (MW)": [
+                7.31305,
+                6.87645,
+                6.549,
+                6.43985
+            ]
+        },
+        "b13": {
+            "Load (MW)": [
+                16.18461,
+                15.21837,
+                14.49368,
+                14.25212
+            ]
+        },
+        "b14": {
+            "Load (MW)": [
+                17.86302,
+                16.79657,
+                15.99673,
+                15.73012
+            ]
+        }
+    },
+    "Transmission lines": {
+        "l1": {
+            "Source bus": "b1",
+            "Target bus": "b2",
+            "Reactance (ohms)": 0.05917000000000001,
+            "Susceptance (S)": 29.496860773945063,
+            "Normal flow limit (MW)": 300.0,
+            "Emergency flow limit (MW)": 400.0,
+            "Flow limit penalty ($/MW)": 1000.0
+        },
+        "l2": {
+            "Source bus": "b1",
+            "Target bus": "b5",
+            "Reactance (ohms)": 0.22304000000000002,
+            "Susceptance (S)": 7.825184953346168
+        },
+        "l3": {
+            "Source bus": "b2",
+            "Target bus": "b3",
+            "Reactance (ohms)": 0.19797,
+            "Susceptance (S)": 8.816129979261149
+        },
+        "l4": {
+            "Source bus": "b2",
+            "Target bus": "b4",
+            "Reactance (ohms)": 0.17632,
+            "Susceptance (S)": 9.898645939169292
+        },
+        "l5": {
+            "Source bus": "b2",
+            "Target bus": "b5",
+            "Reactance (ohms)": 0.17388,
+            "Susceptance (S)": 10.037550333530765
+        },
+        "l6": {
+            "Source bus": "b3",
+            "Target bus": "b4",
+            "Reactance (ohms)": 0.17103,
+            "Susceptance (S)": 10.204813494675376
+        },
+        "l7": {
+            "Source bus": "b4",
+            "Target bus": "b5",
+            "Reactance (ohms)": 0.04211,
+            "Susceptance (S)": 41.44690695783257
+        },
+        "l8": {
+            "Source bus": "b4",
+            "Target bus": "b7",
+            "Reactance (ohms)": 0.20911999999999997,
+            "Susceptance (S)": 8.346065665619404
+        },
+        "l9": {
+            "Source bus": "b4",
+            "Target bus": "b9",
+            "Reactance (ohms)": 0.55618,
+            "Susceptance (S)": 3.1380654680037567
+        },
+        "l10": {
+            "Source bus": "b5",
+            "Target bus": "b6",
+            "Reactance (ohms)": 0.25201999999999997,
+            "Susceptance (S)": 6.92536009838239
+        },
+        "l11": {
+            "Source bus": "b6",
+            "Target bus": "b11",
+            "Reactance (ohms)": 0.1989,
+            "Susceptance (S)": 8.774908255376218
+        },
+        "l12": {
+            "Source bus": "b6",
+            "Target bus": "b12",
+            "Reactance (ohms)": 0.25581,
+            "Susceptance (S)": 6.8227561549365925
+        },
+        "l13": {
+            "Source bus": "b6",
+            "Target bus": "b13",
+            "Reactance (ohms)": 0.13027,
+            "Susceptance (S)": 13.397783465067395
+        },
+        "l14": {
+            "Source bus": "b7",
+            "Target bus": "b8",
+            "Reactance (ohms)": 0.17615,
+            "Susceptance (S)": 9.908198989465395
+        },
+        "l15": {
+            "Source bus": "b7",
+            "Target bus": "b9",
+            "Reactance (ohms)": 0.11001,
+            "Susceptance (S)": 15.865187273832648
+        },
+        "l16": {
+            "Source bus": "b9",
+            "Target bus": "b10",
+            "Reactance (ohms)": 0.0845,
+            "Susceptance (S)": 20.65478404727017
+        },
+        "l17": {
+            "Source bus": "b9",
+            "Target bus": "b14",
+            "Reactance (ohms)": 0.27038,
+            "Susceptance (S)": 6.4550974628091184
+        },
+        "l18": {
+            "Source bus": "b10",
+            "Target bus": "b11",
+            "Reactance (ohms)": 0.19207,
+            "Susceptance (S)": 9.08694357262628
+        },
+        "l19": {
+            "Source bus": "b12",
+            "Target bus": "b13",
+            "Reactance (ohms)": 0.19988,
+            "Susceptance (S)": 8.73188539120637
+        },
+        "l20": {
+            "Source bus": "b13",
+            "Target bus": "b14",
+            "Reactance (ohms)": 0.34802,
+            "Susceptance (S)": 5.0150257226433235
+        }
+    },
+    "Contingencies": {
+        "c1": {
+            "Affected lines": [
+                "l1"
+            ]
+        },
+        "c2": {
+            "Affected lines": [
+                "l2"
+            ]
+        },
+        "c3": {
+            "Affected lines": [
+                "l3"
+            ]
+        },
+        "c4": {
+            "Affected lines": [
+                "l4"
+            ]
+        },
+        "c5": {
+            "Affected lines": [
+                "l5"
+            ]
+        },
+        "c6": {
+            "Affected lines": [
+                "l6"
+            ]
+        },
+        "c7": {
+            "Affected lines": [
+                "l7"
+            ]
+        },
+        "c8": {
+            "Affected lines": [
+                "l8"
+            ]
+        },
+        "c9": {
+            "Affected lines": [
+                "l9"
+            ]
+        },
+        "c10": {
+            "Affected lines": [
+                "l10"
+            ]
+        },
+        "c11": {
+            "Affected lines": [
+                "l11"
+            ]
+        },
+        "c12": {
+            "Affected lines": [
+                "l12"
+            ]
+        },
+        "c13": {
+            "Affected lines": [
+                "l13"
+            ]
+        },
+        "c15": {
+            "Affected lines": [
+                "l15"
+            ]
+        },
+        "c16": {
+            "Affected lines": [
+                "l16"
+            ]
+        },
+        "c17": {
+            "Affected lines": [
+                "l17"
+            ]
+        },
+        "c18": {
+            "Affected lines": [
+                "l18"
+            ]
+        },
+        "c19": {
+            "Affected lines": [
+                "l19"
+            ]
+        },
+        "c20": {
+            "Affected lines": [
+                "l20"
+            ]
+        }
+    },
+    "Price-sensitive loads": {
+        "ps1": {
+            "Bus": "b3",
+            "Revenue ($/MW)": 100.0,
+            "Demand (MW)": 50.0
+        }
+    },
+    "Reserves": {
+        "r1": {
+            "Type": "Spinning",
+            "Amount (MW)": 100.0,
+            "Shortfall penalty ($/MW)": 1000.0
+        }
+    }
+}
--- a/docs/format.md
+++ b/docs/format.md
@@ -1,294 +0,0 @@
-```{sectnum}
---
-start: 2
-depth: 2
-suffix: .
---
-```
-
-
-Data Format
-===========
-
-
-Input Data Format
-----------------
-
-Instances are specified by JSON files containing the following main sections:
-
-* Parameters
-* Buses
-* Generators
-* Price-sensitive loads
-* Transmission lines
-* Reserves
-* Contingencies
-
-Each section is described in detail below. For a complete example, see [case14](https://github.com/ANL-CEEESA/UnitCommitment.jl/tree/dev/instances/matpower/case14).
-
-### Parameters
-
-This section describes system-wide parameters, such as power balance and reserve shortfall penalties, and optimization parameters, such as the length of the planning horizon and the time.
-
-| Key                            | Description                                       | Default  | Time series?
-| :----------------------------- | :------------------------------------------------ | :------: | :------------:
-| `Time horizon (h)` | Length of the planning horizon (in hours). | Required | N
-| `Time step (min)` | Length of each time step (in minutes). Must be a divisor of 60 (e.g. 60, 30, 20, 15, etc). | `60` | N
-| `Power balance penalty ($/MW)` | Penalty for system-wide shortage or surplus in production (in $/MW). This is charged per time step. For example, if there is a shortage of 1 MW for three time steps, three times this amount will be charged. | `1000.0` | Y
-| `Reserve shortfall penalty ($/MW)` | Penalty for system-wide shortage in meeting reserve requirements (in $/MW). This is charged per time step. Negative value implies reserve constraints must always be satisfied. | `-1` | Y
-
-
-#### Example
-```json
-{
-    "Parameters": {
-        "Time horizon (h)": 4,
-        "Power balance penalty ($/MW)": 1000.0,
-        "Reserve shortfall penalty ($/MW)": -1.0
-    }
-}
-```
-
-### Buses
-
-This section describes the characteristics of each bus in the system. 
-
-| Key                | Description                                                   | Default | Time series?
-| :----------------- | :------------------------------------------------------------ | ------- | :-------------:
-| `Load (MW)`        | Fixed load connected to the bus (in MW).                      | Required | Y
-
-
-#### Example
-```json
-{
-    "Buses": {
-        "b1": {
-            "Load (MW)": 0.0
-        },
-        "b2": {
-            "Load (MW)": [
-                26.01527,
-                24.46212,
-                23.29725,
-                22.90897
-            ]
-        }
-    }
-}
-```
-
-
-### Generators
-
-This section describes all generators in the system, including thermal units, renewable units and virtual units.
-
-| Key                       | Description                                      | Default | Time series?
-| :------------------------ | :------------------------------------------------| ------- | :-----------:
-| `Bus`                     | Identifier of the bus where this generator is located (string). | Required | N
-| `Production cost curve (MW)` and `Production cost curve ($)` | Parameters describing the piecewise-linear production costs. See below for more details. | Required | Y
-| `Startup costs ($)` and `Startup delays (h)` | Parameters describing how much it costs to start the generator after it has been shut down for a certain amount of time. If `Startup costs ($)` and `Startup delays (h)` are set to `[300.0, 400.0]` and `[1, 4]`, for example, and the generator is shut down at time `00:00` (h:min), then it costs \$300 to start up the generator at any time between `01:00` and `03:59`, and \$400 to start the generator at time `04:00` or any time after that.  The number of startup cost points is unlimited, and may be different for each generator. Startup delays must be strictly increasing and the first entry must equal `Minimum downtime (h)`. | `[0.0]` and `[1]` | N
-| `Minimum uptime (h)`      | Minimum amount of time the generator must stay operational after starting up (in hours). For example, if the generator starts up at time `00:00` (h:min) and `Minimum uptime (h)` is set to 4, then the generator can only shut down at time `04:00`. | `1` | N
-| `Minimum downtime (h)`    | Minimum amount of time the generator must stay offline after shutting down (in hours). For example, if the generator shuts down at time `00:00` (h:min) and `Minimum downtime (h)` is set to 4, then the generator can only start producing power again at time `04:00`. | `1` | N
-| `Ramp up limit (MW)`      | Maximum increase in production from one time step to the next (in MW). For example, if the generator is producing 100 MW at time step 1 and if this parameter is set to 40 MW, then the generator will produce at most 140 MW at time step 2. | `+inf` | N
-| `Ramp down limit (MW)`    | Maximum decrease in production from one time step to the next (in MW). For example, if the generator is producing 100 MW at time step 1 and this parameter is set to 40 MW, then the generator will produce at least 60 MW at time step 2. | `+inf` | N
-| `Startup limit (MW)`   | Maximum amount of power a generator can produce immediately after starting up (in MW). For example, if `Startup limit (MW)` is set to 100 MW and the unit is off at time step 1, then it may produce at most 100 MW at time step 2.| `+inf` | N
-| `Shutdown limit (MW)`     | Maximum amount of power a generator can produce immediately before shutting down (in MW). Specifically, the generator can only shut down at time step `t+1` if its production at time step `t` is below this limit.  | `+inf` | N
-| `Initial status (h)`  | If set to a positive number, indicates the amount of time (in hours) the generator has been on at the beginning of the simulation, and if set to a negative number, the amount of time the generator has been off. For example, if `Initial status (h)` is `-2`, this means that the generator was off since `-02:00` (h:min). The simulation starts at time `00:00`. If `Initial status (h)` is `3`, this means that the generator was on since `-03:00`. A value of zero is not acceptable. | Required | N
-| `Initial power (MW)`  | Amount of power the generator at time step `-1`, immediately before the planning horizon starts. | Required | N
-| `Must run?`               | If `true`, the generator should be committed, even if 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 are represented as piecewise-linear curves. Figure 1 shows an example cost curve with three segments, where it costs \$1400, \$1600, \$2200 and \$2400 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.
-
-<center>
-    <img src="../_static/cost_curve.png" style="max-width: 500px"/>
-    <div><b>Figure 1.</b> Piecewise-linear production cost curve.</div>
-    <br/>
-</center>
-
-#### 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 steps 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
-
-```json
-{
-    "Generators": {
-        "gen1": {
-            "Bus": "b1",
-            "Production cost curve (MW)": [100.0, 110.0, 130.0, 135.0],
-            "Production cost curve ($)": [1400.0, 1600.0, 2200.0, 2400.0],
-            "Startup costs ($)": [300.0, 400.0],
-            "Startup delays (h)": [1, 4],
-            "Ramp up limit (MW)": 232.68,
-            "Ramp down limit (MW)": 232.68,
-            "Startup limit (MW)": 232.68,
-            "Shutdown limit (MW)": 232.68,
-            "Minimum downtime (h)": 4,
-            "Minimum uptime (h)": 4,
-            "Initial status (h)": 12,
-            "Must run?": false,
-            "Provides spinning reserves?": true,
-        },
-        "gen2": {
-            "Bus": "b5",
-            "Production cost curve (MW)": [0.0, [10.0, 8.0, 0.0, 3.0]],
-            "Production cost curve ($)": [0.0, 0.0],
-            "Provides spinning reserves?": true,
-        }
-    }
-}
-```
-
-### 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. 
-
-| Key               | Description                                       | Default  | Time series?
-| :---------------- | :------------------------------------------------ | :------: | :------------:
-| `Bus`             | Bus where the load is located. Multiple price-sensitive loads may be placed at the same bus. | Required | N
-| `Revenue ($/MW)`  | Revenue obtained for serving each MW of power to this load. | Required | Y
-| `Demand (MW)`     | Maximum amount of power required by this load. Any amount lower than this may be served. | Required | Y
-
-
-#### Example
-```json
-{
-    "Price-sensitive loads": {
-        "p1": {
-            "Bus": "b3",
-            "Revenue ($/MW)": 23.0,
-            "Demand (MW)": 50.0
-        }
-    }
-}
-```
-
-### Transmission Lines
-
-This section describes the characteristics of transmission system, such as its topology and the susceptance of each transmission line.
-
-| Key                    | Description                                      | Default | Time series?
-| :--------------------- | :----------------------------------------------- | ------- | :------------:
-| `Source bus`           | Identifier of the bus where the transmission line originates. | Required | N
-| `Target bus`           | Identifier of the bus where the transmission line reaches. | Required | N
-| `Reactance (ohms)`     | Reactance of the transmission line (in ohms). | Required | N
-| `Susceptance (S)`      | Susceptance  of the transmission line (in siemens). | Required | N
-| `Normal flow limit (MW)` | Maximum amount of power (in MW) allowed to flow through the line when the system is in its regular, fully-operational state. | `+inf` | Y
-| `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 step. For example, if there is a thermal violation of 1 MW for three time steps, then three times this amount will be charged. | `5000.0` | Y
-
-#### Example
-
-```json
-{
-    "Transmission lines": {
-        "l1": {
-            "Source bus": "b1",
-            "Target bus": "b2",
-            "Reactance (ohms)": 0.05917,
-            "Susceptance (S)": 29.49686,
-            "Normal flow limit (MW)": 15000.0,
-            "Emergency flow limit (MW)": 20000.0,
-            "Flow limit penalty ($/MW)": 5000.0
-        }
-    }
-}
-```
-
-
-### Reserves
-
-This section describes the hourly amount of operating reserves required.
-
-
-| Key                   | Description                                        | Default   |  Time series?
-| :-------------------- | :------------------------------------------------- | --------- |  :----:
-| `Spinning (MW)`       | Minimum amount of system-wide spinning reserves (in MW). Only generators which are online may provide this reserve. | `0.0` | Y
-
-#### Example
-
-```json
-{
-    "Reserves": {
-        "Spinning (MW)": [
-            57.30552,
-            53.88429,
-            51.31838,
-            50.46307
-        ]
-    }
-}
-```
-
-### Contingencies
-
-This section describes credible contingency scenarios in the optimization, such as the loss of a transmission line or generator.
-
-| Key                   | Description                                      | Default
-| :-------------------- | :----------------------------------------------- | ----------
-| `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
-
-```json
-{
-    "Contingencies": {
-        "c1": {
-            "Affected lines": ["l1", "l2", "l3"],
-            "Affected generators": ["g1"]
-        },
-        "c2": {
-            "Affected lines": ["l4"]
-        },
-    }
-}
-```
-
-### Additional remarks
-
-#### 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, if they are time-dependent, where `T` is the number of time steps in the planning horizon. For example, both formats below are valid when `T=3`:
-
-```json
-{
-    "Load (MW)": 800.0,
-    "Load (MW)": [800.0, 850.0, 730.0]
-}
-```
-
-The value `T` depends on both `Time horizon (h)` and `Time step (min)`, as the table below illustrates.
-
-Time horizon (h) | Time step (min) | T
-:---------------:|:---------------:|:----:
-24               | 60              | 24
-24               | 15              | 96
-24               | 5               | 288
-36               | 60              | 36
-36               | 15              | 144
-36               | 5               | 432
-
-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.
-
-
-Current limitations
-------------------
-
-* All reserves are system-wide. Zonal reserves are not currently supported.
-* Network topology remains the same for all time periods
-* Only N-1 transmission contingencies are supported. Generator contingencies are not currently supported.
-* Time-varying minimum production amounts are not currently compatible with ramp/startup/shutdown limits.
-
-
--- a/docs/make.jl
+++ b/docs/make.jl
@@ -0,0 +1,18 @@
+using Documenter, UnitCommitment, JuMP
+
+function make()
+    makedocs(
+        sitename="UnitCommitment.jl",
+        pages=[
+            "Home" => "index.md",
+            "usage.md",
+            "format.md",
+            "instances.md",
+            "model.md",
+            "api.md",
+        ],
+        format = Documenter.HTML(
+            assets=["assets/custom.css"],
+        )
+    )
+end
--- a/docs/model.md
+++ b/docs/model.md
@@ -1,244 +0,0 @@
-```{sectnum}
---
-start: 4
-depth: 2
-suffix: .
---
-```
-
-JuMP Model
-==========
-
-In this page, we describe the JuMP optimization model produced by the function `UnitCommitment.build_model`. A detailed understanding of this model is not necessary if you are just interested in using the package to solve some standard unit commitment cases, but it may be useful, for example, if you need to solve a slightly different problem, with additional variables and constraints. The notation in this page generally follows [KnOsWa20].
-
-Decision variables
------------------
-
-### Generators
-
-Name | Symbol | Description | Unit
-----|:--------:|-------------|:------:
-`is_on[g,t]` | $u_{g}(t)$ | True if generator `g` is on at time `t`. | Binary
-`switch_on[g,t]` | $v_{g}(t)$ | True is generator `g` switches on at time `t`. | Binary
-`switch_off[g,t]` | $w_{g}(t)$ | True if generator `g` switches off at time `t`. | Binary
-`prod_above[g,t]` |$p'_{g}(t)$ | Amount of power produced by generator `g` above its minimum power output at time `t`. For example, if the minimum power of generator `g` is 100 MW and `g` is producing 115 MW of power at time `t`, then `prod_above[g,t]` equals `15.0`. | MW
-`segprod[g,t,k]` | $p^k_g(t)$ | Amount of power from piecewise linear segment `k` produced by generator `g` at time `t`. For example, if cost curve for generator `g` is defined by the points `(100, 1400)`, `(110, 1600)`, `(130, 2200)` and `(135, 2400)`, and if the generator is producing 115 MW of power at time `t`, then `segprod[g,t,:]` equals `[10.0, 5.0, 0.0]`.| MW
-`reserve[g,t]` | $r_g(t)$ | Amount of reserves provided by generator `g` at time `t`. | MW
-`startup[g,t,s]` | $\delta^s_g(t)$ | True if generator `g` switches on at time `t` incurring start-up costs from start-up category `s`. | Binary
-
-
-### Buses
-
-Name | Symbol | Description | Unit
-----|:------:|-------------|:------:
-`net_injection[b,t]` | $n_b(t)$ | Net injection at bus `b` at time `t`. | MW
-`curtail[b,t]` | $s^+_b(t)$ | Amount of load curtailed at bus `b` at time `t` | MW
-
-
-### Price-sensitive loads
-
-Name | Symbol | Description | Unit
-----|:------:|-------------|:------:
-`loads[s,t]` | $d_{s}(t)$ | Amount of power served to price-sensitive load `s` at time `t`. | MW
-
-### Transmission lines
-
-Name | Symbol | Description | Unit
-----|:------:|-------------|:------:
-`flow[l,t]` | $f_l(t)$ | Power flow on line `l` at time `t`. | MW
-`overflow[l,t]` | $f^+_l(t)$ | Amount of flow above the limit for line `l` at time `t`. | MW
-
-```{warning}
-
-Since transmission and N-1 security constraints are enforced in a lazy way, most of the `flow[l,t]` variables are never added to the model. Accessing `model[:flow][l,t]` without first checking that the variable exists will likely generate an error.
-```
-
-Objective function
------------------
-
-$$
-\begin{align}
-    \text{minimize} \;\; &
-        \sum_{t \in \mathcal{T}}
-          \sum_{g \in \mathcal{G}}
-          C^\text{min}_g(t) u_g(t) \\
-    &
-        + \sum_{t \in \mathcal{T}}
-          \sum_{g \in \mathcal{G}}
-          \sum_{g \in \mathcal{K}_g}
-          C^k_g(t) p^k_g(t) \\
-    &
-        + \sum_{t \in \mathcal{T}}
-          \sum_{g \in \mathcal{G}}
-          \sum_{s \in \mathcal{S}_g}
-          C^s_{g}(t) \delta^s_g(t) \\
-    &
-        + \sum_{t \in \mathcal{T}}
-          \sum_{l \in \mathcal{L}}
-          C^\text{overflow}_{l}(t) f^+_l(t) \\
-    &
-        + \sum_{t \in \mathcal{T}}
-           \sum_{b \in \mathcal{B}}
-           C^\text{curtail}(t) s^+_b(t) \\
-    &
-        - \sum_{t \in \mathcal{T}}
-           \sum_{s \in \mathcal{PS}}
-           R_{s}(t) d_{s}(t) \\
-          
-\end{align}
-$$
-where
- $\mathcal{B}$ is the set of buses
- $\mathcal{G}$ is the set of generators
- $\mathcal{L}$ is the set of transmission lines
- $\mathcal{PS}$ is the set of price-sensitive loads
- $\mathcal{S}_g$ is the set of start-up categories for generator $g$
- $\mathcal{T}$ is the set of time steps
- $C^\text{curtail}(t)$ is the curtailment penalty (in \$/MW)
- $C^\text{min}_g(t)$ is the cost of keeping generator $g$ on and producing at minimum power during time $t$ (in \$)
- $C^\text{overflow}_{l}(t)$ is the flow limit penalty for line $l$ at time $t$ (in \$/MW)
- $C^k_g(t)$ is the cost for generator $g$ to produce 1 MW of power at time $t$ under piecewise linear segment $k$
- $C^s_{g}(t)$ is the cost of starting up generator $g$ at time $t$ under start-up category $s$ (in \$)
- $R_{s}(t)$ is the revenue obtained from serving price-sensitive load $s$ at time $t$ (in \$/MW)
-
-
-Constraints
-----------
-
-TODO
-
-
-Inspecting and modifying the model
----------------------------------
-
-### Accessing decision variables
-
-After building a model using `UnitCommitment.build_model`, it is possible to obtain a reference to the decision variables by calling `model[:varname][index]`. For example, `model[:is_on]["g1",1]` returns a direct reference to the JuMP variable indicating whether generator named "g1" is on at time 1. The script below illustrates how to build a model, solve it and display the solution without using the function `UnitCommitment.solution`.
-
-```julia
-using Cbc
-using Printf
-using JuMP
-using UnitCommitment
-
-# Load benchmark instance
-instance = UnitCommitment.read_benchmark("matpower/case118/2017-02-01")
-
-# Build JuMP model
-model = UnitCommitment.build_model(
-    instance=instance,
-    optimizer=Cbc.Optimizer,
-)
-
-# Solve the model
-UnitCommitment.optimize!(model)
-
-# Display commitment status
-for g in instance.units
-    for t in 1:instance.time
-        @printf(
-            "%-10s %5d %5.1f %5.1f %5.1f\n",
-            g.name,
-            t,
-            value(model[:is_on][g.name, t]),
-            value(model[:switch_on][g.name, t]),
-            value(model[:switch_off][g.name, t]),
-        )
-    end
-end
-```
-
-### Fixing variables, modifying objective function and adding constraints
-
-Since we now have a direct reference to the JuMP decision variables, it is possible to fix variables, change the coefficients in the objective function, or even add new constraints to the model before solving it. The script below shows how can this be accomplished. For more information on modifying an existing model, [see the JuMP documentation](https://jump.dev/JuMP.jl/stable/manual/variables/).
-
-```julia
-using Cbc
-using JuMP
-using UnitCommitment
-
-# Load benchmark instance
-instance = UnitCommitment.read_benchmark("matpower/case118/2017-02-01")
-
-# Construct JuMP model
-model = UnitCommitment.build_model(
-    instance=instance,
-    optimizer=Cbc.Optimizer,
-)
-
-# Fix a decision variable to 1.0
-JuMP.fix(
-    model[:is_on]["g1",1],
-    1.0,
-    force=true,
-)
-
-# Change the objective function
-JuMP.set_objective_coefficient(
-    model,
-    model[:switch_on]["g2",1],
-    1000.0,
-)
-
-# Create a new constraint
-@constraint(
-    model,
-    model[:is_on]["g3",1] + model[:is_on]["g4",1] <= 1,
-)
-
-# Solve the model
-UnitCommitment.optimize!(model)
-```
-
-### Adding new component to a bus
-
-The following snippet shows how to add a new grid component to a particular bus. For each time step, we create decision variables for the new grid component, add these variables to the objective function, then attach the component to a particular bus by modifying some existing model constraints. 
-
-```julia
-using Cbc
-using JuMP
-using UnitCommitment
-
-# Load instance and build base model
-instance = UnitCommitment.read_benchmark("matpower/case118/2017-02-01")
-model = UnitCommitment.build_model(
-    instance=instance,
-    optimizer=Cbc.Optimizer,
-)
-
-# Get the number of time steps in the original instance
-T = instance.time
-
-# Create decision variables for the new grid component.
-# In this example, we assume that the new component can
-# inject up to 10 MW of power at each time step, so we
-# create new continuous variables 0 ≤ x[t] ≤ 10.
-@variable(model, x[1:T], lower_bound=0.0, upper_bound=10.0)
-
-# For each time step
-for t in 1:T
-
-    # Add production costs to the objective function.
-    # In this example, we assume a cost of $5/MW.
-    set_objective_coefficient(model, x[t], 5.0)
-
-    # Attach the new component to bus b1, by modifying the
-    # constraint `eq_net_injection`.
-    set_normalized_coefficient(
-        model[:eq_net_injection]["b1", t],
-        x[t],
-        1.0,
-    )
-end
-
-# Solve the model
-UnitCommitment.optimize!(model)
-
-# Show optimal values for the x variables
-@show value.(x)
-```
-
-References
----------
-* [KnOsWa20] **Bernard Knueven, James Ostrowski and Jean-Paul Watson.** "On Mixed-Integer Programming Formulations for the Unit Commitment Problem". INFORMS Journal on Computing (2020). [DOI: 10.1287/ijoc.2019.0944](https://doi.org/10.1287/ijoc.2019.0944)
-
--- a/docs/src/api.md
+++ b/docs/src/api.md
@@ -0,0 +1,62 @@
+# API Reference
+
+## Read data, build model & optimize
+
+```@docs
+UnitCommitment.read
+UnitCommitment.read_benchmark
+UnitCommitment.build_model
+UnitCommitment.optimize!
+UnitCommitment.solution
+UnitCommitment.validate
+UnitCommitment.write
+```
+
+## Locational Marginal Prices
+
+### Conventional LMPs
+```@docs
+UnitCommitment.compute_lmp(::JuMP.Model,::UnitCommitment.ConventionalLMP)
+```
+
+### Approximated Extended LMPs
+```@docs
+UnitCommitment.AELMP
+UnitCommitment.compute_lmp(::JuMP.Model,::UnitCommitment.AELMP)
+```
+
+
+## Modify instance
+
+```@docs
+UnitCommitment.slice
+UnitCommitment.randomize!(::UnitCommitment.UnitCommitmentInstance)
+UnitCommitment.generate_initial_conditions!
+```
+
+## Formulations
+
+```@docs
+UnitCommitment.Formulation
+UnitCommitment.ShiftFactorsFormulation
+UnitCommitment.ArrCon2000
+UnitCommitment.CarArr2006
+UnitCommitment.DamKucRajAta2016
+UnitCommitment.Gar1962
+UnitCommitment.KnuOstWat2018
+UnitCommitment.MorLatRam2013
+UnitCommitment.PanGua2016
+UnitCommitment.WanHob2016
+```
+
+## Solution Methods
+
+```@docs
+UnitCommitment.XavQiuWanThi2019.Method
+```
+
+## Randomization Methods
+
+```@docs
+UnitCommitment.XavQiuAhm2021.Randomization
+```
--- a/docs/src/assets/cost_curve.png
+++ b/docs/src/assets/cost_curve.png
--- a/docs/src/assets/custom.css
+++ b/docs/src/assets/custom.css
@@ -0,0 +1,36 @@
+@media screen and (min-width: 1056px) {
+    #documenter .docs-main {
+      max-width: 65rem !important;
+    }
+}
+  
+
+tbody, thead, pre {
+    border: 1px solid rgba(0, 0, 0, 0.25);
+}
+
+table td, th {
+    padding: 8px;
+}
+
+table p {
+    margin-bottom: 0;
+}
+
+table td code {
+    white-space: nowrap;
+}
+
+table tr,
+table th {
+    border-bottom: 1px solid rgba(0, 0, 0, 0.1);
+}
+
+table tr:last-child {
+    border-bottom: 0;
+}
+
+code {
+    background-color: transparent;
+    color: rgb(232, 62, 140);
+}
--- a/docs/src/format.md
+++ b/docs/src/format.md
@@ -0,0 +1,408 @@
+Data Format
+===========
+
+Input Data Format
+-----------------
+
+An instance of the stochastic security-constrained unit commitment (SCUC) problem is composed multiple scenarios. Each scenario should be described in an individual JSON file containing the main section belows. For deterministic instances, a single scenario file, following the same format below, may also be provided. Fields that are allowed to differ among scenarios are marked as "uncertain". Fields that are allowed to be time-dependent are marked as "time series".
+
+* [Parameters](#Parameters)
+* [Buses](#Buses)
+* [Generators](#Generators)
+* [Storage units](#Storage-units)
+* [Price-sensitive loads](#Price-sensitive-loads)
+* [Transmission lines](#Transmission-lines)
+* [Reserves](#Reserves)
+* [Contingencies](#Contingencies)
+
+Each section is described in detail below. See [case118/2017-01-01.json.gz](https://axavier.org/UnitCommitment.jl/0.3/instances/matpower/case118/2017-01-01.json.gz) for a complete example.
+
+### Parameters
+
+This section describes system-wide parameters, such as power balance penalty, and optimization parameters, such as the length of the planning horizon and the time.
+
+| Key                            | Description                                       | Default  | Time series? | Uncertain?
+| :----------------------------- | :------------------------------------------------ | :------: | :------------:| :----------:
+| `Version` | Version of UnitCommitment.jl this file was written for. Required to ensure that the file remains readable in future versions of the package. If you are following this page to construct the file, this field should equal `0.4`. | Required | No | No
+| `Time horizon (min)` or  `Time horizon (h)` | Length of the planning horizon (in minutes or hours). Either `Time horizon (min)` or `Time horizon (h)` is required, but not both.  | Required | No | No
+| `Time step (min)` | Length of each time step (in minutes). Must be a divisor of 60 (e.g. 60, 30, 20, 15, etc). | `60` | No | No
+| `Power balance penalty ($/MW)` | Penalty for system-wide shortage or surplus in production (in $/MW). This is charged per time step. For example, if there is a shortage of 1 MW for three time steps, three times this amount will be charged. | `1000.0` | No | Yes
+| `Scenario name` | Name of the scenario. | `"s1"` | No | ---
+| `Scenario weight` | Weight of the scenario. The scenario weight can be any positive real number, that is, it does not have to be between zero and one. The package normalizes the weights to ensure that the probability of all scenarios sum up to one. | 1.0 | No | ---
+
+
+#### Example
+```json
+{
+    "Parameters": {
+        "Version": "0.3",
+        "Time horizon (h)": 4,
+        "Power balance penalty ($/MW)": 1000.0,
+        "Scenario name": "s1",
+        "Scenario weight": 0.5
+    }
+}
+```
+
+### Buses
+
+This section describes the characteristics of each bus in the system. 
+
+| Key                | Description                                                   | Default | Time series? | Uncertain?
+| :----------------- | :------------------------------------------------------------ | ------- | :-----------: | :---:
+| `Load (MW)`        | Fixed load connected to the bus (in MW).                      | Required | Yes | Yes
+
+
+#### Example
+```json
+{
+    "Buses": {
+        "b1": {
+            "Load (MW)": 0.0
+        },
+        "b2": {
+            "Load (MW)": [
+                26.01527,
+                24.46212,
+                23.29725,
+                22.90897
+            ]
+        }
+    }
+}
+```
+
+
+### Generators
+
+This section describes all generators in the system. Two types of units can be specified:
+
+- **Thermal units:** Units that produce power by converting heat into electrical energy, such as coal and oil power plants. These units use a more complex model, with binary decision variables, and various constraints to enforce ramp rates and minimum up/down time.
+- **Profiled units:** Simplified model for units that do not require the constraints mentioned above, only a maximum and minimum power output for each time period. Typically used for renewables and hydro.
+
+#### Thermal Units
+
+| Key                       | Description                                      | Default | Time series? | Uncertain?
+| :------------------------ | :------------------------------------------------| ------- | :-----------: | :---:
+| `Bus`                     | Identifier of the bus where this generator is located (string). | Required | No | Yes
+| `Type`                     | Type of the generator (string). For thermal generators, this must be `Thermal`.  | Required | No | No
+| `Production cost curve (MW)` and `Production cost curve ($)` | Parameters describing the piecewise-linear production costs. See below for more details. | Required | Yes | Yes
+| `Startup costs ($)` and `Startup delays (h)` | Parameters describing how much it costs to start the generator after it has been shut down for a certain amount of time. If `Startup costs ($)` and `Startup delays (h)` are set to `[300.0, 400.0]` and `[1, 4]`, for example, and the generator is shut down at time `00:00` (h:min), then it costs \$300 to start up the generator at any time between `01:00` and `03:59`, and \$400 to start the generator at time `04:00` or any time after that.  The number of startup cost points is unlimited, and may be different for each generator. Startup delays must be strictly increasing and the first entry must equal `Minimum downtime (h)`. | `[0.0]` and `[1]` | No | Yes
+| `Minimum uptime (h)`      | Minimum amount of time the generator must stay operational after starting up (in hours). For example, if the generator starts up at time `00:00` (h:min) and `Minimum uptime (h)` is set to 4, then the generator can only shut down at time `04:00`. | `1` | No | Yes
+| `Minimum downtime (h)`    | Minimum amount of time the generator must stay offline after shutting down (in hours). For example, if the generator shuts down at time `00:00` (h:min) and `Minimum downtime (h)` is set to 4, then the generator can only start producing power again at time `04:00`. | `1` | No | Yes
+| `Ramp up limit (MW)`      | Maximum increase in production from one time step to the next (in MW). For example, if the generator is producing 100 MW at time step 1 and if this parameter is set to 40 MW, then the generator will produce at most 140 MW at time step 2. | `+inf` | No | Yes
+| `Ramp down limit (MW)`    | Maximum decrease in production from one time step to the next (in MW). For example, if the generator is producing 100 MW at time step 1 and this parameter is set to 40 MW, then the generator will produce at least 60 MW at time step 2. | `+inf` | No | Yes
+| `Startup limit (MW)`   | Maximum amount of power a generator can produce immediately after starting up (in MW). For example, if `Startup limit (MW)` is set to 100 MW and the unit is off at time step 1, then it may produce at most 100 MW at time step 2.| `+inf` | No | Yes
+| `Shutdown limit (MW)`     | Maximum amount of power a generator can produce immediately before shutting down (in MW). Specifically, the generator can only shut down at time step `t+1` if its production at time step `t` is below this limit.  | `+inf` | No | Yes
+| `Initial status (h)`  | If set to a positive number, indicates the amount of time (in hours) the generator has been on at the beginning of the simulation, and if set to a negative number, the amount of time the generator has been off. For example, if `Initial status (h)` is `-2`, this means that the generator was off since `-02:00` (h:min). The simulation starts at time `00:00`. If `Initial status (h)` is `3`, this means that the generator was on since `-03:00`. A value of zero is not acceptable. | Required | No | No
+| `Initial power (MW)`  | Amount of power the generator at time step `-1`, immediately before the planning horizon starts. | Required | No | No
+| `Must run?`               | If `true`, the generator should be committed, even if that is not economical (Boolean). | `false` | Yes | Yes
+| `Reserve eligibility` | List of reserve products this generator is eligibe to provide. By default, the generator is not eligible to provide any reserves. | `[]` | No | Yes
+| `Commitment status` | List of commitment status over the time horizon. At time `t`, if `true`, the generator must be commited at that time period; if `false`, the generator must not be commited at that time period. If `null` at time `t`, the generator's commitment status is then decided by the model. By default, the status is a list of `null` values. | `null` | Yes | Yes
+
+#### Profiled Units
+
+| Key               | Description                                       | Default  | Time series? | Uncertain?
+| :---------------- | :------------------------------------------------ | :------: | :------------: | :---:
+| `Bus`             | Identifier of the bus where this generator is located (string). | Required | No | Yes
+| `Type`            | Type of the generator (string). For profiled generators, this must be `Profiled`.  | Required | No | No
+| `Cost ($/MW)`     | Cost incurred for serving each MW of power by this generator. | Required | Yes | Yes
+| `Minimum power (MW)` | Minimum amount of power this generator may supply. | `0.0` | Yes | Yes
+| `Maximum power (MW)` | Maximum amount of power this generator may supply. | Required | Yes | Yes
+
+#### 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 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.
+
+```@raw html
+<center>
+    <img src="../assets/cost_curve.png" style="max-width: 500px"/>
+    <div><b>Figure 1.</b> Piecewise-linear production cost curve.</div>
+    <br/>
+</center>
+```
+
+#### 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 steps 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
+
+```json
+{
+    "Generators": {
+        "gen1": {
+            "Bus": "b1",
+            "Type": "Thermal",
+            "Production cost curve (MW)": [100.0, 110.0, 130.0, 135.0],
+            "Production cost curve ($)": [1400.0, 1600.0, 2200.0, 2400.0],
+            "Startup costs ($)": [300.0, 400.0],
+            "Startup delays (h)": [1, 4],
+            "Ramp up limit (MW)": 232.68,
+            "Ramp down limit (MW)": 232.68,
+            "Startup limit (MW)": 232.68,
+            "Shutdown limit (MW)": 232.68,
+            "Minimum downtime (h)": 4,
+            "Minimum uptime (h)": 4,
+            "Initial status (h)": 12,
+            "Initial power (MW)": 115,
+            "Must run?": false,
+            "Reserve eligibility": ["r1"]
+        },
+        "gen2": {
+            "Bus": "b5",
+            "Type": "Thermal",
+            "Production cost curve (MW)": [0.0, [10.0, 8.0, 0.0, 3.0]],
+            "Production cost curve ($)": [0.0, 0.0],
+            "Initial status (h)": -100,
+            "Initial power (MW)": 0,
+            "Reserve eligibility": ["r1", "r2"],
+            "Commitment status": [true, false, null, true]
+        },
+        "gen3": {
+            "Bus": "b6",
+            "Type": "Profiled",
+            "Minimum power (MW)": 10.0,
+            "Maximum power (MW)": 120.0,
+            "Cost ($/MW)": 100.0
+        }
+    }
+}
+```
+
+### Storage units
+
+This section describes energy storage units in the system which charge and discharge power. The storage units consume power while charging, and generate power while discharging. 
+
+| Key               | Description                                       | Default  | Time series? | Uncertain?
+| :---------------- | :------------------------------------------------ | :------: | :------------: | :----: 
+| `Bus`             | Bus where the storage unit is located. Multiple storage units may be placed at the same bus. | Required | No | Yes
+| `Minimum level (MWh)`  | Minimum of energy level this storage unit may contain. | `0.0` | Yes | Yes
+| `Maximum level (MWh)`  | Maximum of energy level this storage unit may contain. | Required | Yes | Yes
+| `Allow simultaneous charging and discharging`  | If `false`, the storage unit is not allowed to charge and discharge at the same time (Boolean). | `true` | Yes | Yes
+| `Charge cost ($/MW)`  | Cost incurred for charging each MW of power into this storage unit. | Required | Yes | Yes
+| `Discharge cost ($/MW)`  | Cost incurred for discharging each MW of power from this storage unit. | Required | Yes | Yes
+| `Charge efficiency`  | Efficiency rate to charge power into this storage unit. This value must be greater than or equal to `0.0`, and less than or equal to `1.0`. | `1.0` | Yes | Yes
+| `Discharge efficiency`  | Efficiency rate to discharge power from this storage unit. This value must be greater than or equal to `0.0`, and less than or equal to `1.0`. | `1.0` | Yes | Yes
+| `Loss factor`  | The energy dissipation rate of this storage unit. This value must be greater than or equal to `0.0`, and less than or equal to `1.0`. | `0.0` | Yes | Yes
+| `Minimum charge rate (MW)`  | Minimum amount of power rate this storage unit may charge. | `0.0` | Yes | Yes
+| `Maximum charge rate (MW)`  | Maximum amount of power rate this storage unit may charge. | Required | Yes | Yes
+| `Minimum discharge rate (MW)`  | Minimum amount of power rate this storage unit may discharge. | `0.0` | Yes | Yes
+| `Maximum discharge rate (MW)`  | Maximum amount of power rate this storage unit may discharge. | Required | Yes | Yes
+| `Initial level (MWh)`  | Amount of energy this storage unit at time step `-1`, immediately before the planning horizon starts. | `0.0` | No | Yes
+| `Last period minimum level (MWh)`  | Minimum of energy level this storage unit may contain in the last time step. By default, this value is the same as the last value of `Minimum level (MWh)`. | `Minimum level (MWh)` | No | Yes
+| `Last period maximum level (MWh)`  | Maximum of energy level this storage unit may contain in the last time step. By default, this value is the same as the last value of `Maximum level (MWh)`. | `Maximum level (MWh)` | No | Yes
+
+#### Example
+```json
+{
+    "Storage units": {
+        "su1": {
+            "Bus": "b2",
+            "Maximum level (MWh)": 100.0,
+            "Charge cost ($/MW)": 2.0,
+            "Discharge cost ($/MW)": 2.5,
+            "Maximum charge rate (MW)": 10.0,
+            "Maximum discharge rate (MW)": 8.0
+        },
+        "su2": {
+            "Bus": "b2",
+            "Minimum level (MWh)": 10.0,
+            "Maximum level (MWh)": 100.0,
+            "Allow simultaneous charging and discharging": false,
+            "Charge cost ($/MW)": 3.0,
+            "Discharge cost ($/MW)": 3.5,
+            "Charge efficiency": 0.8,
+            "Discharge efficiency": 0.85,
+            "Loss factor": 0.01,
+            "Minimum charge rate (MW)": 5.0,
+            "Maximum charge rate (MW)": 10.0,
+            "Minimum discharge rate (MW)": 2.0,
+            "Maximum discharge rate (MW)": 10.0,
+            "Initial level (MWh)": 70.0,
+            "Last period minimum level (MWh)": 80.0,
+            "Last period maximum level (MWh)": 85.0
+        },
+        "su3": {
+            "Bus": "b9",
+            "Minimum level (MWh)": [10.0, 11.0, 12.0, 13.0],
+            "Maximum level (MWh)": [100.0, 110.0, 120.0, 130.0],
+            "Allow simultaneous charging and discharging": [false, false, true, true],
+            "Charge cost ($/MW)": [2.0, 2.1, 2.2, 2.3],
+            "Discharge cost ($/MW)": [1.0, 1.1, 1.2, 1.3],
+            "Charge efficiency": [0.8, 0.81, 0.82, 0.82],
+            "Discharge efficiency": [0.85, 0.86, 0.87, 0.88],
+            "Loss factor": [0.01, 0.01, 0.02, 0.02],
+            "Minimum charge rate (MW)": [5.0, 5.1, 5.2, 5.3],
+            "Maximum charge rate (MW)": [10.0, 10.1, 10.2, 10.3],
+            "Minimum discharge rate (MW)": [4.0, 4.1, 4.2, 4.3],
+            "Maximum discharge rate (MW)": [8.0, 8.1, 8.2, 8.3],
+            "Initial level (MWh)": 20.0,
+            "Last period minimum level (MWh)": 21.0,
+            "Last period maximum level (MWh)": 22.0
+        }
+    }
+}
+```
+
+### 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. 
+
+| Key               | Description                                       | Default  | Time series? | Uncertain?
+| :---------------- | :------------------------------------------------ | :------: | :------------: | :----: 
+| `Bus`             | Bus where the load is located. Multiple price-sensitive loads may be placed at the same bus. | Required | No | Yes
+| `Revenue ($/MW)`  | Revenue obtained for serving each MW of power to this load. | Required | Yes | Yes
+| `Demand (MW)`     | Maximum amount of power required by this load. Any amount lower than this may be served. | Required | Yes | Yes
+
+
+#### Example
+```json
+{
+    "Price-sensitive loads": {
+        "p1": {
+            "Bus": "b3",
+            "Revenue ($/MW)": 23.0,
+            "Demand (MW)": 50.0
+        }
+    }
+}
+```
+
+### Transmission lines
+
+This section describes the characteristics of transmission system, such as its topology and the susceptance of each transmission line.
+
+| Key                    | Description                                      | Default | Time series? | Uncertain?
+| :--------------------- | :----------------------------------------------- | ------- | :------------: | :---:
+| `Source bus`           | Identifier of the bus where the transmission line originates. | Required | No | Yes
+| `Target bus`           | Identifier of the bus where the transmission line reaches. | Required | No | Yes
+| `Susceptance (S)`      | Susceptance of the transmission line (in siemens). | Required | No | Yes
+| `Normal flow limit (MW)` | Maximum amount of power (in MW) allowed to flow through the line when the system is in its regular, fully-operational state. | `+inf` | Yes | Yes
+| `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 | Yes
+| `Flow limit penalty ($/MW)` | Penalty for violating the flow limits of the transmission line (in $/MW). This is charged per time step. For example, if there is a thermal violation of 1 MW for three time steps, then three times this amount will be charged. | `5000.0` | Yes | Yes
+
+#### Example
+
+```json
+{
+    "Transmission lines": {
+        "l1": {
+            "Source bus": "b1",
+            "Target bus": "b2",
+            "Susceptance (S)": 29.49686,
+            "Normal flow limit (MW)": 15000.0,
+            "Emergency flow limit (MW)": 20000.0,
+            "Flow limit penalty ($/MW)": 5000.0
+        }
+    }
+}
+```
+
+
+### Reserves
+
+This section describes the hourly amount of reserves required.
+
+
+| Key                   | Description                                        | Default   | Time series? | Uncertain?
+| :-------------------- | :------------------------------------------------- | --------- | :----: | :---:
+| `Type` | Type of reserve product. Must be either "spinning" or "flexiramp". | Required | No | No
+| `Amount (MW)` | Amount of reserves required. | Required | Yes | Yes
+| `Shortfall penalty ($/MW)` | Penalty for shortage in meeting the reserve requirements (in $/MW). This is charged per time step. Negative value implies reserve constraints must always be satisfied. | `-1` | Yes | Yes
+
+#### Example 1
+
+```json
+{
+    "Reserves": {
+        "r1": {
+            "Type": "spinning",
+            "Amount (MW)": [
+                57.30552,
+                53.88429,
+                51.31838,
+                50.46307
+            ],
+            "Shortfall penalty ($/MW)": 5.0
+        },
+        "r2": {
+            "Type": "flexiramp",
+            "Amount (MW)": [
+                20.31042,
+                23.65273,
+                27.41784,
+                25.34057
+            ],
+        }
+    }
+}
+```
+
+### Contingencies
+
+This section describes credible contingency scenarios in the optimization, such as the loss of a transmission line or generator.
+
+| Key                   | Description                                      | Default | Uncertain?
+| :-------------------- | :----------------------------------------------- | :--------: | :---:
+| `Affected generators` | List of generators affected by this contingency. May be omitted if no generators are affected. | `[]` | Yes
+| `Affected lines`      | List of transmission lines affected by this contingency. May be omitted if no lines are affected. | `[]` | Yes
+
+#### Example
+
+```json
+{
+    "Contingencies": {
+        "c1": {
+            "Affected lines": ["l1", "l2", "l3"],
+            "Affected generators": ["g1"]
+        },
+        "c2": {
+            "Affected lines": ["l4"]
+        },
+    }
+}
+```
+
+### Additional remarks
+
+#### 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, if they are time-dependent, where `T` is the number of time steps in the planning horizon. For example, both formats below are valid when `T=3`:
+
+```json
+{
+    "Load (MW)": 800.0,
+    "Load (MW)": [800.0, 850.0, 730.0]
+}
+```
+
+The value `T` depends on both `Time horizon (h)` and `Time step (min)`, as the table below illustrates.
+
+Time horizon (h) | Time step (min) | T
+:---------------:|:---------------:|:----:
+24               | 60              | 24
+24               | 15              | 96
+24               | 5               | 288
+36               | 60              | 36
+36               | 15              | 144
+36               | 5               | 432
+
+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.
+
+
+Current limitations
+-------------------
+
+* Network topology must remain the same for all time periods.
+* Only N-1 transmission contingencies are supported. Generator contingencies are not currently supported.
+* Time-varying minimum production amounts are not currently compatible with ramp/startup/shutdown limits.
+* Flexible ramping products can only be acquired under the `WanHob2016` formulation, which does not support spinning reserves. 
+* The set of generators must be the same in all scenarios.
--- a/docs/src/index.md
+++ b/docs/src/index.md
@@ -1,29 +1,29 @@
 # UnitCommitment.jl

-**UnitCommitment.jl** (UC.jl) is a Julia/JuMP 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.
+**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. Both deterministic and two-stage stochastic versions of the problem are supported. The package provides benchmark instances for the problem, a flexible and well-documented data format for the problem, as well as Julia/JuMP implementations of state-of-the-art mixed-integer programming formulations and solution methods.

 ## Package Components

-* **Data Format:** The package proposes an extensible and fully-documented JSON-based data specification format for SCUC, developed in collaboration with Independent System Operators (ISOs), which describes the most important aspects of the problem. The format supports all the most common generator characteristics (including ramping, piecewise-linear production cost curves and time-dependent startup costs), as well as operating reserves, price-sensitive loads, transmission networks and contingencies.
+* **Data Format:** The package proposes an extensible and fully-documented JSON-based data specification format for SCUC, developed in collaboration with Independent System Operators (ISOs), which describes the most important aspects of the problem. The format supports all the most common thermal generator characteristics (including ramping, piecewise-linear production cost curves and time-dependent startup costs), as well as profiled generators, reserves, price-sensitive loads, battery storage, transmission, and contingencies.
 * **Benchmark Instances:** The package provides a diverse collection of large-scale benchmark instances collected from the literature, converted into a common data format, and extended using data-driven methods to make them more challenging and realistic.
-* **Model Implementation**: The package provides a Julia/JuMP implementations of state-of-the-art formulations and solution methods for SCUC, including multiple ramping formulations ([ArrCon2000][ArrCon2000], [MorLatRam2013][MorLatRam2013], [DamKucRajAta2016][DamKucRajAta2016], [PanGua2016][PanGua2016]), multiple piecewise-linear costs formulations ([Gar1962][Gar1962], [CarArr2006][CarArr2006], [KnuOstWat2018][KnuOstWat2018]) and contingency screening methods ([XavQiuWanThi2019][XavQiuWanThi2019]). Our goal is to keep these implementations up-to-date as new methods are proposed in the literature.
+* **Model Implementation**: The package provides a Julia/JuMP implementations of state-of-the-art formulations and solution methods for the deterministic and stochastic SCUC, including multiple ramping formulations ([ArrCon2000](https://doi.org/10.1109/59.871739), [MorLatRam2013](https://doi.org/10.1109/TPWRS.2013.2251373), [DamKucRajAta2016](https://doi.org/10.1007/s10107-015-0919-9), [PanGua2016](https://doi.org/10.1287/opre.2016.1520)), piecewise-linear costs formulations ([Gar1962](https://doi.org/10.1109/AIEEPAS.1962.4501405), [CarArr2006](https://doi.org/10.1109/TPWRS.2006.876672), [KnuOstWat2018](https://doi.org/10.1109/TPWRS.2017.2783850)), contingency screening methods ([XavQiuWanThi2019](https://doi.org/10.1109/TPWRS.2019.2892620)) and decomposition methods. Our goal is to keep these implementations up-to-date as new methods are proposed in the literature.
 * **Benchmark Tools:** The package provides automated benchmark scripts to accurately evaluate the performance impact of proposed code changes.

-[ArrCon2000]: https://doi.org/10.1109/59.871739
-[CarArr2006]: https://doi.org/10.1109/TPWRS.2006.876672
-[DamKucRajAta2016]: https://doi.org/10.1007/s10107-015-0919-9
-[Gar1962]: https://doi.org/10.1109/AIEEPAS.1962.4501405
-[KnuOstWat2018]: https://doi.org/10.1109/TPWRS.2017.2783850
-[MorLatRam2013]: https://doi.org/10.1109/TPWRS.2013.2251373
-[PanGua2016]: https://doi.org/10.1287/opre.2016.1520
-[XavQiuWanThi2019]: https://doi.org/10.1109/TPWRS.2019.2892620
+## Table of Contents

-### Authors
+```@contents
+Pages = ["usage.md", "format.md", "instances.md", "model.md", "api.md"]
+Depth = 3
+```
+
+## Authors
 * **Alinson S. Xavier** (Argonne National Laboratory)
 * **Aleksandr M. Kazachkov** (University of Florida)
+* **Ogün Yurdakul** (Technische Universität Berlin)
+* **Jun He** (Purdue University)
 * **Feng Qiu** (Argonne National Laboratory)

-### Acknowledgments
+## Acknowledgments

 * We would like to thank **Yonghong Chen** (Midcontinent Independent System Operator), **Feng Pan** (Pacific Northwest National Laboratory) for valuable feedback on early versions of this package.

@@ -31,19 +31,19 @@

 * Based upon work supported by the **U.S. Department of Energy Advanced Grid Modeling Program** under Grant DE-OE0000875.

-### Citing
+## Citing

 If you use UnitCommitment.jl in your research (instances, models or algorithms), we kindly request that you cite the package as follows:

-* **Alinson S. Xavier, Aleksandr M. Kazachkov, Feng Qiu**, "UnitCommitment.jl: A Julia/JuMP Optimization Package for Security-Constrained Unit Commitment". Zenodo (2020). [DOI: 10.5281/zenodo.4269874](https://doi.org/10.5281/zenodo.4269874).
+* **Alinson S. Xavier, Aleksandr M. Kazachkov, Ogün Yurdakul, Jun He, Feng Qiu**, "UnitCommitment.jl: A Julia/JuMP Optimization Package for Security-Constrained Unit Commitment (Version 0.4)". Zenodo (2023). [DOI: 10.5281/zenodo.4269874](https://doi.org/10.5281/zenodo.4269874).

 If you use the instances, we additionally request that you cite the original sources, as described in the [instances page](instances.md).

-### License
+## License

 ```text
 UnitCommitment.jl: A Julia/JuMP Optimization Package for Security-Constrained Unit Commitment
-Copyright © 2020, UChicago Argonne, LLC. All Rights Reserved.
+Copyright © 2020-2023, UChicago Argonne, LLC. All Rights Reserved.

 Redistribution and use in source and binary forms, with or without modification, are permitted
 provided that the following conditions are met:
@@ -67,16 +67,3 @@ THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING N
 OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
 POSSIBILITY OF SUCH DAMAGE.
 ```
-
-## Site contents
-
-```{toctree}
---
-maxdepth: 2
---
-usage.md
-format.md
-instances.md
-model.md
-```
-
--- a/docs/src/instances.md
+++ b/docs/src/instances.md
@@ -1,20 +1,11 @@
-```{sectnum}
---
-start: 3
-depth: 2
-suffix: .
---
-```
-
 Instances
 =========

-UnitCommitment.jl provides a large collection of benchmark instances collected
-from the literature and converted to a [common data format](format.md). In some cases, as indicated below, the original instances have been extended, with realistic parameters, using data-driven methods. 
-If you use these instances in your research, we request that you cite UnitCommitment.jl, as well as the original sources.
+UnitCommitment.jl provides a large collection of benchmark instances collected from the literature and converted to a [common data format](format.md). In some cases, as indicated below, the original instances have been extended, with realistic parameters, using data-driven methods. If you use these instances in your research, we request that you cite UnitCommitment.jl, as well as the original sources, as listed below. Benchmark instances can be loaded with `UnitCommitment.read_benchmark(name)`, as explained in the [usage section](usage.md). Instance files can also be [directly downloaded from our website](https://axavier.org/UnitCommitment.jl/0.3/instances/).

-Raw instances files are [available at our GitHub repository](https://github.com/ANL-CEEESA/UnitCommitment.jl/tree/dev/instances). Benchmark instances can also be loaded with
-`UnitCommitment.read_benchmark(name)`, as explained in the [usage section](usage.md).
+!!! warning
+
+    The instances included in UC.jl are still under development and may change in the future. If you use these instances in your research, for reproducibility, you should specify what version of UC.jl they came from.


 MATPOWER
@@ -34,7 +25,7 @@ Because most MATPOWER test cases were originally designed for power flow studies

 * **Contingencies** were set to include all N-1 transmission line contingencies that do not generate islands or isolated buses. More specifically, there is one contingency for each transmission line, as long as that transmission line is not a bridge in the network graph.

-For each MATPOWER test case, UC.jl provides two variations (`2017-02-01` and `2017-08-01`) corresponding respectively to a winter and to a summer test case.
+For each MATPOWER test case, UC.jl provides 365 variations (`2017-01-01` to `2017-12-31`) corresponding different days of the year.

 ### MATPOWER/UW-PSTCA

@@ -42,16 +33,11 @@ A variety of smaller IEEE test cases, [compiled by University of Washington](htt

 | Name | Buses | Generators | Lines | Contingencies | References |
 |------|-------|------------|-------|---------------|--------|
-| `matpower/case14/2017-02-01` | 14 | 5 | 20 | 19 | [MTPWR, PSTCA]
-| `matpower/case14/2017-08-01` | 14 | 5 | 20 | 19 | [MTPWR, PSTCA]
-| `matpower/case30/2017-02-01` | 30 | 6 | 41 | 38 | [MTPWR, PSTCA]
-| `matpower/case30/2017-08-01` | 30 | 6 | 41 | 38 | [MTPWR, PSTCA]
-| `matpower/case57/2017-02-01` | 57 | 7 | 80 | 79 | [MTPWR, PSTCA]
-| `matpower/case57/2017-08-01` | 57 | 7 | 80 | 79 | [MTPWR, PSTCA]
-| `matpower/case118/2017-02-01` | 118 | 54 | 186 | 177 | [MTPWR, PSTCA]
-| `matpower/case118/2017-08-01` | 118 | 54 | 186 | 177 | [MTPWR, PSTCA]
-| `matpower/case300/2017-02-01` | 300 | 69 | 411 | 320 | [MTPWR, PSTCA]
-| `matpower/case300/2017-08-01` | 300 | 69 | 411 | 320 | [MTPWR, PSTCA]
+| `matpower/case14/2017-01-01` | 14 | 5 | 20 | 19 | [MTPWR, PSTCA]
+| `matpower/case30/2017-01-01` | 30 | 6 | 41 | 38 | [MTPWR, PSTCA]
+| `matpower/case57/2017-01-01` | 57 | 7 | 80 | 79 | [MTPWR, PSTCA]
+| `matpower/case118/2017-01-01` | 118 | 54 | 186 | 177 | [MTPWR, PSTCA]
+| `matpower/case300/2017-01-01` | 300 | 69 | 411 | 320 | [MTPWR, PSTCA]


 ### MATPOWER/Polish
@@ -60,22 +46,14 @@ Test cases based on the Polish 400, 220 and 110 kV networks, originally provided

 | Name | Buses | Generators | Lines | Contingencies | References |
 |------|-------|------------|-------|---------------|--------|
-| `matpower/case2383wp/2017-02-01` | 2383 | 323 | 2896 | 2240 | [MTPWR]
-| `matpower/case2383wp/2017-08-01` | 2383 | 323 | 2896 | 2240 | [MTPWR]
-| `matpower/case2736sp/2017-02-01` | 2736 | 289 | 3504 | 3159 | [MTPWR]
-| `matpower/case2736sp/2017-08-01` | 2736 | 289 | 3504 | 3159 | [MTPWR]
-| `matpower/case2737sop/2017-02-01` | 2737 | 267 | 3506 | 3161 | [MTPWR]
-| `matpower/case2737sop/2017-08-01` | 2737 | 267 | 3506 | 3161 | [MTPWR]
-| `matpower/case2746wop/2017-02-01` | 2746 | 443 | 3514 | 3155 | [MTPWR]
-| `matpower/case2746wop/2017-08-01` | 2746 | 443 | 3514 | 3155 | [MTPWR]
-| `matpower/case2746wp/2017-02-01` | 2746 | 457 | 3514 | 3156 | [MTPWR]
-| `matpower/case2746wp/2017-08-01` | 2746 | 457 | 3514 | 3156 | [MTPWR]
-| `matpower/case3012wp/2017-02-01` | 3012 | 496 | 3572 | 2854 | [MTPWR]
-| `matpower/case3012wp/2017-08-01` | 3012 | 496 | 3572 | 2854 | [MTPWR]
-| `matpower/case3120sp/2017-02-01` | 3120 | 483 | 3693 | 2950 | [MTPWR]
-| `matpower/case3120sp/2017-08-01` | 3120 | 483 | 3693 | 2950 | [MTPWR]
-| `matpower/case3375wp/2017-02-01` | 3374 | 590 | 4161 | 3245 | [MTPWR]
-| `matpower/case3375wp/2017-08-01` | 3374 | 590 | 4161 | 3245 | [MTPWR]
+| `matpower/case2383wp/2017-01-01` | 2383 | 323 | 2896 | 2240 | [MTPWR]
+| `matpower/case2736sp/2017-01-01` | 2736 | 289 | 3504 | 3159 | [MTPWR]
+| `matpower/case2737sop/2017-01-01` | 2737 | 267 | 3506 | 3161 | [MTPWR]
+| `matpower/case2746wop/2017-01-01` | 2746 | 443 | 3514 | 3155 | [MTPWR]
+| `matpower/case2746wp/2017-01-01` | 2746 | 457 | 3514 | 3156 | [MTPWR]
+| `matpower/case3012wp/2017-01-01` | 3012 | 496 | 3572 | 2854 | [MTPWR]
+| `matpower/case3120sp/2017-01-01` | 3120 | 483 | 3693 | 2950 | [MTPWR]
+| `matpower/case3375wp/2017-01-01` | 3374 | 590 | 4161 | 3245 | [MTPWR]

 ### MATPOWER/PEGASE

@@ -83,16 +61,11 @@ Test cases from the [Pan European Grid Advanced Simulation and State Estimation

 | Name | Buses | Generators | Lines | Contingencies | References |
 |------|-------|------------|-------|---------------|--------|
-| `matpower/case89pegase/2017-02-01` | 89 | 12 | 210 | 192 | [JoFlMa16, FlPaCa13, MTPWR]
-| `matpower/case89pegase/2017-08-01` | 89 | 12 | 210 | 192 | [JoFlMa16, FlPaCa13, MTPWR]
-| `matpower/case1354pegase/2017-02-01` | 1354 | 260 | 1991 | 1288 | [JoFlMa16, FlPaCa13, MTPWR]
-| `matpower/case1354pegase/2017-08-01` | 1354 | 260 | 1991 | 1288 | [JoFlMa16, FlPaCa13, MTPWR]
-| `matpower/case2869pegase/2017-02-01` | 2869 | 510 | 4582 | 3579 | [JoFlMa16, FlPaCa13, MTPWR]
-| `matpower/case2869pegase/2017-08-01` | 2869 | 510 | 4582 | 3579 | [JoFlMa16, FlPaCa13, MTPWR]
-| `matpower/case9241pegase/2017-02-01` | 9241 | 1445 | 16049 | 13932 | [JoFlMa16, FlPaCa13, MTPWR]
-| `matpower/case9241pegase/2017-08-01` | 9241 | 1445 | 16049 | 13932 | [JoFlMa16, FlPaCa13, MTPWR]
-| `matpower/case13659pegase/2017-02-01` | 13659 | 4092 | 20467 | 13932 | [JoFlMa16, FlPaCa13, MTPWR]
-| `matpower/case13659pegase/2017-08-01` | 13659 | 4092 | 20467 | 13932 | [JoFlMa16, FlPaCa13, MTPWR]
+| `matpower/case89pegase/2017-01-01` | 89 | 12 | 210 | 192 | [JoFlMa16, FlPaCa13, MTPWR]
+| `matpower/case1354pegase/2017-01-01` | 1354 | 260 | 1991 | 1288 | [JoFlMa16, FlPaCa13, MTPWR]
+| `matpower/case2869pegase/2017-01-01` | 2869 | 510 | 4582 | 3579 | [JoFlMa16, FlPaCa13, MTPWR]
+| `matpower/case9241pegase/2017-01-01` | 9241 | 1445 | 16049 | 13932 | [JoFlMa16, FlPaCa13, MTPWR]
+| `matpower/case13659pegase/2017-01-01` | 13659 | 4092 | 20467 | 13932 | [JoFlMa16, FlPaCa13, MTPWR]

 ### MATPOWER/RTE

@@ -100,22 +73,14 @@ Test cases from the R&D Division at [Reseau de Transport d'Electricite](https://

 | Name | Buses | Generators | Lines | Contingencies | References |
 |------|-------|------------|-------|---------------|--------|
-| `matpower/case1888rte/2017-02-01` | 1888 | 296 | 2531 | 1484 | [MTPWR, JoFlMa16]
-| `matpower/case1888rte/2017-08-01` | 1888 | 296 | 2531 | 1484 | [MTPWR, JoFlMa16]
-| `matpower/case1951rte/2017-02-01` | 1951 | 390 | 2596 | 1497 | [MTPWR, JoFlMa16]
-| `matpower/case1951rte/2017-08-01` | 1951 | 390 | 2596 | 1497 | [MTPWR, JoFlMa16]
-| `matpower/case2848rte/2017-02-01` | 2848 | 544 | 3776 | 2242 | [MTPWR, JoFlMa16]
-| `matpower/case2848rte/2017-08-01` | 2848 | 544 | 3776 | 2242 | [MTPWR, JoFlMa16]
-| `matpower/case2868rte/2017-02-01` | 2868 | 596 | 3808 | 2260 | [MTPWR, JoFlMa16]
-| `matpower/case2868rte/2017-08-01` | 2868 | 596 | 3808 | 2260 | [MTPWR, JoFlMa16]
-| `matpower/case6468rte/2017-02-01` | 6468 | 1262 | 9000 | 6094 | [MTPWR, JoFlMa16]
-| `matpower/case6468rte/2017-08-01` | 6468 | 1262 | 9000 | 6094 | [MTPWR, JoFlMa16]
-| `matpower/case6470rte/2017-02-01` | 6470 | 1306 | 9005 | 6085 | [MTPWR, JoFlMa16]
-| `matpower/case6470rte/2017-08-01` | 6470 | 1306 | 9005 | 6085 | [MTPWR, JoFlMa16]
-| `matpower/case6495rte/2017-02-01` | 6495 | 1352 | 9019 | 6060 | [MTPWR, JoFlMa16]
-| `matpower/case6495rte/2017-08-01` | 6495 | 1352 | 9019 | 6060 | [MTPWR, JoFlMa16]
-| `matpower/case6515rte/2017-02-01` | 6515 | 1368 | 9037 | 6063 | [MTPWR, JoFlMa16]
-| `matpower/case6515rte/2017-08-01` | 6515 | 1368 | 9037 | 6063 | [MTPWR, JoFlMa16]
+| `matpower/case1888rte/2017-01-01` | 1888 | 296 | 2531 | 1484 | [MTPWR, JoFlMa16]
+| `matpower/case1951rte/2017-01-01` | 1951 | 390 | 2596 | 1497 | [MTPWR, JoFlMa16]
+| `matpower/case2848rte/2017-01-01` | 2848 | 544 | 3776 | 2242 | [MTPWR, JoFlMa16]
+| `matpower/case2868rte/2017-01-01` | 2868 | 596 | 3808 | 2260 | [MTPWR, JoFlMa16]
+| `matpower/case6468rte/2017-01-01` | 6468 | 1262 | 9000 | 6094 | [MTPWR, JoFlMa16]
+| `matpower/case6470rte/2017-01-01` | 6470 | 1306 | 9005 | 6085 | [MTPWR, JoFlMa16]
+| `matpower/case6495rte/2017-01-01` | 6495 | 1352 | 9019 | 6060 | [MTPWR, JoFlMa16]
+| `matpower/case6515rte/2017-01-01` | 6515 | 1368 | 9037 | 6063 | [MTPWR, JoFlMa16]


 PGLIB-UC Instances
@@ -315,7 +280,7 @@ Tejada19
 References
 ----------

-* [UCJL] **Alinson S. Xavier, Aleksandr M. Kazachkov, Feng Qiu.** "UnitCommitment.jl: A Julia/JuMP Optimization Package for Security-Constrained Unit Commitment". Zenodo (2020). [DOI: 10.5281/zenodo.4269874](https://doi.org/10.5281/zenodo.4269874)
+* [UCJL] **Alinson S. Xavier, Aleksandr M. Kazachkov, Ogün Yurdakul, Feng Qiu.** "UnitCommitment.jl: A Julia/JuMP Optimization Package for Security-Constrained Unit Commitment (Version 0.3)". Zenodo (2022). [DOI: 10.5281/zenodo.4269874](https://doi.org/10.5281/zenodo.4269874)

 * [KnOsWa20] **Bernard Knueven, James Ostrowski and Jean-Paul Watson.** "On Mixed-Integer Programming Formulations for the Unit Commitment Problem". INFORMS Journal on Computing (2020). [DOI: 10.1287/ijoc.2019.0944](https://doi.org/10.1287/ijoc.2019.0944)

@@ -323,14 +288,9 @@ References

 * [BaBlEh19] **Clayton Barrows, Aaron Bloom, Ali Ehlen, Jussi Ikaheimo, Jennie Jorgenson, Dheepak Krishnamurthy, Jessica Lau et al.** "The IEEE Reliability Test System: A Proposed 2019 Update." IEEE Transactions on Power Systems (2019). [DOI: 10.1109/TPWRS.2019.2925557](https://doi.org/10.1109/TPWRS.2019.2925557)

-* [JoFlMa16] **C. Josz, S. Fliscounakis, J. Maeght, and P. Panciatici.** "AC Power Flow
-Data in MATPOWER and QCQP Format: iTesla, RTE Snapshots, and PEGASE". [ArXiv (2016)](https://arxiv.org/abs/1603.01533).
+* [JoFlMa16] **C. Josz, S. Fliscounakis, J. Maeght, and P. Panciatici.** "AC Power Flow Data in MATPOWER and QCQP Format: iTesla, RTE Snapshots, and PEGASE". [ArXiv (2016)](https://arxiv.org/abs/1603.01533).

-* [FlPaCa13] **S. Fliscounakis, P. Panciatici, F. Capitanescu, and L. Wehenkel.**
-"Contingency ranking with respect to overloads in very large power
-systems taking into account uncertainty, preventive and corrective
-actions", Power Systems, IEEE Trans. on, (28)4:4909-4917, 2013.
-[DOI: 10.1109/TPWRS.2013.2251015](https://doi.org/10.1109/TPWRS.2013.2251015)
+* [FlPaCa13] **S. Fliscounakis, P. Panciatici, F. Capitanescu, and L. Wehenkel.** "Contingency ranking with respect to overloads in very large power systems taking into account uncertainty, preventive and corrective actions", Power Systems, IEEE Trans. on, (28)4:4909-4917, 2013. [DOI: 10.1109/TPWRS.2013.2251015](https://doi.org/10.1109/TPWRS.2013.2251015)

 * [MTPWR] **D. Zimmerman, C. E. Murillo-Sandnchez and R. J. Thomas.** "Matpower:  Steady-state  operations,  planning,  and  analysis  tools  forpower systems research and education", IEEE Transactions on PowerSystems, vol. 26, no. 1, pp. 12 –19, Feb. 2011. [DOI: 10.1109/TPWRS.2010.2051168](https://doi.org/10.1109/TPWRS.2010.2051168)

--- a/docs/src/model.md
+++ b/docs/src/model.md
@@ -0,0 +1,233 @@
+JuMP Model
+==========
+
+In this page, we describe the JuMP optimization model produced by the function `build_model`. A detailed understanding of this model is not necessary if you are just interested in using the package to solve some standard unit commitment cases, but it may be useful, for example, if you need to solve a slightly different problem, with additional variables and constraints. The notation in this page generally follows [KnOsWa20].
+
+Decision variables
+------------------
+
+UC.jl models the security-constrained unit commitment problem as a two-stage stochastic program. In this approach, some of the decision variables are *first-stage decisions*, which are taken before the uncertainty is realized and must therefore be the same across all scenarios, while the remaining variables are *second-stage decisions*, which can attain a different values in each scenario. In the current version of the package, all binary variables (which model commitment decisions of thermal units) are first-stage decisions and all continuous variables are second-stage decisions.
+
+!!! note
+
+    UC.jl treats deterministic SCUC instances as a special case of the stochastic problem in which there is only one scenario, named `"s1"` by default. To access second-stage decisions, therefore, you must provide this scenario name as the value for `sn`. For example, `model[:prod_above]["s1", g, t]`. 
+
+### Generators
+
+In this section, we describe the decision variables associated with the generators, which include both thermal units (e.g., natural gas-fired power plant) and profiled units (e.g., wind turbine). 
+
+#### Thermal Units
+
+Name |  Description | Unit | Stage
+:-----|:-------------|:------: | :------:
+`is_on[g,t]` | True if generator `g` is on at time `t`. | Binary | 1
+`switch_on[g,t]` | True is generator `g` switches on at time `t`. | Binary| 1
+`switch_off[g,t]` | True if generator `g` switches off at time `t`. | Binary| 1
+`startup[g,t,s]` | True if generator `g` switches on at time `t` incurring start-up costs from start-up category `s`. | Binary| 1
+`prod_above[sn,g,t]` | Amount of power produced by generator `g` above its minimum power output at time `t` in scenario `sn`. For example, if the minimum power of generator `g` is 100 MW and `g` is producing 115 MW of power at time `t` in scenario `sn`, then `prod_above[sn,g,t]` equals `15.0`. | MW | 2
+`segprod[sn,g,t,k]` | Amount of power from piecewise linear segment `k` produced by generator `g` at time `t` in scenario `sn`. For example, if cost curve for generator `g` is defined by the points `(100, 1400)`, `(110, 1600)`, `(130, 2200)` and `(135, 2400)`, and if the generator is producing 115 MW of power at time `t` in scenario `sn`, then `segprod[sn,g,t,:]` equals `[10.0, 5.0, 0.0]`.| MW | 2
+`reserve[sn,r,g,t]` | Amount of reserve `r` provided by unit `g` at time `t` in scenario `sn`. | MW | 2
+
+!!! warning
+
+    The first-stage decision variables of the JuMP model are `is_on[g,t]`, `switch_on[g,t]`, `switch_off[g,t]`, and `startup[g,t,s]`. As such, the dictionaries corresponding to these variables do not include the scenario index in their keys. In contrast, all other variables of the created JuMP model are allowed to obtain a different value in each scenario and are thus modeled as second-stage decision variables. Accordingly, the dictionaries of all second-stage decision variables have the scenario index in their keys. This is true even if the model is created to solve the deterministic SCUC, in which case the default scenario index `s1` is included in the dictionary key.
+    
+
+#### Profiled Units
+
+Name | Description | Unit | Stage
+:-----|:-------------|:------: | :------:
+`prod_profiled[s,t]` | Amount of power produced by profiled unit `g` at time `t`. | MW | 2
+
+
+### Buses
+
+Name | Description | Unit | Stage
+:-----|:-------------|:------:| :------:
+`net_injection[sn,b,t]` | Net injection at bus `b` at time `t` in scenario `sn`. | MW | 2
+`curtail[sn,b,t]` | Amount of load curtailed at bus `b` at time `t` in scenario `sn`. | MW | 2
+
+
+### Price-sensitive loads
+
+Name |  Description | Unit | Stage
+:-----|:-------------|:------:| :------:
+`loads[sn,s,t]` | Amount of power served to price-sensitive load `s` at time `t` in scenario `sn`. | MW | 2
+
+### Transmission lines
+
+Name |  Description | Unit | Stage 
+:-----|:-------------|:------:| :------:
+`flow[sn,l,t]` |  Power flow on line `l` at time `t` in scenario `sn`. | MW | 2
+`overflow[sn,l,t]` | Amount of flow above the limit for line `l` at time `t` in scenario `sn`. | MW | 2
+
+!!! warning
+
+    Since transmission and N-1 security constraints are enforced in a lazy way, most of the `flow[l,t]` variables are never added to the model. Accessing `model[:flow][sn,l,t]` without first checking that the variable exists will likely generate an error.
+
+Objective function
+------------------
+
+TODO
+
+Constraints
+-----------
+
+TODO
+
+
+Inspecting and modifying the model
+----------------------------------
+
+### Accessing decision variables
+
+After building a model using `UnitCommitment.build_model`, it is possible to obtain a reference to the decision variables by calling `model[:varname][index]`. For example, `model[:is_on]["g1",1]` returns a direct reference to the JuMP variable indicating whether generator named "g1" is on at time 1. The script below illustrates how to build a model, solve it and display the solution without using the function `UnitCommitment.solution`.
+
+```julia
+using Cbc
+using Printf
+using JuMP
+using UnitCommitment
+
+# Load benchmark instance
+instance = UnitCommitment.read_benchmark("matpower/case118/2017-02-01")
+
+# Build JuMP model
+model = UnitCommitment.build_model(
+    instance=instance,
+    optimizer=Cbc.Optimizer,
+)
+
+# Solve the model
+UnitCommitment.optimize!(model)
+
+# Display commitment status
+for g in instance.units
+    for t in 1:instance.time
+        @printf(
+            "%-10s %5d %5.1f %5.1f %5.1f\n",
+            g.name,
+            t,
+            value(model[:is_on][g.name, t]),
+            value(model[:switch_on][g.name, t]),
+            value(model[:switch_off][g.name, t]),
+        )
+    end
+end
+```
+
+### Fixing variables, modifying objective function and adding constraints
+
+Since we now have a direct reference to the JuMP decision variables, it is possible to fix variables, change the coefficients in the objective function, or even add new constraints to the model before solving it. 
+!!! warning
+
+    It is important to take into account the stage of the decision variables in modifying the optimization model. In changing a deterministic SCUC model, modifying the second-stage decision variables requires adding the term `s1`, which is the default scenario name assigned to the second-stage decision variables in the SCUC model. For an SUC model, the package permits the modification of the second-stage decision variables individually for each scenario. 
+
+The script below shows how the JuMP model can be modified after it is created. For more information on modifying an existing model, [see the JuMP documentation](https://jump.dev/JuMP.jl/stable/manual/variables/).
+
+```julia
+using Cbc
+using JuMP
+using UnitCommitment
+
+# Load benchmark instance
+instance = UnitCommitment.read_benchmark("matpower/case118/2017-02-01")
+
+# Construct JuMP model
+model = UnitCommitment.build_model(
+    instance=instance,
+    optimizer=Cbc.Optimizer,
+)
+
+# Fix the commitment status of the generator "g1" in time period 1 to 1.0
+JuMP.fix(
+    model[:is_on]["g1",1],
+    1.0,
+    force=true,
+)
+
+# Fix the production level of the generator "g1" above its minimum level in time period 1 and 
+# in scenario "s1" to 20.0 MW. Observe that the three-tuple dictionary key involves the scenario 
+# index "s1", as production above minimum is a second-stage decision variable.
+JuMP.fix(
+    model[:prod_above]["s1", "g1", 1],
+    20.0,
+    force=true,
+)
+
+# Enforce the curtailment of 20.0 MW of load at bus "b2" in time period 4 in scenario "s1".
+JuMP.fix(
+    curtail["s1", "b2", 4] =
+    20.0,
+    force=true,
+)
+
+# Change the objective function
+JuMP.set_objective_coefficient(
+    model,
+    model[:switch_on]["g2",1],
+    1000.0,
+)
+
+# Create a new constraint
+@constraint(
+    model,
+    model[:is_on]["g3",1] + model[:is_on]["g4",1] <= 1,
+)
+
+# Solve the model
+UnitCommitment.optimize!(model)
+```
+
+### Adding new component to a bus
+
+The following snippet shows how to add a new grid component to a particular bus. For each time step, we create decision variables for the new grid component, add these variables to the objective function, then attach the component to a particular bus by modifying some existing model constraints. 
+
+```julia
+using Cbc
+using JuMP
+using UnitCommitment
+
+# Load instance and build base model
+instance = UnitCommitment.read_benchmark("matpower/case118/2017-02-01")
+model = UnitCommitment.build_model(
+    instance=instance,
+    optimizer=Cbc.Optimizer,
+)
+
+# Get the number of time steps in the original instance
+T = instance.time
+
+# Create decision variables for the new grid component.
+# In this example, we assume that the new component can
+# inject up to 10 MW of power at each time step, so we
+# create new continuous variables 0 ≤ x[t] ≤ 10.
+@variable(model, x[1:T], lower_bound=0.0, upper_bound=10.0)
+
+# For each time step
+for t in 1:T
+
+    # Add production costs to the objective function.
+    # In this example, we assume a cost of $5/MW.
+    set_objective_coefficient(model, x[t], 5.0)
+
+    # Attach the new component to bus b1 in scenario s1, by modifying the
+    # constraint `eq_net_injection`.
+    set_normalized_coefficient(
+        model[:eq_net_injection]["s1", "b1", t],
+        x[t],
+        1.0,
+    )
+end
+
+# Solve the model
+UnitCommitment.optimize!(model)
+
+# Show optimal values for the x variables
+@show value.(x)
+```
+
+References
+----------
+* [KnOsWa20] **Bernard Knueven, James Ostrowski and Jean-Paul Watson.** "On Mixed-Integer Programming Formulations for the Unit Commitment Problem". INFORMS Journal on Computing (2020). [DOI: 10.1287/ijoc.2019.0944](https://doi.org/10.1287/ijoc.2019.0944)
+
--- a/docs/src/usage.md
+++ b/docs/src/usage.md
@@ -0,0 +1,381 @@
+Usage
+=====
+
+Installation
+------------
+
+UnitCommitment.jl was tested and developed with [Julia 1.9](https://julialang.org/). To install Julia, please follow the [installation guide on the official Julia website](https://julialang.org/downloads/). To install UnitCommitment.jl, run the Julia interpreter, type `]` to open the package manager, then type:
+
+```text
+pkg> add UnitCommitment@0.4
+```
+
+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 [HiGHS](https://github.com/jump-dev/HiGHS.jl), [Cbc](https://github.com/JuliaOpt/Cbc.jl) and [GLPK](https://github.com/JuliaOpt/GLPK.jl). In the instructions below, HiGHS will be used, but any other MILP solver listed in JuMP installation guide should also be compatible.
+
+Typical Usage
+-------------
+
+### Solving user-provided instances
+
+The first step to use UC.jl is to construct JSON files that describe each scenario of your deterministic or stochastic unit commitment instance. See [Data Format](format.md) for a complete description of the data format UC.jl expects. The next steps, as shown below, are to: (1) read the scenario files; (2) build the optimization model; (3) run the optimization; and (4) extract the optimal solution.
+
+```julia
+using HiGHS
+using JuMP
+using UnitCommitment
+
+# 1. Read instance
+instance = UnitCommitment.read(["example/s1.json", "example/s2.json"])
+
+# 2. Construct optimization model
+model = UnitCommitment.build_model(
+    instance=instance,
+    optimizer=HiGHS.Optimizer,
+)
+
+# 3. Solve model
+UnitCommitment.optimize!(model)
+
+# 4. Write solution to a file
+solution = UnitCommitment.solution(model)
+UnitCommitment.write("example/out.json", solution)
+```
+
+To read multiple files from a given folder, the [Glob](https://github.com/vtjnash/Glob.jl) package can be used:
+
+```jldoctest usage1; output = false
+using Glob
+using UnitCommitment
+
+instance = UnitCommitment.read(glob("s*.json", "example/"))
+
+# output
+UnitCommitmentInstance(2 scenarios, 6 thermal units, 0 profiled units, 14 buses, 20 lines, 19 contingencies, 1 price sensitive loads, 4 time steps)
+```
+
+To solve deterministic instances, a single scenario file may be provided.
+
+```jldoctest usage1; output = false
+instance = UnitCommitment.read("example/s1.json")
+
+# output
+UnitCommitmentInstance(1 scenarios, 6 thermal units, 0 profiled units, 14 buses, 20 lines, 19 contingencies, 1 price sensitive loads, 4 time steps)
+```
+
+### Solving benchmark instances
+
+UnitCommitment.jl contains a large number of deterministic benchmark instances collected from the literature and converted into a common data format. To solve one of these instances individually, instead of constructing your own, the function `read_benchmark` can be used, as shown below. See [Instances](instances.md) for the complete list of available instances.
+
+```jldoctest usage1; output = false
+instance = UnitCommitment.read_benchmark("matpower/case3375wp/2017-02-01")
+
+# output
+UnitCommitmentInstance(1 scenarios, 590 thermal units, 0 profiled units, 3374 buses, 4161 lines, 3245 contingencies, 0 price sensitive loads, 36 time steps)
+```
+
+## Customizing the formulation
+
+By default, `build_model` uses a formulation that combines modeling components from different publications, and that has been carefully tested, using our own benchmark scripts, to provide good performance across a wide variety of instances. This default formulation is expected to change over time, as new methods are proposed in the literature. You can, however, construct your own formulation, based on the modeling components that you choose, as shown in the next example.
+
+```julia
+using HiGHS
+using UnitCommitment
+
+import UnitCommitment:
+    Formulation,
+    KnuOstWat2018,
+    MorLatRam2013,
+    ShiftFactorsFormulation
+
+instance = UnitCommitment.read_benchmark(
+    "matpower/case118/2017-02-01",
+)
+
+model = UnitCommitment.build_model(
+    instance = instance,
+    optimizer = HiGHS.Optimizer,
+    formulation = Formulation(
+        pwl_costs = KnuOstWat2018.PwlCosts(),
+        ramping = MorLatRam2013.Ramping(),
+        startup_costs = MorLatRam2013.StartupCosts(),
+        transmission = ShiftFactorsFormulation(
+            isf_cutoff = 0.005,
+            lodf_cutoff = 0.001,
+        ),
+    ),
+)
+```
+
+## 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 thermal 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 HiGHS
+using UnitCommitment
+
+# Read original instance
+instance = UnitCommitment.read("example/s1.json")
+
+# Generate initial conditions (in-place)
+UnitCommitment.generate_initial_conditions!(instance, HiGHS.Optimizer)
+
+# Construct and solve optimization model
+model = UnitCommitment.build_model(
+    instance=instance,
+    optimizer=HiGHS.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.
+    
+## Verifying solutions
+
+When developing new formulations, it is very easy to introduce subtle errors in the model that result in incorrect solutions. To help avoiding 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.
+
+```jldoctest; output = false
+using JSON
+using UnitCommitment
+
+# Read instance
+instance = UnitCommitment.read("example/s1.json")
+
+# Read solution (potentially produced by other packages) 
+solution = JSON.parsefile("example/out.json")
+
+# Validate solution and print validation errors
+UnitCommitment.validate(instance, solution)
+
+# output
+
+true
+```
+
+## Progressive Hedging
+
+By default, UC.jl uses the Extensive Form (EF) when solving stochastic instances. This approach involves constructing a single JuMP model that contains data and decision variables for all scenarios. Although EF has optimality guarantees and performs well with small test cases, it can become computationally intractable for large instances or substantial number of scenarios.
+
+Progressive Hedging (PH) is an alternative (heuristic) solution method provided by UC.jl in which the problem is decomposed into smaller scenario-based subproblems, which are then solved in parallel in separate Julia processes, potentially across multiple machines. Quadratic penalty terms are used to enforce convergence of first-stage decision variables. The method is closely related to the Alternative Direction Method of Multipliers (ADMM) and can handle larger instances, although it is not guaranteed to converge to the optimal solution. Our implementation of PH relies on Message Passing Interface (MPI) for communication. We refer to [MPI.jl Documentation](https://github.com/JuliaParallel/MPI.jl) for more details on installing MPI.
+
+The following example shows how to solve SCUC instances using progressive hedging. The script should be saved in a file, say `ph.jl`, and executed using `mpiexec -n <num-scenarios> julia ph.jl`.
+
+
+```julia
+using HiGHS
+using MPI
+using UnitCommitment
+using Glob
+
+# 1. Initialize MPI
+MPI.Init()
+
+# 2. Configure progressive hedging method
+ph = UnitCommitment.ProgressiveHedging()
+
+# 3. Read problem instance
+instance = UnitCommitment.read(["example/s1.json", "example/s2.json"], ph)
+
+# 4. Build JuMP model
+model = UnitCommitment.build_model(
+    instance = instance,
+    optimizer = HiGHS.Optimizer,
+)
+
+# 5. Run the decentralized optimization algorithm
+UnitCommitment.optimize!(model, ph)
+
+# 6. Fetch the solution
+solution = UnitCommitment.solution(model, ph)
+
+# 7. Close MPI
+MPI.Finalize()
+```
+
+When using PH, the model can be customized as usual, with different formulations or additional user-provided constraints. Note that `read`, in this case, takes `ph` as an argument. This allows each Julia process to read only the instance files that are relevant to it. Similarly, the `solution` function gathers the optimal solution of each processes and returns a combined dictionary. 
+
+Each process solves a sub-problem with $\frac{s}{p}$ scenarios, where $s$ is the total number of scenarios and $p$ is the number of MPI processes. For instance, if we have 15 scenario files and 5 processes, then each process will solve a JuMP model that contains data for 3 scenarios. If the total number of scenarios is not divisible by the number of processes, then an error will be thrown.
+
+
+!!! warning
+
+    Currently, PH can handle only equiprobable scenarios. Further, `solution(model, ph)` can only handle cases where only one scenario is modeled in each process.
+
+
+## Computing Locational Marginal Prices
+
+Locational marginal prices (LMPs) refer to the cost of supplying electricity at a particular location of the network. Multiple methods for computing LMPs have been proposed in the literature. UnitCommitment.jl implements two commonly-used methods: conventional LMPs and Approximated Extended LMPs (AELMPs). To compute LMPs for a given unit commitment instance, the `compute_lmp` function can be used, as shown in the examples below. The function accepts three arguments -- a solved SCUC model, an LMP method, and a linear optimizer -- and it returns a dictionary mapping `(bus_name, time)` to the marginal price.
+
+
+!!! warning
+
+    Most mixed-integer linear optimizers, such as `HiGHS`, `Gurobi` and `CPLEX` can be used with `compute_lmp`, with the notable exception of `Cbc`, which does not support dual value evaluations. If using `Cbc`, please provide `Clp` as the linear optimizer.
+
+### Conventional LMPs
+
+LMPs are conventionally computed by: (1) solving the SCUC model, (2) fixing all binary variables to their optimal values, and (3) re-solving the resulting linear programming model. In this approach, the LMPs are defined as the dual variables' values associated with the net injection constraints. The example below shows how to compute conventional LMPs for a given unit commitment instance. First, we build and optimize the SCUC model. Then, we call the `compute_lmp` function, providing as the second argument `ConventionalLMP()`.
+
+
+```julia
+using UnitCommitment
+using HiGHS
+
+import UnitCommitment: ConventionalLMP
+
+# Read benchmark instance
+instance = UnitCommitment.read_benchmark("matpower/case118/2018-01-01")
+
+# Build the model
+model = UnitCommitment.build_model(
+    instance = instance,
+    optimizer = HiGHS.Optimizer,
+)
+
+# Optimize the model
+UnitCommitment.optimize!(model)
+
+# Compute the LMPs using the conventional method
+lmp = UnitCommitment.compute_lmp(
+    model,
+    ConventionalLMP(),
+    optimizer = HiGHS.Optimizer,
+)
+
+# Access the LMPs
+# Example: "s1" is the scenario name, "b1" is the bus name, 1 is the first time slot
+@show lmp["s1","b1", 1]
+```
+
+### Approximate Extended LMPs
+
+Approximate Extended LMPs (AELMPs) are an alternative method to calculate locational marginal prices which attemps to minimize uplift payments. The method internally works by modifying the instance data in three ways: (1) it sets the minimum power output of each generator to zero, (2) it averages the start-up cost over the offer blocks for each generator, and (3) it relaxes all integrality constraints. To compute AELMPs, as shown in the example below, we call `compute_lmp` and provide `AELMP()` as the second argument.
+
+This method has two configurable parameters: `allow_offline_participation` and `consider_startup_costs`. If `allow_offline_participation = true`, then offline generators are allowed to participate in the pricing. If instead `allow_offline_participation = false`, offline generators are not allowed and therefore are excluded from the system. A solved UC model is optional if offline participation is allowed, but is required if not allowed. The method forces offline participation to be allowed if the UC model supplied by the user is not solved. For the second field, If `consider_startup_costs = true`, then start-up costs are integrated and averaged over each unit production; otherwise the production costs stay the same. By default, both fields are set to `true`.
+
+!!! warning
+
+    This approximation method is still under active research, and has several limitations. The implementation provided in the package is based on MISO Phase I only. It only supports fast start resources. More specifically, the minimum up/down time of all generators must be 1, the initial power of all generators must be 0, and the initial status of all generators must be negative. The method does not support time-varying start-up costs. The method does not support multiple scenarios. If offline participation is not allowed, AELMPs treats an asset to be  offline if it is never on throughout all time periods. 
+
+```julia
+using UnitCommitment
+using HiGHS
+
+import UnitCommitment: AELMP
+
+# Read benchmark instance
+instance = UnitCommitment.read_benchmark("matpower/case118/2017-02-01")
+
+# Build the model
+model = UnitCommitment.build_model(
+    instance = instance,
+    optimizer = HiGHS.Optimizer,
+)
+
+# Optimize the model
+UnitCommitment.optimize!(model)
+
+# Compute the AELMPs
+aelmp = UnitCommitment.compute_lmp(
+    model,
+    AELMP(
+        allow_offline_participation = false,
+        consider_startup_costs = true
+    ),
+    optimizer = HiGHS.Optimizer
+)
+
+# Access the AELMPs
+# Example: "s1" is the scenario name, "b1" is the bus name, 1 is the first time slot
+# Note: although scenario is supported, the query still keeps the scenario keys for consistency.
+@show aelmp["s1", "b1", 1]
+```
+
+## Time Decomposition
+
+Solving unit commitment instances that have long time horizons (for example, year-long 8760-hour instances) requires a substantial amount of computational power. To address this issue, UC.jl offers a time decomposition method, which breaks the instance down into multiple overlapping subproblems, solves them sequentially, then reassembles the solution.
+
+When solving a unit commitment instance with a dense time slot structure, computational complexity can become a significant challenge. For instance, if the instance contains hourly data for an entire year (8760 hours), solving such a model can require a substantial amount of computational power. To address this issue, UC.jl provides a time_decomposition method within the `optimize!` function. This method decomposes the problem into multiple sub-problems, solving them sequentially.
+
+The `optimize!` function takes 5 parameters: a unit commitment instance, a `TimeDecomposition` method, an optimizer, and two optional functions `after_build` and `after_optimize`. It returns a solution dictionary. The `TimeDecomposition` method itself requires four arguments: `time_window`, `time_increment`, `inner_method` (optional), and `formulation` (optional). These arguments define the time window for each sub-problem, the time increment to move to the next sub-problem, the method used to solve each sub-problem, and the formulation employed, respectively. The two functions, namely `after_build` and `after_optimize`, are invoked subsequent to the construction and optimization of each sub-model, respectively. It is imperative that the `after_build` function requires its two arguments to be consistently mapped to `model` and `instance`, while the `after_optimize` function necessitates its three arguments to be consistently mapped to `solution`, `model`, and `instance`.
+
+The code snippet below illustrates an example of solving an instance by decomposing the model into multiple 36-hour sub-problems using the `XavQiuWanThi2019` method. Each sub-problem advances 24 hours at a time. The first sub-problem covers time steps 1 to 36, the second covers time steps 25 to 60, the third covers time steps 49 to 84, and so on. The initial power levels and statuses of the second and subsequent sub-problems are set based on the results of the first 24 hours from each of their immediate prior sub-problems. In essence, this approach addresses the complexity of solving a large problem by tackling it in 24-hour intervals, while incorporating an additional 12-hour buffer to mitigate the closing window effect for each sub-problem. Furthermore, the `after_build` function imposes the restriction that `g3` and `g4` cannot be activated simultaneously during the initial time slot of each sub-problem. On the other hand, the `after_optimize` function is invoked to calculate the conventional Locational Marginal Prices (LMPs) for each sub-problem, and subsequently appends the computed values to the `lmps` vector.
+
+> **Warning** 
+> Specifying `TimeDecomposition` as the value of the `inner_method` field of another `TimeDecomposition` causes errors when calling the `optimize!` function due to the different argument structures between the two `optimize!` functions.
+
+```julia
+using UnitCommitment, JuMP, Cbc, HiGHS
+
+import UnitCommitment: 
+    TimeDecomposition,
+    ConventionalLMP,
+    XavQiuWanThi2019,
+    Formulation
+
+# specifying the after_build and after_optimize functions
+function after_build(model, instance)
+    @constraint(
+        model,
+        model[:is_on]["g3", 1] + model[:is_on]["g4", 1] <= 1,
+    )
+end
+
+lmps = []
+function after_optimize(solution, model, instance)
+    lmp = UnitCommitment.compute_lmp(
+        model,
+        ConventionalLMP(),
+        optimizer = HiGHS.Optimizer,
+    )
+    return push!(lmps, lmp)
+end
+
+# assume the instance is given as a 120h problem
+instance = UnitCommitment.read("instance.json")
+
+solution = UnitCommitment.optimize!(
+    instance,
+    TimeDecomposition(
+        time_window = 36,  # solve 36h problems
+        time_increment = 24,  # advance by 24h each time
+        inner_method = XavQiuWanThi2019.Method(),
+        formulation = Formulation(),
+    ),
+    optimizer = Cbc.Optimizer,
+    after_build = after_build,
+    after_optimize = after_optimize,
+)
+```
+
+## Day-ahead (DA) Market to Real-time (RT) Markets
+The UC.jl package offers a comprehensive set of functions for solving marketing problems. The primary function, `solve_market`, facilitates the solution of day-ahead (DA) markets, which can be either deterministic or stochastic in nature. Subsequently, it sequentially maps the commitment status obtained from the DA market to all the real-time (RT) markets, which are deterministic instances. It is essential to ensure that the time span of the DA market encompasses all the RT markets, and the file paths for the RT markets must be specified in chronological order. Each RT market should represent a single time slot, and it is recommended to include a few additional time slots to mitigate the closing window effect.
+
+The `solve_market` function accepts several parameters, including the file path (or a list of file paths in the case of stochastic markets) for the DA market, a list of file paths for the RT markets, the market settings specified by the `MarketSettings` structure, and an optimizer. The `MarketSettings` structure itself requires three optional arguments: `inner_method`, `lmp_method`, and `formulation`. If the computation of Locational Marginal Prices (LMPs) is not desired, the `lmp_method` can be set to `nothing`. Additional optional parameters include a linear programming optimizer for solving LMPs (if a different optimizer than the required one is desired), callback functions `after_build_da` and `after_optimize_da`, which are invoked after the construction and optimization of the DA market, and callback functions `after_build_rt` and `after_optimize_rt`, which are invoked after the construction and optimization of each RT market. It is crucial to note that the `after_build` function requires its two arguments to consistently correspond to `model` and `instance`, while the `after_optimize` function requires its three arguments to consistently correspond to `solution`, `model`, and `instance`.
+
+As an illustrative example, suppose the DA market predicts hourly data for a 24-hour period, while the RT markets represent 5-minute intervals. In this scenario, each RT market file corresponds to a specific 5-minute interval, with the first RT market representing the initial 5 minutes, the second RT market representing the subsequent 5 minutes, and so on. Consequently, there should be 12 RT market files for each hour. To mitigate the closing window effect, except for the last few RT markets, each RT market should contain three time slots, resulting in a total time span of 15 minutes. However, only the first time slot is considered in the final solution. The last two RT markets should only contain 2 and 1 time slot(s), respectively, to ensure that the total time covered by all RT markets does not exceed the time span of the DA market. The code snippet below demonstrates a simplified example of how to utilize the `solve_market` function. Please note that it only serves as a simplified example and may require further customization based on the specific requirements of your use case.
+
+```julia
+using UnitCommitment, Cbc, HiGHS
+
+import UnitCommitment: 
+    MarketSettings,
+    XavQiuWanThi2019,
+    ConventionalLMP,
+    Formulation
+
+solution = UnitCommitment.solve_market(
+    "da_instance.json",
+    ["rt_instance_1.json", "rt_instance_2.json", "rt_instance_3.json"],
+    MarketSettings(
+        inner_method = XavQiuWanThi2019.Method(),
+        lmp_method = ConventionalLMP(),
+        formulation = Formulation(),
+    ),
+    optimizer = Cbc.Optimizer,
+    lp_optimizer = HiGHS.Optimizer,
+)
+```
--- a/docs/usage.md
+++ b/docs/usage.md
@@ -1,149 +0,0 @@
-```{sectnum}
---
-start: 1
-depth: 2
-suffix: .
---
-```
-
-Usage
-=====
-
-Installation
------------
-
-UnitCommitment.jl was tested and developed with [Julia 1.6](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 UnitCommitment@0.2
-```
-
-To test that the package has been correctly installed, run:
-
-```text
-pkg> test UnitCommitment
-```
-
-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.
-
-Typical Usage
-------------
-
-### Solving user-provided instances
-
-The first step to use UC.jl is to construct a JSON file describing your unit commitment instance. See [Data Format](format.md) for a complete description of the data format UC.jl expects. The next steps, as shown below, are to: (1) read the instance from file; (2) construct the optimization model; (3) run the optimization; and (4) extract the optimal solution.
-
-```julia
-using Cbc
-using JSON
-using UnitCommitment
-
-# 1. Read instance
-instance = UnitCommitment.read("/path/to/input.json")
-
-# 2. Construct optimization model
-model = UnitCommitment.build_model(
-    instance=instance,
-    optimizer=Cbc.Optimizer,
-)
-
-# 3. Solve model
-UnitCommitment.optimize!(model)
-
-# 4. Write solution to a file
-solution = UnitCommitment.solution(model)
-UnitCommitment.write("/path/to/output.json", solution)
-```
-
-### Solving benchmark instances
-
-UnitCommitment.jl contains a large number of benchmark instances collected from the literature and converted into a common data format. To solve one of these instances individually, instead of constructing your own, the function `read_benchmark` can be used, as shown below. See [Instances](instances.md) for the complete list of available instances.
-
-```julia
-using UnitCommitment
-instance = UnitCommitment.read_benchmark("matpower/case3375wp/2017-02-01")
-```
-
-Advanced usage
--------------
-
-### Customizing the formulation
-
-By default, `build_model` uses a formulation that combines modeling components from different publications, and that has been carefully tested, using our own benchmark scripts, to provide good performance across a wide variety of instances. This default formulation is expected to change over time, as new methods are proposed in the literature. You can, however, construct your own formulation, based on the modeling components that you choose, as shown in the next example.
-
-```julia
-using Cbc
-using UnitCommitment
-
-import UnitCommitment:
-    Formulation,
-    KnuOstWat2018,
-    MorLatRam2013,
-    ShiftFactorsFormulation
-
-instance = UnitCommitment.read_benchmark(
-    "matpower/case118/2017-02-01",
-)
-
-model = UnitCommitment.build_model(
-    instance = instance,
-    optimizer = Cbc.Optimizer,
-    formulation = Formulation(
-        pwl_costs = KnuOstWat2018.PwlCosts(),
-        ramping = MorLatRam2013.Ramping(),
-        startup_costs = MorLatRam2013.StartupCosts(),
-        transmission = ShiftFactorsFormulation(
-            isf_cutoff = 0.005,
-            lodf_cutoff = 0.001,
-        ),
-    ),
-)
-```
-
-### 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=instance,
-    optimizer=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.
-```
-    
-### 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)
-```
--- a/instances/README.md
+++ b/instances/README.md
@@ -1,53 +0,0 @@
-Instances
-=========
-
-UnitCommitment.jl provides a large collection of benchmark instances collected
-from the literature and converted to a common data format. If you use these instances in your research, we request that you cite UnitCommitment.jl, as well as the original sources, as listed below. [See documentation for more details](https://anl-ceeesa.github.io/UnitCommitment.jl/).
-
-References
----------
-
-### UnitCommitment.jl
-
-* [UCJL] **Alinson S. Xavier, Feng Qiu.** "UnitCommitment.jl: A Julia/JuMP Optimization Package for Security-Constrained Unit Commitment". Zenodo (2020). [DOI: 10.5281/zenodo.4269874](https://doi.org/10.5281/zenodo.4269874)
-
-
-### MATPOWER
-
-* [MTPWR] **D. Zimmerman, C. E. Murillo-Sandnchez and R. J. Thomas.** "Matpower:  Steady-state  operations,  planning,  and  analysis  tools  forpower systems research and education", IEEE Transactions on PowerSystems, vol. 26, no. 1, pp. 12 –19, Feb. 2011. [DOI: 10.1109/TPWRS.2010.2051168](https://doi.org/10.1109/TPWRS.2010.2051168)
-
-* [PSTCA] **University of Washington, Dept. of Electrical Engineering.** "Power Systems Test Case Archive". Available at: <http://www.ee.washington.edu/research/pstca/> (Accessed: Nov 14, 2020)
-
-* [JoFlMa16] **C. Josz, S. Fliscounakis, J. Maeght, and P. Panciatici.** "AC Power Flow
-Data in MATPOWER and QCQP Format: iTesla, RTE Snapshots, and PEGASE". [ArXiv (2016)](https://arxiv.org/abs/1603.01533).
-
-* [FlPaCa13] **S. Fliscounakis, P. Panciatici, F. Capitanescu, and L. Wehenkel.**
-"Contingency ranking with respect to overloads in very large power
-systems taking into account uncertainty, preventive and corrective
-actions", Power Systems, IEEE Trans. on, (28)4:4909-4917, 2013.
-[DOI: 10.1109/TPWRS.2013.2251015](https://doi.org/10.1109/TPWRS.2013.2251015)
-
-
-### PGLIB-UC
-
-* [PGLIB] **Carleton Coffrin and Bernard Knueven.** "Power Grid Lib - Unit Commitment". Available at: <https://github.com/power-grid-lib/pglib-uc> (Accessed: Nov 14, 2020)
-
-* [KrHiOn12] **Eric Krall, Michael Higgins and Richard P. O’Neill.** "RTO unit commitment test system." Federal Energy Regulatory Commission. Available at: <https://www.ferc.gov/industries-data/electric/power-sales-and-markets/increasing-efficiency-through-improved-software-1> (Accessed: Nov 14, 2020)
-
-* [KnOsWa20] **Bernard Knueven, James Ostrowski and Jean-Paul Watson.** "On Mixed-Integer Programming Formulations for the Unit Commitment Problem". INFORMS Journal on Computing (2020). [DOI: 10.1287/ijoc.2019.0944](https://doi.org/10.1287/ijoc.2019.0944)
-
-### RTS-GMLC
-
-* https://github.com/GridMod/RTS-GMLC
-
-* [BaBlEh19] **Clayton Barrows, Aaron Bloom, Ali Ehlen, Jussi Ikaheimo, Jennie Jorgenson, Dheepak Krishnamurthy, Jessica Lau et al.** "The IEEE Reliability Test System: A Proposed 2019 Update." IEEE Transactions on Power Systems (2019). [DOI: 10.1109/TPWRS.2019.2925557](https://doi.org/10.1109/TPWRS.2019.2925557)
-
-### OR-LIB
-
-* [ORLIB] **J.E.Beasley.** "OR-Library: distributing test problems by electronic mail", Journal of the Operational Research Society 41(11) (1990). [DOI: 10.2307/2582903](https://doi.org/10.2307/2582903)
-
-* [FrGe06] **A. Frangioni, C. Gentile.** "Solving nonlinear single-unit commitment problems with ramping constraints" Operations Research 54(4), p. 767 - 775, 2006. [DOI: 10.1287/opre.1060.0309](https://doi.org/10.1287/opre.1060.0309)
-
-### Tejada19
-
-* [TeLuSa19] **D. A. Tejada-Arango, S. Lumbreras, P. Sanchez-Martin and A. Ramos.** "Which Unit-Commitment Formulation is Best? A Systematic Comparison," in IEEE Transactions on Power Systems. [DOI: 10.1109/TPWRS.2019.2962024](https://ieeexplore.ieee.org/document/8941313/).
--- a/instances/matpower/case118/2017-02-01.json.gz
+++ b/instances/matpower/case118/2017-02-01.json.gz
--- a/instances/matpower/case118/2017-08-01.json.gz
+++ b/instances/matpower/case118/2017-08-01.json.gz
--- a/instances/matpower/case1354pegase/2017-02-01.json.gz
+++ b/instances/matpower/case1354pegase/2017-02-01.json.gz
--- a/instances/matpower/case1354pegase/2017-08-01.json.gz
+++ b/instances/matpower/case1354pegase/2017-08-01.json.gz
--- a/instances/matpower/case13659pegase/2017-02-01.json.gz
+++ b/instances/matpower/case13659pegase/2017-02-01.json.gz
--- a/instances/matpower/case13659pegase/2017-08-01.json.gz
+++ b/instances/matpower/case13659pegase/2017-08-01.json.gz
--- a/instances/matpower/case14/2017-02-01.json.gz
+++ b/instances/matpower/case14/2017-02-01.json.gz
--- a/instances/matpower/case14/2017-08-01.json.gz
+++ b/instances/matpower/case14/2017-08-01.json.gz
--- a/instances/matpower/case1888rte/2017-02-01.json.gz
+++ b/instances/matpower/case1888rte/2017-02-01.json.gz
--- a/instances/matpower/case1888rte/2017-08-01.json.gz
+++ b/instances/matpower/case1888rte/2017-08-01.json.gz
--- a/instances/matpower/case1951rte/2017-02-01.json.gz
+++ b/instances/matpower/case1951rte/2017-02-01.json.gz
--- a/instances/matpower/case1951rte/2017-08-01.json.gz
+++ b/instances/matpower/case1951rte/2017-08-01.json.gz
--- a/instances/matpower/case2383wp/2017-02-01.json.gz
+++ b/instances/matpower/case2383wp/2017-02-01.json.gz
--- a/instances/matpower/case2383wp/2017-08-01.json.gz
+++ b/instances/matpower/case2383wp/2017-08-01.json.gz
--- a/instances/matpower/case2736sp/2017-02-01.json.gz
+++ b/instances/matpower/case2736sp/2017-02-01.json.gz
--- a/instances/matpower/case2736sp/2017-08-01.json.gz
+++ b/instances/matpower/case2736sp/2017-08-01.json.gz
--- a/instances/matpower/case2737sop/2017-02-01.json.gz
+++ b/instances/matpower/case2737sop/2017-02-01.json.gz
--- a/instances/matpower/case2737sop/2017-08-01.json.gz
+++ b/instances/matpower/case2737sop/2017-08-01.json.gz
--- a/instances/matpower/case2746wop/2017-02-01.json.gz
+++ b/instances/matpower/case2746wop/2017-02-01.json.gz
--- a/instances/matpower/case2746wop/2017-08-01.json.gz
+++ b/instances/matpower/case2746wop/2017-08-01.json.gz
--- a/instances/matpower/case2746wp/2017-02-01.json.gz
+++ b/instances/matpower/case2746wp/2017-02-01.json.gz
--- a/instances/matpower/case2746wp/2017-08-01.json.gz
+++ b/instances/matpower/case2746wp/2017-08-01.json.gz
--- a/instances/matpower/case2848rte/2017-02-01.json.gz
+++ b/instances/matpower/case2848rte/2017-02-01.json.gz
--- a/instances/matpower/case2848rte/2017-08-01.json.gz
+++ b/instances/matpower/case2848rte/2017-08-01.json.gz
--- a/instances/matpower/case2868rte/2017-02-01.json.gz
+++ b/instances/matpower/case2868rte/2017-02-01.json.gz
--- a/instances/matpower/case2868rte/2017-08-01.json.gz
+++ b/instances/matpower/case2868rte/2017-08-01.json.gz
--- a/instances/matpower/case2869pegase/2017-02-01.json.gz
+++ b/instances/matpower/case2869pegase/2017-02-01.json.gz
--- a/instances/matpower/case2869pegase/2017-08-01.json.gz
+++ b/instances/matpower/case2869pegase/2017-08-01.json.gz
--- a/instances/matpower/case30/2017-02-01.json.gz
+++ b/instances/matpower/case30/2017-02-01.json.gz
--- a/instances/matpower/case30/2017-08-01.json.gz
+++ b/instances/matpower/case30/2017-08-01.json.gz
--- a/instances/matpower/case300/2017-02-01.json.gz
+++ b/instances/matpower/case300/2017-02-01.json.gz
--- a/instances/matpower/case300/2017-08-01.json.gz
+++ b/instances/matpower/case300/2017-08-01.json.gz
--- a/instances/matpower/case3012wp/2017-02-01.json.gz
+++ b/instances/matpower/case3012wp/2017-02-01.json.gz
--- a/instances/matpower/case3012wp/2017-08-01.json.gz
+++ b/instances/matpower/case3012wp/2017-08-01.json.gz
--- a/instances/matpower/case3120sp/2017-02-01.json.gz
+++ b/instances/matpower/case3120sp/2017-02-01.json.gz
--- a/instances/matpower/case3120sp/2017-08-01.json.gz
+++ b/instances/matpower/case3120sp/2017-08-01.json.gz
--- a/instances/matpower/case3375wp/2017-02-01.json.gz
+++ b/instances/matpower/case3375wp/2017-02-01.json.gz
--- a/instances/matpower/case3375wp/2017-08-01.json.gz
+++ b/instances/matpower/case3375wp/2017-08-01.json.gz
--- a/instances/matpower/case57/2017-02-01.json.gz
+++ b/instances/matpower/case57/2017-02-01.json.gz
--- a/instances/matpower/case57/2017-08-01.json.gz
+++ b/instances/matpower/case57/2017-08-01.json.gz
--- a/instances/matpower/case6468rte/2017-02-01.json.gz
+++ b/instances/matpower/case6468rte/2017-02-01.json.gz
--- a/instances/matpower/case6468rte/2017-08-01.json.gz
+++ b/instances/matpower/case6468rte/2017-08-01.json.gz
--- a/instances/matpower/case6470rte/2017-02-01.json.gz
+++ b/instances/matpower/case6470rte/2017-02-01.json.gz
--- a/instances/matpower/case6470rte/2017-08-01.json.gz
+++ b/instances/matpower/case6470rte/2017-08-01.json.gz
--- a/instances/matpower/case6495rte/2017-02-01.json.gz
+++ b/instances/matpower/case6495rte/2017-02-01.json.gz
--- a/instances/matpower/case6495rte/2017-08-01.json.gz
+++ b/instances/matpower/case6495rte/2017-08-01.json.gz
--- a/instances/matpower/case6515rte/2017-02-01.json.gz
+++ b/instances/matpower/case6515rte/2017-02-01.json.gz
--- a/instances/matpower/case6515rte/2017-08-01.json.gz
+++ b/instances/matpower/case6515rte/2017-08-01.json.gz
--- a/instances/matpower/case89pegase/2017-02-01.json.gz
+++ b/instances/matpower/case89pegase/2017-02-01.json.gz
--- a/instances/matpower/case89pegase/2017-08-01.json.gz
+++ b/instances/matpower/case89pegase/2017-08-01.json.gz
--- a/instances/matpower/case9241pegase/2017-02-01.json.gz
+++ b/instances/matpower/case9241pegase/2017-02-01.json.gz
--- a/instances/matpower/case9241pegase/2017-08-01.json.gz
+++ b/instances/matpower/case9241pegase/2017-08-01.json.gz
--- a/instances/or-lib/100_0_1_w.json.gz
+++ b/instances/or-lib/100_0_1_w.json.gz
--- a/instances/or-lib/100_0_2_w.json.gz
+++ b/instances/or-lib/100_0_2_w.json.gz
--- a/instances/or-lib/100_0_3_w.json.gz
+++ b/instances/or-lib/100_0_3_w.json.gz
--- a/instances/or-lib/100_0_4_w.json.gz
+++ b/instances/or-lib/100_0_4_w.json.gz
--- a/instances/or-lib/100_0_5_w.json.gz
+++ b/instances/or-lib/100_0_5_w.json.gz
--- a/instances/or-lib/10_0_1_w.json.gz
+++ b/instances/or-lib/10_0_1_w.json.gz
--- a/instances/or-lib/10_0_2_w.json.gz
+++ b/instances/or-lib/10_0_2_w.json.gz
--- a/instances/or-lib/10_0_3_w.json.gz
+++ b/instances/or-lib/10_0_3_w.json.gz
--- a/instances/or-lib/10_0_4_w.json.gz
+++ b/instances/or-lib/10_0_4_w.json.gz
--- a/instances/or-lib/10_0_5_w.json.gz
+++ b/instances/or-lib/10_0_5_w.json.gz
--- a/instances/or-lib/150_0_1_w.json.gz
+++ b/instances/or-lib/150_0_1_w.json.gz
--- a/instances/or-lib/150_0_2_w.json.gz
+++ b/instances/or-lib/150_0_2_w.json.gz
--- a/instances/or-lib/150_0_3_w.json.gz
+++ b/instances/or-lib/150_0_3_w.json.gz
--- a/instances/or-lib/150_0_4_w.json.gz
+++ b/instances/or-lib/150_0_4_w.json.gz
--- a/instances/or-lib/150_0_5_w.json.gz
+++ b/instances/or-lib/150_0_5_w.json.gz
--- a/instances/or-lib/200_0_10_w.json.gz
+++ b/instances/or-lib/200_0_10_w.json.gz
--- a/instances/or-lib/200_0_11_w.json.gz
+++ b/instances/or-lib/200_0_11_w.json.gz
--- a/Show More
+++ b/Show More
Author	SHA1	Message	Date
Alinson S. Xavier	b0b6b9b2dc	Implement MIPLearn solution method	2024-01-09 14:27:46 -06:00
Alinson S. Xavier	58cc33ac69	Remove unused 'reactance' field	2023-08-01 12:31:19 -05:00
Alinson S. Xavier	b555f9885a	Minor correction to ISF definition	2023-08-01 12:21:22 -05:00
Alinson S. Xavier	b39b14afa4	docs: Minor changes; add examples to repository	2023-07-27 12:02:13 -05:00
Alinson S. Xavier	d49712f41b	initcond: Apply to instance instead of scenario	2023-07-27 11:49:47 -05:00
Alinson S. Xavier	beaf0b785f	Add zenodo.json	2023-07-27 11:10:41 -05:00
Alinson S. Xavier	9853b15f1c	Merge pull request #40 from hejun0524/storage_units Storage units	2023-07-26 09:22:37 -05:00
Alinson S. Xavier	81d4ff5b9d	Merge pull request #31 from hejun0524/dev Time Decomposition and Marketing	2023-07-26 09:17:49 -05:00
Jun He	ad50cdd935	update doc for storage units	2023-07-18 16:04:52 -04:00
Jun He	8f0661c93f	reformat one line	2023-07-17 12:04:16 -04:00
Jun He	ca092a67ce	storage units	2023-07-17 11:39:31 -04:00
Jun He	82cefe2652	disable HiGHS logging	2023-07-16 16:57:53 -04:00
Jun He	cd96b28076	market json gz	2023-06-16 17:11:41 -04:00
Jun He	3086e71611	updated doc with solve_market	2023-06-16 17:02:06 -04:00
Jun He	0bb175078b	da to rt market with tests	2023-06-16 15:35:51 -04:00
Jun He	2fb89045cd	disable optimizer logging	2023-06-16 15:35:10 -04:00
Jun He	f31921fc4f	added `Time horizon (min)`	2023-06-13 15:05:37 -04:00
Jun He	6ea769a68c	add in after_build and after_optimize	2023-06-07 13:24:27 -04:00
Jun He	2d510ca7ea	updated doc for time decomp	2023-06-07 13:22:56 -04:00
Jun He	d602b686bc	add default values	2023-06-07 13:22:38 -04:00
Jun He	53052ec895	standalone test integration	2023-05-27 15:43:39 -04:00
Jun He	f59914f265	Merge remote-tracking branch 'upstream/dev' into dev	2023-05-27 14:54:44 -04:00
Jun He	7201acde78	time decomp bug fix	2023-05-27 14:49:43 -04:00
Alinson S. Xavier	7a96f8cc1e	Merge pull request #32 from oyurdakul/progressive-hedging progressive hedging	2023-05-26 11:58:18 -05:00
Alinson S. Xavier	b8ada6432a	Format source code	2023-05-26 11:50:41 -05:00
Alinson S. Xavier	03bf1c4c04	PH: Rename vars, remove return value	2023-05-26 11:47:34 -05:00
Alinson S. Xavier	3961aedaf5	Revise docs and struct name; add basic MPI test	2023-05-26 10:52:23 -05:00
oyurdakul	9dc3607c56	progressive hedging	2023-05-22 16:41:00 -05:00
Jun He	ec2d56602b	updated the warning block syntax	2023-05-20 12:13:28 -04:00
Alinson S. Xavier	40270b0030	Make test/ a standalone project	2023-05-19 15:35:49 -05:00
Jun He	7c41a9761c	warning on nested time decomp	2023-05-19 13:57:56 -04:00
Jun He	6f9420874d	added more comments	2023-05-19 13:57:33 -04:00
Jun He	eff5908b13	time decomposition doc	2023-05-19 13:31:44 -04:00
Jun He	adcaf6fc55	time decomposition tests	2023-05-19 13:31:32 -04:00
Jun He	46259f7c1c	time decomposition src code	2023-05-19 13:31:20 -04:00
oyurdakul	e8d8272510	Fix pwlcosts bug	2023-05-19 11:34:02 -05:00
Alinson S. Xavier	6db2ca76e8	Fix formatting	2023-05-19 10:40:25 -05:00
Alinson S. Xavier	4adb3344ac	Profiled units: minor changes	2023-05-19 10:38:35 -05:00
Jun He	316d0bdf5a	added profiled units in slice	2023-05-05 14:48:42 -04:00
Jun He	33f8ec26d5	renamed capacity to max_power	2023-05-05 14:48:15 -04:00
Jun He	41790db448	new test case gz file	2023-04-22 14:09:40 -04:00
Jun He	baf529a15d	added commitment status to thermal	2023-04-22 14:02:03 -04:00
Jun He	b71a1c3d5f	Updated randomize, validate and initial conditions	2023-04-07 16:42:03 -04:00
Jun He	bea42d174c	Reformatted code	2023-04-06 16:21:58 -04:00
Jun He	896ef0f3e3	Added min power, fixed typo	2023-04-06 16:16:30 -04:00
Jun He	cb7f9e3b27	Added minimum power to profiled generator	2023-04-06 16:16:04 -04:00
Alinson S. Xavier	319a787904	Merge pull request #26 from hejun0524/dev LMP Methods & Profiled Units	2023-04-06 13:11:04 -05:00
Alinson S. Xavier	b1c963f217	Rename 'production' to 'thermal production'	2023-04-04 15:59:41 -05:00
Alinson S. Xavier	19534a128f	Rename Unit to ThermalUnit	2023-04-04 15:40:44 -05:00
Jun He	51f6aa9a80	Create case14-profiled.json.gz	2023-03-31 15:19:46 -04:00
Jun He	f2c0388cac	Updated the docs	2023-03-31 15:11:59 -04:00
Jun He	3564358a63	Re-formatted the codes	2023-03-31 15:11:47 -04:00
Jun He	b2ed0f67c1	Added the profiled units	2023-03-31 15:11:37 -04:00
Jun He	2a6c206e08	updated LMP for UC scenario	2023-03-30 23:19:24 -04:00
Jun He	30a4284119	Merge remote-tracking branch 'upstream/dev' into dev	2023-03-30 14:35:09 -04:00
Jun He	71ed55cb40	Formatted codes on the LMP dev branch	2023-03-30 14:30:10 -04:00
Jun He	0b95df25ec	typo fix in generator json example	2023-03-24 10:56:41 -04:00
Jun He	5f5c8b66eb	more condition checking on AELMP	2023-03-19 14:28:39 -04:00
Alinson S. Xavier	52f1ff9a27	Merge pull request #25 from oyurdakul/stochastic-extension stochastic extension w/ scenarios	2023-03-16 12:10:13 -05:00
Alinson S. Xavier	414128cc0b	Correct optimize!, add stochastic test case	2023-03-16 12:03:40 -05:00
Alinson S. Xavier	20939dc4b7	Minor edits to instance/structs.jl	2023-03-16 10:43:30 -05:00
Alinson S. Xavier	d8741f04a0	Minor edits to instance/read.jl	2023-03-16 10:38:08 -05:00
Alinson S. Xavier	3b6d810884	Remove duplicate format.jl file	2023-03-16 10:24:31 -05:00
Alinson S. Xavier	204c5d900f	Remove unused dependency	2023-03-16 10:23:40 -05:00
Alinson S. Xavier	cb9334c0a3	Minor changes to tests	2023-03-16 10:21:31 -05:00
Alinson S. Xavier	31e0613134	Remove unused dependency & debug statements	2023-03-16 10:09:01 -05:00
Alinson S. Xavier	4827c29230	Add Jun to authors	2023-03-15 12:41:09 -05:00
Alinson S. Xavier	19e84bac07	Reformat source code	2023-03-15 12:27:43 -05:00
Alinson S. Xavier	d7d2a3fcf6	AELMP: Convert warnings into errors; update docstrings	2023-03-15 12:23:18 -05:00
Alinson S. Xavier	784ebfa199	ConventionalLMP: turn warnings into errors, remove some inline comments	2023-03-15 12:15:57 -05:00
Alinson S. Xavier	d2e11eee42	Flatten dir structure, update docstrings	2023-03-15 12:08:35 -05:00
Alinson S. Xavier	34ca6952fb	Revise docs	2023-03-15 11:34:50 -05:00
Jun He	bc3aee38f8	modified the tests for LMP and AELMP	2023-03-08 13:35:33 -05:00
Jun He	415732f0ec	updated the doc with LMP and AELMP	2023-03-08 13:34:10 -05:00
Jun He	5c91dc2ac9	re-designed the LMP methods The LMP and AELMP methods are re-designed to be dependent on the instance object instead of input files, and to have a unified API style for purposes of flexibility and consistency.	2023-03-08 13:33:47 -05:00
oyurdakul	ad4a754d63	read and repair scenario	2023-03-06 17:07:54 -06:00
oyurdakul	481f5a904c	read and repair scenario	2023-03-06 17:03:34 -06:00
oyurdakul	7e8a2ee026	stochastic extension	2023-02-22 12:44:46 -06:00
oyurdakul	c95b01dadf	stochastic extension w/ scenarios	2023-02-08 23:46:10 -06:00
Feng	8fc84412eb	Update README.md minor corrections on grammer.	2022-08-19 11:03:21 -05:00
Alinson S. Xavier	6573bb7ea2	Update README.md	2022-07-18 09:54:15 -06:00
Alinson S. Xavier	1769f2a932	Project.toml: Remove Revise.jl	2022-07-18 09:42:00 -06:00
Alinson S. Xavier	4dc39363e8	Update references, copyright notices, links	2022-07-18 09:40:52 -06:00
Alinson S. Xavier	5fef01cd99	Improve docs	2022-07-17 15:50:42 -06:00
Alinson S. Xavier	18daaf5358	Switch to Documenter.jl	2022-07-17 14:44:58 -06:00
Alinson S. Xavier	b68b4ff9e4	Update CHANGELOG and docs	2022-07-13 10:14:42 -05:00
Alinson S. Xavier	6e30645084	Allow v0.3 to read v0.2 instance files	2022-07-12 11:57:55 -05:00
Alinson S. Xavier	678e6aa2f5	Update docs	2022-07-11 12:16:06 -05:00
Alinson S. Xavier	fd25580967	Reformat source code	2022-07-11 10:58:42 -05:00
Alinson S Xavier	dc693896a3	Merge branch 'dev' into feature/reserves	2022-06-20 17:17:27 -05:00
Alinson S Xavier	ddebcc6ddb	Merge branch 'dev' into feature/reserves	2022-06-20 14:31:02 -05:00
Alinson S Xavier	3282e5bc3a	Fix all tests	2022-06-20 14:21:02 -05:00
Alinson S. Xavier	15de1901c8	Remove temporary files	2022-06-14 14:55:59 -05:00
Alinson S Xavier	bf2dc4ddc4	Remove instances from repository; download on the fly	2022-06-14 14:38:44 -05:00
Alinson S. Xavier	5c3c8f0d63	GitHub Actions: Remove older non-LTS Julia versions	2022-04-16 11:53:12 -05:00
Alinson S. Xavier	cce6a874b9	Bump JuMP version to 1.0	2022-04-16 11:52:21 -05:00
Alinson S. Xavier	1ce1cddaf3	Remove Gurobi from test dependencies; remove large tests	2022-04-16 11:43:09 -05:00
Alinson S. Xavier	46d754dbcf	GitHub Actions: Add Julia 1.7	2022-04-16 11:34:25 -05:00
Alinson S. Xavier	b7d9083335	Makefile: Update clean target	2022-04-16 11:34:14 -05:00
Alinson S. Xavier	86ae1d0429	juliaw: Make it compatible with Julia 1.7	2022-04-16 11:33:57 -05:00
Alinson S. Xavier	58a7567c16	Randomization: Explicitly use MersenneTwister; allow other RNGs	2022-04-16 11:14:06 -05:00
Alinson S. Xavier	2367e5a348	Fix formatting	2022-04-16 10:27:46 -05:00
Alinson S. Xavier	74b8a8ae2c	Fix formatting	2022-04-16 10:23:58 -05:00
Alinson S. Xavier	3260fa29ad	Remove temporary files	2022-04-16 10:16:53 -05:00
Alinson S. Xavier	3b1d2d1845	Add author: Ogün Yurdakul	2022-04-16 10:15:32 -05:00
Alinson S. Xavier	db106f1a38	Make juliaw executable	2022-04-16 10:12:09 -05:00
Alinson S. Xavier	16b0fec6cd	Make tests completely silent; remove set_gap warnings on Cbc	2022-04-16 10:11:33 -05:00
Alinson S. Xavier	cda1e368fe	Remove some redundant comments	2022-04-16 09:55:28 -05:00
Alinson S. Xavier	099fb4e3cb	Add case14-flex test case	2022-04-16 09:52:08 -05:00
oyurdakul	b4bc50c865	new formatting	2022-04-01 15:22:42 +02:00
oyurdakul	febb4f1aad	new formatting	2022-04-01 15:17:14 +02:00
oyurdakul	8988b00b07	modified validation, error scripts	2022-03-23 02:39:24 +01:00
oyurdakul	0046c4ca2a	change the validation of reserves	2022-03-22 19:01:20 +01:00
Alinson S Xavier	72f659b9ff	Merge branch 'dev' into add-flexiramp	2022-03-01 16:32:52 -06:00
Alinson S Xavier	861284875b	Reformat source code	2022-03-01 16:32:33 -06:00
Alinson S Xavier	360308ef4a	Reformat source code	2022-03-01 16:26:51 -06:00
Alinson S Xavier	03268dd3df	Merge branch 'dev' into add-flexiramp	2022-03-01 16:26:42 -06:00
Alinson S Xavier	ec0f9dcfcd	Temporarily revert changes to instances.md; download v0.2 instances	2022-03-01 16:24:47 -06:00
oyurdakul	a3a71ff5a9	add flexiramp	2022-02-03 09:45:06 +01:00
Alinson S Xavier	5beff627d3	Cite sources in read_benchmark; update docs	2022-01-24 10:42:55 -06:00
Alinson S Xavier	5ca566f147	Remove old reserves	2022-01-20 16:23:22 -06:00
Alinson S Xavier	5e2cdb9e0c	Update docs	2022-01-20 16:20:02 -06:00
Alinson S Xavier	e41f4d11c2	Remove instances from repository; download on the fly	2022-01-20 16:17:48 -06:00
Alinson S Xavier	3220650e39	Implement new reserves	2022-01-20 10:18:19 -06:00
Alinson S Xavier	ca0d250dfa	Parse new reserves	2022-01-19 10:03:22 -06:00
Alinson S Xavier	2bd68b49a5	Reserves: Update docs	2022-01-19 09:23:21 -06:00
Alinson S Xavier	fbc4b004cd	benchmarks: use provided gap and time limit	2021-08-31 10:25:58 -05:00