Thursday 29th August 2024 was 3 weeks ago today.

… at this point, we’ve already collated a number of articles here that pertain to different market events and activities on that day … including:
(a)  High wind yield, and high curtailment;
(b)  Negative prices delivering negative Cumulative Price Threshold in VIC (followed soon after in SA).

But in this article we’re going to focus particular on just one unit (the Darlington Point Solar Farm – DUID = DARLSF1) in order to utilise a few widgets in ez2view to walk through some of the market activity on the day.

 

(A)  High level overview

Let’s start with this 3-day view prepared with the ‘Trends Engine’ in ez2view:

This view spans three sequential days, and shows various parameters relating to Darlington Point Solar Farm:

1)  Wednesday 28th August 2024, with the output bouncing up and down somewhat during the day

2)  Thursday 29th August 2024 is a particular case in point … particularly during the time-range highlighted.

3)  Friday 30th August 2024, which shows a period (10:55 to 13:10) where the output was 0MW for just over 2 hours.

If we zoom into the time-range shown, we see the following:

In this chart we’ve highlighted the time range from ~10:20 to ~13:00 in which we see the actual output repeatedly bouncing up-and-down over the 2+ hour period (i.e. the FinalMW, shown sequentially as a time-series line).

Note that:

1)  I’ve changed the formatting of this zoomed-in view of the chart for a number of the series in here so that they are (more strictly speaking) a truer reflection of the ‘each dispatch interval is unique’ nature of the way NEMDE works for some of the data sets. 

2)  I have, however, retained the ‘area’ nature of the series named ‘UIGF (step 1 – from AEMO)’ in order to show that, according to the AEMO’s own Unconstrained Intermittent Generation Forecast (i.e. UIGF), the solar resource for this Solar Farm over this period was quite consistent.

3)  At this point, readers might want to refer to Linton’s earlier article ‘What inputs and processes determine a semi-scheduled unit’s availability’ as a refresher to where what I have referred to as ‘Step 1’ and ‘Step 2’ in those charts fit (amongst other things):

Note that on each of these three days there were a fair number of Dispatch Intervals in which the Semi-Dispatch Cap (SDC) for DARLSF1 was set to TRUE, meaning that the DUID was required to adhere to the Semi-Scheduled requirements for ‘following’ Targets

…. you might like to refer to this Glossary Page about Semi-Scheduled units, particularly with respect to obligations on them following what we’ve sometimes colloquially referred to as ‘the AER Rule Change’ taking effect on 12th April 2021.

 

(B)  Some particular dispatch intervals

So with the above summary in mind, we’ll use Time-Travel in ez2view, and a couple other widgets, to look in more detail at a couple of dispatch intervals through Thursday 29th August 2024, noting the particular period of interest above (being ~10:20 to 13:00 on the day with the output jumping around like a jack-in-the-box).

(B1)  Before the period of interest (on Thu 29th Aug 2024)

To set the scene, let’s take a quick look at a few dispatch intervals (DIs), semi-randomly chosen prior to the particular period of interest:

B1a)  The 07:00 dispatch interval

At the 07:00 dispatch interval (DI), we see – via the ‘Unit Dashboard’ widget in our ez2view software – that the Solar Farm has commenced its early (late winter) morning ramp with the sunrise:

At this time, we see that:

1)  Referring to Linton’s earlier article, we see that the source of the Availability of the unit is the self-forecast* used by the unit (it has been given a name ‘DARLSF’ by the supplier of the service to the Solar Farm).

* for those interested in delving into the detail, there’s some more context about self-forecasting on this ‘Self-Forecasting’ page of the WattClarity Glossary.

2)  This availability is 6MW

3)  The unit is not constrained at this point, so:

(a)  It’s CPD Price is equal to the RRP for the region
          … noting that there’s also no Intervention at this point as well (that can be another reason why these prices might be different)

(b)  Hence, it receives a Target of 6MW

(c)  At the end of the dispatch interval, its FinalMW is 5MW

(d)  With rounding we see that the Dispatch Error is ~0MW.

