Commitment Optimization Logic

The commitment optimization method in Aurora uses a mixed-integer linear program (MIP) to determine the hourly unit commitment pattern. It is a robust methodology that uses all information about the system for the time period being solved to find a solution that is guaranteed to be optimal up to an input tolerance level. This method is different from traditional Economic Commitment and Pool Commitment in that it uses an actual optimization engine as opposed to heuristics. The commitment optimization method will generally give better results than the other methods in terms of total system production cost, adherence to all commitment constraints, and incorporation of all system characteristics in the commitment decisions (e.g., network topology, outages, Operating Rules, etc.). The higher precision generally comes at the expense of longer run times over the base commitment methods. For very large systems with many commitment units, the commitment optimization method may take significantly more time to solve than the Traditional Commitment options.

The optimization solves the commitment patterns one day at a time with a Mathematical Program. Each day that is solved will include data from a user specified number of additional days to ensure that the commitment decisions adequately take into account the system constraints for upcoming hours. All information about the system is considered in the commitment decisions including demand, fuel prices, resource costs, transmission availability, and operating rules. The objective function is the minimization of system cost which includes resource start and shutdown costs, zonal wheeling charges, and all standard components of resource incremental costs. The commitment decisions use all the same information as the LP dispatch including hourly demand, zonal transfer capacities, resource availability, multi-link limits, and resource segment differentiation. The Minimum up and down times are modeled as hard constraints and minimum capacities will always be honored on commitment units. Additional constraints are automatically added for resource dependency inputs, RMR rules, and pool spinning reserve requirements.

When running with commitment optimization in the Nodal Solution, Aurora will also take into account the nodal level constraints in the mixed-integer program that performs the commitment decisions. This includes branch, corridor, and contingency constraints. In this case, instead of performing one optimization the model will iterate by successively adding the binding transmission constraints until no more constraints are violated. As such, this method does a full security constrained unit commitment (SCUC).

There are two different global ways to run the optimization. The first is with Solve Representation = System. In this case, one commitment optimization is performed for each day with a view of the whole system. For smaller footprints (e.g. ERCOT only), this is the recommended approach.

The second way to run the optimization is with Solve representation = Region, in which the commitment algorithm will solve the commitment pattern for different regions independently. This is the recommended approach for larger systems (e.g. East Interconnect) and it works differently for zonal and nodal:

Zonal: When solving a zonal study with Solve representation = Region, each pool solves its own commitment separately before the dispatch is solved as a whole system with the commitment decisions locked in place. The very first day will solve the system as a whole to get the best starting commitment pattern, so the first day may take significantly longer than subsequent days when running large systems. The representation of the system external to each pool when the commitment is determined based on the Commitment External Representation column in the Operating Pools table.

Nodal: When solving a nodal study with Solve representation = Region, the model solves the commitment for each Region (as defined in the Aggregate Area table) separately. Aurora will first solve a simplified dispatch of the system for each day to estimate power flows between regions, and then these will be used to inform the commitment solve for each Region. Once the commitment decisions have been determined, the model will solve the dispatch for each hour for the entire system with the commitment decisions fixed.

When running with multiple regions the commitment decisions for each region will be threaded, so run times will improve as more cores are available to the model. Be sure to select Use Threading in Logic on the Simulation Options form to make use of the threading capability.

When the Operating Pools table is checked in study the model will automatically add constraints for any spinning requirements that are specified there, even if the Solve representation = System. If an Operating Rules table is being used with RMR rules, these will also be added as constraints to the commitment decisions. Likewise if a Resource Dependency table is employed the dependencies will be honored whenever possible. If there are conflicting constraints, some constraints may need to be relaxed. When this occurs a warning message will appear, and detailed messaging will be written to the StudyLog output table.

Other Considerations

The more resources which are labeled as commitment resources (i.e. Non Cycling <> 0 and Must Run = 0), the longer the run times will be. If there are resources which are known to run nearly all the time, it is recommended to set those as Must Run.
If a resource has Start Costs but is not a commitment unit or a must run unit, the model will still treat it as a commitment resource and use default values when commitment parameters (min up/min down/min capacity) are not specified. The startup cost variable is part of the commitment optimization’s objective function in which the model minimizes the total system production cost. When using Commitment Optimization, all units that have startup costs but which have Non Cycling = 0 are treated as commitment units with MinUpTime=MinDownTime=1. Once the commitment decisions are made by the optimization, startup costs are not included in the Dispatch Costs and therefore will not directly affect the zonal prices.

NOTE: Because both unit commitment and dispatch must be considered to determine (and minimize) system production cost, these two functions are simultaneously solved with commitment optimization rather than sequentially solved as with the other unit commitment methods. Hence, it is possible to observe gaps in the resource stack where some units are not dispatching while others above them (i.e. more expensive dispatch cost) are dispatching (because to do otherwise would result in a higher system production cost).

Additional flexibility may be added to hydro sets using the Use Daily Optimization column in the Hydro Vectors table. In particular, the hourly hydro energy for each plant that was set in the standard hydro logic will be relaxed and only the daily hydro energy will be enforced in the dispatch. This will allow the hydro plants to respond more completely to what is happening on the system while still maintaining the daily (and monthly) hydro energy values. The instantaneous minimums and maximums will be likewise be enforced on the hourly level, though the sustained peaking limits will not be honored. In general, setting this value to true will result in a lower total system cost to serve the load on the system.
There are two limitations to Resource Dependency rules in the traditional commitment logic do not exist when running the commitment optimization. First, units can be both independent and dependent units in the expressions when using the commitment optimization. Second, dependent units can also be modeled with random outages using the convergent outage method.
There are some complex Resource Dependency configurations that are not allowed in the commitment optimization logic. These include:
- Dependencies where the Expression column contains both ‘OR’ and ‘AND’ logical operators
- Dependencies with more than one unique independent condition type specified
Ramp up and down rates can be used in conjunction with the commitment optimization. They can significantly increase the run time, though, and the user should employ them judiciously. Also, the use of ramp rates with the commitment optimization increases the complexity of the price formation logic and prices may be more difficult to back out manually. The model does an extra solve for each day when ramp rates are used to ensure that the zone prices and marginal resources in each hour are determined only by resources which are operating in that hour. Resources which generate between min and max but are binding because of ramp constraints may still be considered marginal units.
The solve for commitment will potentially vary in run time from day to day. Be sure to run for an extended period to get a clear view of what average run times will be. Look in the StudyLog to see summary reporting for the average daily “MIP times”. The following inputs will have a significant effect on overall run times:
- Number of commitment units in the system
- Sampling precision
- Solution tolerance level
- Forecast sampling level
- Dispatch days in solve
- Solve representation
- Linear commitment in look-ahead setting
Demand side curtailment resources (those with the word “demand” in the Name column) are treated differently in the commitment optimization. It is assumed that these resources are meant to dispatch only when all other available generator capability is used up, and so the commitment optimization excludes them from dispatch unless the problem would otherwise be infeasible. If the user would like these resources to dispatch purely based on economics then the word “demand” should be excluded from the name so they are treated as standard resources.
CDS references that update hourly are not compatible since commitment optimization is solving a full day at a time.

Simulation Logic

Commitment Optimization Logic