Questions and concerns, about proposals to shift the ~23 second dead zone within the Dispatch Interval (ICF002)

Yesterday (Sunday 6th April 2025) we wrote ‘Why we have reservations about the possible solution AEMO has been considering (to date) in ICF002’, flagging our understanding that:

1)  What appears to have been explored (at least to date) has not been initiatives that might work to shorten a ~23 second ‘dead zone’ in the dispatch process

2)  But rather just the implications of shifting it ~20 seconds earlier in time

I’ve tried to illustrate our understanding of what’s being proposed at this point in time as follows:

It’s the shift in the purplish filled area (i.e. the ‘dead zone’ referred to above) that is under active consideration, we believe.

If we’ve misunderstood something with respect to the proposed change, please do let us know ASAP … either in comments below, or more directly one-on-one?

Some initial questions about what’s been proposed

Also yesterday (Sunday 6th April) we posted that ‘There are actually several different ramp trajectories that are material to dispatch in the NEM’ (i.e. more than just two), following earlier promises.

In that article we included a sketched profile of a fictitious VRE (i.e. Semi-Scheduled) unit to highlight four different ramp trajectories – each of them used in the dispatch process.  I’ve slightly modified that image (exaggerating some things) in the following sketch to flag some questions with respect to the proposed change:

In this case, the VRE unit (roughly) follows the ‘FinalMW to Target’ trajectory until ~30 seconds prior to the end of the dispatch interval.  This fictitious case is useful to illustrate some questions we have:

1)  We’ve marked the proposed new SCADA snapshot taken at ~20 seconds prior to the dispatch interval

… surely it’s not proposed that this is the measure substituted for the ‘FinalMW’ in the dispatch interval?

(a)  i.e. the InitialMW in the next Dispatch Interval, such as in the MMS table ‘DISPATCHLOAD’.

(b)  which is used inside of NEMDE to determine the Target for the end of the dispatch interval (i.e. in conjunction with bids and ramp rate limitations, along with other constraints etc).

(c)  Because, to us, that would seem …

i.  to merely shift the exact same problem forward ~20 seconds in time

ii.  whilst also creating a mismatch between the defacto new dispatch interval (which would effectively run from 10:04:40 to 10:09:40) and the pricing interval (which would remain from 10:05 to 10:10)

2)  I’m not aware of the specific details of what’s proposed, but assume that the plan is to somehow create some new ‘Estimate for FinalMW’ data point for each unit:

(a)  e.g. by simple linear interpolation as shown in the sketch above, or some method more sophisticated;

(b)  and use this as a replacement to ‘FinalMW’ as an input into NEMDE

(c)  all the while accepting that this estimate can’t ever be a perfect replacement for what the FinalMW actually turns out to be (such as in the fictitious scenario illustrated above).

(d)  and noting that this would require two new data fields added to the MMS (e.g. in the table ‘DISPATCHLOAD’), with names such as:

i.  ‘SCADA snapshot 20 seconds from End of Interval’ a.k.a. the ‘Surely not FinalMW’ snapshot; and

ii.  ‘Estimated FinalMW’.

(e)  If this approach was taken (i.e. and the real FinalMW was retained as it currently works) then at least there’d be no flow-on implications for the AEMO’s Conformance Status processes.

… but this is just speculation on my part, as I’m not aware of detailed proposals such as this.

Please help me out … what am I missing here?

Some other initial concerns

In the first sketch above, I’ve also flagged two other timestamps that have particular relevance to participant inputs into the NEMDE dispatch process:

Concern #1)  interaction with (what would be a) shorter ‘Gate Closure #2’ for bid submission

On 5th September 2024 we published ‘A long-range trend of changing times for “Gate Closure #2”’ … in order to highlight some (very beneficial!) improvements in shortening the deadline for ‘Gate Closure #2’ with respect to volume in bid bands.

… at some point we might take an updated look at whether there’s been any substantial change in the ~7 months since that time.

Two key points in that article were that:

1)  the ‘Gate Closure #2’ was reduced to 12-13 seconds prior to the start of the dispatch interval

2)   … and that many participants had taken advantage of this by submitting more up-to-date bids for AEMO’s consideration in the NEMDE run for the next dispatch interval.

Notwithstanding a few separate concerns* we have, these changes would generally be seen as beneficial to increasing the efficiency and effectiveness of the dispatch process (such as allowing participants to take account of unit trips late in the dispatch interval, or depletion of state of charge, etc).

 * stay tuned for an article exploring ‘Should participants need to pay $10 per rebid?’ [ARTICLE TO COME] that will explore these concerns.

There are some questions we have about how it would work with the ‘Surely not FinalMW’ snapshot taken perhaps ~10 seconds before gate ‘Gate Closure #2’.

1)  For instance, what would happen if there was an automated rebid placed:

(a)  prior to ‘Gate Closure #2’ but after both …

(b)  sometime after a unit trip,

(c)  and even longer after the ‘Surely not FinalMW’ snapshot was taken?

… how realistic (and material) are scenarios such as this?

2)  Or, alternatively, would we be talking about dragging ‘Gate Closure #2’ back to the same ~23 second ‘Surely not FinalMW’ snapshot point, in order to align?

… with the loss in efficiency and effectiveness that would result

Concern #2)  interaction with (what would be a) shorter ‘Gate Closure #3’ for VRE availability forecasts

On 6th September 2024 we published ‘A year-by-year look a changing times for “Gate Closure #3”’ … in order to highlight some (very beneficial!) improvements in shortening the deadline for ‘Gate Closure #3’ with respect to UIGF for Semi-Scheduled units … coming from:

1)  AEMO’s ASEFS and AWEFS processes; but also

2)  Potentially that unit’s own Self-Forecasts.

At this point, it might be worth reminding readers that Linton previously explained ‘What inputs and processes determine a semi-scheduled unit’s availability’.

These changes meant that (from mid 2023) the ‘Gate Closure #3’ has been shortened to ~10 seconds:

1)  even a margin shorter than for ‘Gate Closure #2’

2)  which, notwithstanding the ‘Games that Self-Forecasters can play’, is a very good thing for market efficiency and effectiveness.

Assuming this is the case, then there are some questions we have about how it would work with the ‘Surely not FinalMW’ snapshot taken perhaps ~10 seconds before gate ‘Gate Closure #3’ .

1)  For instance, what would happen if there was an updated UIGF submitted:

(a)  prior to ‘Gate Closure #3’  …

(b)  but after the longer ‘Surely not FinalMW’ snapshot was taken?

… how realistic (and material) are scenarios such as this?

2)  Or, alternatively, would we be talking about dragging ‘Gate Closure #3’  back to the same ~23 second ‘Surely not FinalMW’ snapshot point, in order to align?

… surely this would end up producing less accurate UIGF for Semi-Scheduled units?