MatPower Optimization

Matpower Optimal Scheduling Tool
MOST 1.0.2
User’s Manual
Ray D. Zimmerman Carlos E. Murillo-Sánchez
June 20, 2019
© 2011–2019 Power Systems Engineering Research Center (PSerc)

All Rights Reserved
Contents
1 Introduction 7
1.1 License and Terms of Use . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2 Citing MOST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3 MOST Development . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2 Getting Started 10
2.1 System Requirements . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.2 Installation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3 Running a Simulation . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.1 Preparing Input Data . . . . . . . . . . . . . . . . . . . . . . . 12
2.3.2 Solving the Case . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.3 Accessing the Results . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.4 Setting Options . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.4 Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3 Background and Overview 16

3.1 Continuous Single Period Problems . . . . . . . . . . . . . . . . . . . 16
3.2 Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.3 Uncertainty of Demand and Renewable Generation . . . . . . . . . . 20
3.4 Multiple Periods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.5 Ramping and Load Following Ramp Reserves . . . . . . . . . . . . . 22
3.6 Storage and Deferrable Demand . . . . . . . . . . . . . . . . . . . . . 22
3.7 Linear Time-Varying Dynamical System . . . . . . . . . . . . . . . . 25
3.8 Unit Commitment . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4 Problem Formulation 28
4.1 Nomenclature . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
4.2 Formulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.1 Objective Function . . . . . . . . . . . . . . . . . . . . . . . . 35
4.2.2 Constraints . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.3 Probability Weighting of Base and Contingency States . . . . . . . . 40
4.4 Value of Residual Storage . . . . . . . . . . . . . . . . . . . . . . . . 43
5 most 51
5.1 Input Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
5.1.1 mpc – Matpower Case . . . . . . . . . . . . . . . . . . . . . 51
5.1.2 transmat – Transition Probability Matrices . . . . . . . . . . 53
2
5.1.3 xgd – Extra Generator Data (xGenData) . . . . . . . . . . . . 53
5.1.4 sd – Storage Data (StorageData) . . . . . . . . . . . . . . . . 55
5.1.5 contab – Contingency Table . . . . . . . . . . . . . . . . . . . 55
5.1.6 profiles – Profiles for Time-Varying Parameters . . . . . . . 57
5.2 MOST Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5.3 MOST Data struct . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.3.1 Input Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.3.2 Output Data . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.4 Additional Considerations . . . . . . . . . . . . . . . . . . . . . . . . 70
6 Additional Functions 71
6.1 addgen2mpc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
6.2 addstorage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.3 addwind . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
6.4 apply profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.5 filter ramp transitions . . . . . . . . . . . . . . . . . . . . . . . . 73
6.6 getprofiles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.7 idx profile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.8 loadgenericdata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.9 loadmd . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.10 loadstoragedata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.11 loadxgendata . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6.12 most summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.13 mostver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
7 Tutorial Examples 80
7.1 Single Period Problems . . . . . . . . . . . . . . . . . . . . . . . . . . 81
7.1.1 Example 1 – Deterministic Economic Dispatch . . . . . . . . . 81
7.1.2 Example 2 – Deterministic DC OPF . . . . . . . . . . . . . . 83
7.1.3 Example 3 – Deterministic DC OPF with Binary Commitment 84
7.1.4 Example 4 – Secure and Stochastic DC OPF . . . . . . . . . . 85
7.2 Multiperiod Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
7.2.1 Example 5 – Deterministic Multiperiod OPF . . . . . . . . . . 88
7.2.2 Example 6 – Deterministic Unit Commitment . . . . . . . . . 90
7.2.3 Example 7 – Secure Stochastic Unit Commitment . . . . . . . 99
7.2.4 Dynamical System Constraint Example . . . . . . . . . . . . . 105
8 Acknowledgments 106
3
Appendix A MOST Files and Functions 107
A.1 MOST Documentation Files . . . . . . . . . . . . . . . . . . . . . . . 107
A.2 MOST Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
A.3 Automated Test Suite . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Appendix B Release History 111

B.1 Version 1.0 – released Dec 16, 2016 . . . . . . . . . . . . . . . . . . . 111
B.2 Version 1.0.1 – released Oct 30, 2018 . . . . . . . . . . . . . . . . . . 111
B.3 Version 1.0.2 – released Jun 20, 2019 . . . . . . . . . . . . . . . . . . 112
References 113
4
List of Figures
3-1 MOST Continuous Single-Period Problems . . . . . . . . . . . . . . . 17
3-2 Secure Dispatch Problem Structure . . . . . . . . . . . . . . . . . . . 19
3-3 Reserve Structure for Generator i . . . . . . . . . . . . . . . . . . . . 19
3-4 Problem Structure with Multiple Base Scenarios . . . . . . . . . . . . 20
3-5 Reserve Structure for Generator i in Period t . . . . . . . . . . . . . . 21
3-6 Ramping and Load Following Ramp Reserves . . . . . . . . . . . . . 23
3-7 Storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3-8 Overall Problem Structure . . . . . . . . . . . . . . . . . . . . . . . . 26
3-9 MOST Mixed Integer and Multi-Period Problems . . . . . . . . . . . 27
5-1 Assembling the MOST Data struct . . . . . . . . . . . . . . . . . . . 52
7-1 Tutorial Example System . . . . . . . . . . . . . . . . . . . . . . . . . 81
7-2 Example Load and Wind Profiles . . . . . . . . . . . . . . . . . . . . 89
7-3 Deterministic UC : Base Case with No Network . . . . . . . . . . . . 92
7-4 Deterministic UC : Add DC Network Model . . . . . . . . . . . . . . 93
7-5 Deterministic UC : Add Startup and Shutdown Costs . . . . . . . . . 94
7-6 Deterministic UC : Add Min Up/Down Time Constraints . . . . . . . 96
7-7 Deterministic UC : Add Ramp Constraints and Ramp Reserve Costs 97
7-8 Deterministic UC : Add Storage . . . . . . . . . . . . . . . . . . . . . 98
7-9 Example Wind Profiles, Individual Trajectories . . . . . . . . . . . . 100
7-10 Stochastic UC : Individual Trajectories . . . . . . . . . . . . . . . . . 101
7-11 Example Wind Profiles, Full Transition Probabilities . . . . . . . . . 102
7-12 Stochastic UC : Full Transition Probabilities . . . . . . . . . . . . . . 103
7-13 Secure Stochastic UC : Full Transition Probabilities + Contingencies 104
7-14 Secure Stochastic UC with Storage . . . . . . . . . . . . . . . . . . . 105
List of Tables
4-1 Five Price Model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
5-1 Fields of xGenData struct (xgd) . . . . . . . . . . . . . . . . . . . . . . 54
5-2 Fields of StorageData struct (sd) . . . . . . . . . . . . . . . . . . . . 56
5-3 Fields of Profle Struct (profile) . . . . . . . . . . . . . . . . . . . . . 57
5-4 MOST Run Options . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
5-5 MOST Model Options . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5-6 Input Data Fields of md . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5-7 Additional Input Data Fields of md . . . . . . . . . . . . . . . . . . . 62
5-8 Fields of Offer struct md.offer(t) . . . . . . . . . . . . . . . . . . . . 63
5
5-9 Input Fields of md.Storage . . . . . . . . . . . . . . . . . . . . . . . . 64
5-10 Output Data Fields of md . . . . . . . . . . . . . . . . . . . . . . . . . 66
5-11 Fields of Index struct md.idx . . . . . . . . . . . . . . . . . . . . . . . 67
5-12 Fields of QP struct md.QP . . . . . . . . . . . . . . . . . . . . . . . . 68
5-13 Fields of Results struct md.results . . . . . . . . . . . . . . . . . . . 69
6-1 Typical Generator Types . . . . . . . . . . . . . . . . . . . . . . . . . 71
6-2 Fields of StorageUnitData struct (storage) . . . . . . . . . . . . . . . 72
6-3 Fields of WindUnitData struct (wind) . . . . . . . . . . . . . . . . . . . 73
6-4 Constants Defined by idx profile . . . . . . . . . . . . . . . . . . . . 75
6-5 Fields of StorageDataTable struct (sd table) . . . . . . . . . . . . . . 76
6-6 Fields of xGenDataTable struct (xgd table) . . . . . . . . . . . . . . . 78
6-7 Fields of most summary struct (ms) . . . . . . . . . . . . . . . . . . . . 79
7-1 Summary of Tutorial Example System Data . . . . . . . . . . . . . . 80
A-1 MOST Documentation Files . . . . . . . . . . . . . . . . . . . . . . . 107
A-2 MOST Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
A-3 MOST Test and Example Data . . . . . . . . . . . . . . . . . . . . . 109
A-4 MOST Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
6
1 Introduction
Beginning with version 6, Matpower [1–3] includes a framework for solving gener-
alized steady-state electric power scheduling problems. This framework is known as
MOST, for Matpower Optimal Scheduling Tool [4, 5].
MOST can be used to solve problems as simple as a deterministic, single pe-
riod economic dispatch problem with no transmission constraints or as complex as
a stochastic, security-constrained, combined unit-commitment and multiperiod op-
timal power flow problem with locational contingency and load-following reserves,
ramping costs and constraints, deferrable demands, lossy storage resources and un-
certain renewable generation.
While the problem formulation is general and incorporates a full nonlinear AC
network model, the current implementation is limited to DC power flow modeling of
the network. Some work has been done on an AC implementation, but it is not yet
ready for release.
The primary developers of MOST are Carlos E. Murillo-Sánchez1 and Ray D. Zim-
merman2 of PSerc3 , with significant contributions from Daniel Muñoz-Álvarez and
Alberto J. Lamadrid. It is built on top of Matpower4 , a package of Matlab®
M-files for solving power flow and optimal power flow problems [1, 6]. This man-
ual assumes that the user is familiar with using Matpower, especially for solving
optimal power flow problems, and makes numerious references to version 7.0 of the
Matpower User’s Manual [3].
1.1 License and Terms of Use

The code in MOST is distributed along with Matpower under the 3-clause BSD
license [7]. The full text of the license can be found in the LICENSE file at the top level
of the distribution or at https://matpower.org/license/ and reads as follows.
1
Universidad Nacional de Colombia, Manizales, Colombia
2
Cornell University, Ithaca, NY, USA
3
http://pserc.org/
4
See https://matpower.org for more information on Matpower.
7
Copyright (c) 1996-2016, Power Systems Engineering Research Center
(PSERC) and individual contributors (see AUTHORS file for details).
All rights reserved.
Redistribution and use in source and binary forms, with or without

modification, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright

notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright

notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
3. Neither the name of the copyright holder nor the names of its
contributors may be used to endorse or promote products derived from
this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS

"AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS
FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE
COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT,
INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING,
BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN
ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGE.
1.2 Citing MOST

We request that publications derived from the use of the Matpower Optimal
Scheduling Tool (MOST) explicitly acknowledge that fact by citing both the 2011
MATPOWER paper [1] and the 2013 MOST paper [4].
R. D. Zimmerman, C. E. Murillo-Sánchez, and R. J. Thomas, “Matpower: Steady-
State Operations, Planning and Analysis Tools for Power Systems Research and Ed-
ucation,” Power Systems, IEEE Transactions on, vol. 26, no. 1, pp. 12–19, Feb. 2011.
doi: 10.1109/TPWRS.2010.2051168
8
C. E. Murillo-Sánchez, R. D. Zimmerman, C. L. Anderson, and R. J. Thomas, “Secure
Planning and Operations of Systems with Stochastic Sources, Energy Storage and
Active Demand,” Smart Grid, IEEE Transactions on, vol. 4, no. 4, pp. 2220–2229,
Dec. 2013.
doi: 10.1109/TSG.2013.2281001
The Matpower Optimal Scheduling Tool (MOST) User’s Manual [8] should
also be cited explicitly in work that refers to or is derived from its content. The
citation and DOI can be version-specific or general, as appropriate. For version
1.0.2, use:
R. D. Zimmerman, C. E. Murillo-Sánchez. Matpower Optimal Scheduling Tool

(MOST) User’s Manual, Verision 1.0.2. 2019. [Online]. Available: https://matpower.
org/docs/MOST-manual-1.0.2.pdf
doi: 10.5281/zenodo.3251047
For a version non-specific citation, use the following citation and DOI, with <YEAR>
replaced by the year of the most recent release:
R. D. Zimmerman, C. E. Murillo-Sánchez. Matpower Optimal Scheduling Tool

(MOST) User’s Manual. <YEAR>. [Online]. Available: https://matpower.org/
docs/MOST-manual.pdf
doi: 10.5281/zenodo.3236531
A list of versions of the User’s Manual with release dates and version-specific DOI’s
can be found via the general DOI at https://doi.org/10.5281/zenodo.3236531.
1.3 MOST Development

Following the release of MOST 1.0 (with Matpower 6.0), the MOST project moved
to an open development paradigm, hosted on the MOST GitHub project page:
https://github.com/MATPOWER/most
The MOST GitHub project hosts the public Git code repository as well as a public
issue tracker for handling bug reports, patches, and other issues and contributions.
There are separate GitHub hosted repositories and issue trackers for Matpower,
MOST, MIPS and the testing framework used by all of them, MP-Test, all available
from https://github.com/MATPOWER/.
9
2 Getting Started
The first step in beginning to use the MOST is to get familiar with Matpower.
This step is essential and this manual will assume familiarity with Matpower.
2.1 System Requirements

To use MOST 1.0.2 you will need:
• Matpower version 7.x or later5
• (highly recommended) a high-performance LP/MILP, QP/MIQP solver such
as Gurobi, CPLEX, MOSEK, Matlab’s Optimization Toolbox or GLPK (in-
cluded with Octave).
MOST requires a working installation of Matpower. See the corresponding
section in the Matpower User’s Manual for more information on the system re-
quirements for Matpower. Matpower 6 and later includes a full version of MOST
in the <MATPOWER>/most directory.
It is also highly recommended that you install a high-performance solver such
as Gurobi, CPLEX, MOSEK, Matlab’s Optimization Toolbox or GLPK, described
in Appendix G in the Matpower User’s Manual. For problems involving unit-
commitment, a mixed integer solver is required.6 But even for continuous LP and
QP problems, these solvers will offer much better performance than Matpower’s
built-in solver based on qps mips. The problems MOST generates can quickly become
very large, so using the best solver you have available is a priority.7
2.2 Installation
The preferred method of installation is simply to install Matpower, which is a
prerequisite for MOST and also includes its own copy of MOST.
If you have followed the directions for installing Matpower found in Section 2.3
of the Matpower User’s Manual, then MOST should already be installed in the
<MATPOWER>/most directory and the appropriate paths8 added to your Matlab
path.
5
MOST 1.0 required Matpower 6.
6
At the time of this writing, Matlab’s Optimization Toolbox and GLPK only address MILP
problems. Gurobi, CPLEX and MOSEK all handle MIQP problems as well.
7
Gurobi and CPLEX are currently our preferred solvers for most MOST problems.
8
To use MOST your Matlab path must include <MATPOWER>/most/lib and, to run the tests,
<MATPOWER>/most/lib/t.
10
To run the test suite and verify that MOST is properly installed and functioning,
at the Matlab prompt, type test most . The result should resemble the following,
possibly including extra tests, depending on the availablility of optional packages.
>> test_most
>> test_most
t_most_3b_1_1_0........ok
t_most_3b_3_1_0........ok
t_most_30b_1_1_0.......ok
t_most_30b_3_1_0.......ok
t_most_fixed_res.......ok
t_most_30b_1_1_0_uc....ok
t_most_uc..............ok
t_most_suc.............ok
t_most_w_ds............ok
All tests successful (615 of 615)
Elapsed time 84.68 seconds.
If, for some reason, you prefer to install your own copy of MOST directly from
the MOST GitHub repository9 , simply clone the repository to the location of your
choice, where we use <MOST> to denote the path the resulting most directory. Then
add the following directories to your Matlab or Octave path:
• <MOST>/lib – core MOST functions

• <MOST>/lib/t – test scripts for MOST
It is important that they appear before Matpower in your path if you want to use
this version of MOST, rather than the one included with Matpower.
2.3 Running a Simulation

Running a MOST simulation involves (1) preparing the input data defining all of
the relevant power system parameters, transition probabilities, additional generator
data and offers, storage data, contingencies, and profiles (2) invoking the function to
run the simulation and (3) accessing the results in the output data structures. The
input data is provided in a MOST Data struct and the results are returned in an
updated version of the input data structure.
Since MOST is built upon Matpower, it is assumed that the user is already
familiar with running OPF simulations in Matpower (see Section 2.4 in the Mat-
power User’s Manual).
9
11
2.3.1 Preparing Input Data
The MOST Data struct, containing all of the data needed for the problem, is suf-
ficiently complex that it is not typically created directly, but rather is assembled
from numerous other files or data structures by the loadmd function, as described in
Section 5.1. They consist of (1) a Matpower case file or struct describing the sys-
tem parameters for the base case, (2) transition probability matrices, (3) additional
generator parameters, including commitment parameters, offer parameters related
to reserves, inc/dec prices, and bounds on energy contract amounts, (4) parameters
for storage units, (5) a contingency table defining a credible set of contingencies and
their probabilities, and (6) profiles for time varying parameters such as load and
renewable availability. In addition to the input data, aspects of the simulation are
controlled by a set of Matpower options.
Typically, the Matpower case is defined in a case file and loaded into a struct
using the loadcase function. The transition probability matrices can be specified
as desired via a user-defined script or function as shown in the example below.
The additional generator parameters are typically provided in a file defining an
xGenDataTable and loaded by the loadxgendata function. Both the Matpower
case and the xGenData can be modified by adding wind generators, or generators
that represent energy storage units, using the functions addwind and addstorage, re-
spectively. The latter also loads the additional storage parameters into a StorageData
struct. The contingency table can be provided directly or returned by a user-defined
function and is a changes table (chgtab) in the form expected by Matpower’s
apply changes function.10 And any time-varying parameters, such as load scaling
factors and wind availability, are specified in profile data files and loaded with the
getprofiles function.
mpc = loadcase('ex_case3b');
transmat = ex_transmat(12);
xgd = loadxgendata('ex_xgd_uc', mpc);
[iwind, mpc, xgd] = addwind('ex_wind_uc', mpc, xgd);
[iess, mpc, xgd, sd] = addstorage('ex_storage', mpc, xgd);
contab = ex_contab();
profiles = getprofiles('ex_load_profile');
profiles = getprofiles('ex_wind_profile', profiles, iwind);
mdi = loadmd(mpc, transmat, xgd, sd, contab, profiles);
mpopt = mpoption('verbose', 0);
10
See Section 9.3.5 in the Matpower User’s Manual.
12
2.3.2 Solving the Case
The solver in MOST is implemented in the most function. Assuming the input
data have been loaded into the input MOST Data struct (mdi) and the Matpower
options set in mpopt, the first stage solver can be called as follows.
mdo = most(mdi, mpopt);
=============================================================================
MATPOWER Optimal Scheduling Tool -- MOST Version 1.0.2
A multiperiod stochastic secure OPF with unit commitment
----- Built on MATPOWER -----
by Carlos E. Murillo-Sanchez, Universidad Nacional de Colombia--Manizales
and Ray D. Zimmerman, Cornell University
(c) 2012-2019 Power Systems Engineering Research Center (PSERC)
=============================================================================
- Building indexing structures.
- Building expected storage-tracking mechanism.
- Building constraint submatrices.
- Building DC flow constraints.
- Splitting storage injections into charge/discharge.
- Building CCV constraints for piecewise-linear costs.
- Building contingency reserve constraints.
- Building ramping transitions and reserve constraints.
- Building storage constraints.
- Building unit commitment constraints.
- Building cost structures.
- Assembling full set of costs.
- Assembling full set of constraints.
- Assembling full set of variable bounds.
- Calling MILP solver.
============================================================================
Gurobi Version 8.1.1 -- automatic MILP solver

