diff --git a/Project.toml b/Project.toml
index 9c3832e..2a45202 100644
--- a/Project.toml
+++ b/Project.toml
@@ -18,6 +18,8 @@ PackageCompiler = "9b87118b-4619-50d2-8e1e-99f35a4d4d9d"
 Printf = "de0858da-6303-5e67-8744-51eddeeeb8d7"
 Random = "9a3f8284-a2c9-5f02-9a11-845980a1fd5c"
 SparseArrays = "2f01184e-e22b-5df5-ae63-d93ebab69eaf"
+TimerOutputs = "a759f4b9-e2f1-59dc-863e-4aeb61b1ea8f"
+MPI = "da04e1cc-30fd-572f-bb4f-1f8673147195"
 
 [compat]
 DataStructures = "0.18"
@@ -26,5 +28,7 @@ GZip = "0.5"
 JSON = "0.21"
 JuMP = "1"
 MathOptInterface = "1"
+MPI = "0.20"
 PackageCompiler = "1"
 julia = "1"
+TimerOutputs = "0.5"
\ No newline at end of file
diff --git a/docs/src/format.md b/docs/src/format.md
index 267da58..cf146ea 100644
--- a/docs/src/format.md
+++ b/docs/src/format.md
@@ -4,7 +4,7 @@ Data Format
 Input Data Format
 -----------------
 
-Instances are specified by JSON files containing the following main sections:
+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)
@@ -20,12 +20,14 @@ Each section is described in detail below. See [case118/2017-01-01.json.gz](http
 
 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?
-| :----------------------------- | :------------------------------------------------ | :------: | :------------:
-| `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.3`. | Required | N
-| `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
+| 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.3`. | Required | No | No
+| `Time horizon (h)` | Length of the planning horizon (in hours). | 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
@@ -34,7 +36,9 @@ This section describes system-wide parameters, such as power balance penalty, an
     "Parameters": {
         "Version": "0.3",
         "Time horizon (h)": 4,
-        "Power balance penalty ($/MW)": 1000.0
+        "Power balance penalty ($/MW)": 1000.0,
+        "Scenario name": "s1",
+        "Scenario weight": 0.5
     }
 }
 ```
@@ -43,9 +47,9 @@ This section describes system-wide parameters, such as power balance penalty, an
 
 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
+| Key                | Description                                                   | Default | Time series? | Uncertain?
+| :----------------- | :------------------------------------------------------------ | ------- | :-----------: | :---:
+| `Load (MW)`        | Fixed load connected to the bus (in MW).                      | Required | Yes | Yes
 
 
 #### Example
@@ -77,33 +81,33 @@ This section describes all generators in the system. Two types of units can be s
 
 #### Thermal Units
 
-| Key                       | Description                                      | Default | Time series?
-| :------------------------ | :------------------------------------------------| ------- | :-----------:
-| `Bus`                     | Identifier of the bus where this generator is located (string). | Required | N
-| `Type`                     | Type of the generator (string). For thermal generators, this must be `Thermal`.  | 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
-| `Reserve eligibility` | List of reserve products this generator is eligibe to provide. By default, the generator is not eligible to provide any reserves. | `[]` | N
-| `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` | Y
+| 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?
-| :---------------- | :------------------------------------------------ | :------: | :------------:
-| `Bus`             | Identifier of the bus where this generator is located (string). | Required | N
-| `Type`            | Type of the generator (string). For profiled generators, this must be `Profiled`.  | Required | N
-| `Cost ($/MW)`     | Cost incurred for serving each MW of power by this generator. | Required | Y
-| `Minimum power (MW)` | Minimum amount of power this generator may supply. | `0.0` | Y
-| `Maximum power (MW)` | Maximum amount of power this generator may supply. | Required | Y
+| 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
 
@@ -173,11 +177,11 @@ Note that this curve also specifies the production limits. Specifically, the fir
 
 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
+| 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
@@ -197,15 +201,15 @@ This section describes components in the system which may increase or reduce the
 
 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
+| 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
+| `Reactance (ohms)`     | Reactance of the transmission line (in ohms). | 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
 
@@ -231,11 +235,11 @@ This section describes the characteristics of transmission system, such as its t
 This section describes the hourly amount of reserves required.
 
 
-| Key                   | Description                                        | Default   |  Time series?
-| :-------------------- | :------------------------------------------------- | --------- |  :----:
-| `Type` | Type of reserve product. Must be either "spinning" or "flexiramp". | Required | N
-| `Amount (MW)` | Amount of reserves required. | Required | Y
-| `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` | Y
+| 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
 
@@ -269,10 +273,10 @@ This section describes the hourly amount of reserves required.
 
 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. | `[]`
+| 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
 
@@ -323,8 +327,8 @@ The output data format is also JSON-based, but it is not currently documented si
 Current limitations
 -------------------
 
-* Network topology remains the same for all time periods
+* 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.
diff --git a/docs/src/index.md b/docs/src/index.md
index 9a8a013..7c7f5a5 100644
--- a/docs/src/index.md
+++ b/docs/src/index.md
@@ -1,12 +1,12 @@
 # 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.
 * **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](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)), multiple 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)) and contingency screening methods ([XavQiuWanThi2019](https://doi.org/10.1109/TPWRS.2019.2892620)). 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)), multiple 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)) and contingency screening methods ([XavQiuWanThi2019](https://doi.org/10.1109/TPWRS.2019.2892620)). 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.
 
 ## Table of Contents
@@ -35,7 +35,7 @@ Depth = 3
 
 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, 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).
+* **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.4)". 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](instances.md).
 
@@ -43,7 +43,7 @@ If you use the instances, we additionally request that you cite the original sou
 
 ```text
 UnitCommitment.jl: A Julia/JuMP Optimization Package for Security-Constrained Unit Commitment