4)  We see that the unit has bid its volume (limited to that 6MW availability being set by the self-forecast) down to –$1,000/MWh at the Regional Reference Node (RRN).

With this precursor in mind, let’s step further…

 

B1b)  The 08:00 dispatch interval

If we step forward an hour (to the 08:00 DI), we see that the Solar Farm has become affected by two different bound constraint equations.

We’ll drill into these constraints in a bit more detail shortly, but the key points to note are that:

1)  The two bound constraint equations combine to drive the CPD Price price for the unit down to –$1,000/MWh:

2)  The unit is still bidding all its volume down at –$1,000/MWh at the RRN.

3)  We see the unit output is being ‘constrained down’ by this effect:

(a)  The self-forecast has determined that the rising sun would allow a UIGF of 134MW (i.e. its Availability, capping the volume in the bid)

(b)  But the constraints deliver a Target of only 85MW

(c)  Because of the bound constraint, the SDC flag is TRUE … telling the unit that it needs to pay attention to its Target.

(d)  At this point, we see that the actual output (i.e. FinalMW) is 85MW

(e)  Which means a 0MW Dispatch Error.

Now, let’s talk about the two constraint equations that were bound in this dispatch interval…

 

B1c)  Looking at the ‘N_DARLSF_FLT_85’ Constraint Equation

The first constraint equation in the list is the ‘N_DARLSF_FLT_85’ Constraint Equation, so we’ll click through the hyperlink in the ez2view software to the ‘Constraint Dashboard’ widget for that particular constraint:

On the ‘Constraint Equation Dashboard’ sub-tab (above), we see the following:

1)  In this constraint equation, there is only one DUID on the left-hand side (LHS) of the constraint.

2)  So the form is 1 x Target for DARLSF1 ≤ 85MW

If we flip to the ‘Standing Data’ sub-tab (below), we see the following:

With respect to the above image, we see

1)  This constraint equation is one of the constraint equations in the ‘V-KG_WE_RC’ Constraint Set.

2)  That the constraint equation has a description (provided by the AEMO) that helps to explain its purpose:

‘Limit Darlington Pt Solar Farm upper limit to 85 MW to manage post contingent voltage oscillation’

This description is important, with respect to both:

(a)  The limit of 85MW maximum output; and

(b)  The purpose of (or need for) this limitation.

If we click through on this  hyperlink, we see the Constraint Details widget for the ‘V-KG_WE_RC’ constraint set:

On this image we see:

1)  In the table on the right:

(a)  we see that there are many constraint equations that are members of this set.

i.  Important to note that Constraint Equations are always invoked in Constraint Sets; and

ii.  Typically, Constraint Sets contain many Constraint Equations.

(b)  In the descriptions you can read, we can see that AEMO needs to limit output of many Semi-Scheduled units to manage risks of voltage oscillations and for other reasons.

(c)  Darlington Point Solar Farm is only one of those with limits (though its the only one we’re going to look at in this particular article).

2)  We see that this constraint set has a description as follows:

‘Outage = Kerang to Wemen to Red Cliffs 220 kV line section, entire line section’

3)  We see that this constraint set:

(a)  was expected to be invoked out until 17:20 on this day

(b)  it was invoked for many periods in the past (i.e. in rows below).

(c)  and, in the top row, expected again on Friday 13th September 2024 for some daylight hours.

So let’s sum up…

———- SUMMARY ————–

With respect to the ‘V-KG_WE_RC’ constraint set, and the the ‘N_DARLSF_FLT_85’ constraint equation within that, we see that:

1)  There’s an outage on the Kerang to Wemen to Red Cliffs 220kV line;

2)  As a result of this, the AEMO needs to limit the output of many Semi-Scheduled units to protect against (potentially serious) instabilities like voltage oscillations

3)  Darlington Point Solar farm is only one of these units that are limited … with the maximum output allowed determined to be 85MW.

—————————————-

 

B1d)  Looking at the ‘N^^V_CTMN_1’ Constraint Equation