--- Integer stage complete, starting price computation stage ---
Gurobi Version 8.1.1 -- automatic LP solver
============================================================================
- MOST: MILP solved successfully.
- Post-processing results.
- MOST: Done.
13
2.3.3 Accessing the Results
By default, the simulation does not output any results to the screen, instead storing
the results in the output MOST Data struct (mdo). The details of the results in mdo
can be found in Section 5.3.2.
For example, quantities like the commitment, expected dispatch and expected
energy price, upward contingency and ramping reserve amounts for generator i in
period t, and the dispatch of generator i in period t, scenario j and contingency k
can be extracted as follows.
define_constants;
unit_commitment = mdo.UC.CommitSched(i, t);
expected_dispatch = mdo.results.ExpectedDispatch(i, t);
expected_price = mdo.results.GenPrices(i, t);
cont_reserve_up = mdo.results.Rpp(i, t);
ramp_reserve_up = mdo.results.Rrp(i, t);
Pg_tijk = mdo.flow(t,j,k).mpc.gen(i, PG);
There is also a function called most summary, described in Section 6.12, that can
be used to print some summary results.
2.3.4 Setting Options

The standard Matpower options struct is used to set options such as the amount of
progress output to display and algorithm to use to solve the underlying optimization
problem. The options struct is set using the mpoption function.
mpopt = mpoption('verbose', 2, 'most.solver', 'GUROBI');
The full set of MOST options are detailed in Section 5.2.
2.4 Documentation
There are two primary sources of documentation for MOST. The first is this manual,
which gives an overview of the capabilities and structure and describes the problem
formulation. The MOST User’s Manual can be found in your Matpower distribu-
tion at <MATPOWER>/most/docs/MOST-manual.pdf and the latest version is always
available at: https://matpower.org/docs/MOST-manual.pdf.
The second is the built-in help command. As with Matlab’s built-in functions
and toolbox routines, you can type help followed by the name of a command or M-
file to get help on that particular function. Many of the MOST related M-files have
14
such documentation and this should be considered the main reference for the calling
options for each individual function. See Appendix A for a list of MOST functions.
There is one other important source of related documentation and that is the
Matpower User’s Manual. It is assumed that the user is very familiar with Mat-
power and its OPF capabilities.
15
3 Background and Overview
MOST grew out of research at Cornell University on the development and testing of
new tools for the power industry, funded by the U.S. Department of Energy through
the CERTS Reliability and Markets program.11 Initially the work was focused on
extending the AC optimal power flow problem to include co-optimization of locational
reserves for security defined in terms of explicitly included contingencies [9,10]. This
work was then extended to include multiple base scenarios to represent stochastic
load and renewable generation availability, a multiperiod planning horizon, energy
storage resources, ramping considerations and binary unit commitment decisions [4].
The formulation implemented in MOST and described in the next section further
generalizes the problem by including the facility to define zonal reserve requirements
like those from Section 7.6.1 in the Matpower User’s Manual [3], and to constrain
the solutions via a general linear time-varying dynamical system. The initial proto-
type was implemented by Carlos E. Murillo-Sánchez with subsequent development
by Ray D. Zimmerman along with contributions by Daniel Muñoz-Álvarez and Al-
berto J. Lamadrid.
The description of the problem formulation will begin with a conceptual overview
of the approach, beginning with the simplest single period problem that MOST
handles and extending and expanding the problem one step at a time to illustrate
how each additional aspect of the full problem is handled.
3.1 Continuous Single Period Problems

A single period problem can be as simple as a lossless economic dispatch (ED) prob-
lem, where the objective is to find the set of generator dispatch points that minimize
the total cost of meeting a specified demand, with no modeling of any network flows
at all. Even at this level, dispatchable demands can be introduced, modeled as
negative generation as in Section 6.4.2 in the Matpower User’s Manual, to model
either involuntary load shedding or demand-side resources dispatched according to a
benefit or bid function. It is assumed throughout that power injection variables may
represent either generators or loads.
By introducing DC power flow equations as a function of bus voltage angle vari-
ables, along with limits on the branch flows, the problem becomes a DC OPF, taking
11
This work was supported by the Consortium for Electric Reliability Technology Solutions
and the Office of Electricity Delivery and Energy Reliability, Transmission Reliability Pro-
gram of the U.S. Department of Energy under the National Energy Technology Laboratory
Cooperative Agreement No. DE-FC26-09NT43321. https://certs.lbl.gov/research-areas/
reliability-markets-rm
16
into account transmission system limitations. Using instead the AC power flow equa-
tions and flow constraints and introducing voltage magnitude and reactive injection
variables results in an AC OPF problem, which models losses along with voltage and
reactive power requirements.
Figure 3-1 illustrates the range of continuous single period problems considered by
the formulation, with the varying level of detail of the network modeling represented
by the vertical dimension. The horizontal dimension represents different ways to
handle (or not) operational security requirements, with a third dimension adding a
stochastic option for handling the uncertainty of demand and renewable generation.
The green portion denotes the parts of the formulation that are implemented in the
current version of MOST.
single deterministic multiple probabilistic

AC OPF system state system states
w/reserves AC OPF secure
AC OPF
stochastic stochastic
AC OPF secure
AC OPF
DC OPF
w/reserves DC OPF secure
DC OPF
stochastic stochastic
DC OPF secure
DC OPF
ED economic
w/reserves dispatch secure
ED
MOST stochastic stochastic

ED secure
ED
Figure 3-1: MOST Continuous Single-Period Problems
17
3.2 Security
Two options are included for addressing security in the single period problem, that
is the need to find a dispatch that meets some criteria for withstanding disturbances
or outages. The first is a deterministic approach that simply adds fixed zonal re-
serve requirements using the additional variables, constraints and costs described in
Section 7.6.1 in the Matpower User’s Manual.
The second is a stochastic approach, based on explicitly modeling the post-
contingency state for each of a set of credible contingencies. In this approach, the
base case ED or OPF problem is fully duplicated (all variables, costs and constraints)
for each of the contingency states and modified to reflect the outaged equipment.
The base and contingency states are then combined into one large problem, where
they are treated as separate islands in a single network, with the cost of each state
weighted by its probability of occurence. The base and contingency states are further
tied together by ramp limits on the generators, ensuring that the contingency state
dispatches can be reached from the base case while respecting ramp rate constraints.
Finally, associated with each generator is a variable representing a reference dis-
patch value (e.g. optimal contract value) from which dispatch deviations (incremen-
tal and decremental redispatches) are defined. The maximum upward and downward
deviations from this reference dispatch across all (base and contingency) states are
defined as the upward and downward contingency reserves, respectively, and these
reserves can have costs associated with them. In addition, the state specific devia-
tions from the reference quantity can have their own probability weighted redispatch
costs.
This second approach to security yields security constrained dispatch (ED or
OPF) problem with endogenously determined generator-specific locational reserve
requirements, derived optimally as a function of the set of included credible con-
tingencies. In this problem formulation, it is assumed that the decisions regarding
a reference dispatch and the corresponding dispatch ranges that define the reserves
are made before the uncertain outcome of the occurence or non-occurence of a con-
tingency is revealed. The state specific dispatch decisions are recourse decisions
contingent on the outcome of that uncertainty.
The structure of this problem is illustrated by the diagram in Figure 3-2, where
the circles represent the ED or OPF problems corresponding to the individual states,
the dashed box denotes the reference dispatch, redispatches, reserves and associated
costs and constraints, and the arrows illustrate the ramp limits constraining the
deviations of contingency state dispatches from the base case dispatch.
Figure 3-3 shows the reserve structure for generator i. The green and pink bars
show upward and downward redispatches from the reference dispatch pic , where the
18
Pc power flow scenario
P1 "high probability", intact case
P2
P0 power flow scenario
"low probability", contingency case
Pk
root variable set, deviations, limits
(e.g. contract, incs/decs, reserves)
transition constraint (e.g. ramp limit)
Figure 3-2: Secure Dispatch Problem Structure
MW injections
physical
ramp up
limit
pi3 i
+
pi1
pi3
+
i
r+
pi1
+ upward
pi0 reserve
pi0
+
pic
ik
p
pik
ri
i pi2 downward
i2 physical reserve
p
ramp down
limit
0 1 2 3 k contingencies
Figure 3-3: Reserve Structure for Generator i
19
maximums of these deviations define the corresponding reserve quantities. The phys-
ical ramp limit restrict deviations of contingency dispatches with respect to the base
case dispatch pi0 .
3.3 Uncertainty of Demand and Renewable Generation

While contingencies refer to discrete low probability events, there is another kind
of uncertainty introduced by errors in forecasting of demand and renewable sources
of generation, such as wind and solar production. This type of uncertainty can be
characterized by random system parameters with continuous probability distribu-
tions. MOST can model this type of uncertainty by drawing scenarios from the
joint distribution of uncertain parameters and including these scenarios as multiple
probability-weighted base cases in a structure similar to that described above for
the continencies. There are two primary differences. First, the probabilities of the
scenarios used to represent this type of uncertainty need not be small and, second,
the base scenarios are tied to each other by the inc/dec and reserve variables, but
not by physical ramp limits. This results in a stochastic dispatch problem with
endogenously determined generator-specific locational reserves.
To make this problem secure, outage scenarios can be added for each base case,
in the same manner as they were added to the single base case problem described
previously. For a case with two contingency states, representing uncertain forecasts
with two base scenarios results in the problem structure shown in Figure 3-4. In
this case the reserves are defined by the maximum redispatch deviations across all
scenarios and contingencies and the physical ramp rates limit the deviations of con-
tingecy cases from the base case within each scenario, as illustrated in Figure 3-5.
In this figure the variables include a t index as well, since the same structure is used
at each period t in the multiperiod problems discussed below.
single base scenario multiple base scenarios
Figure 3-4: Problem Structure with Multiple Base Scenarios
20
MW injections
pti11
physical
ramp up upward
ptij2 limit reserve
pti11
+ ∆i+ ti
r+
pti10
ptij2
pti10
+
+
pti
c
ptij0 ptij0
−
pti12
−
∆i− ti
pti12 physical ptij1
r−
− downward
ramp down
reserve
limit
ptij1
(1, 0) (1, 1) (1, 2) (j, 0) (j, 1) (j, 2) (scenarios,

contingencies)
(j, k)
scenario 1 scenario j
Figure 3-5: Reserve Structure for Generator i in Period t
Though there are now two types of uncertainty, contingencies and parameter un-
certainty for demand and renewables, the reference dispatch and reserve decisions
are made before the uncertainty is realized, with the state-specific dispatch deci-
sions being recourse decisions contingent on the revealed outcome of both types of
uncertainty.
3.4 Multiple Periods

For deterministic scheduling problems, the extension to multiple periods is straight-
forward. The single period problem is duplicated for each period in the planning
horizon and combined into a single large problem which the individual periods ap-
pear as islands in a single network. Linking between adjacent periods is in the form
of ramping costs and constraints involving the corresponding dispatch variables.
In the case of the stochastic problems with multiple probabilistic system states in
each period, the extension to multiple periods is more complicated. One approach is
to define each “scenario” as a particular realization of all uncertainties, defining a full
trajectory through the entire planning horizon. The challenge here is in enforcing
the non-anticipativity of the recourse decisions, since in reality the uncertainty is
revealed period by period. On the other extreme, the option is to assume that from
21
each scenario in period t the system might transition to any of a number of states
in period t + 1. Clearly, the explosion of the number of states with the length of the
planning horizon is the barrier to adopting this approach.
MOST takes this multi-stage decision approach, but adds scenario recombination
and scenario trimming to avoid the exploding number of scenarios. This is accom-
plished by assuming a Markovian structure for a high-probability central path where
a transition probability matrix is used to describe the transitions from a limited set
of base scenarios in one period to a limited set of base scenarios in the next period.
States subsequent to contingency states are trimmed, on the assumption that they
occur with low probability and likely require re-optimizing for the future following
their occurence.
3.5 Ramping and Load Following Ramp Reserves

Ramping feasibility is only enforced on this high probability central path, in which
all possible transitions are constrained to be feasible with respect to physical ramping
capabilities as well as any load following reserve capacity offers. MOST includes the
facility to define a simple quadratic “wear and tear” cost on the difference in dispatch
from one period to another, applied in as a probability-weighted cost to each possible
transition, as well as up and down load-following ramping reserve costs. These reserve
costs apply to maximum upward and downward transitions included in the central
path scenarios, as illustrated in Figure 3-6.
3.6 Storage and Deferrable Demand

Including the time dimension in the problem also opens the door for centrally dis-
patching resources such as energy storage and deferrable demand technologies which
inherently couple operations across time periods. Battery terminology, such as charg-
ing and discharging, will be used to describe the storage model implemented by
MOST, though the concepts and model are applicable to a range of storage and en-
ergy limited technologies, including batteries, pumped-storage units, combined space
conditioning and thermal storage (e.g. ice batteries), and even dispatchable demands
or generation with an energy quota over a given horizon.
A storage unit is implemented as a generator with an associated stored energy.
The unit has upper and lower bounds on both power and energy, all of which can be
either positive or negative. The power bounds define the maximum and minimum
power injections, corresponding to the discharging and charging power limits for a
traditional battery. The bounds on stored energy, which can vary over time, are
22
MW injections
central “high-probability” path

load following ramp up capacity
load following ramp down capacity
t t+1 t+2 t+3 t+4 time
Figure 3-6: Ramping and Load Following Ramp Reserves
used to specify the energy capacity (e.g. for a battery) or quota (e.g. time-flexible
demand). The storage unit can also have non-unity charging and discharging effi-
ciencies as well as a loss coefficient defining energy losses in each period as a linear
function of the amount of stored energy.
For deterministic problems, as with ramping, enforcing the intertemporal con-
straints imposed by such an energy storage resource is straightforward. In this case,
it is a simple set of conservation of energy constraints.
For the stochastic problems, on the other hand, it becomes more complicated.
Since the quantity of stored energy available in any given scenario at time t is depen-
dent on the dispatches in preceding periods, there is no uniquely defined quantity
of stored energy for each scenario, so it is not possible to track actual stored energy
values, only expected values and minimum and maximum values.
For this reason MOST defines decision variables representing the upper and lower
bounds on stored energy in each period and enforces feasibility with respect to these
limits. Figure 3-7 shows how these limits spread out from period to period when
the dispatch of the storage unit varies across scenarios. The only instance in which
23
Stored Energy MWh
smax st+4
+
st+2
+
st+3
+
st+1
+
st+
st+1
− st+2
−
st−
st+3
−
smin st+4
−
t t+1 t+2 t+3 t+4 time
Figure 3-7: Storage
the limits do not spread out is if the unit adheres to the same dispatch schedule
across all scenarios in a period. This formulation allows the optimization problem to
make an optimal tradeoff between using the storage to arbitrage energy across time
(same dispatch schedule across scenarios to avoid spreading of limits) and using it
to mitigate uncertainty (vary the dispatch in response to the different scenarios, but
at the expense of spreading limits).
The formulation also includes the option to relax the restrictions on the stored
energy bounds in some or all periods to base them on the range of expected stored
energy quantities in the previous period, rather than on the worst case ranges.
An important aspect of modeling storage is to include some way of either valuing
or constraining both the initial amount of stored energy in each unit and the amount
of leftover storage in terminal states, both end-of-horizon states and contingency
states. MOST includes several options. First, for each unit there is a cost assigned
to any initial stored energy at the beginning of the horizon. Similarly, there are a
number of parameters used to specify the value of leftover stored energy in termi-
nal states. Furthermore, the initial stored energy amount can be specified and the
final expected stored energy amount can be constrained to equal a target quantity.
24
Finally, there is also the option to simply constrain the initial amount and the final
expected amount to be equal while letting that level be determined as an output of
the optimization.
3.7 Linear Time-Varying Dynamical System

The main decision variables in the problem are the dispatches, and they in turn can
affect subsequent systems of different kinds. Specifically, the dispatch schedule can
be restricted by putting constraints on the states of a linear time-varying system
whose inputs are the expected dispatches at each time period.
One can think, for example, of a very simplified atmospheric diffusion model in
which the amount of a greenhouse gas or pollutant released by a specific generation
unit is proportional its dispatch. Or, perhaps the water level at different locations of
a river downstream from a hydro unit can be modeled using a linear time-varying sys-
tem driven by the unit’s dispatch history. Flood levels or navigability might impose
constraints on those levels. While this modeling capability is not, by any means,
for the casual user of MOST, advanced users may find that it provides a flexible
mechanism for customization that precludes the need for modifying the MOST code
directly to achieve purpose-specific ends.
3.8 Unit Commitment

So far, the discussion has been restricted to problems with continuous optimization
variables, with an overall structure for the general case as illustrated in Figure 3-8.12
The class of problems addressed by MOST also includes those with discrete unit
commitment decisions, with optional startup and shutdown costs associated with
changes in online status from a prior commitment state. In multiperiod problems,
these states are coupled through time, not only by the startup and shutdown costs,
but also by minimum up and down time constraints.
For stochastic problems modeling multiple scenarios and/or contingency states
there is a single commitment schedule shared by all states. That is, in the current
formulation, a single binary variable is used to model the commitment for a given
unit across all scenarios and contingencies in a given period.13
12
The linear dynamical system constraints and the unit commitment aspects of the problem are
not included in this illustration.
13
To correctly model the commitment of fast start units with non-zero minimum generation
constraints requires individual commitment variables for each scenario.
25
Key
base case contingency inc/dec, contingency load-following ramp costs, storage variables,
OPF scenario OPF scenario reserve structure constraints, reserves constraints
Figure 3-8: Overall Problem Structure
26
Figure 3-9 illustrates the ways in which any one of the single period continuous
variable problems of Figure 3-1 can be extended to include combinations of multiple
periods, ramping, storage, integer commitment, startup and shutdown costs and
minimum up and down times.
with integer commitment

+ transition costs
+ min up/down times
with integer
commitment
+ transition
costs
with integer
commitment
continuous
dispatch
single multi-period multi-period

period + ramping
multi-period
multi-period + ramping
+ storage + storage
Figure 3-9: MOST Mixed Integer and Multi-Period Problems
27
4 Problem Formulation
4.1 Nomenclature
This section summarizes the nomenclature for the full multi-period mixed-integer
nonlinear problem. In order to simplify the indexing notation, the index literals and
their order are maintained wherever possible. Furthermore, no commas are used,
so the superindex tijk refers to time period t, generator i (or dispatchable load or
storage unit i), base scenario j and contingency k. A dispatchable or curtailable
load is modeled as negative generation, as in Section 6.4.2 in the Matpower User’s
Manual, each wind farm as a generator whose maximum output varies by scenario
according to the forecast distribution, and a storage unit as a device with a given
loss factor, energy capacity, and “charging” and “discharging” power capacities and
efficiencies.
Variable and Parameter Indexing

Symbol Meaning
t Index over time periods.
T Set of indices of time periods in planning horizon, typically {1 . . . nt }.
j Index over scenarios.
Jt Set of indices of all scenarios considered at time t.
k Index over post-contingency cases (k = 0 for base case, i.e. no
contingency occured).
K tj Set of indices of contingencies considered in scenario j at time t,
including base case (k = 0).
i Index over injections (generation units, storage units and dis-
patchable or curtailable loads).
It Indices of all units (generators, storage and dispatchable or cur-
tailable loads) available for dispatch in any contingency at time t.
I tjk Indices of all units available for dispatch in post-contingency state k
of scenario j at time t.
28
l Index over reserve zones.
Ltjk Indices of all reserve zones defined in post-contingency state k of
scenario j at time t.
Zltjk Set of generators providing reserves in zone l in post-contingency
state k of scenario j at time t.
nds
t Number of time periods in the horizon of the dynamical system
model.
Optimization Variables
Symbol Meaning
ptijk , q tijk Active/reactive injection for unit i in post-contingency state k of
ptic Active power contract quantity for unit i at time t.
ptijk tijk
+ , p− Upward/downward deviation from active power contract quantity
for unit i in post-contingency state k of scenario j at time t.
rztijk Zonal reserve quantity provided by unit i in post-contingency
ti ti
r+ , r− Upward/downward active contingency reserve quantity provided
by unit i at time t.
ti ti
δ+ , δ− Upward/downward load-following ramping reserves needed from
unit i at time t for transition to time t + 1.
θtjk , V tjk , ptjk , q tjk Voltage angles and magnitudes, active and reactive injections for
power flow in post-contingency state k of scenario j at time t.
tijk
ptijk
sc , psd Charge/discharge power injections of storage unit i in post-contingency
sti+ , sti− Endogenously computed upper/lower bounds on the energy stored
in storage unit i at the end of period t. For t = 0 this is a fixed
input parameter representing the bounds at the beginning of the
first period.
29
si0 Initial stored energy (expected) in storage unit i.
uti Binary commitment state for unit i in period t, 1 if unit is on-line,