-Copyright © 2020-2022, 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:
diff --git a/docs/src/model.md b/docs/src/model.md
index d944b07..17ea389 100644
--- a/docs/src/model.md
+++ b/docs/src/model.md
@@ -1,57 +1,69 @@
 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].
+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 | 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[r,g,t]` | $r_g(t)$ | Amount of reserve `r` provided by unit `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
+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 | Symbol | Description | Unit
-:-----|:------:|:-------------|:------:
-`prod_profiled[s,t]` | $p^{\dagger}_{g}(t)$ | Amount of power produced by profiled unit `g` at time `t`. | MW
+Name | Description | Unit | Stage
+:-----|:-------------|:------: | :------:
+`prod_profiled[s,t]` | Amount of power produced by profiled unit `g` at time `t`. | MW | 2
 
 
 ### 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
+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 | Symbol | Description | Unit
-:-----|:------:|:-------------|:------:
-`loads[s,t]` | $d_{s}(t)$ | Amount of power served to price-sensitive load `s` at time `t`. | MW
+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 | 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
+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][l,t]` without first checking that the variable exists will likely generate an error.
+    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
 ------------------
@@ -106,7 +118,12 @@ 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/).
+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
@@ -122,13 +139,29 @@ model = UnitCommitment.build_model(
     optimizer=Cbc.Optimizer,
 )
 
-# Fix a decision variable to 1.0
+# 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,
@@ -178,10 +211,10 @@ for t in 1:T
     # 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
+    # Attach the new component to bus b1 in scenario s1, by modifying the
     # constraint `eq_net_injection`.
     set_normalized_coefficient(
-        model[:eq_net_injection]["b1", t],
+        model[:eq_net_injection]["s1", "b1", t],
         x[t],
         1.0,
     )
diff --git a/docs/src/usage.md b/docs/src/usage.md
index 26d1779..d141edc 100644
--- a/docs/src/usage.md
+++ b/docs/src/usage.md
@@ -4,28 +4,24 @@ Usage
 Installation
 ------------
 
-UnitCommitment.jl was tested and developed with [Julia 1.7](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:
+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.3
+pkg> add UnitCommitment@0.4
 ```
 
