Balancing Markets
Contents
- Introduction
- Balancing Generation Offers
- Linking day ahead and Balancing Market Solutions
- Handling Different Horizon Resolutions
- Pumped Storage Offers and Bids
- Interleaved Run Mode
1. Introduction
In a balancing (or real-time) market, generators define their dispatch level from a day-ahead market using the properties Generator Offer Base (for Generation) and Pump Bid Base (for Pump Load). The goal of the balancing process is then to select optimal increments (incr) and decrements (decr) around these day-ahead positions to meet deviations in the real-time load (which may be higher or lower than the load that defined the day-ahead positions).
2. Balancing Generation Offers
The input pairs Generator Offer Quantity, and Offer Price are used to define the incr and decr offers. Positive quantities are interpreted as offers to increment the generator's dispatch above the base quantity, while negative quantities are interpreted as offers to decrement the generator's dispatch. The impact on the system is the product of the inc/dec and the offer price, thus an inc with a positive price increases cost accordingly and a dec with a positive offer price, decreases system cost. To prevent dec bids below a certain point (such as Min Stable Level), use a negative offer price with dec bids to create an increase in system cost for a dec in the specified range.
Generally the first offer band equals the day-ahead generation (Offer Base) with a price equal to the negative of the incremental cost of generation to that point. Subsequent bands are priced at the incremental cost of moving the generation above the Offer Base.
Note that Offer Price is usually positive for both incr and decr parts of the offer, except in cases where negative offer prices are being used to keep generation above Min Stable Level.
Example
The following shows a balancing market offer with a 200MW generator with a day-ahead generation of 100MW and Min Stable Level of 80MW.
| Property | Value | Units | Band |
|---|---|---|---|
| Max Capacity | 200 | MW | 1 |
| Min Stable Level | 80 | MW | 1 |
| Offer Base | 100 | MW | 1 |
| Offer Quantity | -80 | MW | 1 |
| Offer Quantity | -20 | MW | 2 |
| Offer Quantity | 80 | MW | 3 |
| Offer Quantity | 20 | MW | 4 |
| Offer Price | -9999 | $/MWh | 1 |
| Offer Price | 28 | $/MWh | 2 |
| Offer Price | 30 | $/MWh | 3 |
| Offer Price | 9999 | $/MWh | 4 |
In this example the generator has a day-ahead Generation of 100 MW. If the system chooses to dispatch the generator at 100 MW it incurs zero Cleared Offer Cost, but if it increments the generator dispatch, it pays the prices defined by the positive offer quantities i.e. the first megawatt increment would cost $30 for up to 80MW, then $9999 above that to the Max Capacity. However, if the system chooses to decrement the generation it is paid the prices associated with the negative quantities i.e. the first megawatt decrement earns the system $28, and this price holds for decrements up to 20MW, below which the system must pay $9999 per unit of decrement (since the decrement bid price is negative).
Thus, in this scheme, incr offers are cleared from lowest priced to highest priced, while decr offers are cleared highest priced to lowest (as if the day-ahead dispatch were being 'unwound').
3. Linking Day ahead and Balancing market Solutions
The simulator provides a means for the solution of one Model to act as input for subsequent Models via the Data File class. This is particularly useful for modelling balancing (or real-time) markets because it allows the Generation and other solution values to be passed from the day-ahead simulation to the real-time simulation without any manual intervention or data processing.
The data are passed between simulations using text files written when the Report Write Flat File option is set. For the day-ahead Model select all the outputs that will act as inputs to the real-time simulation. These might include:
The Model will then write out these files into a folder structure. The interval solution values e.g. period-by-period Generation appear in the files:
Model DA Solution\interval\ST Generator(*).Generation.csv
where "DA" is an example Model name, and the * represents the numeric index of each Generator in the system.
Generator names are not used to name these files and instead the index must be looked-up in the reference file "id2name.csv" which is created in the root of the text solution folder. It would be time consuming to do this look-up every time you wanted to pass solution data to another model, so instead the Write Flat File class supports the wildcard syntax in the Filename field directly, allowing you to 'point' to the day-ahead solution files with a single line of input.
Example
The following Data File definitions link to the "DA" Model solution:
| Data File | Property | Value | Units | Band | Filename |
|---|---|---|---|---|---|
| Available Capacity | Filename | 0 | - | 1 | Model DA Solution\interval\ST Generator(*).Available Capacity.csv |
| Generation | Filename | 0 | - | 1 | Model DA Solution\interval\ST Generator(*).Generation.csv |
| Price Received | Filename | 0 | - | 1 | Model DA Solution\interval\ST Generator(*).Price Received.csv |
| Pump Load | Filename | 0 | - | 1 | Model DA Solution\interval\ST Generator(*).Pump Load.csv |
| Undispatched Capacity | Filename | 0 | - | 1 | Model DA Solution\interval\ST Generator(*).Undispatched Capacity.csv |
| SRMC | Filename | 0 | - | 1 | Model DA Solution\interval\ST Generator(*).SRMC.csv |
The these can be applied as input to the real-time thus:
| Generator | Property | Value | Units | Band | Data Files | Scenario | Memo |
|---|---|---|---|---|---|---|---|
| Coal | Offer Base | 0 | MW | 1 | Generation | RT Offers & Bids | - |
| Coal | Offer Quantity | 0 | MW | 1 | Generation | RT Offers & Bids | - |
| Coal | Offer Base | 0 | MW | 2 | Undispatched Quantity | RT Offers & Bids | - |
| Coal | Offer QuantityScalar | -1 | MW | 1 | - | RT Offers & Bids | Negate to create dec offer |
| Coal | Offer Quantity Scalar | 1 | MW | 2 | - | RT Offers & Bids | OK to omit, this is default value |
| Coal | Offer Price | 0 | $/MWh | 1 | SRMC | RT Offers & Bids | - |
| Coal | Offer Price | 0 | $/MWh | 2 | SRMC | RT Offers & Bids | - |
| Coal | Offer Price Scalar | 1 | $/MWh | 1 | - | RT Offers & Bids | OK to omit, this is default value |
| Coal | Offer Price Scalar | 1.01 | $/MWh | 2 | - | RT Offers & Bids | Increase inc prices by 1% over SRMC |
| Gas | Offer Base | 0 | MW | 1 | Generation | RT Offers & Bids | - |
| Gas | Offer Quantity | 0 | MW | 1 | Generation | RT Offers & Bids | - |
| Gas | Offer Quantity | 0 | MW | 2 | Undispatched Capacity | RT Offers & Bids | - |
| Gas | Offer Quantity Scalar | -1 | MW | 1 | - | RT Offers & Bids | Negate to create dec offer |
| Gas | Offer Quantity Scalar | 1 | MW | 2 | - | RT Offers & Bids | OK to omit, this is default value |
| Gas | Offer Price | 0 | $/MWh | 1 | SRMC | RT Offers & Bids | - |
| Gas | Offer Price | 0 | $/MWh | 2 | SRMC | RT Offers & Bids | - |
| Gas | Offer Price Scalar | 1 | $/MWh | 1 | - | RT Offers & Bids | OK to omit, this is default value |
| Gas | Offer Price Scalar | 1.01 | $/MWh | 2 | - | RT Offers & Bids | Increase inc prices by 1% over SRMC |
This example uses the properties offer quantity scalar and offer price scalar to convert the data file input data to the desired offer table. For both generators "coal" and "gas", band 1 represents dec offers and the generation data is multiplied using the offer quantity scalar -1. Band 2 represents inc offers and the offer price scalar is used to increase the day ahead prices (data file SRMC) by 1%.
4. Handling Different Horizon Resolutions
Where the day-ahead market is simulated at a different resolution to the real-time market, the text data passed between the models are automatically upscaled or downscaled. The method used for up/downscaling can be controlled by the Data File Upscaling Method, when increasing the resolution in real-time compared to day-ahead, vice versa for Downscaling Method. If these are not defined then the method is chosen that best suits the property e.g. Generator Commit is upscaled using the "Step" method, whereas Fixed Load is upscaled using the "Interpolate" method.
5. Pumped Storage Offers and Bids
Pumped storage generation can be modelled in balancing markets by treating it as an equivalent thermal resource. Offer Base represents Generation while Pump Bid Base represents Pump Load. The Offer Price of pumped storage generation is equal to the Price Received in the day-ahead solution and similarly the Pump Bid Price for load is also equal to the Price Received in day-ahead.
Example
| Property | Value | Units | Band | Data File | Scenario | Memo |
|---|---|---|---|---|---|---|
| Offer Base | 0 | MW | 1 | Generation | RT Offers & Bids | The DA Generation |
| Offer Quantity | 0 | MW | 1 | Generation | RT Offers & Bids | The DA Generation as a decrement "offer"(bid) |
| Offer Quantity | 0 | MW | 2 | Undispatched Capacity | RT Offers & Bids | The remaining undispatched generation |
| Offer Quantity Scalar | -1 | MW | 1 | - | RT Offers & Bids | Negate to create dec offer |
| Offer Quantity Scalar | 1 | MW | 2 | Generation | RT Offers & Bids | OK to omit, default value |
| Offer Price | 0 | $/MWh | 1 | Price Received | RT Offers & Bids | The price at which pump generation was dispatched DA |
| Offer Price | 0 | $/MWh | 2 | Price Received | RT Offers & Bids | Offered just above the DA price |
| Offer Price Scalar | 1 | $/MWh | 1 | - | RT Offers & Bids | OK to omit, default value |
| Offer Price Scalar | 1.01 | $/MWh | 2 | - | RT Offers & Bids | Increase inc offers by 1% over DA bids |
| Pump Bid Base | 0 | MW | 1 | Pump Load | RT Offers & Bids | The DA pump load |
| Pump Bid Quantity | 0 | MW | 1 | Pump Load | RT Offers & Bids | The DA pump load as a decrement "bid" (offer) |
| Pump Bid Quantity | 0 | MW | 2 | Available Capacity | RT Offers & Bids | The remaining undispatched pump load |
| Pump Bid Quantity Scalar | -1 | MW | 1 | - | RT Offers & Bids | Negate to create dec offers |
| Pump Bid Quantity Scalar | 1 | MW | 2 | - | RT Offers & Bids | OK to omit, default value |
| Pump Bid Price | 0 | $/MWh | 1 | Price Received | RT Offers & Bids | The price at which pump load was dispatched DA |
| Pump Bid Price | 0 | $/MWh | 2 | Price Received | RT Offers & Bids | Bid just below the DA price |
| Pump Bid Price Scalar | 1 | $/MWh | 1 | - | RT Offers & Bids | OK to omit, default value |
| Pump Bid Price | 0.99 | $/MWh | 2 | - | RT Offers & Bids | Decrease bid price by 1% |
In this scheme where day-ahead prices are used as offer/bid prices for pumped storage, it is sensible to remove any restrictions on the pumped storage End Volume so that the real-time storage can move freely to balance the system.
Example
| Storage | Property | Value | Units | Bands | Scenario | Memo |
|---|---|---|---|---|---|---|
| Head | End Effects Method | 0 | - | 1 | DA | DA enforces storage recycling |
| Head | End Effects Method | 1 | - | 1 | RT | Allow RT storage to change from DA |
| Head | Enforce Bounds | -1 | YES/NO | 1 | DA | DA enforces storage recycling |
| Head | Enforce Bounds | 0 | YES/NO | 1 | RT | Allow RT storage to drift outside bounds |
| Tail | End Effects Method | 0 | - | 1 | DA | DA enforces storage recycling |
| Tail | End Effects Method | 1 | - | 1 | RT | Allow RT storage to change from DA |
| Tail | Enforce Bounds | -1 | YES/NO | 1 | DA | DA enforces storage recycling |
| Tail | Enforce Bounds | 0 | YES/NO | 1 | RT | Allow RT storage to drift outside bounds |
Here the End Effects Method is set to "free" in the real-time, meaning the Storage End Volume can deviate from the day-ahead solution if it is optimal for balancing.
6. Interleaved Run Mode
An issue with running the "DA" Model followed in sequence by the "RT" Model is that the day-ahead decisions do not reflect the outcome of the real-time in that the initial conditions for generation and storage (in particular) for each day of the "day-ahead" Model are based on the previous day-ahead solution not those from the real-time. Interleaved run mode addresses this problem by running both "DA" and "RT" Models interleaved, with initial conditions being passed back automatically from "RT" to "DA". This sophisticated run method is described further in the Model class and illustrated in Figure 1.
Figure 1: Interleaved Run Mode
NOTE: A restriction of the Interleaved run mode is that you cannot apply Escalator objects to any data that will be passed between "DA" and "RT". A work-around is to use the properties Generator Offer Quantity Scalar, Offer Price Scalar for generation offers, and Pump Bid Quantity Scalar, Pump Bid Price Scalar to perform the multiplication as in the following example, which is equivalent to the previous example but without the need for Escalator objects:
| Property | Value | Units | Band | Data File | Scenario | Memo |
|---|---|---|---|---|---|---|
| Offer Base | 0 | MW | 1 | Generation | RT Offers & Bids | The DA generation |
| Offer Quantity | 0 | MW | 1 | Generation | RT Offers & Bids | The DA generation as a decrement "offer"(bid) |
| Offer Quantity | 0 | MW | 2 | Undispatched Capacity | RT Offers & Bids | The remaining undispatched generation |
| Offer Price | 0 | $/MWh | 1 | Price Received | RT Offers & Bids | The price at which pump generation was dispatched DA |
| Offer Price | 0 | $/MWh | 2 | Price Received | RT Offers & Bids | Offered just above the DA price |
| Offer Quantity Scalar | -1 | - | 1 | - | RT Offers & Bids | - |
| Offer Quantity Scalar | 1.01 | - | 2 | - | RT Offers & Bids | - |
| Pump Bid Base | 0 | MW | 1 | Pump Load | RT Offers & Bids | The DA pump load |
| Pump Bid Quantity | 0 | MW | 2 | Available Capacity | RT Offers & Bids | The remaining undispatched pump load |
| Pump Bid Price | 0 | $/MWh | 1 | Price Received | RT Offers & Bids | The price at which pump load was dispatched DA |
| Pump Bid Price | 0 | $/MWh | 2 | Price Received | RT Offers & Bids | Bid just below the DA price |
| Pump Bid Quantity Scalar | -1 | - | 1 | - | RT Offers & Bids | - |
| Pump Bid Price Scalar | 0.99 | - | 2 | - | RT Offers & Bids | - |