The second constraint equation in the list is the ‘N^^V_CTMN_1’ Constraint Equation, so we’ll click through the hyperlink in the ez2view software to the ‘Constraint Dashboard’ widget for that particular constraint:

On the ‘Constraint Equation Dashboard’ sub-tab (above), we see the following:

1)  LHS of this constraint is much more complex, with many DUIDs listed

2)  Of particular interest is that there are some units highlighted, including DARLSF1 which:

(a)  Have negative LHS Factors … which, with reference to the ≤ form of this constraint, means that this particular constraint equation would be trying to ‘constrain up’ the output of these units;

(b)  Yet the units highlighted (all Semi-Scheduled) are being ‘constrained down’ to below their Availability (seen in the pink colour in their bars)

i.  presumably by other constraints

ii.  such as  the ‘N_DARLSF_FLT_85’ constraint equation for DARLSF1 (and similar for the others)

3)  We can see that all 5 of these units have bid down to –$1,000/MWh:

(a)   to try to get around this constraint;

… some call this ‘disorderly bidding’

(b)  but the CPD Price is down at –$1,000MW also

… meaning a limitation on output.

(c)  in this case for DARLSF1, to only 85MW for the reasons already noted above.

4)  Also visible in this window are other units with spare capacity (like the Snowy Hydro units, and Uranquinty) which are not being dispatched at all

(a)  This is also shown in pink (where Availability > Target)

(b)  But in this case we see the ‘Next MW (G)’ column shows that their volume is just priced ‘out of the money’ in the relevant region.

If we flip to the ‘Plain English Translation’ sub-tab (below), we see the following:

I’ve highlighted the form of the RHS used in dispatch.  The important points for the reader here are that:

1)  The RHS is typically not of linear form … and are often quite complex

2)  It contains things that NEMDE can’t control (i.e. in terms of setting Dispatch Targets)

3)  Rather reflects the state of the network at the start of the dispatch interval.

If we flip to the ‘Standing Data’ sub-tab (below), we see the following:

With respect to the above image, we see

1)  This constraint equation is one of the constraint equations in the ‘N-CTMN_4_WG_CLOSE’ constraint set.

2)  That the constraint equation has a description (provided by the AEMO) that helps to explain its purpose:

‘Out = Collector – Marulan (4) or Collector – Yass (3L) or Marulan – Yass (5), avoid voltage collapse at Southern NSW for loss of the largest Vic generating unit or Basslink’

If we click through on this  hyperlink, we see the Constraint Details widget for the ‘N-CTMN_4_WG_CLOSE’ constraint set:

On this image we see:

1)  In the table on the right:

(a)  we see that there are many constraint equations that are members of this set.

i.  Remember that Constraint Equations are always invoked in Constraint Sets; and

ii.  Typically, Constraint Sets contain many Constraint Equations.

(b)  We’ve highlighted the constraint equation at the top of the list as the only constraint equation currently bound (i.e. 0MW headroom and/or non-zero Marginal Value).

2)  We see that this constraint set has a description as follows:

‘Out = Collector – Marulan (4) 330kV line [Wagga-Yass 132kV parallel lines CLOSED]’

3)  We see that this constraint set:

(a)  was expected to be invoked out until 16:25 on this day … after starting on 14th August 2024.

(b)  was not invoked in any prior period (i.e. in rows below).

(c)  and, above that, no future outages planned (at that point in time).

So let’s sum up…

———- SUMMARY ————–

With respect to the ‘N-CTMN_4_WG_CLOSE’ constraint set, and the the ‘N^^V_CTMN_1’ constraint equation within that, we see that:

1)  There’s an outage on the Collector to Marulan 330kV line (which TransGrid refers to as line 4);

2)  As a result of this, there are many constraint equations invoked in the set … we have only looked at one of them

3)  Because Darlington Point Solar farm has a negative factor on the LHS of this constraint, in its own right this constraint would be seeking to ‘constrain up’ the output of Darlington Point Solar Farm (amonst others)

4)  But we know that, by virtue of the the ‘V-KG_WE_RC’ constraint set above, the output of Darlington Point

