FAQ: Dispatch model

• Why are merchant revenues higher than merchant & ancillary revenues in the forecast?
• Why aren't the revenues of batteries with a 4-hour duration double that of an equivalent 2-hour duration battery?
• Are electricity import costs included in the BESS revenue forecast?
• Why is average cycling shown less than the daily limit of the scenario?
• How do we treat a cycle?
• How do you model churn within the model?
• Do you model local flexibility services?
• How do you define maximum continuous time and hourly throughput?
• How does the dispatch model decide how much volume to procure for each ancillary service?
• Do you model planned outages for BESS in the dispatch model?

Why are merchant revenues higher than merchant & ancillary revenues in the forecast?

We run our dispatch model for two strategies: merchant only - where the battery can trade across day-ahead, intraday, balancing mechanism; and merchant + ancillary - where the battery can also do frequency response services (i.e. ancillary services Dynamic Containment, Dynamic Moderation and Dynamic Regulation) for the Electricity System Operator.

There are nuances with how the timeliness of these market auctions interacts in each optimization, which means that the revenue outturn looks higher for merchant-only versus merchant + ancillary.

Day-ahead & frequency response markets are determined the day before delivery. In our model, we 'cross-optimize' these - i.e., allow the battery to participate in both at the same time (while following the rules of the services) because both auctions clear at a similar time. This mirrors reality. Intraday uplift and revenues from the Balancing Mechanism are added afterward to fit around the day-ahead position and any cycling constraints.

We do a similar thing for the merchant-only scenario but get the day-ahead position just from the forecasted day-ahead power price. Again, intraday uplift and revenues from the Balancing Mechanism are added afterward. Without locking into any ancillary services (in which contracts are awarded for 4 hours at a time), less of the battery's flexibility is locked into day-ahead contracts in the merchant-only strategy. This means it can take better advantage of those closer to real-time services (intraday and the BM), where prices are more volatile.

The meaning of all of this is that the merchant-only revenues are higher than the merchant+ancillary revenues, essentially because the BM uplift is greater in the merchant-only scenario. One way to think about this is the risk/reward. Leaving more of the battery's flexibility to more real-time markets is a riskier strategy and so is compensated with higher revenues. The day-ahead position is (mostly) blind to the revenue opportunity in the BM - because we think it's difficult to forecast at day-ahead. However, we reserve 30% of daily cycling for BM opportunity post-2027 in v3.0 of the forecast (as that is post-OBP when optimizers can be more certain of the revenue opportunity in the BM).

This is all a bit counter-intuitive because there is 'more' optionality with an additional set of markets to optimize in. However, the merchant+ancillary scenario typically has lower cycling than its merchant cousin, alongside its lower revenues. The revenue per cycle is actually pretty consistent across both - with the revenue per cycle in the merchant+ancillary strategy slightly higher across the forecast horizon.

Why aren't the revenues of batteries with a 4-hour duration double that of an equivalent 2-hour duration battery?

In wholesale, a 4-hour battery only makes double when high prices are sustained for 4 hours (and low prices for 4 hours), allowing the battery to fully discharge (and charge) during the most advantageous periods.

But, we rarely see such sustained high/low prices.

We might only see a price spike for 1 or 2 hours. A 1 or 2-hour duration battery can make the same revenues on such occasions as a 4-hour system.

Are electricity import costs included in the BESS revenue forecast?

Yes, they are.

Our dispatch model works out when to charge and when to discharge. The revenue in wholesale markets we present is the net of this position.

In our ancillary modelling, we account for the energy cost (or revenue) of importing power to be able to discharge (or charge) in response to low (or high) grid frequency. This reflects the cost of the state of charge management, and is shown in wholesale costs. Given the requirements of the particular service, we limit the state of charge in both upper and lower directions. In addition, we take into account the cost of charging in response to high grid frequency, and discharging when grid frequency is low, using historic data as an input to the expected throughput of each service.

Why is average cycling shown less than the daily limit of the scenario?

Our 2-cycle scenario shows average cycling of less than 2 cycles per day. Why?

Our cycling is limited to a maximum of 2 cycles per day (for example). It will only do this when economical - on many days, there aren't the price spreads to warrant the additional cycling. So, overall, the average comes out less than 2 per day.

