The Start Up Costs column is used to specify the startup cost ($ per MW per startup) to be recognized in the unit commitment and/or dispatch decisions for non-cycling (commitment) and cycling (dispatchable) units. The application of these startup costs vary depending on the unit commitment method employed and whether the unit is non-cycling or cycling as follows:

• Self/Econ Commit:

Non-cycling units: For units that are non-cycling, the startup costs will be included in the commitment decision and spread over the minimum up time.  If the unit is committed (can recover all the costs plus the amortized startup cost), then the dispatch cost will not include the startup cost (sunk cost).  If the unit is not committed, then the model will calculate the non-commitment penalty based upon the projected value (expected revenue minus expected variable and start costs) across the minimum up time.  The precise magnitude of this cost penalty will depend upon the logic setting indicating either an economic non-commitment penalty or fixed non-commitment penalty.

Cycling units: Cycling units that specify a startup cost are subject to specialized commitment logic (Short Term commitment logic).  For these units, the startup costs will be included in the commitment decision and spread over 4 hours. If the pre-forecast predicts that the unit will be profitable (can recover all the costs plus the amortized startup cost), then the unit will be committed and the dispatch cost will not include the startup cost (sunk cost). If the unit is not committed, then the dispatch cost will equal the incremental costs plus the full startup costs.

When using Self/Econ commitment method, the model uses Pool Commitment for the first day in the study period to derive an initial state for all commitment units since no history about the state of these units is known or assumed. See below for more information on how short term commitment units are treated in pool commitment.

Generally, when using the Self/Econ commitment method start up costs should not be applied generally to all the resources in a system

• Pool Commitment:

With pool commitment, the model does not employ separate logic for cycling units with startup costs. In other words, for all units with non-cycling=0 and with a startup costs>0, the model will impose min up and min down time constraints and treat them just like units which have a non-cycling value greater than 0.  The model uses the input Min Up and Min Down times if those are specified.  If those are not specified, it sets Min Up = 6 and Min Down = 3.  For each hour, if the unit is not committed (based on pool commitment algorithm), the dispatch cost will include the full start costs that hour.  If the pool commitment logic foresees that the unit will be needed the next hour, and it is not currently running, the dispatch cost will include the start cost divided by the Min Up time for that next hour. The dispatch cost will not include the start costs for any hours in which the unit was running the previous hour.

• Commitment Optimization:

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).

 NOTE: Inputs can be specified for any time period (annual, monthly, weekly, hourly or sub-hourly). For information on how to specify a time series for a variable, see Entering a Time Series.