Transcript Summer ’05 work - Cornell University

An optimal day-ahead
allocation of energy and
reserve
MATPOWER and Super OPFs
August 24, 2006
Summary



MATPOWER: many small tasks that were needed to be
able to release version 3.1 beta; later, as part of an
effort to help MINOPF behave more robustly, some
changes to the FORTRAN code.
SuperOPF: Continuation of implementation work.
Since last year, most of the effort has been aimed
towards making the implementation amenable to a
higher-level unit decommitment strategy. This turned
out to be a big task. Stage 2 solver implemented as
well.
Proposal of a modification of the SuperOPF with
interesting implications and (we think) an
improvement with regards to better reflecting the
“problem that it makes sense to solve”. The analysis
of the first order optimality conditions is carried out,
highlighting the difference between the ’05 and ’06
formulations.
1. MATPOWER


Beta version 3.1 is out for testing
MINOPF changes: (a) try to guess initial
basic/nonbasic optimization variable
status to improve behavior of MINOS’
initialization procedure; (b) Changes in
allowed dimension of reduced Hessian wrt
number of optimization variables: larger
memory requirement and Hessian update
overhead in exchange for (hopefully) more
robust behavior; currently being tested.
2: Cooptimization, contingencies
The basic idea in a cooptimization setting is
to replicate the power flow equations,
adding one set of extra equations on extra
variables to represent each postcontingency load flow. Then additional
constraints can be imposed linking the
variables of the base case flow and the
variables in post-contingency load flows
for the purpose of ensuring physical
feasibility of post-contingency flows
(Thomas, Thorp & Murillo-Sanchez, 2001).
How to implement? Using islands

Network data defining nc+1 islands
in an “augmented network” is
generated from base case and
contingency data. The flow in the
kth island represents the kth postcontingency flow. The solver thinks
of it as a single large network
consisting of islands. All variables
are thus available to impose
constraints (and costs) on them.
Super OPF work Sept. ‘05 – Aug. ‘06


After leaving last year, the prototype Super OPF
underwent many changes in design, mostly to
accommodate the requirements of the existing unit
decommitment code in MATPOWER. This required
several extra layers of pre-processing of the
problem data on input, as well as undoing those
changes on output.
Example: at some point, nth-generator is considered
for decommitment, so on input its status is “0”. But
in the list of contingencies, originally there is a
contingency where that generator is taken out. The
contingency must be taken out of the list, the
corresponding post-contingency flow must not be
considered, and a complete re-arrangement of the
ordering of the islands and the optimization
variables is needed. Row pointers in contingency
spec table must be updated to reflect new row
position of items to be changed in the contingency
definition data.
… continued

There are several ways to implement the
sets of inequalities in the formulation, but
some are more friendly to MINOS than
others; in some cases MINOS quits in the
starting phase because it thinks that the
problem is infeasible. Starting point
strategies were improved both in Matlab
wrappers and in the FORTRAN code; Also,
the specific implementation of the
formulation was tweaked with aim towards
improving robustness.
SOPF2

Second stage solver implemented,
with modified formulation (later).
Currently in testing stage. This is the
solver that seemed to have more
problems in the starting phase;
solutions of first stage solver seem to
feature “tightness” in the feasible set
and MINOS sometimes struggles to
find a feasible starting linearized
subproblem.
3. Cooptimization: an evolving
concept




Islands and post-contingency flow restrictions as an approach
to security and distributed reserve allocation (2001)
Reserve as the right-hand tail; required generation range
[Gmin, Gmax]; stochastic cost; static-like symmetric
redispatch limits under contingencies; experiments (Jie Chen
’02-’03).
Two-sided reserve (needed for VAr formulation and meaningful
also for active power: loss of load contingencies), day-ahead
contract for reserve (and perhaps also power), inc and dec
costs (for signaling the reluctance to move from an operating
point, such as for nukes), receding horizon approach more
clearly articulated, dynamic vs static security more clearly
defined (2005)
A small modification is proposed now where we distinguish
between day-ahead contracted quantities and expected base
case dispatch. Two-settlement structure is implicit. Real time
OPF also looks one step ahead towards maintaining security.
Should not take more than two or three days to implement 
2005 Super OPF in words

Solve for the optimal base case
dispatch and overall reserve such
that the “intact system” state and
transitions from the intact system to
post-contingency states are feasible.
2006 Super OPF in words

Solve for the optimal contractual
allocation of energy and reserve
(least expected total cost day-ahead
strategy) such that the “intact
system” state and transitions from
the intact system to postcontingency states are feasible.





The optimal contracted quantities are not the
solution to any particular power flow!
In particular, they need not be equal to the base
case dispatch.
Older restriction that the contracted quantity
must also be a solution of the base case limits
ISO options and there may be a strategy to
exploit this (in hindsight) arbitrary restriction.
Incs and decs must also be considered for the
base case as deviations from the contracted
quantities
The variables for the contracted quantities do not
appear in the cost function directly, though the
energy objective could be written in terms of
Security-constrained dispatch of energy,
VArs, upward and downward reserve, and
expected incremental balancing dispatch wrt
contracted quantity Pc
Subject to

Power flow equations, MVA limits, PQ
curves, constant power factor
constraints etc.
Subject to (continued; only active power)
Lagrangian (active power only)
First order optimality: injections
Incs and decs
Reserve variables
Contract quantities (more later)
Sum of λ’s
Rearranging separates energy and
reserve components of nodal price
Relationship between ’05 and ’06
formulation

Relaxing Pc = Pi0 means equal
marginal incremental and
decremental costs at solution
Second stage problem



In real time, we still want to dispatch
securely. There will still be a set of
contingencies that the system should be able
to “reach”; however, the uncertainty in the
load is much smaller (although load loss
contingencies are still a possibility).
Adequacy wrt contingencies is assessed one
step into the future from the current or
expected point of operation, consistent with
a receding horizon scheme.
If desired, probabilities of contingencies may
be set to zero.
SOPF2 formulation
subject to

Power flow equations, MVA limits, PQ
curves, constant power factor
constraints etc.
subject to (continued)
With
being the quantities
contracted the previous day, which are
constants in this problem, and no reserve
SOPF2 is



More consistent with the day ahead
formulation and with the idea of receding
horizon planning
Can zero out contingency probabilities for
pricing if needed, though the sensitivity of
the Lagrangian to demand changes is still
a sum of lambdas over contingencies
It is implemented and its robustness is to
be tested. There have been issues…




If a contingency occurs, SOPF2 might not be able
to reach other contingencies from the current
operating point; that would require N-2 planning
day-ahead.
Including more extreme contingencies day-ahead
might improve chances that SOPF2 will work from
a post-contingency state.
Otherwise, additional real-time purchases may be
necessary for restoration of system security, or
the ISO can decide to operate with reduced
security temporarily by taking out some of the
considered contingencies.
But this is to be expected from a formulation that
procures only what is absolutely necessary to
guarantee system security one step ahead.