-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.
+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, 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.
+The first step to use UC.jl is to construct JSON files that describe each scenario of your 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.
+
+!!! note
+
+> By default, UC.jl uses the extensive form to solve the problem. For a more advanced solution method, see below. 
 
 ```julia
 using Cbc
@@ -33,7 +29,7 @@ using JSON
 using UnitCommitment
 
 # 1. Read instance
-instance = UnitCommitment.read("/path/to/input.json")
+instance = UnitCommitment.read(["/path/to/s1.json", "/path/to/s2.json"])
 
 # 2. Construct optimization model
 model = UnitCommitment.build_model(
@@ -49,12 +45,24 @@ solution = UnitCommitment.solution(model)
 UnitCommitment.write("/path/to/output.json", solution)
 ```
 
+To read all files in a given folder, the [Glob](https://github.com/vtjnash/Glob.jl) package can be used:
+
+```julia
+using Glob
+instance = UnitCommitment.read(glob("*.json", "/path/to/scenarios/"))
+```
+
+To solve deterministic instances, a single scenario file may be provided.
+
+```julia
+instance = UnitCommitment.read("/path/to/s1.json")
+```
+
 ### 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.
+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.
 
 ```julia
-using UnitCommitment
 instance = UnitCommitment.read_benchmark("matpower/case3375wp/2017-02-01")
 ```
 
@@ -137,6 +145,56 @@ solution = JSON.parsefile("solution.json")
 UnitCommitment.validate(instance, solution)
 ```
 
+## 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 Cbc
+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(["s1.json", "s2.json"], ph)
+
+# 4. Build JuMP model
+model = UnitCommitment.build_model(
+    instance = instance,
+    optimizer = Cbc.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 a 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.
diff --git a/src/UnitCommitment.jl b/src/UnitCommitment.jl
index 3191395..40016f7 100644
--- a/src/UnitCommitment.jl
+++ b/src/UnitCommitment.jl
@@ -19,6 +19,7 @@ include("model/formulations/KnuOstWat2018/structs.jl")
 include("model/formulations/MorLatRam2013/structs.jl")
 include("model/formulations/PanGua2016/structs.jl")
 include("solution/methods/XavQiuWanThi2019/structs.jl")
+include("solution/methods/ProgressiveHedging/structs.jl")
 include("model/formulations/WanHob2016/structs.jl")
 
 include("import/egret.jl")
@@ -49,6 +50,9 @@ include("solution/methods/XavQiuWanThi2019/enforce.jl")
 include("solution/methods/XavQiuWanThi2019/filter.jl")
 include("solution/methods/XavQiuWanThi2019/find.jl")
 include("solution/methods/XavQiuWanThi2019/optimize.jl")
+include("solution/methods/ProgressiveHedging/optimize.jl")
+include("solution/methods/ProgressiveHedging/read.jl")
+include("solution/methods/ProgressiveHedging/solution.jl")
 include("solution/optimize.jl")
 include("solution/solution.jl")
 include("solution/warmstart.jl")
diff --git a/src/solution/methods/ProgressiveHedging/optimize.jl b/src/solution/methods/ProgressiveHedging/optimize.jl
new file mode 100644
index 0000000..03831d8
--- /dev/null
+++ b/src/solution/methods/ProgressiveHedging/optimize.jl
@@ -0,0 +1,230 @@
+# UnitCommitment.jl: Optimization Package for Security-Constrained Unit Commitment
+# Copyright (C) 2020, UChicago Argonne, LLC. All rights reserved.
+# Released under the modified BSD license. See COPYING.md for more details.
+using MPI, Printf
+using TimerOutputs
+import JuMP
+const to = TimerOutput()
+
+function optimize!(model::JuMP.Model, method::ProgressiveHedging)::Nothing
+    mpi = MpiInfo(MPI.COMM_WORLD)
+    iterations = PHIterationInfo[]
+    consensus_vars = [var for var in all_variables(model) if is_binary(var)]
+    nvars = length(consensus_vars)
+    weights = ones(nvars)
+    if method.initial_weights !== nothing
+        weights = copy(method.initial_weights)
+    end
+    target = zeros(nvars)
+    if method.initial_target !== nothing
+        target = copy(method.initial_target)
+    end
+    params = PHSubProblemParams(
+        ρ = method.ρ,
+        λ = [method.λ for _ in 1:nvars],
+        target = target,
+    )
+    sp = PHSubProblem(model, model[:obj], consensus_vars, weights)
+    while true
+        iteration_time = @elapsed begin
+            solution = solve_subproblem(sp, params, method.inner_method)
+            MPI.Barrier(mpi.comm)
+            global_obj = compute_global_objective(mpi, solution)
+            target = compute_target(mpi, solution)
+            update_λ_and_residuals!(solution, params, target)
+            global_infeas = compute_global_infeasibility(solution, mpi)
+            global_residual = compute_global_residual(mpi, solution)
+            if has_numerical_issues(target)
+                break
+            end
+        end
+        total_elapsed_time =
+            compute_total_elapsed_time(iteration_time, iterations)
+        current_iteration = PHIterationInfo(
+            global_infeas = global_infeas,
+            global_obj = global_obj,
+            global_residual = global_residual,
+            iteration_number = length(iterations) + 1,
+            iteration_time = iteration_time,
+            sp_vals = solution.vals,
+            sp_obj = solution.obj,
+            target = target,
+            total_elapsed_time = total_elapsed_time,
+        )
+        push!(iterations, current_iteration)
+        print_progress(mpi, current_iteration, method.print_interval)
+        if should_stop(mpi, iterations, method.termination)
+            break
+        end
+    end
+    return
+end
+
+function compute_total_elapsed_time(
+    iteration_time::Float64,
+    iterations::Array{PHIterationInfo,1},
+)::Float64
+    length(iterations) > 0 ?
+    current_total_time = last(iterations).total_elapsed_time :
+    current_total_time = 0
+    return current_total_time + iteration_time
+end
+
+function compute_global_objective(
+    mpi::MpiInfo,
+    s::PhSubProblemSolution,
+)::Float64
+    global_obj = MPI.Allreduce(s.obj, MPI.SUM, mpi.comm)
+    global_obj /= mpi.nprocs
+    return global_obj
+end
+
+function compute_target(mpi::MpiInfo, s::PhSubProblemSolution)::Array{Float64,1}
+    sp_vals = s.vals
+    target = MPI.Allreduce(sp_vals, MPI.SUM, mpi.comm)
+    target = target / mpi.nprocs
+    return target
+end
+
+function compute_global_residual(mpi::MpiInfo, s::PhSubProblemSolution)::Float64
+    n_vars = length(s.vals)
+    local_residual_sum = abs.(s.residuals)
+    global_residual_sum = MPI.Allreduce(local_residual_sum, MPI.SUM, mpi.comm)
+    return sum(global_residual_sum) / n_vars
+end
+
+function compute_global_infeasibility(
+    solution::PhSubProblemSolution,
+    mpi::MpiInfo,
+)::Float64
+    local_infeasibility = norm(solution.residuals)
+    global_infeas = MPI.Allreduce(local_infeasibility, MPI.SUM, mpi.comm)
+    return global_infeas
+end
+
+function solve_subproblem(
+    sp::PHSubProblem,
+    params::PHSubProblemParams,
+    method::SolutionMethod,
+)::PhSubProblemSolution
+    G = length(sp.consensus_vars)
+    if norm(params.λ) < 1e-3
+        @objective(sp.mip, Min, sp.obj)
+    else
+        @objective(
+            sp.mip,
+            Min,
+            sp.obj +
+            sum(
+                sp.weights[g] *
+                params.λ[g] *
+                (sp.consensus_vars[g] - params.target[g]) for g in 1:G
+            ) +
+            (params.ρ / 2) * sum(
+                sp.weights[g] * (sp.consensus_vars[g] - params.target[g])^2 for
+                g in 1:G
+            )
+        )
+    end
+    optimize!(sp.mip, method)
+    obj = objective_value(sp.mip)
+    sp_vals = value.(sp.consensus_vars)
+    return PhSubProblemSolution(obj = obj, vals = sp_vals, residuals = zeros(G))
+end
+
+function update_λ_and_residuals!(
+    solution::PhSubProblemSolution,
+    params::PHSubProblemParams,
+    target::Array{Float64,1},
+)::Nothing
+    n_vars = length(solution.vals)
+    params.target = target
+    for n in 1:n_vars
+        solution.residuals[n] = solution.vals[n] - params.target[n]
+        params.λ[n] += params.ρ * solution.residuals[n]
+    end
+end
+
+function print_header(mpi::MpiInfo)::Nothing
+    if !mpi.root
+        return
+    end
+    @info "Solving via Progressive Hedging:"
+    @info @sprintf(
+        "%8s %20s %20s %14s %8s %8s",
+        "iter",
+        "obj",
+        "infeas",
+        "consensus",
+        "time-it",
+        "time"
+    )
+end
+
+function print_progress(
+    mpi::MpiInfo,
+    iteration::PHIterationInfo,
+    print_interval,
+)::Nothing
+    if !mpi.root
+        return
+    end
+    if iteration.iteration_number % print_interval != 0
+        return
+    end
+    @info @sprintf(
+        "%8d %20.6e %20.6e %12.2f %% %8.2f %8.2f",
+        iteration.iteration_number,
+        iteration.global_obj,
+        iteration.global_infeas,
+        iteration.global_residual * 100,
+        iteration.iteration_time,
+        iteration.total_elapsed_time
+    )
+end
+
+function has_numerical_issues(target::Array{Float64,1})::Bool
+    if target == NaN
+        @warn "Numerical issues detected. Stopping."
+        return true
+    end
+    return false
+end
+
+function should_stop(
+    mpi::MpiInfo,
+    iterations::Array{PHIterationInfo,1},
+    termination::PHTermination,
+)::Bool
+    if length(iterations) >= termination.max_iterations
+        if mpi.root
+            @info "Iteration limit reached. Stopping."
+        end
+        return true
+    end
+
+    if length(iterations) < termination.min_iterations
+        return false
+    end
+
+    if last(iterations).total_elapsed_time > termination.max_time
+        if mpi.root
+            @info "Time limit reached. Stopping."
+        end
+        return true
+    end
+
+    curr_it = last(iterations)
+    prev_it = iterations[length(iterations)-1]
+
+    if curr_it.global_infeas < termination.min_feasibility
+        obj_change = abs(prev_it.global_obj - curr_it.global_obj)
+        if obj_change < termination.min_improvement
+            if mpi.root
+                @info "Feasibility limit reached. Stopping."
+            end
+            return true
+        end
+    end
+    return false
+end
diff --git a/src/solution/methods/ProgressiveHedging/read.jl b/src/solution/methods/ProgressiveHedging/read.jl
new file mode 100644
index 0000000..6247cd7
--- /dev/null
+++ b/src/solution/methods/ProgressiveHedging/read.jl
@@ -0,0 +1,18 @@
+# UnitCommitment.jl: Optimization Package for Security-Constrained Unit Commitment
+# Copyright (C) 2020, UChicago Argonne, LLC. All rights reserved.
+# Released under the modified BSD license. See COPYING.md for more details.
+
+function read(
+    paths::Vector{String},
+    ::ProgressiveHedging,
+)::UnitCommitmentInstance
+    comm = MPI.COMM_WORLD
+    mpi = MpiInfo(comm)
+    (length(paths) % mpi.nprocs == 0) || error(
+        "Number of processes $(mpi.nprocs) is not a divisor of $(length(paths))",
+    )
+    bundled_scenarios = length(paths) ÷ mpi.nprocs
+    sc_num_start = (mpi.rank - 1) * bundled_scenarios + 1
+    sc_num_end = mpi.rank * bundled_scenarios
+    return read(paths[sc_num_start:sc_num_end])
+end
diff --git a/src/solution/methods/ProgressiveHedging/solution.jl b/src/solution/methods/ProgressiveHedging/solution.jl
new file mode 100644
index 0000000..8d672b6
--- /dev/null
+++ b/src/solution/methods/ProgressiveHedging/solution.jl
@@ -0,0 +1,83 @@
+# UnitCommitment.jl: Optimization Package for Security-Constrained Unit Commitment
+# Copyright (C) 2020, UChicago Argonne, LLC. All rights reserved.
+# Released under the modified BSD license. See COPYING.md for more details.
+
+using MPI, DataStructures
+const FIRST_STAGE_VARS = ["Is on", "Switch on", "Switch off"]
+
+function solution(model::JuMP.Model, method::ProgressiveHedging)::OrderedDict
+    comm = MPI.COMM_WORLD
+    mpi = MpiInfo(comm)
+    sp_solution = UnitCommitment.solution(model)
+    gather_solution = OrderedDict()
+    for (solution_key, dict) in sp_solution
+        if solution_key !== "Spinning reserve (MW)" &&
+           solution_key ∉ FIRST_STAGE_VARS
+            push!(gather_solution, solution_key => OrderedDict())
+            for (gen_bus_key, values) in dict
+                global T = length(values)
+                receive_values =
+                    MPI.UBuffer(Vector{Float64}(undef, T * mpi.nprocs), T)
+                MPI.Gather!(float.(values), receive_values, comm)
+                if mpi.root
+                    push!(
+                        gather_solution[solution_key],
+                        gen_bus_key => receive_values.data,
+                    )
+                end
+            end
+        end
+    end
+    push!(gather_solution, "Spinning reserve (MW)" => OrderedDict())
+    for (reserve_type, dict) in sp_solution["Spinning reserve (MW)"]
+        push!(
+            gather_solution["Spinning reserve (MW)"],
+            reserve_type => OrderedDict(),
+        )
+        for (gen_key, values) in dict
+            receive_values =
+                MPI.UBuffer(Vector{Float64}(undef, T * mpi.nprocs), T)
+            MPI.Gather!(float.(values), receive_values, comm)
+            if mpi.root
+                push!(
+                    gather_solution["Spinning reserve (MW)"][reserve_type],
+                    gen_key => receive_values.data,
+                )
+            end
+        end
+    end
+    aggregate_solution = OrderedDict()
+    if mpi.root
+        for first_stage_var in FIRST_STAGE_VARS
+            aggregate_solution[first_stage_var] = OrderedDict()
+            for gen_key in keys(sp_solution[first_stage_var])
+                aggregate_solution[first_stage_var][gen_key] =
+                    sp_solution[first_stage_var][gen_key]
+            end
+        end
+        for i in 1:mpi.nprocs
+            push!(aggregate_solution, "s$i" => OrderedDict())
+            for (solution_key, solution_dict) in gather_solution
+                push!(aggregate_solution["s$i"], solution_key => OrderedDict())
+                if solution_key !== "Spinning reserve (MW)"
+                    for (gen_bus_key, values) in solution_dict
+                        aggregate_solution["s$i"][solution_key][gen_bus_key] =
+                            gather_solution[solution_key][gen_bus_key][(i-1)*T+1:i*T]
+                    end
+                else
+                    for (reserve_name, reserve_dict) in solution_dict
+                        push!(
+                            aggregate_solution["s$i"][solution_key],
+                            reserve_name => OrderedDict(),
+                        )
+                        for (gen_key, values) in reserve_dict
+                            aggregate_solution["s$i"][solution_key][reserve_name][gen_key] =
+                                gather_solution[solution_key][reserve_name][gen_key][(i-1)*T+1:i*T]
+                        end
+                    end
+                end
+            end
+        end
+    end
+    return aggregate_solution
+end
diff --git a/src/solution/methods/ProgressiveHedging/structs.jl b/src/solution/methods/ProgressiveHedging/structs.jl
new file mode 100644
index 0000000..46f68f2
--- /dev/null
+++ b/src/solution/methods/ProgressiveHedging/structs.jl
@@ -0,0 +1,73 @@
+# UnitCommitment.jl: Optimization Package for Security-Constrained Unit Commitment
+# Copyright (C) 2020, UChicago Argonne, LLC. All rights reserved.
+# Released under the modified BSD license. See COPYING.md for more details.
+
+using JuMP, MPI, TimerOutputs
+
+Base.@kwdef mutable struct PHTermination
+    max_iterations::Int = 1000
+    max_time::Float64 = 14400.0
+    min_feasibility::Float64 = 1e-3
+    min_improvement::Float64 = 1e-3
+    min_iterations::Int = 2
+end
+
+Base.@kwdef mutable struct PHIterationInfo
+    global_infeas::Float64
+    global_obj::Float64
+    global_residual::Float64
+    iteration_number::Int
+    iteration_time::Float64
+    sp_vals::Array{Float64,1}
+    sp_obj::Float64
+    target::Array{Float64,1}
+    total_elapsed_time::Float64
+end
+
+Base.@kwdef mutable struct ProgressiveHedging <: SolutionMethod
+    initial_weights::Union{Vector{Float64},Nothing} = nothing
+    initial_target::Union{Vector{Float64},Nothing} = nothing
+    ρ::Float64 = 1.0
+    λ::Float64 = 0.0
+    print_interval::Int = 1
+    termination::PHTermination = PHTermination()
+    inner_method::SolutionMethod = XavQiuWanThi2019.Method()
+end
+
+struct SpResult
+    obj::Float64
+    vals::Array{Float64,1}
+end
+
+Base.@kwdef mutable struct PHSubProblem
+    mip::JuMP.Model
+    obj::AffExpr
+    consensus_vars::Array{VariableRef,1}
+    weights::Array{Float64,1}
+end
+
+Base.@kwdef struct PhSubProblemSolution
+    obj::Float64
+    vals::Array{Float64,1}
+    residuals::Array{Float64,1}
+end
+
+Base.@kwdef mutable struct PHSubProblemParams
+    ρ::Float64
+    λ::Array{Float64,1}
+    target::Array{Float64,1}
+end
+
+struct MpiInfo
+    comm::Any
+    rank::Int
+    root::Bool
+    nprocs::Int
+
+    function MpiInfo(comm)
+        rank = MPI.Comm_rank(comm) + 1
+        is_root = (rank == 1)
+        nprocs = MPI.Comm_size(comm)
+        return new(comm, rank, is_root, nprocs)
+    end
+end
diff --git a/test/Project.toml b/test/Project.toml
index 7b68ed9..167e679 100644
--- a/test/Project.toml
+++ b/test/Project.toml
@@ -13,6 +13,7 @@ JSON = "682c06a0-de6a-54ab-a142-c8b1cf79cde6"
 JuMP = "4076af6c-e467-56ae-b986-b466b2749572"
 JuliaFormatter = "98e50ef6-434e-11e9-1051-2b60c6c9e899"
 LinearAlgebra = "37e2e46d-f89d-539d-b4ee-838fcccc9c8e"
+MPI = "da04e1cc-30fd-572f-bb4f-1f8673147195"
 MathOptInterface = "b8f27783-ece8-5eb3-8dc8-9495eed66fee"
 Random = "9a3f8284-a2c9-5f02-9a11-845980a1fd5c"
 Revise = "295af30f-e4ad-537b-8983-00126c2a3abe"
diff --git a/test/src/UnitCommitmentT.jl b/test/src/UnitCommitmentT.jl
index c07f547..f529c42 100644
--- a/test/src/UnitCommitmentT.jl
+++ b/test/src/UnitCommitmentT.jl
@@ -12,6 +12,7 @@ include("model/formulations_test.jl")
 include("solution/methods/XavQiuWanThi19/filter_test.jl")
 include("solution/methods/XavQiuWanThi19/find_test.jl")
 include("solution/methods/XavQiuWanThi19/sensitivity_test.jl")
+include("solution/methods/ProgressiveHedging/usage_test.jl")
 include("transform/initcond_test.jl")
 include("transform/slice_test.jl")
 include("transform/randomize/XavQiuAhm2021_test.jl")
@@ -37,6 +38,7 @@ function runtests()
         solution_methods_XavQiuWanThi19_filter_test()
         solution_methods_XavQiuWanThi19_find_test()
         solution_methods_XavQiuWanThi19_sensitivity_test()
+        solution_methods_ProgressiveHedging_usage_test()
         transform_initcond_test()
         transform_slice_test()
         transform_randomize_XavQiuAhm2021_test()
diff --git a/test/src/solution/methods/ProgressiveHedging/ph.jl b/test/src/solution/methods/ProgressiveHedging/ph.jl
new file mode 100644
index 0000000..0cc1f49
--- /dev/null
+++ b/test/src/solution/methods/ProgressiveHedging/ph.jl
@@ -0,0 +1,40 @@
+using HiGHS
+using MPI
+using JuMP
+using UnitCommitment
+
+UnitCommitment._setup_logger(level = Base.CoreLogging.Error)
+function fixture(path::String)::String
+    basedir = dirname(@__FILE__)
+    return "$basedir/../../../../fixtures/$path"
+end
+
+# Initialize MPI
+MPI.Init()
+
+# Configure progressive hedging method
+ph = UnitCommitment.ProgressiveHedging()
+
+# Read problem instance
+instance = UnitCommitment.read(
+    [fixture("case14.json.gz"), fixture("case14.json.gz")],
+    ph,
+)
+
+# Build JuMP model
+model = UnitCommitment.build_model(
+    instance = instance,
+    optimizer = optimizer_with_attributes(
+        HiGHS.Optimizer,
+        MOI.Silent() => true,
+    ),
+)
+
+# Run the decentralized optimization algorithm
+UnitCommitment.optimize!(model, ph)
+
+# Fetch the solution
+solution = UnitCommitment.solution(model, ph)
+
+# Close MPI
+MPI.Finalize()
diff --git a/test/src/solution/methods/ProgressiveHedging/usage_test.jl b/test/src/solution/methods/ProgressiveHedging/usage_test.jl
new file mode 100644
index 0000000..418dda9
--- /dev/null
+++ b/test/src/solution/methods/ProgressiveHedging/usage_test.jl
@@ -0,0 +1,16 @@
+# UnitCommitment.jl: Optimization Package for Security-Constrained Unit Commitment
+# Copyright (C) 2020, UChicago Argonne, LLC. All rights reserved.
+# Released under the modified BSD license. See COPYING.md for more details.
+
+using MPI
+
+function solution_methods_ProgressiveHedging_usage_test()
+    basedir = dirname(@__FILE__)
+    @testset "ProgressiveHedging" begin
+        mpiexec() do exe
+            return run(
+                `$exe -n 2 $(Base.julia_cmd()) --project=test $basedir/ph.jl`,
+            )
+        end
+    end
+end