The average spread that an asset captures are shown below, for a 2-cycle and 2-hour system.

We do have a 2.5 cycling scenario available in the run library, which gives an average cycling rate closer to 2.

We have no minimum threshold for cycling the battery in our optimisation, only require the action to be economical. This means any spread must at least compensate for efficiency losses in the charge/discharge action. Average revenues per cycle across the forecast horizon are shown below.

How do we treat a cycle?

One cycle is defined as the energy throughput of a battery relative to the nameplate or starting capacity of the site.
For a site that was 100MWh in capacity on day 1 of its life, one cycle is the same throughput throughout its lifetime: 100MWh. Throughput is defined as discharge energy.

So, after 7,000 cycles, that site will still discharge 100MWh to perform its 7001st cycle, even if it's now degraded down to 70% of that initial capacity and can only store 70MWh now.

Cycling is defined like this to be aligned with battery warranties.

Cycles in the forecast spreadsheets consider battery actions within the day-ahead and frequency markets. The cycling is then topped up to the maximum number of cycles permitted per day in the Balancing Mechanism (when it is profitable to cycle here).

With more and more subsidy-free wind at the back end of the forecast horizon, we find are fewer double-price spikes within a day, and more and more zero-priced days. This means that over the forecast horizon, we tend to see less cycling in the day ahead markets.

How do you model churn within the model?

Churn, or non-physical trading, is quantified via our intraday uplift: detailed here. There is also some churn within our Balancing Mechanism revenues, as positions are re-traded via accepted bids or offers. A graph showing this behavior is here.

We do a historical analysis of the uplift due to re-optimizing the day-ahead position into intraday markets, assuming perfect foresight of intraday RPD HH prices (find these on our API). We limit cycling, duration, efficiency etc, according to each scenario, and then apply the uplift to day-ahead revenues going forward within the forecast. There is a smaller uplift for assets providing frequency response, as they have more constraints on how much power they can charge or discharge at any time.

This shift of day-ahead to intraday position consists of churn, or non-physical trading. Systems are still delivering physical positions when it is profitable to do so.

Do you model local flexibility services?

Not yet.

Local flexibility services are highly locational, and usually have small contract sizes (MW). So far, two utility-scale batteries have tendered into local flex markets. While the volumes each Distribution Network Operator has procured of local flex (which might be upward or downward flexibility) has been growing, it is still quite small.

More info on local flexibility services for grid-scale battery storage here.

How do you define maximum continuous time and hourly throughput?

Maximum continuous time is the maximum duration for which a frequency response provide must be able to output its maximum contracted power, e.g. for contracted 5 MW in DCL you need to be able to export 5 MW for 15 minutes. However, this is very rare and would involve a sustained frequency deviation of 0.5 Hz.

Hourly throughput is average energy exported/imported per MW contracted in Low/High frequency response per hour. We calculate this using historical grid frequency data, and use it to quantify the battery's state-of-charge whilst it provides frequency response.

How does the dispatch model decide how much volume to procure for each ancillary service?

The dispatch model decides based on what maximises total revenues. For example, if doing a combination of ancillary services and wholesale maximises revenues, then the dispatch model will decide to procure less ancillary volume so that it has available capacity for wholesale trading. Whereas, if wholesale spreads are low then it will decide to procure greater ancillary volumes.

We also limit the maximum volume that can be procured in each ancillary service based on market saturation. The dispatch model decides how much volume to allocate, which must lie within 0 and this saturation limited maximum.

Do we model planned outages or curtailment for the BESS in the dispatch model?

In our forecast run library, we assume full availability of BESS in the dispatch model. However, when we calibrate the forecast battery revenues to real-life battery revenues, we capture the impact of all of the grid-scale batteries real-life availability (amongst other things, like perfect foresight of the forecast values in the dispatch model optimisation, and the likelihood of winning an ancillary service contract).

In custom runs, we can offer curtailment modeling. This works best if you have an idea of any restrictions on the grid connection or battery output. For example, if you know your site is planned to be out for three months next summer, we can incorporate this into our revenue projections (and you won't get any revenue for those three months).

Alternatively, the site might be subject to active network management actions in the summer months when solar output is high, preventing it from exporting power during those times. By supplying us with a profile of what that active network management profile is likely to be, we can incorporate it into the modeling.

There is a bit more info on active network management here.