0 otherwise.
v ti , wti Binary startup and shutdown states for unit i in period t, 1 if unit
has a startup/shutdown event in period t, 0 otherwise.
zt Partition (nds
z × 1 vector) corresponding to period t of state vari-
able z of the dynamical system model.
Constraint Functions and Parameters
Symbol Meaning
g tjk (·) Nonlinear AC power flow equations in post-contingency state k

htjk (·) Transmission, voltage and other limits in post-contingency state k

tijk tijk
Pmin , Pmax Limits on active injection for unit i in post-contingency state k of
Qtijk tijk
min , Qmax Limits on reactive injection for unit i in post-contingency state k
ti ti
Rmax+ , Rmax− Upward/downward contingency (or zonal) reserve capacity limits
for unit i at time t.
Rltjk MW reserve requirement for zone l in post-contingency state k of

ti ti
δmax+ , δmax− Upward/downward load-following ramping reserve limits for unit i
at time t for transition to time t + 1.
∆i+ , ∆i− Upward/downward physical ramping limits for unit i for transi-
tions from base (k = 0) to contingency cases.
30
ρti Parameter for storage unit i at period t that determines the
weighting in storage constraints, where the storage dispatch bounds
are computed relative to a weighted average of previous period en-
(t−1)i (t−1)i
dogenous bounds s+ , s− (ρti = 1) and period- and scenario-
specific initial expected stored energy (ρti = 0).
ti ti
Smax , Smin Stored energy (in MWh) max/min limits for storage unit i at
time t.
0i 0i
Smin , Smax Lower/upper bounds on initial stored energy (expected) in storage
unit i.
nt i nt i
Smin , Smax Lower/upper bounds on target stored energy (expected) in storage
unit i at end of final period nt .
τi+ , τi− Minimum up and down times for unit i in number of periods.
t
Atds , Bds t
, Cds t
, Dds Matrices used to define the state transitions and output con-
straints for the dynamical system model at time t.
t t
zmin , zmax Lower and upper bounds on dynamical system model state z t at
time t.
t t
ymin , ymax Lower and upper bounds on dynamical system model output at
time t.
Cost Functions and Parameters

Symbol Meaning
CPti (·) Cost function for active injection i at time t.
CPti+ (·), CPti− (·) Cost for upward/downward deviation from active power contract
quantity for unit i at time t.
Czti (·) Cost function for zonal reserve purchased from unit i at time t.
ti ti
CR+ (·), CR− (·) Cost function for upward/downward contingency reserve purchased
from unit i at time t.
ti ti
Cδ+ (·), Cδ− (·) Cost of upward/downward load-following ramp reserve for unit i
at time t for transition to time t + 1.
31
Cδi (·) Quadratic, symmetric ramping cost on the difference between the
dispatches for unit i in adjacent periods.
Cs0 Vector of costs by storage unit associated with starting out with
a given level of stored energy s0 in the storage units at time t = 0.
Cs Vector of prices by storage unit for contributions to terminal stor-

age14 from charging or discharging in non-terminal states.
Csc0 , Csd0 Vector of prices by storage unit for contributions to terminal stor-
age14 from charging/discharging in terminal end-of-horizon base
states.
Csck , Csdk Vector of prices by storage unit for contributions to terminal stor-
age14 from charging/discharging in terminal contingency states.
Cvti , Cwti Startup and shutdown costs for unit i at time t in $ per startup/shutdown.
Other Parameters
Symbol Meaning
∆ Length of scheduling time slice in hours, typically 1 hour.

ti ti
ηin , ηout Charging/discharging (or pumping/generating) efficiencies for stor-
age unit i at time t.
ti
ηloss Fraction of stored energy lost per hour by storage unit i at time t.
α For contingency cases, the fraction of the time slice that is spent
in the base case before the contingency occurs (α = 0 means the
entire period is spent in the contingency).
ψ0tjk Conditional probability of contingency k in scenario j at time t,

conditioned on making it to period t without branching off the
central path in a contingency in periods 1 . . . t−1 and on scenario j
being realized in some form (base or contingency). ψ0tj0 is the
conditional probability of no contingency, i.e. the base case.
14
That is, expected leftover stored energy in terminal states.
32
φtj2 j1 Probability of transitioning to scenario j2 in period t given that
scenario j1 was realized in period t − 1.
ζ tj2 j1 Binary valued mask indicating whether transition to scenario j2
in period t from scenario j1 in period t − 1 should be included in
load-following ramp requirements.
Derived Parameters
Symbol Meaning
eti (·)
C Modified cost function for active injection i at time t with the no
P
eti (p) ≡ C ti (p) − C ti (0).
load cost subtracted, C P P P
Cts0 , Ctsc , Ctsd Weighted price vectors summarizing contributions to the value
of terminal storage14 from initial storage/charging/discharging,
derived from Cs , Csc0 , Csd0 , Csck , Csdk .15
ψ tjk Probability of contingency k in scenario j at time t, derived from
transition probabilities φtj2 j1 and conditional probabilities of con-
tingencies ψ0tjk . ψ tj0 is the probability of no contingency, i.e. the
base case.
ψαtjk Probability ψ tjk of contingency k in scenario j at time t adjusted
for α.
 X
tj0
 ψ +α
 ψ tjκ , k = 0
ψαtjk = κ∈K tj 6=0 (4.1)
tjk tj

 (1 − α)ψ , ∀k ∈ K 6= 0
γt Probability of making it to period t without branching off the

central path in a contingency in periods 1 . . . t − 1.
X X
γt ≡ ψ (t−1)j0 = ψ tjk (4.2)
j∈J t−1 j∈J t ,k∈K tj
β1ti . . . β5ti Storage parameters defined in (4.61) and (4.69)–(4.71) in terms

ti
of ∆, α and ηloss to simplify storage constraint expression.
15
See Section 4.4, especially (4.104)–(4.107), for details.
33
16
Derived Variables
Symbol Meaning
stijk
∆ Net increase in stored energy due to charging or discharging for
unit i in post-contingency state k of scenario j at time t.
1 tijk
stijk ti tijk
∆ ≡ −∆(ηin psc + p ) (4.3)
ηout sd
ti
S̄Itj Vector of expected stored energy for all storage units in base sce-
nario j at the beginning of period t, defined as a linear function
of s0 , psc and psd .17
s̄tij0
I Expected stored energy in storage unit i in base scenario j at the
beginning of period t (i-th element of S̄Itj ).
snFt i Expected stored energy in storage unit i at the end of period nt ,

the final period.17
p̄t Vector of expected values of ptijk across j and k at time t, condi-

tional on making it to time t.
1 X
p̄t = ψαtjk ptjk (4.4)
γt
j∈J t ,k∈K tj
Individual variables can be grouped into vectors such as pt for all active injections
considered across all scenarios and contingencies at hour t and it will be consistent
with the context. The subset referring to scenario j would be ptj .
16
All are linear functions of the optimization variables, used only to simplify the presentation.
17
See Section 4.4 for details.
34
4.2 Formulation
The problem formulation can be expressed as a mixed-integer nonlinear optimization
problem, where the optimization variable x is comprised of all the θ, V , p, q, pc , p+ ,
p− , rz , r+ , r− , δ+ , δ− , psc , psd , s0 , s+ , s− , u, v, w, and z variables, for all t, j, k, i and
l. The u commitment variables are binary and the rest continuous. For simplicity,
the formulation restricts the treatment of costs, deviations, ramping and reserves
to consider only active power, but an extension to include reactive counterparts is
straightforward.
4.2.1 Objective Function

The objective then is to
min f (x) (4.5)
x
where f (x) is comprised of seven components.18
f (x) = fp (p, p+ , p− ) + fz (rz ) + fr (r+ , r− ) + fδ (p)

+ flf (δ+ , δ− ) + fs (s0 , psc , psd ) + fuc (u, v, w) (4.6)
Each part is expressed in terms of the individual optimization variables as follows.
– expected cost of active power dispatch and redispatch
XX X Xh i
fp (p, p+ , p− ) = ψαtjk Ceti (ptijk ) + C ti (ptijk ) + C ti
(p tijk
) (4.7)
P P+ + P− −
t∈T j∈J t k∈K tj i∈I tjk
– cost of zonal reserves18

XX X X
fz (rz ) = ψαtjk Czti (rztijk ) (4.8)
t∈T j∈J t k∈K tj i∈I tjk
– cost of endogenous contingency reserves18

X X
γt ti ti ti ti

fr (r+ , r− ) = CR+ (r+ ) + CR− (r− ) (4.9)
t∈T i∈I t
18
A typical secure problem uses either zonal reserves or endogenous contingency reserves, but
not both. Zonal reserves are typically used only for cases with a single base scenario with no
contingencies, that is, when J t = {1} and K tj = {0}.
35
– expected cost of load-following ramping (wear and tear)
X X X
fδ (p) = γ t φtj2 j1 Cδi (ptij2 0 − p(t−1)ij1 0 ) (4.10)
t∈T
j1 ∈J t−1 i∈I tj2 0
j2 ∈J t
– cost of load-following ramp reserves

X X
γt ti ti ti ti

flf (δ+ , δ− ) = Cδ+ (δ+ ) + Cδ− (δ− ) (4.11)
t∈T i∈I t
– cost of initial stored energy and value (since it is negative) of expected leftover
stored energy in terminal states
T T T T
fs (s0 , psc , psd ) = Cs0 s0 − (Cts0 s0 + Ctsc psc + Ctsd psd ) (4.12)
– no load, startup and shutdown costs

X X
fuc (u, v, w) = γt CPti (0)uti + Cvti v ti + Cwti wti (4.13)
t∈T i∈I t
4.2.2 Constraints
This minimization is subject to the following constraints, for all t ∈ T , all j ∈ J t ,
all k ∈ K tj , all i ∈ I tjk , and all l ∈ Ltjk , beginning with the constraints that are
separable by period.
Standard OPF Constraints

– power balance equations19
g tjk (θtjk , V tjk , ptjk , q tjk ) = 0 (4.14)
– transmission flow limits, voltage limits, any other OPF inequality constraints20
htjk (θtjk , V tjk , ptjk , q tjk ) ≤ 0 (4.15)
19
These can take the form of nonlinear AC power balance equations (not yet implemented) (4.2)
and (4.3), linear DC power balance equations (6.29), or a simple equating of total demand and total
supply, where the equation numbers referenced are from the Matpower User’s Manual.
20
These can also take the form of inequality constraints from a nonlinear AC OPF (not yet
implemented) including (6.9), (6.10) and (6.13), a linear DC OPF including (6.30) and (6.31), or a
simple economic dispatch, where the equation numbers referenced are from the Matpower User’s
Manual.
36
Security Constraints (Option 1): Zonal Reserve Requirements21
– fixed zonal reserve requirements

0 ≤ rztijk ≤ min(Rmax+
ti
, ∆i+ ) (4.16)
ptijk + rztijk ≤ uti Pmax
tijk
(4.17)
X
rztijk ≥ Rltjk (4.18)
i∈Zltjk
Security Constraints (Option 2): Contingency Constraints21

– reserve, redispatch and contract variables
0 ≤ ptijk ti ti
+ ≤ r+ ≤ Rmax+ (4.19)
0 ≤ ptijk
− ≤ r− ≤
ti ti
Rmax− (4.20)
ptijk − ptic = ptijk
+ − ptijk
− (4.21)
– ramping limits on transitions from base to contingency cases

− ∆i− ≤ ptijk − ptij0 ≤ ∆i+ , k 6= 0 (4.22)
The remaining sets of constraints include intertemporal restrictions and typically

include constraints from a known starting point at t = 0 into the first period.
Load-following Ramping Limits and Reserves

– variable limits
ti ti
0 ≤ δ+ ≤ δmax+ (4.23)
ti ti
0 ≤ δ− ≤ δmax− (4.24)
– load-following ramp reserve definition

∀{t ∈ T, i ∈ I tjk , j1 ∈ J t−1 , j2 ∈ J t | ζ tj2 j1 = 1} : (4.25)
(t−1)i
ptij2 0 − p(t−1)ij1 0 ≤ δ+ (4.26)
(t−1)i
p(t−1)ij1 0 − ptij2 0 ≤ δ− (4.27)
21
A typical secure problem uses either zonal reserves or endogenous contingency reserves, but
not both. Zonal reserves are typically used only for cases with a single base scenario with no
contingencies, that is, when J t = {1} and K tj = {0}.
37
Storage Constraints
– storage dispatch definition and limits
tijk
ptijk = ptijk
sc + psd (4.28)
ptijk
sc ≤ 0 (4.29)
ptijk
sd ≥0 (4.30)
– energy bound limits

sti− ≥ Smin
ti
(4.31)
sti+ ≤ ti
Smax (4.32)
– storage dispatch vs. base scenario energy bounds

h i
(t−1)i
sti− ≤ β1ti ρti s− + 1 − ρti s̄tij0 + β2ti stij0

I ∆ (4.33)
h i
(t−1)i
sti+ ≥ β1ti ρti s+ + 1 − ρti s̄tij0 + β2ti stij0

I ∆ (4.34)
– storage dispatch vs. contingency scenario energy limits

h i
(t−1)i
ti
≤ β5ti ρti s− + 1 − ρti s̄tij0 + β4ti stij0 ti tijk

Smin I ∆ + β3 s∆ , k 6= 0 (4.35)
h tij0 i
ti (t−1)i
ti ti
Smax ≥ β5 ρ s+ ti
+ 1 − ρ s̄I + β4ti stij0 ti tijk
6 0
∆ + β3 s ∆ , k = (4.36)
– optional storage constraints

– Option 1 : Constrain the expected final stored energy in each unit at the
end of the horizon22 to equal some target value or lie in some target range.
nt i
Smin ≤ snFt i ≤ Smax
nt i
(4.37)
– Option 2 : Constrain the expected final stored energy at the end of the
horizon22 to equal the initial stored energy.
snFt i = si0 (4.38)
0i
Smin ≤ si0 ≤ 0i
Smax (4.39)
When using this option si0 is an optimization variable that can take on
any value between its bounds. When not using this option, it is simply a
fixed parameter.
22
See (4.93) in the Section 4.4 for details on how snFt i is computed as a linear function of x.
38
Unit Commitment
– injection limits and commitments
tijk
uti Pmin ≤ ptijk ≤ uti Pmax
tijk
(4.40)
uti Qtijk
min ≤ q
tijk
≤ uti Qtijk
max (4.41)
– startup and shutdown events
uti − u(t−1)i = v ti − wti (4.42)

ti
0≤v ≤1 (4.43)
0 ≤ wti ≤ 1 (4.44)
– minimum up and down times

t
X
v yi ≤ uti (4.45)
y=t−τi+ +1
t
X
wyi ≤ 1 − uti (4.46)
y=t−τi− +1
Note: These summations can be made to “wrap around” to implement a cyclic

commitment schedule where commitment transitions from the last period of
the horizon back to the first are also constrained to be feasible.
– integrality constraints
uti ∈ {0, 1} (4.47)
Linear Time-Varying Dynamical System

The partition of the state variable corresponding to time t is denoted z t , the corre-
sponding output by y t (not an explicit optimization variable), and p̄t represents the
vector of expected values of ptijk across j and k at time t, conditional on making it
to time t, as defined in (4.4). That is
1 X
p̄t = ψαtjk ptjk (4.48)
γt
j∈J t ,k∈K tj
39
– state bounds
t
zmin ≤ z t ≤ zmax
t
, t = 1 . . . nds
t (4.49)
– state update equations

t t
z t+1 = Atds z t + Bds p̄ , t = 1 . . . nt (4.50)
t+1
z = Atds z t , t = (nt + 1) . . . (nds
t − 1) (4.51)
– output equations
t t t t t t
ymin ≤ Cds z + Dds p̄ ≤ ymax , t = 1 . . . nt (4.52)
t t t t
ymin ≤ Cds z ≤ ymax , t = (nt + 1) . . . nds
t (4.53)
The initial state z 1 is not a variable, but is assumed to be a given initial condition.
4.3 Probability Weighting of Base and Contingency States

This section describes the assumptions regarding the probabilistic weighting of each
term in the cost function. A given initial state at time t = 0, with known dispatches
and energy storage states, is assumed to have probability 1. From this initial state,
transitions, each with some known probability, are possible to any of the scenarios
considered for period t = 1. Hence the probabilities assigned to each of the states in
period t = 1 sum to 1.
Now, consider the transition into t = 2. This transition is only possible provided
the system did not branch off into any contingency at time t = 1, that is, provided
the realized state at t = 1 is one of the base scenarios. However, given that at least
one contingency has a non-zero probability of occurrence, the sum of the probabilities
of these base cases for t = 1 is less than 1. So the probability of actually making
it to t = 2 in the considered graph is equal to the sum of the probabilities of the
base cases at t = 1, which is less than 1. Generalizing for period t, the probability
of making it to period t is equal to the sum of the probabilities of the base cases at
t − 1, a value less than 1 except when t = 1:
X X
γt = ψ (t−1)j0 = ψ tjk < 1, t > 1 (4.54)
j∈J t j∈J t ,k∈K tj
While the fact that the probabilities in future periods do not sum to 1 may
seem odd, this results from choosing, in an N − 1 contingency fashion, to ignore the
40
cost implications of resuming normal operations after branching off in a contingency,
since that would involve exploration of a geometric number of possible paths. This
implies, for the branches that have been trimmed, the existence of an unknown cost
with respect to the decision variables. Since we do not have any information about
the relationship of this unknown cost to our decisions, we explicitly ignore its impact
by excluding it from the optimization.
The probability of transitioning to scenario j2 in period t given that scenario j1
was realized in period t − 1 is assumed to be a known value φtj2 j1 . These transition
probabilities for each time step t can be arranged in a transition probability matrix.
 
φt11 φt12 · · · φt1nJ t−1
 φt21 φt22 · · · φt2nJ t−1 
t
Φ =  .. (4.55)
 
.. . . .. 
 . . . . 
φtnJ t 1 φtnJ t 2 · · · φtnJ t nJ t−1
The columns of Φt sum to 1, and its coefficients are used to weight the wear and tear
costs of ramping.
The individual state specific probabilities ψ tjk for period t can be derived from
those in period t − 1 in two steps. First, the probability γ tj that scenario j or any of
its associated contingencies will occur at time t is given by
   
γ t1 ψ (t−1)10
 γ t2   ψ (t−1)20 
t
 ..  = Φ  (4.56)
  
.. 
 .   . 
γ tnJ t ψ (t−1)nJ t−1 0
where X
γ tj = ψ tjk . (4.57)
k∈K tj
Since the sum across k of the conditional probabilities of contingencies ψ0tjk is 1, we

simply scale each by the corresponding γ tj to get the correct state specific probabil-
ities
ψ tjk = γ tj ψ0tjk . (4.58)
Caveat Regarding Unit Commitment