—————————————-

 

 

(B2)  During the period of interest (on Thu 29th Aug 2024)

So a key question for readers might be … if it was so important for the AEMO that the output of Darlington Point Solar Farm should be limited to a maximum of 85MW output, how come the output frequently jumped well above that for discrete dispatch intervals?

That’s what we’ll explore here ….

B2a)  Cycle #1 (10:25 and 10:30)

We noted above that the period of interest began at ~10:20  … so if we wind the clock forward on this 5-widget-window forward to 10:25 we see the following:

With respect to this image we see it’s not too much different, in principle, to the snapshot shown above for 08:00.  The key points to highlight are that:

1)  The source of the Availability is the self-forecast

2)  The self-forecast is setting the availability to be 223MW

… we see the dotted red line on the bid chart showing an understandable solar resource availability profile for winter

3)  As a result:

(a)  The SDC flag is true;

(b)  The CPD Price is 1 cent under –$1,000/MWh

(c)  Bidding is still down at –$1,000/MWh

… incidentally this is still the ‘Initial Bid’ submitted at 12:03 some days earlier on 15th August

(d)  Unit output is capped with Target = 85MW

(e)  Which is matched with output

4)  For interest sake, note that the ‘N^^V_CTMN_1’ constraint equation is no longer bound.

 

So, in summary, at 10:25 it’s all well and good.  But if we step to 10:30 things start to go awry:

The key points to highlight are that:

1)  First and foremost, the most important thing to notice is that the Actual Output of the unit has ramped up to be 221MW (i.e. FinalMW) at the end of the Dispatch Interval.

(a)  which is obviously well above what we know to be the AEMO’s intent to have the unit capped at 85MW;

(b)  But why was that the case? We’ll see in the following…

2)  In this case, the self-forecast has (for reasons unknown*) dropped the UIGF to be (only) 84MW in this dispatch interval

* noting that there’s no requirement to submit anything akin to a rebid reasons via the self-forecasting process.

(a)  We don’t know why this was the case;

i.   Though, as per this warning here from some years ago, that’s not going to stop some readers speculating at possible causes and/or motives;

ii.  For instance (and here be speculation!) perhaps some gremlin in the works has flipped the self-forecast to be based on persistence (i.e. based on what the actual output was at 10:25).

(b)  But it is easer (and less contentious) to see the effect that this has …

3)  With Availability only 84MW, then NEMDE says (acknowledging that the ‘N_DARLSF_FLT_85’ constraint equation will limit Target to a maximum of 85MW):

(a)  Effectively says ‘well, I’ll have all of that low-priced energy!’

(b)  Because the Target (84MW) is less than 85MW the SDC flag changes to FALSE;

(c)  Which seems to unblock the dispatch system for the plant

i.  With the net effect that the unit ramps up to 221MW;

ii.  Which is obviously:

1.  Well above the 84MW which the self-forecast said was its capability;

2.  And also well above the 85MW limit which the AEMO is seeking to maintain to protect the grid from the risk of voltage oscillations!

3.  A major (and unexpected) Dispatch Error of –137MW

Yikes?!

 

B2b)  Cycle #2 (10:35 and 10:40)

Stepping forward to 10:35 (i.e. 5 minutes forward) we see the cycle begin to repeat:

We see:

1)  That the self-forecast sets the UIGF, and hence the Availability, at 211MW (not far below the 221MW FinalMW from the prior interval)

2)  NEMDE then uses this to:

(a)  Set a target at 85MW; and

(b)  Switch the SDC flag to TRUE;

3)  As a result of which the dispatch system onsite ramps the plant down to 87MW (a small Dispatch Error of -2MW).

But step forward to 10:40 and those gremlins are at work again!

We see:

1)  That the self-forecast sets the UIGF, and hence the Availability, at 74MW (again for unknown reasons)

2)  NEMDE then uses this to:

(a)  Set a target at 74MW; and

(b)  Switch the SDC flag to FALSE;