The derivation of scenario probabilities presented above is based on the assump-
tion that the conditional probability of a contingency occuring in any given state
41
j is fixed and independent of any optimization variables. However, in the context
of unit commitment, this is not a valid assumption for a generator outage contin-
gency. In this case the probability of that contingency goes to zero if the generator is
not committed. The current MOST implementation uses the formulation described
above and does not take into account this dependency of contingency probabilities
on commitment status.
42
4.4 Value of Residual Storage
Given the complexity of the storage model, numerous derived parameters and vari-
ables were used in Section 4.2 to simplify the presentation of the problem formulation.
The specifics of these derivations are presented here. This includes details of the sixth
term fs (·) of the objective function (4.6), specifically the last three terms of (4.12)
related to the expected residual value of stored energy in terminal states. It also
includes details of the storage constraints (4.33)–(4.38).
First, for each storage resource i, an efficient method is needed to compute the
expected amount of stored energy at the beginning and end of each period t for each
scenario j. We will denote these by the nJ t × 1 vectors SIti and SFti , respectively,
where nJ t is the number of scenarios in period t.
The stored energy stij0
F in unit i at the end of period t in base state j can be
computed deterministically from the stored energy at the beginning stij0 I and the
injections in that state, where the losses are assumed to be proportional to the
average stored energy during the period. Using the definition of stijk
∆ from (4.3), this
relationship can be expressed as follows
tij0
ti sI + stij0
stij0
F = stij0
I + stij0
∆ − ∆ηloss F
(4.59)
2
= β1ti stij0
I + β2ti stij0
∆ , (4.60)
where ti
ηloss
1−∆ 1
β1ti ≡ 2
ti
ηloss
, β2ti ≡ ti
ηloss
. (4.61)
1+ ∆ 2 1+∆ 2
For a period where a contingency occurs at a fraction α of the way through the
period, the losses are more tricky to compute. Let us call the expected stored energy
at the moment the contingency occurs stijk
α , expressed as
stijk
α = stijk
I + α(stij0 tijk
F − sI ). (4.62)
Then the losses are equal to

" #
tijk tijk tijk tijk
s + s s + s
stijk
loss
ti
= ∆ηloss α I α
+ (1 − α) α F
(4.63)
2 2
" #
tij0 tij0 tijk tijk
ti s + s s + s
= ∆ηloss α I F
+ (1 − α) I F
(4.64)
2 2
43
where (4.64) follows directly from (4.62) and (4.63), keeping in mind that stijk
I = stij0
I .
In this case, the stored energy in unit i at the end of period t in state jk can be
computed deterministically from the stored energy at the beginning and the injec-
tions in states j0 and jk as follows.
stijk
F = stijk
I + αstij0 tijk
∆ + (1 − α)s∆ − sloss
tijk
(4.65)
" #
tij0 tij0
s + s
= α stij0
I + stij0
∆ − ∆ηloss
ti I F
2
" #
tijk tijk
s + s
+ (1 − α) stijkI + stijk
∆ − ∆ηloss
ti I F
(4.66)
2
" #
tijk tijk
s + s
= α β1 sI + β2ti stij0
ti tij0
+ (1 − α) stijk + stijk ti I F