3)  As a result of which the dispatch system onsite is unblocked, and the unit output balloons to 220MW (a major Dispatch Error of -146MW).

We can almost visualise the question marks occurring in various control rooms….

 

B2b)  Cycle #3 (10:45 and 10:50)

Stepping forward to 10:45 (i.e. 5 minutes forward) we see the cycle re-occur, but with a difference:

We see:

1)  That the self-forecast sets the UIGF, and hence the Availability, at 213MW.

2)  NEMDE then uses this to:

(a)  Set a target at 85MW; and

(b)  Switch the SDC flag to TRUE;

3)  As a result of which the dispatch system onsite ramps the plant down to 87MW (a small Dispatch Error of -2MW).

4)  Notable here is that (for the first time today) we see a rebid received by AEMO at ~10:38:

(a)  The rebid reason (i.e. ‘NSW1 5MIN PD RRP FOR 1055 ($-44.99) PUBLISHED AT 1036 IS $38.69 LOWER THAN 5MIN PD RRP PUBLISHED AT 1020 ($-6.3)’) suggests it’s come from some auto-bidder:

i.  Those with access to our major GenInsights21 report will recall how (in Appendix 22) we identified about a dozen different (internally or externally-developed) technology-enhanced bid submission systems in the NEM.

…. note that we’re not one of them!

ii.  However, in this instance, the rebid reason does not really help us understand:

1.   why this is the first rebid for the day; and

2.  whether the timing has any relation to the emergence of the gremlins in the self-forecasting process?

(b)  But in the Bid Details view shown below, we see that the unit has moved volume from the –$1,000/MWh bid band at the RRN up to the –$57.01/MWh bid band at the RRN

(c)  But note that this this change does not take effect in the 10:55 dispatch interval (as there’s no change of volume for 10:50, for reasons that have not been explored).

 

Keeping this in mind, we step forward to 10:50 and those same gremlins in the Self-Forecast are at work again!

We see:

1)  That the self-forecast sets the UIGF, and hence the Availability, at 78MW (again for unknown reasons)

2)  NEMDE then uses this to:

(a)  Set a target at 78MW; and

(b)  Switch the SDC flag to FALSE;

3)  As a result of which the dispatch system onsite is unblocked, and the unit output balloons to 218MW (a major Dispatch Error of -146MW).

4)  Readers should note here that:

(a)  the rebid submitted earlier (and illustrated above) was overwritten by one the AEMO received at 10:43 … so before Gate Closure #2 and able to be taken into account for the 10:50 dispatch run

(b)  but this second rebid had no effect;

i.  this was even though the capacity is now offered at (the higher) –$57.01/MWh,

ii.  because this bid band is below the CPD Price

iii.  and the CPD Price has risen because the ‘N_DARLSF_FLT_85’ constraint equation is unbound

(c)  ultimately ‘the problem’ was not in the bid or rebid, but rather the gremlin in the Self-Forecast!

We can almost visualise the heart rate rising higher, and brows furrowing, in various control rooms….

 

B2c)  Cycle #4 to Cycle #13 (another 10) skipped

We’ll skip through another 10 cycles of much the same iterations … I’ve not looked in detail but it seems that there were the same gremlins in the Self-Forecast as the ultimate ‘culprit’ to the oscillations … which we presume would have been causing consternation at the Generator and also  in the AEMO control rooms?

 

B2d)  Cycle #14 (12:45 and 12:50)

So we land at the 12:45 for the last cycle of the day:

We see:

1)  That the self-forecast sets the UIGF, and hence the Availability, at 213MW.

2)  NEMDE then uses this to:

(a)  Set a target at 85MW; and

(b)  Switch the SDC flag to TRUE;

3)  As a result of which the dispatch system onsite ramps the plant down to 87MW (a small Dispatch Error of -2MW).

We skip forward to 12:50 and those same gremlins in the Self-Forecast are at work again!

We see:

1)  That the self-forecast sets the UIGF, and hence the Availability, at 78MW (again for unknown reasons)

2)  NEMDE then uses this to:

(a)  Set a target at 78MW; and

(b)  Switch the SDC flag to FALSE;

3)  As a result of which the dispatch system onsite is unblocked, and the unit output balloons to 218MW (a major Dispatch Error of -146MW).

4)  Readers should note here that:

(a)  the rebid submitted earlier was overwritten by one the AEMO received at 10:43 … so before Gate Closure #2 and able to be taken into account

(b)  but this second rebid had no effect;

i.  this was even though the capacity is now offered at (the higher) –$57.01/MWh,

ii.  because this bid band is below the CPD Price

iii.  and the CPD Price has risen because the ‘N_DARLSF_FLT_85’ constraint equation is unbound

(c)  ultimately ‘the problem’ was not in the bid or rebid, but rather the gremlin in the Self-Forecast!

 

(B3)  After the period of interest (on Thu 29th Aug 2024)

We skip forward to 12:55 and see – via the ‘Unit Dashboard’ widget in our ez2view software – how the saw-tooth output profile over the past ~2 hours has delivered 14 oscillations.  We wonder if this the start of another cycle…

… but notably (as highlighted on the image) we see that the source of the UIGF has switched* from the Self-Forecast (used at 12:50) to the AEMO’s ASEFS system (at 12:55).

*  I’ve not invested time, at this point, to ascertain whether this was a self-suppression of the self-forecast or an AEMO suppression.  Something, perhaps, for Part 2 of this Case Study?

Let’s step forward another 5 minutes, to 13:00, to verify that the oscillations have ceased:

We see that AEMO’s ASEFS forecast persists as the source of the Availability … as indeed it does out until the 17:10 dispatch interval, which is shown below:

 

Whew!

 

(B4)  The next day (on Fri 30th Aug 2024)

In the first trend chart above, we see that on Friday 30th August 2024 there was a period (10:55 to 13:10) where the output was 0MW for just over 2 hours.

Curiosity makes me take a quick look at the 13:00 dispatch interval on the following day (i.e. 24 hours after the last snapshot above):

In this case we see that:

1)  With the dotted red line, we do see the Availability has been jumping up and down a bit through this day as well;

2)  But the unit output has been down at 0MW consistently through the prior ~2 hours; and

3)  In the case of this particular dispatch interval, it’s a different constraint equation that’s bound.

Clicking through to the ‘N::N_CTMN_2’ constraint equation in the ‘Constraint Dashboard’ widget we see the following:

In summary, the DARLSF1 unit has been ‘constrained off’ by virtue of the CPD Price (-$57.49/MWh at the RRN) being below it’s bid price (-$52.04/MWh at the RRN).

… but note that I have not looked at any other Dispatch Intervals.

 

(C)  Summing up

What appears to have happened on that day is (for reasons unknown) some gremlin has imposed itself on the self-forecasting system to deliver a (clearly erroneous) UIGF that both:

1)  Significantly understated the output capability of the plant;

2)  Whilst, at the time, being just low enough (i.e. below the 85MW stability limit AEMO was seeking to impose) to ‘unblock’ the SDC and allow the output to balloon way up, well beyond the level of output AEMO was seeking to maintain in its constraint equation.

3)  It appears to have taken 14 cycles over a little over 2 hours to sort this problem out and bring it back under control.

… as a PS to the article we can add …

4)  clarifying, for those perhaps not so familiar, there’s a few differences between the oscillations that unfolded on Thursday 29th August compared with the oscillations that AEMO was seeking to prevent via the constraints on DARLSF1 and others – including:

(a)  The AEMO was seeking to prevent oscillations in voltage and the oscillations that occurred were with respect to output

(b)  The time-scale of the oscillations was potentially quite different – on a 5-minute dispatch interval basis for output, but potentially on much smaller time-steps for voltage (remembering Stephen Wilson’s explanation that the NEM works on many different timescales concurrently).

(c)  The oscillations in output actually happened, whereas the oscillations in voltage only might have occurred in the event of some contingency occurring

(d)  and so on…

 

 

That’s where we’ll leave this for now… (until Part 2, perhaps?)