∆ I ∆ − ∆ηloss (4.67)
2
= β5ti stijk
I + β4ti stij0 ti tijk
∆ + β3 s ∆ (4.68)
where
1 η ti
β3ti ≡ ( + ∆ loss )−1
1−α 2
1−α
= ti
ηloss
(4.69)
1 + (1 − α)∆ 2
α
β4ti ≡ β ti β ti
1−α 2 3
α
= η ti η ti
(4.70)
(1 + ∆ loss
2
)(1 + (1 − α)∆ loss
2
)
ti
β
β5ti ≡ 1ti (β3ti + β4ti )
β2
ti η ti
α + (1 − α)(1 + ∆ loss

ηloss 2
)
= 1−∆ η ti ti
ηloss
(4.71)
2 (1 + ∆ loss )(1 + (1 − α)∆ )
2 2
Let Gtik and Hkti be matrices containing appropriately placed efficiencies relating
the charging and discharging injections, respectively, in state jk of storage unit i in
period t to the corresponding change in stored energy from the beginning to the end
ti
of the period. Specifically, the elements gjl and htijl in row j and column l of Gtik and
44
Hkti are set as follows
(
ti
ti −∆ηin , where column l corresponds to ptijk
sc
gjl = (4.72)
0, otherwise
−∆ 1 , where column l corresponds to ptijk

ti ti sd
hjl = ηout (4.73)
0, otherwise

The reason for keeping Gtik and Hkti separate is to make it possible to use different
prices to represent the gain in value from increasing the amount of residual storage
and the loss in value from reducing the amount of residual storage. The need to use
different prices to value charging and discharging is supported by the intuition that
stored energy should not be used in a given terminal state if there is a better time to
use it (expect a higher price on the horizon), neither should we be storing additional
energy in a given terminal state if there is a better time to store it (expect a lower
price on the horizon).
Using these matrices, (4.60) can be expressed for the vector SFti as a deterministic
function of SIti and the injections as
SFti = β1ti SIti + β2ti (Gti0 + H0ti )x (4.74)
On the other hand, the expected stored energy in each scenario at the beginning
of period t depends on the corresponding values at the end of period t − 1 and the
transition probabilities. Let σ t equal the vector of probabilities of each of the base
scenarios at the end of period t − 1, conditional on arriving at the end of that period
without the occurence of a continency.
 
ψ (t−1)10
(t−1)20
1 (t−1)J0  ψ
1  
t
σ ≡ tψ = t . (4.75)

..
γ γ  . 
ψ (t−1)nJ t−1 0
If we also let [a] denote a diagonal matrix with the vector a on the main diagonal,
(t−1)i
then the relationship between SIti and SF can be expressed as
t t ti (t−1)i
Φ σ SI = Φt σ t SF . (4.76)
In other words,
(t−1)i
SIti = Dti SF (4.77)
45
where (
ti
1nJ t ×1 , t = 1
D ≡ t t −1 t t (4.78)
Φσ Φ σ , t= 6 1.
Stacking the vectors SIti and SFti for all storage units (i from 1 to ns ) allows the
relationships above to be expressed in terms of matrices formed by stacking the Dti
along the diagonals and the Gtik and Hkti vertically.
     
Dt1 0 · · · 0 Gt1
k Hkt1
 0 Dt2 · · · 0   t2  t2 
 t  Gk  t  Hk 

t
D =  .. ..  , Gk =  ..  , Hk =  ..  (4.79)

.. ..
 . . . .   .   . 
0 0 · · · Dtns Gtn
k
s
Hktns
Similarly, scalars βnti are converted to diagonal matrices Bnti ≡ βnti · InJ t ×nJ t and
stacked to form  
Bnt1 0 ··· 0
 0 Bnt2 · · · 0 
Bnt =  .. ..  . (4.80)
 
.. . .
 . . . . 
0 0 · · · Bntns
The full expression for all storage units in all scenarios in period t can then be
expressed as follows.
(t−1)
SIt = Dt SF (4.81)
SFt = B1t SIt + B2t (Gt0 + H0t )x (4.82)
The relationships in (4.81) and (4.82) imply that the expected stored energy at
any point in the planning horizon can be expressed in the following form as a linear
function of the expected initial stored energy s0 and the active power injections in
x, specifically the injections of the storage units.
SIt = LtI s0 + (Mgt + Mht )x (4.83)

SFt = LtF s0 + (Ngt + Nht )x (4.84)
The following recursive expressions can be used for computing LtI , LtF , Mgt , Mht , Ngt
46
and Nht
(t−1) (t−1) (t−1)
LtI = Dt LF = Dt B1 LI (4.85)
(t−1)
LtF = B1t LtI = B1t Dt LF (4.86)
Mgt = Dt Ng(t−1) (4.87)
(t−1)
Mht = Dt Nh (4.88)
Ngt = B1t Mgt + B2t Gt0 (4.89)
Nht = B1t Mht + B2t H0t , (4.90)
where L1I = D1 and Mg1 = Mh1 = 0.

If the rows of each of these vectors and matrices are sorted and partitioned by
scenario (as opposed to by storage unit), we can denote the resulting j-th compo-
nents, whose i-th row corresponds to storage unit i, with a bar, for example S̄Ftj ,
S̄Itj , Ḡtj tj tj tj tj tj tj tj
k , H̄k , L̄I , L̄F , M̄g , M̄h , N̄g and N̄h . It should be noted that for the B
matrices, the corresponding B̄ntj is just the diagonal matrix [βnt ], with the individual
βnti on the diagonal. Using this notation, the expected residual stored energy for all
units in a base scenario j at the end of the last period nt of the horizon, the vector
S̄Fnt j can be written as a function of these matrices
S̄Fnt j = [β1t ]S̄Int j + [β2t ](Ḡn0 t j + H̄0nt j )x

= [β1t ] L̄nI t j s0 + (M̄gnt j + M̄hnt j )x + [β2t ](Ḡn0 t j + H̄0nt j )x

= [β1t ]L̄nI t j s0 + [β1t ]M̄gnt j + [β2t ]Ḡ0nt j + [β1t ]M̄hnt j + [β2t ]H̄0nt j x.

(4.91)
Likewise, the expected residual stored energy at the end of period t for any scenario j
and contingency k is expressed as follows,
S̄Ftjk = [β5t ]S̄Itj + [β4t ]S̄∆

tj0 tjk
+ [β3t ]S̄∆
= [β5t ]S̄Itj + [β4t ](Ḡtj tj t tj tj

0 + H̄0 ) + [β3 ](Ḡk + H̄k ) x
= [β5t ] L̄tj tj tj t tj tj t tj tj

I s0 + (M̄g + M̄h )x + [β4 ](Ḡ0 + H̄0 ) + [β3 ](Ḡk + H̄k ) x
= [β5t ]L̄tj t tj t tj
I s0 + [β5 ]M̄g + [β4 ]Ḡ0 + [β3 ]Ḡk
t tj
+ [β5t ]M̄htj + [β4t ]H̄0tj + [β3t ]H̄ktj x.

(4.92)
The overall expected quantity of stored energy across all non-contingency states
at the end of the horizon is given by
1 X
snFt = ψ nt j0 S̄Fnt j (4.93)
γ (nt +1) j∈J nt
47
where γ (nt +1) = j ψ nt j0 . This expression can be used in contraints, such as (4.37)
P
or (4.38) or in constructing terms of the objective function.
Finally, we return to the value, call it vS (x), of the expected stored energy leftover
in terminal states, expressed in the last three terms of fs in (4.12).
T T T
vS (x) = Cts0 s0 + Ctsc psc + Ctsd psd (4.94)
If we were to use a single price for each storage unit i to value all contributions
to that expected leftover energy, regardless of the state in which they occur, then
the value vS (x) would be that price times a simple probability-weighted sum of the
energy in each state, modified by the output efficiency. To be more precise, the price
relates to the value of each MW of recoverable energy23 as opposed to stored energy.
 
X X X X
vS (x) = CsT [ηout
nt
] ψ nt j0 S̄Fnt j + t
[ηout ] ψ tjk S̄Ftjk  (4.95)
j∈J nt t∈T j∈J t k∈K tj 6=0
However, it may be useful to classify the system states into three categories:
terminal contingency states, terminal end-of-horizon base states, and non-terminal
states (base states preceding the last period). This allows for the possibility of
valuing differently the contributions made to the expected terminal stored energy in
each of these categories of states. It may also be useful to differentiate between the
value gained by increasing the expected terminal stored energy and the value lost by
decreasing it.
Table 4-1: Five Price Model

price applies to contributions from . . .
Cs charging and discharging in non-terminal states
Csc0 charging in terminal end-of-horizon base states
Csd0 discharging in terminal end-of-horizon base states
Csck charging in terminal contingency states
Csdk discharging in terminal contingency states
This leads to the current design based on the five price model summarized in
Table 4-1. Expressing (4.95) in terms of (4.91) and (4.92), splitting up the terms and
applying different prices to the five different types of contributions to the expected
terminal storage quantities, yields the following.
23
It is not the amount of energy stored that is of interest, but rather the amount which can be
ti
recovered after output efficiency losses ηout .
48
vS (x) = CsT (A1 s0 + A2 x + A3 x) + Csc0
T T
A4 x + Csd0 A5 x
T T
+ Csck A6 x + Csdk A7 x (4.96)
where
 
X X X X
nt
A1 = [ηout ][β1nt ] ψ nt j0 L̄nI t j + t
[ηout ][β5t ]  ψ tjk  L̄tj
I (4.97)
 
X X X X
nt
][β1nt ] ψ nt j0 M̄gnt j t
ψ tjk  [β5t ]M̄gtj + [β4t ]Ḡtj

A2 = [ηout + [ηout ]  0
(4.98)
 
X X X X
nt
][β1nt ] ψ nt j0 M̄hnt j + t
ψ tjk  [β5t ]M̄htj + [β4t ]H̄0tj

A3 = [ηout [ηout ] 
(4.99)
X
nt
A4 = [ηout ][β2nt ] ψ nt j0 Ḡn0 t j (4.100)
j∈J nt
X
nt
A5 = [ηout ][β2nt ] ψ nt j0 H̄0nt j (4.101)
j∈J nt
X X X
A6 = t
[ηout ][β3t ] ψ tjk Ḡtj
k (4.102)
t∈T j∈J t k∈K tj 6=0
X X X
A7 = t
[ηout ][β3t ] ψ tjk H̄ktj (4.103)
t∈T j∈J t k∈K tj 6=0
If we use Ān to represent the version of An with all columns removed except
for those corresponding to the relevant charging and discharging injections (psc for
n = 2, 4, 6 and psd for n = 3, 5, 7), then we can express the cost of initial and terminal
stored energy fs from (4.12) as
T
fs (s0 , psc , psd ) = Cs0 s0 − vS (x)
T T T T
= Cs0 s0 − (Cts0 s0 + Ctsc psc + Ctsd psd ) (4.104)
49
where
Cts0 = AT1 Cs (4.105)

Ctsc = ĀT2 Cs + ĀT4 Csc0 + ĀT6 Csck (4.106)
Ctsd = ĀT3 Cs + ĀT5 Csd0 + ĀT7 Csdk . (4.107)
50
5 most
In Matpower, a MOST optimization problem is executed by calling most with
a MOST Data struct as the first argument (mdi). The results are returned in an
updated MOST Data struct (mdo). An additional optional input argument can be
used to set options (mpopt).
The following sections describe the input data, the MOST options, the MOST
Data struct itself, including the results, and some additional considerations.
5.1 Input Data

The MOST Data struct, containing all of the data needed for the problem, is suf-
ficiently complex that it is not typically created directly, but rather is assembled
from numerous other files or data structures by the loadmd function as illustrated in
Figure 5-1.
mdi = loadmd(mpc, transmat, xgd, sd, contab, profiles);
The following sections describe the input arguments to loadmd and the way they
are normally constructed. Except for the transition probability matrices, all pa-
rameters which vary from period to period are specified via profiles, as per-period
changes applied to a set of base values provided in the other input arguments.
Since the input arguments to loadmd are handled by loadgenericdata (see Sec-
tion 6.8 for details), they can either take the form of the data structure described
in each section below, or a string containing the name of an M-file or MAT-file that
returns the required data structure.
5.1.1 mpc – Matpower Case

The mpc argument is a Matpower case,24 specified either as a file name or a struct,
to be passed by loadmd as an input to loadcase from Section 9.1.1 in the Matpower
User’s Manual. This case corresponds to the base case from which all other cases,
corresponding to different time periods, scenarios and contingency states, are built
using change tables and the apply changes function described in Section 9.3.5 in the
Matpower User’s Manual.
24
It is important that this case have consecutively numbered buses starting at 1 (i.e. internal
ordering). See Matpower’s ext2int function in Section 9.4.1 of the Matpower User’s Manual
for converting a case to internal ordering.
51
mpc md – MOST Data struct
MATPOWER case mpc.bus mpopt
data mpc.branch solver
mpc.gen options
mpc.gencost
transmat
tstep(t).TransMat
transition CommitKey, CommitSched, InitialPg
probability
InitialState, MinUp, MinDown
matrices
offer(t).PositiveActiveReservePrice
offer(t).PositiveActiveReserveQuantity
xgd offer(t).NegativeActiveReservePrice
additional offer(t).NegativeActiveReserveQuantity most()
generator data offer(t).PositiveLoadFollowReservePrice
(xGenData)
MATPOWER
loadmd() offer(t).PositiveLoadFollowReserveQuantity
Optimal
offer(t).NegativeLoadFollowReservePrice Scheduling
sd Tool
offer(t).NegativeLoadFollowReserveQuantity
additional RampWearCostCoeff
storage unit
Storage.MinStorageLevel
data (StorageData)
Storage.MaxStorageLevel
Storage.InitialStorage
contab Storage.InitialStorageLowerBound
contingency Storage.InitialStorageUpperBound
data Storage.OutEff
Storage.InEff
Storage.LossFactor
profiles Storage.TerminalStoragePrice
time varying cont(t,j).contab

parameters tstep(t).OpCondSched(j).tab
Figure 5-1: Assembling the MOST Data struct
52
If the problem you are setting up includes storage resources or wind generators,
it may be simpler to exclude these from the gen matrix in mpc and add them later
using the addstorage and addwind functions described below in Sections 6.2 and 6.3.
5.1.2 transmat – Transition Probability Matrices

In the general case of a stochastic model with multiple base scenarios per period,
transmat is a cell array of length nt containing the transition probability matrices
Φt of (4.55). That is, transmat{t} contains the nJ t × nJ (t−1) matrix of transition
probabilities from period t − 1 to period t. The first element transmat{1} is a column
vector of transition probabilities from period 0 (nJ t = 1) to period 1.
For deterministic models or secure models with contingencies but only a single
base scenario per period, transmat can simply be an integer nt specifying the number
of periods in the planning horizon and it will be expanded internally to a cell array
of 1’s with the appropriate length. If the problem is also single period, transmat is
optional, with a default value of 1.
5.1.3 xgd – Extra Generator Data (xGenData)

The optional xgd argument is an xGenData struct containing base values for all of
the per-generator data required for the problem that are not included in mpc, that is,
in the standard Matpower case data. This includes unit commitment (UC) data,
reserve offer data, ramping costs, and more. Table 5-1 presents the details of the
xGenData struct, whose fields are all ng × 1 vectors of per generator values.
An xGenData struct is typically created from a data file or struct in the xGenDataTable
format via the loadxgendata function described in Section 6.11. In this context, all
fields are optional and loadxgendata will provide defaults for anything not explicitly
specified. The addstorage and addwind functions described in Sections 6.2 and 6.3
also return xGenData by calling the loadxgendata function internally.
53
Table 5-1: Fields* of xGenData struct (xgd)
name default† description
CommitSched C 0 or 1, UC status to use for non-UC runs
InitialPg P active power dispatch at time t = 0
TerminalPg active power dispatch at time t = nt + 1
(only included if explicitly specified)
RampWearCostCoeff 0 quadratic coefficient for Cδi (·)‡ in (4.10)
PositiveActiveReservePrice 0 ti
linear coefficient for CR+ (·)‡ in (4.9)
ti
PositiveActiveReserveQuantity R max upward reserve quantity Rmax+ in
(4.19)
NegativeActiveReservePrice 0 ti
linear coefficient for CR− (·)‡ in (4.9)
ti
NegativeActiveReserveQuantity R max downward reserve quantity Rmax− in
(4.20)
PositiveActiveDeltaPrice 0 linear coefficient for CPti+ (·)‡ in (4.7)
NegativeActiveDeltaPrice 0 linear coefficient for CPti− (·)‡ in (4.7)
PositiveLoadFollowReservePrice 0 ti
linear coefficient for Cδ+ (·)‡ in (4.11)
ti
PositiveLoadFollowReserveQuantity R max upward ramp reserve δmax+ in (4.23)
ti ‡
NegativeLoadFollowReservePrice 0 linear coefficient for Cδ− (·) in (4.11)
ti
NegativeLoadFollowReserveQuantity R max downward ramp reserve δmax− in
(4.24)
CommitKey required for problems with UC
-1 – offline, unit forced off
0 or 1 – available for UC decisions
2 – must run, unit forced on
InitialState§ ±∞¶ if positive (negative), number of uptime
(downtime) periods at time t = 0
MinUp§ 1 minimum up time in number of periods
MinDown§ 1 minimum down time in number of periods
* All fields are ng × 1 vectors of per-generator values.
† These are defaults provided by loadxgendata. If gen is provided, either directly or as the gen field of mpc,
then P = gen(:, PG), C = gen(:, GEN STATUS) and R = 2*(gen(:, PMAX) - MIN(0, gen(:, PMIN))), other-
wise C = 1, R = 0 and no default is provided for P (corresponding field is not optional).
‡ Each of these costs C(·) is presented in the formulation as a general function, but is implmented as a simple
linear function of the form C(x) = ax, where the linear coefficient being supplied is a. The only exception is
the ramping cost, which has the quadratic form Cδi (x) = ax2 .
§ Requires that CommitKey be present and non-empty.
¶ Sign is based on C† , i.e. +∞ for C = 1, −∞ for C = 0.
54
5.1.4 sd – Storage Data (StorageData)
The optional sd argument is a StorageData struct containing base values for all of
the storage unit data required for the problem that are not included in the standard
Matpower case mpc or in the xGenData.
This includes bounds on stored energy (capacities), efficiencies, loss factors, initial
and terminal values, prices used to value leftover storage, and more. Table 5-2
presents the details of the StorageData struct, whose fields are all ns × 1 vectors of
per storage unit values, except where indicated otherwise.
A StorageData struct is typically created from data files or structs in StorageDataTable
format via the loadstoragedata function described in Section 6.10. The addstorage
function from Section 6.2 also returns StorageData by calling the loadstoragedata
function internally.
5.1.5 contab – Contingency Table

The optional contab argument is a contingency table with a master set of contingen-
cies used for security throughout entire horizon. It is a matrix in the form of a change
table recognized by apply changes, described in Section 9.3.5 in the Matpower
User’s Manual. The probabilities defined in this contingency table correspond to the
conditional probabilities ψ0tjk of contingency k occuring conditioned on being in base
scenario j. While the MOST Data struct (md) itself allows for contingencies to be
defined independently for all scenarios and time periods, loadmd applies a single set
of contingencies and conditional probabilities (single contab) to all.
55
Table 5-2: Fields* of StorageData struct (sd)
name default description
UnitIdx none corresponding row index into gen matrix
ExpectedTerminalStorageAim none † target value for expected final stored energy at
end of last period, overrides any values pro-
vided for both ExpectedTerminalStorageMin and
ExpectedTerminalStorageMax
ExpectedTerminalStorageMax none † upper bound Smax nt i
on expected final stored energy
at end of last period in (4.37)
ExpectedTerminalStorageMin none † lower bound Sminnt i
on expected final stored energy at
end of last period in (4.37)
InitialStorage none value for initial (expected) stored energy s0
InitialStorageCost none ‡ cost Cs0 associated with starting with amount s0 at
time t = 0
InitialStorageLowerBound none ‡ lower bound Smin0i
on inital (expected) stored energy
s0 in (4.39)
InitialStorageUpperBound none ‡ upper bound Smax 0i
on inital (expected) stored en-
ergy s0 in (4.39)
InEff¶ 1 input efficiency ηin ti
OutEff¶ 1 output efficiency ηout ti
LossFactor¶ 0 fraction of stored energy lost per hour ηloss ti
MaxStorageLevel¶ none stored energy maximum limit Smax ti
MinStorageLevel¶ none stored energy minimum limit Smin ti
rho¶ 1 ti
ρ parameter controlling weighting of worst case
(ρti = 1) and expected values (ρti = 0) for defining
storage constraints in (4.33)–(4.36)
TerminalStoragePrice prices Cs for contributions to terminal storage from
charging/discharging in non-terminal states
TerminalChargingPrice0 Cs § prices Csc0 for contributions to terminal storage
from charging in terminal end-of-horizon base states
TerminalDischargingPrice0 Cs § prices Csd0 for contributions to terminal storage
from discharging in terminal end-of-horizon base
states
TerminalChargingPriceK Cs § prices Csck for contributions to terminal storage
from charging in terminal contingency states
TerminalDischargingPriceK Cs § prices Csdk for contributions to terminal storage
from discharging in terminal contingency states
* All fields are ns ×1 vectors of per storage unit values, except where indicated otherwise. If no default is specified,
it means the field is required.
† If the most.storage.terminal target option is set to 0, the ExpectedTerminalStorage* parameters are optional
and ignored; if set to 1, at least one of them is required; if set to −1, the presence of any of the optional
ExpectedTerminalStorage* parameters will turn the most.storage.terminal target option on.
‡ If the most.storage.cyclic option is set to 1, InitialStorageCost is required and the default values
of the initial storage bounds InitialStorageLowerBound and InitialStorageUpperBound are taken from
MinStorageLevel(:, 1) and MaxStorageLevel(:, 1), respectively, otherwise InitialStorageCost is optional
and both initial storage bounds default to InitialStorage.
¶ Can also be a scalar, in which case the value will be used for all storage units.
§ That is, the default is taken from TerminalStoragePrice.
56
5.1.6 profiles – Profiles for Time-Varying Parameters
Profiles are used to specify how parameters vary from period to period and are
defined in terms of changes to a base value. There are currently three different types
of data that can be changed by a profile, corresponding to the base values provided
by the mpc, xgd and sd arguments to loadmd.
A profile is a struct that specifies, for a given set of changes to be applied across
time periods and scenarios, the type of data, the table or field, the elements in that
table or field, the method of modification and the values to be applied. Table 5-3
summarizes the structure of the profile struct.
Table 5-3: Fields of Profle Struct (profile)

name description
type string defining type of target data structure modified by the profile
'mpcData' – parameters in fields of mpc, e.g. bus, gen, gencost, etc.*
'xGenData' – parameters in fields of xGenData, e.g. reserve offers, commitment
parameters, etc.
'StorageData' – parameters in fields of StorageData, e.g. storage capacities, ef-
ficiencies, etc.
table numeric scalar or string identifying the table or field; valid values depend on type
type = 'mpcData' – numeric values defined in Table 9-2 in the Matpower
User’s Manual
type = 'xGenData' – string-valued field names defined in Table 5-1
type = 'StorageData' – string-valued field names defined in Table 5-2
rows vector of indices of rows (first dimension) of array to be modified, or area indices for
area-wide modifications; 0 means “apply to all”
col column index or other ID of parameter to modify as defined in Table 9-4 in the
Matpower User’s Manual; ignored unless type = 'mpcData'
chgtype method of modification, see Table 9-3 in the Matpower User’s Manual
values n1 × n2 × n3 numeric array containing the new values or scale/shift factors
n1 – corresponds to number of time periods nt
n2 – corresponds to number of scenarios nmax j
n3 – corresponds to number of elements indicated by rows
A singleton dimension in values not matching with nt = 1 or nmax j = 1 or
length(profile.rows) = 1 is interpreted as “apply to all” whenever the parameter
being modified allows such an expansion.
* Possible modifications are as implemented by Matpower’s apply changes function. See Section 9.3.5 in the
Matpower User’s Manual.
Section 6.7 describes idx profile which defines a number of constants that are
useful for specifying profiles. The apply profile function from Section 6.4 is used
internally by loadmd to apply the profiles. And getprofiles from Section 6.6 is used
to load a profile or set of profiles from a struct, MAT-file or M-file function.
57
5.2 MOST Options
In addition to making use of the verbose option and the solver-specific options, such
as those under the fields cplex, glpk, gurobi, etc. as documented in Appendix C in
the Matpower User’s Manual, there are also a number of options specific to MOST
that appear under a most field in the standard Matpower options struct. These
can be classified into two main categories and are described in Tables 5-4 and 5-5.
The first consists of options related to how most is run, such as the solver to use and
the phases of the problem building and solving to be included. The second is all of
the options controlling various details of the model to be built and solved.
Table 5-4: MOST Run Options

most.solver 'DEFAULT' solver option passed in opt.alg to miqps matpower or
qps matpower, see miqps matpower or qps matpower
for details
most.skip prices 0 skip price computation stage for mixed integer prob-
lems, see miqps matpower for details
most.price stage warn tol 10−7 tolerance on the objective function value and primal
variable relative match required to avoid mis-match
warning message, see miqps matpower for details
most.build model 1 toggle building of MIQP model
0 – do not build MIQP, assume it has already been
built
1 – build MIQP, both constraints and standard costs
(not coordination cost†) and store in mdo.QP
most.solve model 1 toggle solving of MIQP model
0 – do not solve MIQP, assume it is just being built;
requires 'most.build model' set to 1
1 – solve MIQP; if coordination cost† exists, update
it; requires either 'most.build model' set to 1
or mdi.QP must contain previously built model
most.resolve new cost 0 toggle solving pre-built MIQP with updated coordina-
tion cost‡
0 – build full MIQP from scratch, then solve
1 – solve pre-built MIQP with updated coordination
cost†
† Coordination costs are related to a price coordination scheme employed in a decomposition used for solving the
non-linear AC formulation (not yet implemented).
‡ Requires 'most.solve model' set to 1.
58
Table 5-5: MOST Model Options
most.dc model 1 power balance model
0–P use simple total P power balance constraint
generation = demand
1 – use DC power flow network model
most.q coordination 0 create q tijk variables for reactive power coordina-
tion (0 or 1)
most.fixed res −1 include fixed zonal reserve constraints (4.8),
(4.16)–(4.18) for security
−1 – if fixed zonal reserves specified
0 – never
1 – always
most.security constraints −1 include contingency constraints for security
−1 – if contingencies specified
0 – never
1 – always
most.storage.terminal target −1 constrain expected terminal storage to a target
range†
−1 – if target range specified
0 – never
1 – always
most.storage.cyclic 0 use cyclic storage constraints (4.38)†
0 – off, initial storage si0 is a fixed parameter,
no constraint on final expected storage snFt i
1 – on, initial storage si0 is an optimization
variable constrained to equal final expected
storage snFt i
most.uc.run −1 flag to indicate whether to perform unit commit-
ment
-1 – perform unit commitment if and only if
mdi.UC.CommitKey is present and non-
empty
0 – do not perform unit commitment
1 – do perform unit commitment
most.uc.cyclic 0 commitment restrictions (e.g. min up and down
times) roll over from end of horizon back to be-
ginning (0 or 1)
most.alpha 0 α, for contingency states, fraction of period spent
in base state before contingency occurs (0–1)
† The most.storage.terminal target and most.storage.cyclic options cannot be used simultaneously (i.e. at
least one of them must be set to 0).
59
5.3 MOST Data struct
5.3.1 Input Data
The input to the most function takes the form of a MOST Data struct, a single Mat-
lab struct md, with the primary input fields described in Tables 5-6 through 5-9. As
described previously in Section 5.1, a MOST Data struct is typically not constructed
directly, but rather assembled from various other inputs by the loadmd function.
However, some of the features, such as fixed zonal reserve requirements, binary tran-
sition masks for load-following ramp, or linear dynamical system constraints, are
only available by modifying portions of the MOST Data struct directly.
60
Table 5-6: Input Data Fields of md
name type* default description
cont(t,j).contab I empty changes table† defining contingencies for period t,
scenario j
Delta T I 1 length of time step in hours
idx.nt I number of periods in scheduling horizon
InitialPg(i) I ng × 1, injection of generator i at t = 0
mpc I base system data, standard Matpower case
struct‡, with baseMVA, bus, gen, branch and
gencost fields
offer(t) I struct with offer data for period t, see Table 5-8
for details of sub-fields
OpenEnded I 1 ignore terminal dispatch ramp constraints, depre-
cated
RampWearCostCoeff(i,t) I 0 ng × nt , cost of ramping of generator i from pe-
riod t−1 to t, coefficient Cδi for square of dispatch
difference in (4.10)
Storage B struct with parameters for storage units, see Ta-
ble 5-9 for the input fields
TerminalPg(i) I ng × 1, injection of generator i at t = nt , depre-
cated, untested
tstep(t) B nt × 1 struct of parameters related to period t
.OpCondSched(j).tab I changes table defining modifications from mpc for
each base scenario j in period t
.TransMask I an nj(t) × nj(t−1) matrix of binary transition
masks ζ tj2 j1 from scenario j1 in period t − 1 to
j2 in period t, see Section 6.5
.TransMat I Φt , an nj(t) × nj(t−1) matrix of transition proba-
bilities φtj2 j1 from scenario j1 in period t − 1 to
j2 in period t, see Section 5.1.2
* I = input, O = output, B = both, opt = taken from Matpower options.
† See Section 5.1.5 for details. Note that, while loadmd assigns the same contab to all t and j, it is possible to set
different contab values manually and they will be respected by most.
‡ See Appendix B in the Matpower User’s Manual for details.
61
Table 5-7: Additional Input Data Fields of md
name type* default description
CoordCost I empty user supplied coordination costs for AC version
.Huser I sparse matrix of quadratic coefficients
.Cuser I vector of linear coefficients
.cuser I scalar constant term
dstep(t) I empty nds
t × 1 struct with parameters for optional dy-
namical system model, (4.49)–(4.53)
.A I Atds , from (4.50)–(4.51)
t
.B I Bds , from (4.50)
t
.C I Cds , from (4.52)–(4.53)
t
.D I Dds , from (4.52)
t
.ymin I ymin , lower bound on output from (4.52)–(4.53)
t
.ymax I ymax , upper bound on output from (4.52)–(4.53)
.zmin I zmin , lower bound on z t from (4.49)
t
t
.zmax I zmax , upper bound on z t from (4.49)
FixedReserves(t,j,k) I empty zonal reserve input parameters for period t, sce-
nario j, contingency k, in form of reserves field
of mpc from Table 7-2 in the Matpower User’s
Manual, with cost, qty, zones, req sub-fields.
UC B struct with unit commitment parameters
.CommitKey(i,t) I empty optional ng × nt vector specifying availability of
unit i for commitment at time t
-1 – offline, unit forced off
0 or 1 – available for UC decisions
2 – must run, unit forced on
.CommitSched(i,t) B ng × nt matrix UC status (0 or 1) of unit i at
time t, input for non-UC runs, result for UC runs
.InitialState(i)† I empty ng ×1 vector of initial states, if positive (negative),
number of uptime (downtime) periods at time t =
0
.MinUp(i)† I empty ng × 1 vector, minimum up time in number of
periods
.MinDown(i)† I empty ng × 1 vector, minimum down time in number of
periods
z1 I empty initial state z 1 of optional dynamical system
model
† Requires that CommitKey be present and non-empty.
62
Table 5-8: Fields of Offer struct md.offer(t)
name description
† ti
PositiveActiveReservePrice linear coefficient of CRP + (·) in (4.6)
PositiveActiveReserveQuantity† max upward reserve quantity RP ti
max+ in (4.19)
NegativeActiveReservePrice† ti
linear coefficient of CRP − (·) in (4.6)
NegativeActiveReserveQuantity† max downward reserve quantity RP ti
max− in (4.20)
PositiveActiveDeltaPrice† ti
linear coefficient of CP + (·) in (4.6)
NegativeActiveDeltaPrice† linear coefficient of CPti− (·) in (4.6)
PositiveLoadFollowReservePrice† ti
linear coefficient of Cδ+ (·) in (4.6)
PositiveLoadFollowReserveQuantity† max upward ramp reserve δmax+ ti
in (4.23)
NegativeLoadFollowReservePrice† ti
linear coefficient of Cδ− (·) in (4.6)
NegativeLoadFollowReserveQuantity† max downward ramp reserve δmax− ti
in (4.24)
gencost‡ energy offers in the form of generator cost functions
† ng × 1 vector of values for each generator at time t.
‡ Deprecated. Use profiles instead.
63
Table 5-9: Input Fields of md.Storage
name type* default description†
UnitIdx(i) I corresponding gen matrix row index
ExpectedTerminalStorageAim(i) I target value for expected final stored en-
ergy at end of last period for storage
unit i, overrides any values provided for
both ExpectedTerminalStorageMin and
ExpectedTerminalStorageMax
nt i
ExpectedTerminalStorageMax(i) I upper bound Smin on expected final stored
energy in (4.37)
nt i
ExpectedTerminalStorageMin(i) I lower bound Smax on expected final stored
energy in (4.37)
InitialStorage(i) B initial (expected) stored energy s0 in MWh
InitialStorageCost(i) I cost Cs0 associated with starting with
amount s0 at time t = 0
0i
InitialStorageLowerBound(i) I lower bound Smin on inital (expected)
stored energy s0 in (4.39)
0i
InitialStorageUpperBound(i) I upper bound Smax on inital (expected)
stored energy s0 in (4.39)
InEff(i,t)‡ I 1 input efficiency ηin ti
OutEff(i,t)‡ I 1 output efficiency ηout ti
LossFactor(i,t)‡ I 0 fraction of stored energy lost per hour ηlossti
MaxStorageLevel(i,t)‡ I stored energy maximum limit Smax ti
MinStorageLevel(i,t)‡ I stored energy minimum limit Smin ti

ti
rho(i,t) I ρ parameter controlling weighting of
worst case (ρti = 1) and expected values
(ρti = 0) for defining storage constraints
in (4.33)–(4.36)
TerminalStoragePrice(i) I prices Cs for contributions to terminal
storage from charging/discharging in non-
terminal states
TerminalChargingPrice0(i) I Cs § prices Csc0 for . . . charging in terminal end-
of-horizon base states
TerminalChargingPriceK(i) I Cs § prices Csck for . . . charging in terminal con-
tingency states
TerminalDischargingPrice0(i) I Cs § prices Csd0 for . . . discharging in terminal
end-of-horizon base states
TerminalDischargingPriceK(i) I Cs § prices Csdk for . . . discharging in terminal
contingency states
† All fields have ns rows, where row i refers to storage unit i. See also Table 5-2.
‡ Automatically expanded from scalar, ns × 1 or 1 × nt vector to a full ns × nt matrix.
§ That is, the default is taken from TerminalStoragePrice.
64
5.3.2 Output Data
Additional fields are initialized or added to the MOST Data struct by most and re-
turned in the updated output struct. Some simply record the values of correspond-
ing options found in the Matpower options struct passed in, while others contain
computed results. The output fields added or updated by most are summarized in
Tables 5-10 through 5-13.
65
Table 5-10: Output Data Fields of md
name type* description
alpha opt α, copy of most.alpha option
CostWeights(k,j,t)† O ψ tjk , probability of contingency k in scenario j at
time t
CostWeightsAdj(k,j,t)† O ψαtjk , same as ψ tjk , but adjusted for α as in (4.1)
DCMODEL opt copy of most.dc model option
flow(t,j,k) O case data for period t, scenario j, contingency k
.mpc Matpower case struct,‡ prices and gen costs are
probability-weighted
.PLsh vector needed to compute branch flow results
idx B various problem dimensions, see Table 5-11
IncludeFixedReserves opt copy of most.fixed res option
QCoordination opt copy of most.q coordination option
QP B¶ (MI)QP/LP problem setup and results, see Ta-
ble 5-12
results O results, see Table 5-13
SecurityConstrained opt copy of most.security constraints option
StepProb(t) O γ t , probability of making it to period t
Storage B γ t , probability of making it to period t
.ExpectedStorageDispatch(i,t) O ns × nt , expected dispatch of storage unit i
.ExpectedStorageState(i,t) O ns × nt , expected stored energy in storage unit i
at end period t
.ForceCyclicStorage opt copy of most.storage.cyclic option
.ForceExpectedTerminalStorage opt copy of most.storage.terminal target option
.InitialStorage(i) B ns ×1, initial (expected) stored energy s0 in MWh,
computed as output when most.storage.cyclic
option is on
tstep(t) B nt × 1 struct of parameters related to period t
.E§ O E t , used to compute expected injections in pe-
riod t
.G§ O Gt
.H§ O Ht
.Li§ O LtI
.Lf§ O LtF
.Mg§ O Mgt
.Mh§ O Mht
.Ng§ O Ngt
.Nh§ O Nht
UC.CommitSched(i,t) B ng × nt matrix UC status (0 or 1) of unit i at
time t, input for non-UC runs, result for UC runs
† Note index order – (:,:,t) refers to period t.
‡ See Appendix B in the Matpower User’s Manual for details.
¶ The QP field is either contructed by most or taken as an input, based on the value of the most.build model option
described in Table 5-4.
§ Used to compute expected inital and final storage amounts for period t. See (4.83)–(4.90) for details.
66
Table 5-11: Fields of Index struct md.idx
nt I number of periods in scheduling horizon
nj(t) O number of base scenarios for period t, computed from length of
tstep(t).OpCondSched(j)
nc(t,j) O number of contingencies in period t, scenario j
nb(t,j,k) O number of buses in period t, scenario j, contingency k
nb total O total number of buses summed over all flows
ng O number of gens in mpc.gen
ny(t,j,k) O number of gens with piecewise linear costs in period t, scenario j,
contingency k
nf total O total number of flows (periods t × scenarios j × contingencies k)
ns O number of storage units
ns total O ns × nf total
ntramp O number of periods of load-following reserves, always equal to nt - 1
since OpenEnded has been deprecated
ntds O nds
t , number of time periods in the horizon of the dynamical system
model
nzds O nds
z , size of state vector for dynamical system model (4.50)-(4.51)
nyds O nds
y , number of outputs of dynamical system model (4.52)-(4.53)
nvars O total number of variables
† Used to compute expected inital and final storage amounts for period t. See (4.83)–(4.90) for details.
67
Table 5-12: Fields of QP struct md.QP
A§ B linear constraint matrix
l§ B linear constraint lower bound
u§ B linear constraint upper bound
x§ O full optimization variable x
f§ O value of objective function at solution (same as md.results.f)
vtype§ B string containing variable types
x0§ B variable initial value
xmin§ B variable lower bound
xmax§ B variable upper bound
H§ B quadratic cost coefficient matrix†
C§ B linear cost coefficient vector†
c B constant cost term†
H1 B quadratic cost coefficient matrix‡
C1 B linear cost coefficient vector‡
c1 B constant cost term‡
Cfstor B linear cost coefficients of full x to reflect expected value of storage in
terminal states
opt§ B options struct for qps matpower or miqps matpower, set by MOST
run options and solver-specific Matpower options via mpopt2qpopt
exitflag§ O 1 = converged successfully, 0 or negative value = solver specific failure
code
output§ O struct with solver-specific fields and alg field specifying solver that
was used
lambda§ O Lagrange and Kuhn-Tucker multipliers on constraints
.mu l§ O lower (left-hand) limit on linear constraints
.mu u§ O upper (right-hand) limit on linear constraints
.lower§ O lower bound on optimization variables
.upper§ O upper bound on optimization variables
* I = input, O = output, B = both, opt = taken from Matpower options. The QP struct and its fields
are either contructed by most or taken as an input, based on the value of the most.build model option
described in Table 5-4.
† Including user defined coordination costs from md.CoordCost.
‡ Excluding user defined coordination costs from md.CoordCost.
§ See input and output arguments for qps matpower or miqps matpower for details.
68
Table 5-13: Fields of Results struct md.results
f O value of objective function f (x) in (4.6) at solution (same as md.QP.f)
success O optimization success flag, 1 = succeeded, 0 = failed
Pc(i,t) O ng × nt , active power contract quantity, pti c
ti
Rpp(i,t) O ng × nt , upward active contingency reserve quantity r+
ti
Rpm(i,t) O ng × nt , downward active contingency reserve quantity r−
ti
Rrp(i,t) O ng × nt , upward load-following ramping reserve quantity δ+
ti
Rrm(i,t) O ng × nt , downward load-following ramping reserve quantity δ−
Sp O ns × nt , endogenously computed upper stored energy bounds sti +
Sm O ns × nt , endogenously computed lower stored energy bounds sti −
GenPrices(i,t) O ng × nt , expected energy price
CondGenPrices(i,t) O ng × nt , expected energy price, conditional on making it to time t
RppPrices(i,t) O ng × nt , price on upward active contingency reserve
RpmPrices(i,t) O ng × nt , price on downward active contingency reserve
RrpPrices(i,t) O ng × nt , price on upward load-following ramping reserve
RrmPrices(i,t) O ng × nt , price on downward load-following ramping reserve
ExpectedRampCost(i,t) O ng × nt , expected ramping cost (wear and tear)
ExpectedDispatch(i,t) O ng × nt , expected generator dispatch across base cases
Z O nds ds
z × nt , dynamical system model state z
Y O ny × nds
ds
t , dynamical system model output
SetupTime O time to construct model in seconds
SolveTime O time to solve model in seconds
69
5.4 Additional Considerations
The current version of MOST has a number of modeling limitations relative to Mat-
power. The following is a list of Matpower features that are not yet supported
by MOST:
• branch angle difference limits
• branch flow soft limits
• DC transmission lines
• full non-linear AC network modeling
• interface flow limits
70
6 Additional Functions
6.1 addgen2mpc
[new_mpc, idx] = addgen2mpc(mpc, gen, gencost, gen_type)
Appends a set of generators to those contained in an existing Matpower case

struct. The existing case in mpc is a standard Matpower case with additional fields,
genfuel containing a cell array of string-valued fuel types (one for each generator),
and i<type> containing (for each fuel type) a vector of indices of the generators of
type <type>. The gen and gencost inputs are the standard Matpower generator
and generator cost matrices and gen type is a string or cell array of strings of fuel
types for the generators to be appended.
It returns the updated case struct in new mpc, with the new generators appended
to the gen, gencost and genfuel fields and updated i<type> fields, along with a
vector idx of indices of the newly added generators.
While there are no canonical definitions for generator types, Table 6-1 contains
some strings that have been used by convention, where 'ess' and 'wind' are used
explicitly by some functions in MOST.
Table 6-1: Typical Generator Types

type string description
'biomass' biomass
'coal' coal
'dl' dispatchable load
'ess' energy storage system
'hydro' hydro
'ng' natural gas, combustion turbine
'ngcc' natural gas, combined cycle
'nuclear' nuclear
'oil' oil
'refuse' refuse
'solar' solar PV
'syncgen' synchronous condensor
'wind' wind
'na' none
'unknown' unknown
71
6.2 addstorage
[idx, new_mpc] = addstorage(storage, mpc)
[idx, new_mpc, new_xgd, new_sd] = addstorage(storage, mpc)
[idx, new_mpc, new_xgd, new_sd] = addstorage(storage, mpc, xgd)
[idx, new_mpc, new_xgd, new_sd] = addstorage(storage, mpc, xgd, sd)
Given a StorageUnitData struct (storage), or the name of a function or MAT-

file containing such a struct, this function adds the specified storage units, modeled
as additional special generators, to the existing gen and gencost matrices of the
Matpower case (mpc) and to the existing xGen and StorageData structs, providing
a convenient way to specify in one place all of the parameters for a set of storage
units.
The parameters for the storage units to be added are specified in a StorageUnitData
struct, which is a single struct with the four fields described in Table 6-2. Return
values include a vector idx of generator indices for the newly added storage units,
along with updated versions of the mpc, xgd and sd structs specified by the inputs..
Table 6-2: Fields of StorageUnitData struct (storage)

gen none rows to be appended to the gen matrix* in mpc
gencost zero cost rows to be appended to the gencost matrix* in mpc
xgd table none xGenDataTable struct† corresponding to units to be added
sd table none StorageDataTable struct‡ corresponding to units to be added
* See Tables B-2 and B-4 in Appendix B of the Matpower User’s Manual for details on the format.
† See loadxgendata in Section 6.11 and Table 6-6 for details of the xGenDataTable struct.
‡ See loadstoragedata in Section 6.10 and Table 6-5 for details of the StorageDataTable struct.
6.3 addwind
[idx, new_mpc] = addwind(wind, mpc)
[idx, new_mpc, new_xgd] = addwind(wind, mpc)
[idx, new_mpc, new_xgd] = addwind(wind, mpc, xgd)
Given a WindUnitData struct (wind), or the name of a function or MAT-file con-

taining such a struct, this function adds the specified wind generators to the existing
gen and gencost matrices of the Matpower case (mpc) and to the existing xGen
struct, providing a convenient way to specify in one place all of the parameters for a
set of wind generators.
72
The parameters for the wind generators to be added are specified in a WindUnitData
struct, which is a single struct with the four fields described in Table 6-3. Return
values include a vector idx of generator indices for the newly added wind generators,
along with updated versions of the mpc and xgd structs specified by the inputs.
Table 6-3: Fields of WindUnitData struct (wind)
gen none rows to be appended to the gen matrix* in mpc
gencost zero cost rows to be appended to the gencost matrix* in mpc
xgd table none xGenDataTable struct† corresponding to units to be added
* See Tables B-2 and B-4 in Appendix B of the Matpower User’s Manual for details on the format.
† See loadxgendata in Section 6.11 and Table 6-6 for details of the xGenDataTable struct.
6.4 apply profile

chgtabs = apply_profile( profile, chgtabsi )
xgd = apply_profile( profile, xgdi, dim )
sd = apply_profile( profile, sdi, dim )
The apply profile function applies a single profile of a given type to the provided
input. See Section 5.1.6 and Table 5-3 for details on the profile struct.
For profiles of type 'mpcData', the output is an nt ×nmax
j cell array of change tables
in the format expected by Matpower’s apply changes function.25 The second input
is also nt × nmax
j cell array. Each element can be either empty or contain a change
table to which the new changes are appended.
For profiles of type 'xGenData' the second argument is the xGenData struct to
be modified (xgdi) and the output xgd is a modified version of the same struct.
The the third argument dim is a positive integer indicating the number of elements
corresponding to the third dimension of profile.values. This allows this dimension
to be expanded to the appropriate size if it is specified as a singleton dimension in
profile.values.
Profiles of type 'StorageData' are completely analogous, taking a StorageData
struct (sdi) as the second input and returning a modified version of it in sd.
6.5 filter ramp transitions

md = filter_ramp_transitions(md0, threshold)
25
See Section 9.3.5 in the Matpower User’s Manual.
73
The filter ramp transitions function creates a binary valued transition mask
tj2 j1
ζ for ramping reserves based on a given probability threshold. Only transitions
with probabilities greater than or equal to a given threshold value are included,
where the probability of the transition from state j1 to j2 is taken to be the conditional
probability Φt from (4.55), specified in the transmat argument to loadmd, multiplied
by the conditional probability of being in state j1 , given that you’ve made it to
period t.
6.6 getprofiles
profiles = getprofiles(profilesi);
profiles = getprofiles(profilesi, profiles0);
profiles = getprofiles(profilesi, idx);
profiles = getprofiles(profilesi, profiles0, idx);
Loads a profile or set of profiles from a struct, MAT-file or M-file (profilei),

optionally using the n-dimensional index vector idx to modify any non-zero values
in the rows fields so that the corresponding rows field in the returned profiles is
equal to idx(rows). This makes it easy to use profiles defined for a particular set of
generators, such as those added to a case as a group by addwind or addstorage.
The optional profiles0 argument allows the user to provide an existing profile
struct to which the new profiles are appended.
6.7 idx profile

[PR_REP, PR_REL, PR_ADD, PR_TCONT, PR_TYPES, PR_TMPCD,...
PR_TXGD, PR_TCTD, PR_TSTGD, PR_CHGTYPES] = idx_profile;
This function defines constants that are useful in defining profiles.
6.8 loadgenericdata
var = loadgenericdata(varfile, vartype)
var = loadgenericdata(varfile, vartype, fields)
var = loadgenericdata(varfile, vartype, fields, varname)
var = loadgenericdata(varfile, vartype, fields, varname, args)
The loadgenericdata function loads data from a variable, M-file or MAT-file and
checks that it matches a specified type. The first argument, varfile, is a variable
74
Table 6-4: Constants Defined by idx profile
name value description
PR REP 1 replace old values with new ones
PR REL 2 multiply old values by scale factors
PR ADD 3 add shift factor to old values
PR TCONT* 1
PR TYPES list list of profile types
PR TMPCD list vector of valid table types for 'mpcData'
PR TXGD list list of valid table types for 'xGenData'
PR TCTD* list list of valid table types for 'ContingencyData'
PR TSTGD list list of valid table types for 'StorageData'
PR CHGTYPES list list of valid change types
* Related to functionality not yet implemented.
containing the data structure or a string containing the name of a function M-file
or a MAT-file on the Matlab path. If no file extension is provided, it will attempt
to load a MAT-file with the specified name and, if not found, will call a function
by that name to get the data. The function M-file should return a single argument
containing the data. A MAT-file should either contain a single variable with the
desired data or provide the variable name in varname.
The second argument, vartype, is a string or cell array of strings with, in order
of priority, the data structure type to be returned. Valid values are 'struct', 'cell'
and 'array'.
The third argument, fields, is optional and contains a string or cell array of
strings containing a list of required fields in case the vartype is 'struct'. If a
required field is missing it will throw an error.
The varname and args arguments are also optional. varname is a string containing
the name of the variable to extract when loading a MAT-file. If not provided, the
default is to extract the first variable, regardless of name. And args is a scalar or
cell array of values that are passed as input arguments to the function, in the case
where varfile is a function name.
6.9 loadmd
md = loadmd(mpc, transmat, xgd, sd, contab, profiles)
The loadmd function provides the canonical way of loading a MOST Data struct.
For details please see Sections 5.1.1–5.1.6.
75
6.10 loadstoragedata
sd = loadstoragedata(sd_table)
sd = loadstoragedata(sd_table, gen)
sd = loadstoragedata(sd_table, mpc)
The loadstoragedata function provides the canonical way of loading additional

parameters for storage resources into a StorageData struct, described in Section 5.1.4
and summarized in Table 5-2. It takes a StorageDataTable struct as input, either
directly or as the name of a function or MAT-file that returns such a struct. If
the optional second argument is provided, either a Matpower gen matrix or a
Matpower case file mpc, the number of storage units is checked for consistency.
The StorageDataTable struct is used as a convenient way to define the StorageData
struct using a table format for the data and is summarized in Table 6-5. It has two
mandatory fields, colnames and data. The data field is a ns × N matrix, where ns is
the number of storage units and N is the number of fields in the StorageData being
defined. The colnames field is an N dimensional cell array of strings with field names
corresponding to the columns in data. The number of columns in the table and their
order are determined by the user, depending on the fields for which they want to
specify non-default values.
Table 6-5: Fields of StorageDataTable struct (sd table)
colnames none N element cell array of StorageData field names* corresponding
to the columns of the data field†
data none ns × N matrix of storage parameters†
MinStorageLevel‡ none stored energy minimum limit Sminti
MaxStorageLevel‡ none stored energy maximum limit Smax ti
OutEff‡ 1 ti
output efficiency ηout
InEff‡ 1 ti
input efficiency ηin
LossFactor‡ 0 ti
fraction of stored energy lost per hour ηloss
rho‡ 1 ρti parameter controlling weighting of worst case (ρti = 1) and
expected values (ρti = 0) for defining storage constraints in
(4.33)–(4.36)
* See Table 5-2 for a list of valid field names.
† ns is the number of storage units and N is the number of fields in the StorageData being defined by the given
StorageDataTable.
‡ Values in these scalar fields are overridden by any corresponding values in the data table.
There are six additional optional scalar fields that can be used instead of the
data table if a single value is to be assigned uniformly to all of the storage units. An
example StorageDataTable struct is created by the following code.
76
storage.sd_table.OutEff = 0.9;
storage.sd_table.InEff = 0.9;
storage.sd_table.LossFactor = 0.02;
storage.sd_table.rho = 0;
storage.sd_table.colnames = { % indented to align with data cols
'InitialStorage', ...
'InitialStorageLowerBound', ...
'InitialStorageUpperBound', ...
'InitialStorageCost', ...
'TerminalStoragePrice', ...
'MinStorageLevel', ...
'MaxStorageLevel', ...
};
storage.sd_table.data = [
40 0 80 45 43 0 40;
30 0 60 47 45 0 30;
50 0 100 46 44 0 50;
];
See also the addstorage function in Section 6.2 for a potentially more convenient
way to specify all of the parameters for your storage resources in a single file or
struct.
6.11 loadxgendata
xgd = loadxgendata(xgd_table)
xgd = loadxgendata(xgd_table, gen)
xgd = loadxgendata(xgd_table, mpc)
The loadxgendata function provides the canonical way of loading extra generator
data into an xGenData struct described in Section 5.1.3 and summarized Table 5-1. It
takes an xGenDataTable struct as input, either directly or as the name of a function
or MAT-file that returns such a struct. If the optional second argument is provided,
either a Matpower gen matrix or a Matpower case file mpc, the generator status
and limits are used to set certain default values as indicated in Table 5-1.
The xGenDataTable struct is used as a convenient way to define the xGenData
struct using a table format for the data and is summarized in Table 6-6. It has
two fields, colnames and data. The data field is a ng × N matrix, where ng is the
number of generators and N is the number of fields in the xGenData being defined.
Those that are not defined in the xGenDataTable struct are assigned default values
77
by loadxgendata. The colnames field is an N dimensional cell array of strings with
field names corresponding to the columns in data. The number of columns in the
table and their order are determined by the user, depending on the fields for which
they want to specify non-default values.
Table 6-6: Fields of xGenDataTable struct (xgd table)

colnames none N element cell array of xGenData field names* corresponding to the columns
of the data field†
data none ng × N matrix of extra generator parameters†
* See Table 5-1 for a list of valid field names.
† ng is the number of generators and N is the number of fields in the xGenData being defined by the given
xGenDataTable.
An example xGenDataTable struct is created by the following code.
xgd_table.colnames = { % indented to align with data cols

'CommitSched', ...
'PositiveActiveReservePrice', ...
'PositiveActiveReserveQuantity' };
xgd_table.data = [
1 5 25;
1 8 200;
1 20 60;
1 2 100;
];
78
6.12 most summary
most_summary(mdo)
ms = most_summary(mdo)
This function should be considered experimental. It is included because it is often

better than nothing, though it is very incomplete.
Given a MOST Data struct returned by most, this function returns a struct with
the fields listed in Table 6-7. Printing to the console is currently controlled by the
mdo.QP.verbose flag.
Table 6-7: Fields of most summary struct (ms)

name description
f objective function value
nb nb , number of buses
ng ng , number of generators (incl. storage, disp. load, etc.)
nl nl , number of branches
nt nt , number of periods in planning horizon
nj max nmax
j , max number of scenarios per period
nc max nmax
c , max number of contingencies per scenario in any period
Pg ng × nt × nmax
j × (nmax
c + 1), real power generation
Rup ng × nt , upward ramping reserve quantities
Rdn ng × nt , downward ramping reserve quantities
Pf ng × nt × nmax
j × (nmax
c + 1), real power generation
u ng × nt × nj × (nmax
max
c + 1), generator commitment status
lamP nb × nt × nmax
j × (n max
c + 1), shadow price on power balance
muF nl × nt × nmax
j × (n max
c + 1), shadow price on flow limits
6.13 mostver
mostver
vnum = mostver
v = mostver('all')
Called with no output arguments, mostver prints the version number and release
date of the current MOST installation. Otherwise, if called with no input arguments,
it returns the current version as a string and with any true input argument, such as
the string 'all', it returns a struct with the fields Name, Version, Release and Date
(all strings).
79
7 Tutorial Examples
The examples in this section are based on the simple three bus model summarized in
Table 7-1 and illustrated in Figure 7-1. The case data can be found in the ex case3a
and ex case3b files. Not all examples include every part of the model. For example,
the single-period deterministic examples do not have the wind generator at bus 2,
none of the deterministic cases include the contingencies and the stochastic cases do
not include the fixed reserve requirement. The storage unit is only included where
specifically mentioned.
Table 7-1: Summary of Tutorial Example System Data

topology 3-bus triangle network
2 identical 200 MW gens at bus 1, different reserve cost
generators 500 MW gen at bus 2
all 3 have identical quadratic generation costs*
load 450 MW at bus 3
curtailable at $1000/MWh
300 MW limit, line 1–2
branches 240 MW limit, line 1–3
300 MW limit, line 2–3
adequacy requirement option 1: 150 MW system requirement
- generator 2 at bus 1
option 2: contingencies:
- line 1–3
wind unit at bus 2 with 100 MW output in nominal case
stochastic cases use 3 samples of normal distribution
storage 200 MWh unit at bus 3
80 MW max charge/discharge rate
* Linear costs of $25, $30, and $40/WMh are used for some examples.
The code for the following examples can be found in <MATPOWER>/most/lib/t

in the files whose names begin with most ex, such as most ex1 ed.m. For all of the
following examples, assume that mpopt is a Matpower options struct and that
define constants has already been executed.
define_constants
mpopt = mpoption('verbose', 0);
80
200 MW 200 MW 500 MW
100 MW
gen 1 gen 2 gen 3
bus 1 bus 2
300 MW
240 MW 300 MW
bus 3
200 MWh
450 MW
±80 MW
Figure 7-1: Tutorial Example System
7.1 Single Period Problems

Even without MOST, Matpower can solve the deterministic single period problems
since they are just special cases of the optimal power flow problem. Where applicable,
both methods will be shown for comparison.
7.1.1 Example 1 – Deterministic Economic Dispatch

The single period deterministic economic dispatch problem minimizes the cost of
generation subject to generator limits, so the solution is identical to that given by a
DC OPF problem when the branch flow limits are eliminated.26 Of course, this can
be solved without MOST by using rundcopf, as shown in the example below, where
the results are returned in the variable r1, a standard Matpower OPF results struct
with bus, branch, gen fields, etc.
26
The deterministic economic dispatch examples can be found in most ex1 ed.m.
81
mpc = loadcase('ex_case3a');
mpc.branch(:, RATE_A) = 0; % disable line flow limits (mimic no network case)
r1 = rundcopf(mpc, mpopt);
Pg1 = r1.gen(:, PG); % active generation
lam1 = r1.bus(:, LAM_P); % nodal energy price
The equivalent “no network” economic dispatch problem can be solved by MOST as
follows. In this case, the variable r2 with many of the results can be extracted from
the mpc field of the first (and, in this case, only) element of mdo.flow. As described in
Table 5-10, this is also a standard Matpower case struct containing the expected
results.
mpopt = mpoption(mpopt, 'most.dc_model', 0); % use model with no network
mdi = loadmd(mpc);
r2 = mdo.flow.mpc;
Zonal reserve requirements can be added and the problem solved by runopf w res
as described in Section 7.6.1 in the Matpower User’s Manual. The solved reserve
quantities and prices are returned in r1.reserves, as summarized in Table 7-6 in the
same section.
mpc.branch(:, RATE_A) = 0; % disable line flow limits (mimic no network case)
mpopt = mpoption(mpopt, 'model', 'DC');
r1 = runopf_w_res(mpc, mpopt);
R1 = r1.reserves.R; % reserve quantity
prc1 = r1.reserves.prc; % reserve price
The equivalent problem, solved by MOST is the following, where the inputs must
be specified in mdi.FixedReserves and the solved reserve quantities and prices are
found in r2.reserves.
82
mdi = loadmd(mpc);
mdi.FixedReserves = mpc.reserves; % include fixed zonal reserves
r2 = mdo.flow.mpc;
7.1.2 Example 2 – Deterministic DC OPF

The deterministic optimal power flow problem simply adds a DC power flow network
model, including branch flow limits.27 Once again, this problem can be solved with
rundcopf, now without disabling branch flow limits.
r1 = rundcopf(mpc, mpopt);
And it can be solved with MOST, by turning the DC network model back on (the
default).
mpopt = mpoption(mpopt, 'most.dc_model', 1); % use DC network model (default)
mdi = loadmd(mpc);
r2 = mdo.flow.mpc;
Similarly, zonal reserve requirements can be included as above in the economic

dispatch problem, and solved via runopf w res.
27
The deterministic DC OPF examples can be found in most ex2 dcopf.m.
83
mpopt = mpoption(mpopt, 'model', 'DC');
r1 = runopf_w_res(mpc, mpopt);
And the MOST equivalent, in this case, looks like the following.
mdi = loadmd(mpc);
mdi.FixedReserves = mpc.reserves; % include fixed zonal reserves
r2 = mdo.flow.mpc;
7.1.3 Example 3 – Deterministic DC OPF with Binary Commitment

The option of binary commitment decisions can be added to the deterministic eco-
nomic dispatch and DC OPF problems28 above by specifying a 'CommitKey' value
for each generator in the corresponding xGenData.29
In this example, ex case3b is modified by adding a wind generator at bus 2, with
available generation capacity of 100 MW, and scaling the load to 499 MW. Startup
and shutdown costs are also ignored. The xGenData in this example indicates that
the three conventional generators are available for commitment (CommitKey = 1) and
the dispatchable load is always on (CommitKey = 2).30
28
The deterministic DC OPF examples with binary commitment can be found in
most ex3 dcopf w uc.m.
29
See Section 6.11.
30
The xGenData specified in ex wind uc.m for the wind unit also indicates that it is always on
(CommitKey = 2).
84
casefile = 'ex_case3b';
mpc = loadcase(casefile);
xgd_table.colnames = { 'CommitKey' };
xgd_table.data = [ 1; 1; 1; 2];
xgd = loadxgendata(xgd_table, mpc);
mpc = scale_load(499, mpc, [], struct('scale', 'QUANTITY'));
mpc.gencost(:, STARTUP) = 0; % ignore STARTUP and SHUTDOWN
mpc.gencost(:, SHUTDOWN) = 0; % costs for this example
Matpower’s runduopf function uses a heuristic to solve this problem as de-

scribed in Chapter 8 of the Matpower User’s Manual. This heuristic however can
be quite slow on large systems and there is no measure of the quality of the resulting
solution.
r1 = runduopf(mpc, mpopt);
u1 = r1.gen(:, GEN_STATUS); % commitment status
On the other hand, MOST takes advantage of an explicit MIP solver to solve this
problem rather more efficiently and with solution quality guarantees.
mdi = loadmd(mpc, [], xgd);
r2 = mdo.flow.mpc;
u2 = mdo.UC.CommitSched; % commitment status
7.1.4 Example 4 – Secure and Stochastic DC OPF

In contrast to a deterministic optimal power flow, which solves for dispatches, volt-
ages, flows and prices for a single scenario, the examples in this section in corporate
multiple probability-weighted scenarios.31
Secure DC OPF - with contingencies

Instead of using pre-determined fixed zonal reserve requirements to ensure a secure
dispatch, as in the example in Section 7.1.2, a set of credible contingencies can be
31
The secure and stochastic DC OPF examples can be found in most ex4 dcopf ss.m.
85
included explicitly via a contingency table, described in Section 5.1.5. The function
ex contab defines a contingency table with two outages. Generator 2 at bus 1 trips
off-line with a 6% probability, and the transmission line from bus 1 to bus 3 fails
with a 4% probability.
function contab = ex_contab
define_constants;
% label probty type row column chgtype newvalue
contab = [
1 0.06 CT_TGEN 2 GEN_STATUS CT_REP 0; %% gen 2 at bus 1
2 0.04 CT_TBRCH 2 BR_STATUS CT_REP 0; %% line 1-3
];
The xGenData is loaded from a file (ex xgd res) that defines prices and capacities for
contingency reserves.
xgd = loadxgendata('ex_xgd_res', mpc);
mdi = loadmd('ex_case3a', [], xgd, [], 'ex_contab');
EPg = mdo.results.ExpectedDispatch; % expected active generation
Elam = mdo.results.GenPrices; % nodal energy price
most_summary(mdo); % print results, depending on 'verbose' option
The results can be printed by most summary or extracted directly from the output
MOST Data struct, mdo.
Stochastic DC OPF - with renewable uncertainty

In contrast to the discrete event uncertainty related to contingencies, forecasting of
uncertain system parameters, such as demand or renewable generation from wind or
solar, results in a different sort of uncertainty that can be approximated by a set of
probability-weighted scenarios.
In the example below, a wind generator is added to the system and the maximum
output of the unit is set to 0, 50 and 100 MW, respectively, for three scenarios defined
by a profile. The probabilities of the scenarios are specified in transmat.
xgd = loadxgendata('ex_xgd_res', mpc);
[iwind, mpc, xgd] = addwind('ex_wind', mpc, xgd);
transmat = {[0.16; 0.68; 0.16]};
nt = 1; % number of periods
nj = 3; % number of scenarios
profiles = getprofiles(uniformwindprofile(nt, nj), iwind);
86
These parameters are then used by loadmd to create the MOST Data struct to pass
to the solver.
mdi = loadmd(mpc, transmat, xgd, [], [], profiles);
EPg = mdo.results.ExpectedDispatch; % active generation
As with the previous example, the results can be printed by most summary or
extracted directly from the output MOST Data struct, mdo.
Secure Stochastic DC OPF

Both types of uncertainty can be included in the same problem, with uncertain wind
and contingencies, by passing both the contingency table and the wind profile with
transition probabilities to loadmd.
mdi = loadmd(mpc, transmat, xgd, [], 'ex_contab', profiles);

Secure Stochastic DC OPF with Binary Commitment

Binary commitment decisions are added to the previous example by including a
'CommitKey' value for each generator in the corresponding xGenData, in this case
specified in ex xgd uc.m. In this example the generator startup and shutdown costs
are ignored and the load is decreased to 350 MW.
mpc = scale_load(350, mpc, [], struct('scale', 'QUANTITY'));
mpc.gencost(:, STARTUP) = 0;
mpc.gencost(:, SHUTDOWN) = 0;
Using the wind profile and transition probabilities defined in the previous example,
we can load and run this case as follows.
87
u = mdo.UC.CommitSched; % commitment status
Looking at the value of u, we see that in this example generator 2 is shut down.
>> u
u =
1
0
1
1
1
7.2 Multiperiod Problems

For the multiperiod examples, a 12 hour planning horizon is used. The load profile
is defined in ex load profile.m that varies from a high of 540 MW in period 3 to
a low of 300 MW in period 9, as illustrated in Figure 7-2. The available output of
the wind farm is represented in various ways. For the stochastic cases the output is
represented by 3 samples from a normal distribution around a mean forecast value,
where the distribution widens the further as we forecast futher into the future. In
the deterministic cases the available wind is simply set to this mean, as represented
by the solid red line in Figure 7-2. These profiles are defined in ex wind profile.m
and ex wind profile d.m, respectively.
7.2.1 Example 5 – Deterministic Multiperiod OPF

This example illustrates a simple deterministic multiperiod DC OPF problem, where
the dispatches in adjacent periods are linked by ramping constraints and costs.32 As
described above, the variations to load and wind through the planning horizon are
defined using profiles.
The xGenData is loaded from ex xgd ramp.m, which includes a $10/MW cost on
upward and downward ramping of generator 3 from one period to the next.
32
The deterministic multiperiod DC OPF examples can be found in most ex5 mpopf.m.
88
Load and Wind Profiles
600
Load
Deterministic Wind
Stochastic Wind
500
400
MW
300
200
100
0
1 2 3 4 5 6 7 8 9 10 11 12
Period
Figure 7-2: Example Load and Wind Profiles
xgd = loadxgendata('ex_xgd_ramp', mpc);
[iwind, mpc, xgd] = addwind('ex_wind', mpc, xgd);
profiles = getprofiles('ex_wind_profile_d', iwind);
profiles = getprofiles('ex_load_profile', profiles);
nt = size(profiles(1).values, 1); % number of periods
The generator dispatches can be found in mdo.flow(t).mpc.gen(:, PG) for period

t, or for all periods in the ng × nt matrix mdo.results.ExpectedDispatch.
mdi = loadmd(mpc, nt, xgd, [], [], profiles);
89
The RampWearCostCoeff field of xgd is modified to add the wear and tear ramping
costs from (4.10). This can be done directly for an existing xgd, as shown below, or by
adding a RampWearCostCoeff column in the xGenData file and defining the parameters
there.
xgd.RampWearCostCoeff(1:3) = 1;
7.2.2 Example 6 – Deterministic Unit Commitment

This example illustrates a deterministic unit commitment problem and how the com-
mitment changes as more features are added.33 These examples require a mixed-
integer solver as described in Section 2.1 on System Requirements.
The Matpower case and xGenData for the full-featured example are loaded first
and saved for later. Note that the xGenData here comes from ex xgd uc.m which
includes CommitKey and activates the unit commitment formulation.
profiles = getprofiles('ex_wind_profile_d', iwind);
mpc_full = mpc; % save for later
xgd_full = xgd; % save for later
Base : No Network
This example begins with a simple sequence of economic dispatch problems, with
no network constraints, no startup and shutdown costs, no minimum up or down
time constraints, no ramp constraints or ramp reserve costs, and no storage. These
features, except for storage, are already in included in the full model data loaded, so
33
The deterministic unit commitment examples can be found in most ex6 uc.m. These example
cases and the code used to produce the plots can also be found in the test file t most uc.m. Both
files contain additional solver-specific options that you may find useful for these unit commitment
examples.
90
the first step is to remove these features to prepare for the first example. They will
be added back in one at a time in the subsequent examples.
mpc.gencost(:, [STARTUP SHUTDOWN]) = 0; % remove startup/shutdown costs
xgd.MinUp(2) = 1; % remove min up-time constraint
xgd.PositiveLoadFollowReserveQuantity(3) = 250; % remove ramp reserve
xgd.PositiveLoadFollowReservePrice(3) = 1e-6; % constraint and costs
xgd.NegativeLoadFollowReservePrice(3) = 1e-6;
This model can then be run after turning off the DC network modeling.
ms = most_summary(mdo); % print results, depending on 'verbose' option
The resulting commitment, dispatch and price schedules are shown in Figure 7-3.
Notice that generator 3 only operates during hours 2, 3 and 4 and, as expected, the
prices at all three buses are identical, since there is no network model to introduce
transmission congestion.
Add DC Network Model

If a DC network model is added, by simply toggling the 'most.dc model' option and
re-running the same model, the congestion in the line from bus 1 to bus 3 results in
the nodal prices separating from one another and generator 3 carrying more of the
load during the periods of higher net load, as seen in Figure 7-4.
Add Startup and Shutdown Costs

To add startup and shutdown costs, restore the values from the original Matpower
case and re-run.
mpc.gencost(2, [STARTUP SHUTDOWN]) = [ 200 200];
mpc.gencost(3, [STARTUP SHUTDOWN]) = [3000 600];
% equivalent to doing: mpc = mpc_full;
Notice in Figure 7-5 that this results in generator 3 remaining on through the lower
load hours, allowing generator 2 to stay off for hours 8–11.
91
Base : No Network
Unit Commitment
Gen 1 @ Bus 1
Gen 2 @ Bus 1
Gen 3 @ Bus 2
1 2 3 4 5 6 7 8 9 10 11 12
Period
500 500
Generation, MW
Gen 1
Net Load, MW
400 Gen 2 400
Gen 3
300 300
200 200
100 100
0 0
1 2 3 4 5 6 7 8 9 10 11 12
Period
Nodal Price, $/MWh
100
Bus 1
Bus 2
Bus 3
50
0
1 2 3 4 5 6 7 8 9 10 11 12
Period
Figure 7-3: Deterministic UC : Base Case with No Network
92
+ DC Network
Unit Commitment
Gen 1 @ Bus 1
Gen 2 @ Bus 1
Gen 3 @ Bus 2
1 2 3 4 5 6 7 8 9 10 11 12
Period
500 500
Generation, MW
Gen 1
Net Load, MW
400 Gen 2 400
Gen 3
300 300
200 200
100 100
0 0
1 2 3 4 5 6 7 8 9 10 11 12
Period
Nodal Price, $/MWh
100
Bus 1
Bus 2
Bus 3
50
0
1 2 3 4 5 6 7 8 9 10 11 12
Period
Figure 7-4: Deterministic UC : Add DC Network Model
93
+ Startup/Shutdown Costs
Unit Commitment
Gen 1 @ Bus 1
Gen 2 @ Bus 1
Gen 3 @ Bus 2
1 2 3 4 5 6 7 8 9 10 11 12
Period
500 500
Generation, MW
Gen 1
Net Load, MW
400 Gen 2 400
Gen 3
300 300
200 200
100 100
0 0
1 2 3 4 5 6 7 8 9 10 11 12
Period
Nodal Price, $/MWh
100
Bus 1
Bus 2
Bus 3
50
0
1 2 3 4 5 6 7 8 9 10 11 12
Period
Figure 7-5: Deterministic UC : Add Startup and Shutdown Costs
94
Add Minimum Up and Down Time Constraints
Notice in the previous example that the generator 2 is only running for two hours
(6 and 7) in the middle of the planning horizon. Adding back the 3 hour minimum
up-time constraint eliminates that solution.
xgd.MinUp(2) = 3;
Figure 7-6 shows how this constraint results in starting up generator 2 an hour
earlier (in period 5). Notice also that previously there was no network congestion in
period 5, but starting generator 2 introduces congestion, causing the nodal prices in
that period to separate from one another.
Add Ramping Constraints and Ramp Reserve Costs

To add back the ramping constraints and ramp reserve costs, restore the values from
the original xGenData and re-run.
xgd.PositiveLoadFollowReserveQuantity(3) = 100; % restore ramp reserve

xgd.PositiveLoadFollowReservePrice(3) = 10; % constraint and costs
xgd.NegativeLoadFollowReservePrice(3) = 10;
% equivalent to doing: xgd = xgd_full;
Previously, generator 3 was ramping more than 200 MW from hour 1 to hour 3,
which the newly added ramp constraint of 100 MW per hour precludes. Figure 7-7
shows that this fast ramp is reduced by shutting down generator 2 during the first
two hours and starting generator 3 at a higher output level.
Add Storage
Finally, a 200 MWh storage unit is added at bus 3, as shown in the diagram in
Figure 7-1. The magnitude of the power injection for this storage unit is limited to
80 MW, both for “charging” and “discharging”. The cyclic storage constraint option
is used to ensure that the stored energy at the end of the planning horizon is equal
to the stored energy at the beginning.
95
+ Min Up/Down Time Constraints
Unit Commitment
Gen 1 @ Bus 1
Gen 2 @ Bus 1
Gen 3 @ Bus 2
1 2 3 4 5 6 7 8 9 10 11 12
Period
500 500
Generation, MW
Gen 1
Net Load, MW
400 Gen 2 400
Gen 3
300 300
200 200
100 100
0 0
1 2 3 4 5 6 7 8 9 10 11 12
Period
Nodal Price, $/MWh
100
Bus 1
Bus 2
Bus 3
50
0
1 2 3 4 5 6 7 8 9 10 11 12
Period
Figure 7-6: Deterministic UC : Add Min Up/Down Time Constraints
96
+ Ramping Constraints/Ramp Reserve Costs
Unit Commitment
Gen 1 @ Bus 1
Gen 2 @ Bus 1
Gen 3 @ Bus 2
1 2 3 4 5 6 7 8 9 10 11 12
Period
500 500
Generation, MW
Gen 1
Net Load, MW
400 Gen 2 400
Gen 3
300 300
200 200
100 100
0 0
1 2 3 4 5 6 7 8 9 10 11 12
Period
Nodal Price, $/MWh
100
Bus 1
Bus 2
Bus 3
50
0
1 2 3 4 5 6 7 8 9 10 11 12
Period
Figure 7-7: Deterministic UC : Add Ramp Constraints and Ramp Reserve Costs
97
mpopt = mpoption(mpopt, 'most.storage.cyclic', 1);
mdi = loadmd(mpc, nt, xgd, sd, [], profiles);
Figure 7-8 illustrates the effect of adding the storage unit. Since the unit is located
at bus 3 with the load, it can reduce the congestion enough in peak hours to allow
generator 2 to stay on for the full 12 hours. It also reduces the ramping capability
required from the more expensive generator 3. As expected, the storage unit is
charged during the periods of lower demand and lower price and discharged during
the periods of higher demand and higher price.
+ Storage
Unit Commitment
Gen 1 @ Bus 1
Gen 2 @ Bus 1
Gen 3 @ Bus 2
1 2 3 4 5 6 7 8 9 10 11 12
Period
Gen 1
500 Gen 2 500
Generation, MW
Gen 3
Net Load, MW
400 Storage Charge 400
300 Storage Discharge 300
200 200
100 100
0 0
1 2 3 4 5 6 7 8 9 10 11 12
Period
Nodal Price, $/MWh
100
Bus 1
Bus 2
Bus 3
50
0
1 2 3 4 5 6 7 8 9 10 11 12
Period
Figure 7-8: Deterministic UC : Add Storage
98
7.2.3 Example 7 – Secure Stochastic Unit Commitment
The following examples are based on example 6 above, with all of the features,
except storage, included. Instead of deterministic wind, however, a stochastic model
of wind is assumed.34 In these examples, three samples of wind availability serve
as the base scenarios, representing low, average and high wind realizations. These
wind scenarios are defined in ex wind profile.m. In this case, since there is a single
load profile defined in ex load profile.m, it is automatically expanded to apply to
all three wind scenarios as well. The examples in this section all use the following
setup.
mpc = loadcase('ex_case3b');
profiles = getprofiles('ex_wind_profile', iwind);
nj = size(profiles(1).values, 2); % number of scenarios
Stochastic Unit Commitment – Individual Trajectories

The transmat argument to loadmd defines the probabilities of transitions from the
scenarios in period t − 1 to the scenarios in period t. If identity matrices are used
for these transition probabilities, this results in the special case in which there are
3 full trajectories through the horizon, each of which can be viewed as a different
“scenario”. That is, if the system is in the high wind state in the first period, it
will stay in the high wind state in every subsequent period, and the same with the
average and low wind states. Figure 7-9 illustrates this special case.
In this case, it is also necessary to define the binary valued mask ζ tj2 j1 in (4.25)
so that the ramp reserve constraints (4.26)–(4.27) only include the transitions with
non-zero probability. This is done using the filter ramp transitions function.35
34
The secure and stochastic unit commitment examples can be found in most ex7 suc.m. These
example cases and the code used to produce the plots can also be found in the test file t most suc.m.
35
See Section 6.5.
99
Wind Profile, Individual Trajectories
200
Wind Scenarios
Possible Transitions
150
MW
100
50
0
1 2 3 4 5 6 7 8 9 10 11 12
Period
Figure 7-9: Example Wind Profiles, Individual Trajectories
transmat = cell(1, nt);

I = speye(nj);
[transmat{:}] = deal(I);
transmat{1} = [0.16; 0.68; 0.16]; % period 1 probabilities
mdi = filter_ramp_transitions(mdi, 0.1);
ms = most_summary(mdo);
The resulting unit commitment, expected dispatch and price schedules are shown in
Figure 7-10.
Stochastic Unit Commitment – Full Transition Probabilities

The more general case of stochastic unit commitment implemented by MOST uses
full transition probability matrices, where transitions between low, average and high
wind scenarios are allowed from period to period as illustrated in Figure 7-11. In
this case the binary valued mask ζ tj2 j1 is left at its default value of all ones, resulting
in ramp reserve constraints that encompass the largest period to period ramps.
transmat = ex_transmat(nt);
100
Individual Trajectories
Unit Commitment
Gen 1 @ Bus 1
Gen 2 @ Bus 1
Gen 3 @ Bus 2
1 2 3 4 5 6 7 8 9 10 11 12
Period
500 500
Generation, MW
Gen 1
Net Load, MW
400 Gen 2 400
Gen 3
300 300
200 200
100 100
0 0
1 2 3 4 5 6 7 8 9 10 11 12
Period
Nodal Price, $/MWh
150
Bus 1
Bus 2
100 Bus 3
50
0
1 2 3 4 5 6 7 8 9 10 11 12
Period
Figure 7-10: Stochastic UC : Individual Trajectories
101
Wind Profile, Full Transition Probabilities
200
Wind Scenarios
Possible Transitions
150
MW
100
50
0
1 2 3 4 5 6 7 8 9 10 11 12
Period
Figure 7-11: Example Wind Profiles, Full Transition Probabilities
This case results in a different unit commitment as seen in Figure 7-12, where gen-
erator 2 remains on throughout the later hours.
Secure Stochastic Unit Commitment

This example uses the general full transition probabilities and also includes contin-
gencies for security in each period.
Figure 7-13 shows the resulting unit commitment, expected dispatch and pricing
scheules.
Secure Stochastic Unit Commitment with Storage

Finally, a storage unit is added to the system, yielding a case that utilizes the majority
of the features of the MOST formulation.
mdi = loadmd(mpc, transmat, xgd, sd, 'ex_contab', profiles);
102
Full Transition Probabilities
Unit Commitment
Gen 1 @ Bus 1
Gen 2 @ Bus 1
Gen 3 @ Bus 2
1 2 3 4 5 6 7 8 9 10 11 12
Period
500 500
Generation, MW
Gen 1
Net Load, MW
400 Gen 2 400
Gen 3
300 300
200 200
100 100
0 0
1 2 3 4 5 6 7 8 9 10 11 12
Period
Nodal Price, $/MWh
150
Bus 1
Bus 2
100 Bus 3
50
0
1 2 3 4 5 6 7 8 9 10 11 12
Period
Figure 7-12: Stochastic UC : Full Transition Probabilities
103
+ Contingencies
Unit Commitment
Gen 1 @ Bus 1
Gen 2 @ Bus 1
Gen 3 @ Bus 2
1 2 3 4 5 6 7 8 9 10 11 12
Period
500 500
Generation, MW
Gen 1
Net Load, MW
400 Gen 2 400
Gen 3
300 300
200 200
100 100
0 0
1 2 3 4 5 6 7 8 9 10 11 12
Period
Nodal Price, $/MWh
150
Bus 1
Bus 2
100 Bus 3
50
0
1 2 3 4 5 6 7 8 9 10 11 12
Period
Figure 7-13: Secure Stochastic UC : Full Transition Probabilities + Contingencies
104
As seen in Figure 7-14, the storage allows all units to remain on for the entire horizon,
avoiding the startup and shutdown costs.
+ Storage
Unit Commitment
Gen 1 @ Bus 1
Gen 2 @ Bus 1
Gen 3 @ Bus 2
1 2 3 4 5 6 7 8 9 10 11 12
Period
Gen 1
500 Gen 2 500
Generation, MW
Gen 3
Net Load, MW
400 Storage Charge 400
300 Storage Discharge 300
200 200
100 100
0 0
1 2 3 4 5 6 7 8 9 10 11 12
Period
Nodal Price, $/MWh
150
Bus 1
Bus 2
100 Bus 3
50
0
1 2 3 4 5 6 7 8 9 10 11 12
Period
Figure 7-14: Secure Stochastic UC with Storage
7.2.4 Dynamical System Constraint Example

An example of using the linear time-varying dynamical system constraints can be
found in t most w ds.m.
105
8 Acknowledgments
This work was supported in part by the Consortium for Electric Reliability Tech-
nology Solutions (Certs) and the Office of Electricity Delivery and Energy Reli-
ability, Transmission Reliability Program of the U.S. Department of Energy under
the National Energy Technology Laboratory Cooperative Agreement No. DE-FC26-
09NT43321.
The authors would like to thank the following people, in no particular order,
for their various contributions to MOST and the SuperOPF project upon which it
is based: Robert J. Thomas, Timothy D. Mount, C. Lindsay Anderson, Alberto
Lamadrid, Daniel Muñoz-Álvarez, James S. Thorp, William D. Schulze, Jie Chen,
Hongye Wang, Wooyoung Jeon and Surin Maneevitjit.
106
Appendix A MOST Files and Functions
This appendix lists all of the files and functions that MOST provides. In most cases,
the function is found in a Matlab M-file of the same name in the lib directory of
the MOST distribution36 , where the .m extension is omitted from this listing. For
more information on each, at the Matlab prompt, simply type help followed by the
name of the function. For documentation and data files, the filename extensions are
included.
A.1 MOST Documentation Files
Table A-1: MOST Documentation Files

name description
docs/ MOST documentation
MOST-manual.pdf MOST User’s Manual
src/ LATEX source for MOST User’s Manual
lib/ MOST software (see Table A-2)
t/ MOST tests and examples (see Tables A-3 and A-4)
AUTHORS list of MOST authors
CHANGES.md MOST change history
CONTRIBUTING.md MOST Contributors Guide
LICENSE license file
README.md basic introduction to MOST
36
That is, in the <MATPOWER>/most/lib directory.
107
A.2 MOST Functions
Table A-2: MOST Functions

name description
lib/
addgen2mpc appends generators to existing case, see Section 6.1
addstorage appends storage units to existing case, see Section 6.2
addwind appends wind generators to existing case, see Section 6.3
apply profile applies a single profile to the specified data, see Section 6.4
filter ramp transitions creates binary valued transition mask ζ tj2 j1 for ramping re-
serves based on a probability threshold, see Section 6.5
getprofiles loads profiles from a struct or file, see Section 6.6
idx profile defines constants for use with profiles, see Section 6.7
loadgenericdata loads data from a variable, M-file or MAT-file and checks
that it matches a specified type, see Section 6.8
loadmd loads a MOST Data struct, see Section 6.9
loadstoragedata loads parameters for storage units, see Section 6.10
loadxgendata loads extra generator data, see Section 6.11
md init data structure initialization
most top-level solver, see Chapter 5
mostver prints/returns version info for MOST, see Section 6.13
mpoption info most option information for MOST
plot gen create plots of generator results
plot storage create plots of storage unit results
plot uc data plot generator commitment summary from raw data
plot uc plot generator commitment summary from md
108
A.3 Automated Test Suite
Table A-3: MOST Test and Example Data

name description
lib/t/
c118swf 118-bus test case, used by t most w ds
ex case3a sample 3-bus Matpower case (version a)
ex case3b sample 3-bus Matpower case (version b)
ex contab sample contingency table
ex load profile sample deterministic load profile
ex storage sample StorageUnitData
ex transmat sample transition probability data
ex wind profile sample stochastic wind profile
ex wind profile d sample deterministic wind profile
ex wind sample WindUnitData
ex wind uc sample WindUnitData for UC problem
ex xgd sample xGenData
ex xgd ramp sample xGenData with reserve and ramping costs
ex xgd res sample xGenData with reserve costs
ex xgd uc sample xGenData for UC problem
most ex1 ed Tutorial Example 1, see Section 7.1.1
most ex2 dcopf Tutorial Example 2, see Section 7.1.2
most ex3 dcopf w uc Tutorial Example 3, see Section 7.1.3
most ex4 dcopf ss Tutorial Example 4, see Section 7.1.4
most ex5 mpopf Tutorial Example 5, see Section 7.2.1
most ex6 uc Tutorial Example 6, see Section 7.2.2
most ex7 suc Tutorial Example 7, see Section 7.2.3
t case3 most 3-bus Matpower test case
t case30 most 30-bus Matpower test case
t most suc soln.mat solution data for t most suc
t most uc soln.mat solution data for t most uc
t most w ds z.mat solution data for t most w ds
109
Table A-4: MOST Tests
name description
lib/t/
test most runs full MOST test suite
t most 3b 1 1 0 3-bus, single period, no contingencies
t most 3b 1 1 2 3-bus, single period, 2 contingencies
t most 3b 3 1 0 3-bus, 3 periods, no contingencies
t most 3b 3 1 2 3-bus, 3 periods, 2 contingencies
t most 30b 1 1 0 uc 30-bus, single period, no contingencies, w/unit commitment
t most 30b 1 1 0 30-bus, single period, no contingencies
t most 30b 1 1 17 30-bus, single period, 17 contingencies
t most 30b 3 1 0 30-bus, 3 periods, no contingencies
t most 30b 3 1 17 30-bus, 3 periods, 17 contingencies
t most fixed res with fixed zonal reserve requirements
t most sp single period continuous problems
t most spuc single period mixed-integer problems, i.e. w/UC
t most suc multiperiod with stochastic unit commitment
t most uc multiperiod with deterministic unit commitment
t most w ds with linear dynamical system constraints
uniformwindprofile creates a wind profile with evenly spaced capacity values
110
Appendix B Release History
The full release history can be found in <MATPOWER>/most/docs/CHANGES.
B.1 Version 1.0 – released Dec 16, 2016

The MOST 1.0 User’s Manual is available online.37
New Open Development Model

• MOST development has moved to GitHub! The code repository is now publicly
available to clone and submit pull requests.38
• Public issue tracker for reporting bugs, submitting patches, etc.39
• Separate repositories for Matpower, MOST, MIPS, MP-Test, all available
from https://github.com/MATPOWER/.
• New developer e-mail list (MATPOWER-DEV-L) to facilitate communication
between those collaborating on Matpower-related development. Sign up at:
https://matpower.org/mailing-lists/#devlist.
Other Changes
• No significant changes since first public beta release.40
B.2 Version 1.0.1 – released Oct 30, 2018

The MOST 1.0.1 User’s Manual is available online.41
Bugs Fixed
• Fix bugs in plot uc data() resulting in incorrect legends.
• Fix dimension of RampWear cost indexing if mdi.OpenEnded is true.
• Add missing constant term to objective function value reported by most summary.
37
https://matpower.org/docs/MOST-manual-1.0.pdf
38
39
https://github.com/MATPOWER/most/issues
40
Version 1.0b1 was released on Jun 1, 2016 and 1.0b2 on Nov 1, 2016
41
https://matpower.org/docs/MOST-manual-1.0.1.pdf
111
Other Changes
• LATEX source code for MOST User’s Manual included in docs/src.
• Updated to use OOP notation for opt model object, and avoid calls to depre-
cated methods, using init indexed name() and add lin constraint() instead.
• Updated to use Matpower’s new quadratic costs in opt model in place of the
legacy cost model.
• Add success flag to md.results output MOST Data struct to indicate success
or failure of optimization.
Incompatible Changes
• Failure of the optimization no longer halts execution and jumps to the debug-
ger.
• Requires Matpower 7.x or later.
B.3 Version 1.0.2 – released Jun 20, 2019

The MOST 1.0.2 User’s Manual is available online.42
Bugs Fixed
• Fix default solver selection issue in t most w ds test.
Other Changes
• Add CITATION file.
• Other miscellaneous documentation updates, e.g. Matpower website links

updated to https://matpower.org, separate references for Matpower soft-
ware and User’s Manual, with DOIs.
42
https://matpower.org/docs/MOST-manual-1.0.2.pdf
112
References
[1] R. D. Zimmerman, C. E. Murillo-Sánchez, and R. J. Thomas, “Matpower:
Steady-State Operations, Planning and Analysis Tools for Power Systems Re-
search and Education,” Power Systems, IEEE Transactions on, vol. 26, no. 1,
pp. 12–19, Feb. 2011. doi: 10.1109/TPWRS.2010.2051168 1, 1.2
[2] R. D. Zimmerman, C. E. Murillo-Sánchez (2019). Matpower

[Software]. Available: https://matpower.org
doi: 10.5281/zenodo.3236535 1
[3] R. D. Zimmerman, C. E. Murillo-Sánchez. Matpower User’s Manual. 2019.

[Online]. Available: https://matpower.org/docs/MATPOWER-manual.pdf
doi: 10.5281/zenodo.3236519 1, 3
[4] C. E. Murillo-Sánchez, R. D. Zimmerman, C. L. Anderson, and R. J. Thomas,

“Secure Planning and Operations of Systems with Stochastic Sources, Energy
Storage and Active Demand,” Smart Grid, IEEE Transactions on, vol. 4, no. 4,
pp. 2220–2229, Dec. 2013. doi: 10.1109/TSG.2013.2281001 1, 1.2, 3
[5] A. J. Lamadrid, D. Muñoz-Álvarez, C. E. Murillo-Sánchez, R. D. Zimmerman,

H. D. Shin and R. J. Thomas, “Using the Matpower Optimal Scheduling Tool
to Test Power System Operation Methodologies Under Uncertainty,” Sustain-
able Energy, IEEE Transactions on, vol. 10, no. 3, pp. 1280–1289, July 2019.
doi: 10.1109/TSTE.2018.2865454 1
[6] R. D. Zimmerman, C. E. Murillo-Sánchez, and R. J. Thomas, “Mat-

power’s Extensible Optimal Power Flow Architecture,” Power and En-
ergy Society General Meeting, 2009 IEEE, pp. 1–7, July 26–30 2009.
doi: 10.1109/PES.2009.5275967 1
[7] The BSD 3-Clause License. [Online]. Available: https://opensource.org/

licenses/BSD-3-Clause. 1.1
[8] R. D. Zimmerman, C. E. Murillo-Sánchez. Matpower Optimal Scheduling

Tool (MOST) User’s Manual. 2019. [Online]. Available: https://matpower.
org/docs/MOST-manual.pdf
doi: 10.5281/zenodo.3236531 1.2
[9] A. J. Lamadrid, S. Maneevitjit, T. D. Mount, C. E. Murillo-Sánchez,

R. J. Thomas, R. D. Zimmerman, “A ‘SuperOPF’ Framework”, CERTS Report,
113
December 2008. [Online]. Available: https://certs.lbl.gov/publications/
superopf-framework 3
[10] C. E. Murillo-Sánchez, R. D. Zimmerman, C. L. Anderson, and R. J.

Thomas, “A Stochastic, Contingency-Based Security-Constrained Optimal
Power Flow for the Procurement of Energy and Distributed Reserve,” De-
cision Support Systems, Vol. 56, pp. 1-10, Dec. 2013, ISSN 0167-9236.
doi: 10.1016/j.dss.2013.04.006 3
114

MatPower Optimization

Uploaded by

Copyright:

Available Formats

MatPower Optimization

Uploaded by

Copyright:

Available Formats

Matpower Optimal Scheduling Tool

© 2011–2019 Power Systems Engineering Research Center (PSerc)

3 Background and Overview 16

Appendix B Release History 111

1.1 License and Terms of Use

Redistribution and use in source and binary forms, with or without

1. Redistributions of source code must retain the above copyright

2. Redistributions in binary form must reproduce the above copyright

THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS

1.2 Citing MOST

R. D. Zimmerman, C. E. Murillo-Sánchez. Matpower Optimal Scheduling Tool

R. D. Zimmerman, C. E. Murillo-Sánchez. Matpower Optimal Scheduling Tool

1.3 MOST Development

2.1 System Requirements

• <MOST>/lib – core MOST functions

2.3 Running a Simulation

mdo = most(mdi, mpopt);

Gurobi Version 8.1.1 -- automatic MILP solver

2.3.4 Setting Options

mpopt = mpoption('verbose', 2, 'most.solver', 'GUROBI');

The full set of MOST options are detailed in Section 5.2.

3.1 Continuous Single Period Problems

single deterministic multiple probabilistic

MOST stochastic stochastic

Figure 3-1: MOST Continuous Single-Period Problems

Figure 3-2: Secure Dispatch Problem Structure

Figure 3-3: Reserve Structure for Generator i

3.3 Uncertainty of Demand and Renewable Generation

single base scenario multiple base scenarios

Figure 3-4: Problem Structure with Multiple Base Scenarios

(1, 0) (1, 1) (1, 2) (j, 0) (j, 1) (j, 2) (scenarios,

Figure 3-5: Reserve Structure for Generator i in Period t

3.4 Multiple Periods

3.5 Ramping and Load Following Ramp Reserves

3.6 Storage and Deferrable Demand

central “high-probability” path

t t+1 t+2 t+3 t+4 time

Figure 3-6: Ramping and Load Following Ramp Reserves

t t+1 t+2 t+3 t+4 time

Figure 3-7: Storage

3.7 Linear Time-Varying Dynamical System

3.8 Unit Commitment

Figure 3-8: Overall Problem Structure

with integer commitment

single multi-period multi-period

Figure 3-9: MOST Mixed Integer and Multi-Period Problems

Variable and Parameter Indexing

uti Binary commitment state for unit i in period t, 1 if unit is on-line,

Constraint Functions and Parameters

g tjk (·) Nonlinear AC power flow equations in post-contingency state k

htjk (·) Transmission, voltage and other limits in post-contingency state k

Rltjk MW reserve requirement for zone l in post-contingency state k of

Cost Functions and Parameters

Cs Vector of prices by storage unit for contributions to terminal stor-

∆ Length of scheduling time slice in hours, typically 1 hour.

ψ0tjk Conditional probability of contingency k in scenario j at time t,

γt Probability of making it to period t without branching off the

β1ti . . . β5ti Storage parameters defined in (4.61) and (4.69)–(4.71) in terms

snFt i Expected stored energy in storage unit i at the end of period nt ,

p̄t Vector of expected values of ptijk across j and k at time t, condi-

4.2.1 Objective Function

where f (x) is comprised of seven components.18

f (x) = fp (p, p+ , p− ) + fz (rz ) + fr (r+ , r− ) + fδ (p)

Each part is expressed in terms of the individual optimization variables as follows.

– expected cost of active power dispatch and redispatch

– cost of zonal reserves18

– cost of endogenous contingency reserves18

– cost of load-following ramp reserves

– no load, startup and shutdown costs

Standard OPF Constraints

– fixed zonal reserve requirements

Security Constraints (Option 2): Contingency Constraints21