It was now just over 5 years ago when Marcelle wrote ‘Not as simple as it appears – estimating curtailment of renewable generation’ … and since that time:

• We’ve seen an increasing number of commentators writing about curtailment, particularly of Semi-Scheduled VRE;
  • But I still wonder whether some of the caveats evoked by Marcelle are properly understood.
• We’ve also seen an increasing number of participants operating Semi-Scheduled assets in the NEM
  • including some via self-forecasts
    • … with a subset of these appearing to engage in ‘games that self-forecasters can play’
    • though readers should note – I’m not implying any such games in this example …
    • with these examples perhaps more ‘just’ being insufficient sophistication in some self-forecast models?
  • with some appearing to slip up with reference to various AEMO procedures and handbooks.

So I thought I’d use the example of the ‘N-DPWG_63_X5’ constraint set that was invoked for a ~24 hour period (to do with the recent ‘Unplanned outage of Darlington Point – Wagga No.63 330 kV line’) to take a look at a couple of things,

Background

In yesterday’s article we used an ez2view snapshot that looked particularly at the 16:10 dispatch interval on Tuesday 24th June 2025.

So in this first snapshot in this article, we’ll use the ‘Constraint Equations’ widget in ez2view that is:

• Time-travelled to the same point yesterday; and
• Filtered down to show just the constraint equations invoked inside of the ‘N-DPWG_63_X5’ constraint set.

The image is a bit busy, but has been included to highlight three things:

1)  Firstly, there were 103 constraint equations invoked (or scheduled to be invoked in the limited predispatch period) within the ‘N-DPWG_63_X5’ constraint set.

… in this view we are showing only 60

(a)  users can configure under the ‘cog’ icon

(b)  in this view there are 6 rows of 10 columns, which is enough to show the 2nd point…

2)  Note that (as highlighted) there are two different constraint equations speaking to Sunraysia Solar Farm

… and also pairs of constraints for numerous other inverter-based units as well.

3)  Thirdly (and this is important), there were only 3 constraint equations bound with a non-zero Marginal Value in this view

… but there are many more than that constraint equations that were actively limiting output …

(a)  even though they are not bound

(b)  which is part of what Marcelle explained in her article 5 years ago.

(at least) 4 different issues!

In this article, we’ll briefly touch on two related issues that analysts need to be aware of, in correct interpretation of the MMS data in relation to what’s actually happening on the grid.

Issue #1 … the hidden curtailment

Taking the ‘Bids & Offers’ widget in ez2view from 10:15 this morning (Wednesday 25th June 2025) and looking back 7 days we see that the data suggests (i.e. in the lower shape of availability) that there might have been cloud cover suppressing solar availability on Tuesday 24th June 2025

… but that might be a fully false inference (it’s certainly misleading, to some extent).

Let’s create a power filter in ez2view that’s constructed as follows:

… with the 10 x DUIDs chosen there all being Solar Farm DUIDs that were affected by the twin set of constraint equations (in a similar way as what was noted above for SUNRSF1).  Applying this filter, we see a different picture for this sub-set of NSW solar farm units:

Note that:

1)  A ‘fully following AEMO processes’ picture would have shown 0MW available through the entirety of the day

2)  Because these 10 x Solar Farms all have 0 inverters available in aggregate

… and that’s required (for system security reasons) due to the Unplanned outage of Darlington Point – Wagga No.63 330 kV line

3)  Analysts should be aware that this ‘invisible curtailment’ is actually spilled energy … it’s not because of some very specific dense cloud cover over these specific solar farms

4)  But the picture is not a ‘perfect’ picture

… because of Issue #2.

Issue #2 … self-forecasters ignoring ELAV=0, to produce a non-sensical UIGF

In this case we’ll briefly flag that one particular unit that appears to:

1)  Have a self-forecast deployed on the unit;

2)  But where the self-forecast seems to ignore the fact that Elements Available (i.e. ELAV, which in this case is number of inverters) is set at 0;

3)  … thereafter producing a nonsensical non-zero number for the UIGF.

(i.e. if there are no inverters available (by instruction of the TNSP and/or AEMO), how would it be possible for a solar farm to produce any output?)

First, spot-checking the AEMO processes

In the image below, we sample one page each out of the following AEMO documents:

1)  we take p5/15 from the AEMO ‘Semi-Scheduled Generation Dispatch Self-Forecast – Assessment Procedure’ from 7th August 2023, and highlight the sentences:

‘The participant dispatch SF must be capped at all local limits that are forecast to apply at the end of the next dispatch interval. These are defined under “SCADA Local Limit” in the relevant ECM.

The participant dispatch SF must not be negative and must not exceed the generating unit’s registered Maximum Capacity’

… and then we follow the links in footnote 1 to the following…

2)  we see p11/24 of the AEMO’s ‘NEM Operational Forecasting and Dispatch Handbook for wind and solar generators’ from Month 2023 and highlight the following:

‘The intermittent generation availability information entered in the Production Markets Portal (or submitted via API) is used to produce the UIGF in the pre-dispatch, PDPASA and STPASA timeframes. For the dispatch timeframe, participants must reflect their technical availability via their ECM SCADA signals, such as SCADA Local Limit and SCADA Turbines/Inverters Available. If these signals do not reflect the actual availability or are unavailable, participants can update their energy bid (eg. via Bid Max Avail) to achieve the desired dispatch outcome. As a last resort, participants can request the AEMO Control Room to apply a quick constraint to the actual MW availability level if ECM SCADA signals fail to reflect the farm’s true availability and if the energy bid is unable to be updated.’

Perhaps I am misunderstanding something, but I would take this to mean that the self-forecast should be cognisant of any limitation in either of the LOCL or ELAV.

… but, if someone thinks I’ve misunderstood something, please let me (and our readers) know in a comment below?

Example = Sunraysia Solar Farm

For instance, here’s a collage of 3 different widgets focused on the SUNRSF1 unit:

Firstly, let’s emphasise to readers that:

1)  it’s not just this one that was suffering from this particular sub-optimality

2)  and, we’re not trying to apportion ‘blame’ – just point out an idiosyncrasy/complexity/quirk in the depths of the dispatch processes:

In this window we have:

1)  ‘Dispatch Constraints’ widget at the top

… filtered for this dispatch interval to show all the ~100 constraint equations in the ‘N-DPWG_63_X5’ constraint set,

2)  then we have two instances of ‘Constraint Dashboard’ widget underneath, pointed at two of the constraints seeking to keep the output of SUNRSF1 to 0MW (and the number of inverters to zero):

(a)   The first instance is focused on the ‘N_SUNRSF1_ZERO’ constraint equation, which we can see has a RHS of 0MW and so will limit output (i.e. on the LHS) to 0MW.

(b)   The second instance is focused on the ‘N_SUNRSF1_0INV’ constraint equation, which we see has a RHS of 10,000MW …which

i.  is because of ‘swamping’ because the unit has zero inverters

ii.  but which has an inadvertant outcome that (if it were not for the ‘N_SUNRSF1_ZERO’ constraint equation) might actually giving the unit a non-zero target even though it has zero inverters in service.

As a result of the above, if we flip back to the ‘Bids & Offers’ widget in ez2view we can see the following:

We can see through the day that the unit did not receive any target (i.e. it was ‘constrained down’ due to the ‘N_SUNRSF1_ZERO’ constraint equation) … but it’s still not ideal that its Availability did not follow the pattern of the other Solar Farms similarly affected by ‘zero inverter’ requirements with the transmission line outage.

Other Examples

It does not take much looking, to find other examples (on other occasions) in other units…

Issue #3 … units (and/or their self-forecasters) belatedly waking up to the constraints

In some other cases we see several units that appear to:

1)  Have non-zero, and climbing, Availability for the first few dispatch intervals of the morning

2)  Before seeming to recognise the ‘zero inverter’ requirement and resetting to 0MW available

3)  Despite the ‘N-DPWG_63_X5’ constraint set (containing these constraints) having been invoked from 17:25 the evening beforehand (Monday 23rd June 2025) and persisting into the morning.

Example = Limondale Solar Farm

In this case, here’s the ‘Unit Dashboard’ widget at 08:00 (NEM time) for LIMOSF11 just before the Availability was set to 0MW:

Issue #4 … zero Marginal Value … hence zero Local Price Adjustment … so the (incorrect?!) appearance of less congestion

Our growing number of ez2view users would be aware that

1)  we recently invested heavily in producing a v9.11 of the software that contained a released version of the new ‘Congestion Map’ widget

(a)  With notes about this here;

(b)  And, for readers here, understanding that this is another step towards helping clients understand the nature of congestion across the NEM (i.e. building on the various other widgets providing understandability of constraint equations and constraint sets

2)  and (noting for ez2view users) that we’ve continued to enhance the software with v9.12 released in June.

So here’s a snapshot of this widget (again at 16:10 on Tuesday 24th June 2025), combined with the same (filtered) ‘Dispatch Constraints’ widget we saw above:

I don’t have time to explain all of the details, here, but a few quirks to flag in the depths of the NEMDE process:

1)  The ‘N-DPWG_63_X5’ constraint set has had numerous units (including the 10 x Solar Farm units in the filter above) set their number of inverters to zero …

(a)  Which surely is ‘constraining down’ their output via what the layperson would think of as ‘congestion’

(b)  And yet by the quirks of NEMDE mechanisms:

i.  the Marginal Value of these constraints is $0/MWh,

ii.  which feeds into a Local Price Adjustment of $0/MWh (so no visibility currently on our ‘Congestion Map’ widget)

iii.  which some might mistakenly read as ‘no congestion’ on these units

(c)  Note, in the snapshot above, it’s only because of the way in which SUNRSF1 suffers from Issue #2 that it’s Local Price Adjustment is non-zero, so lights up on the map!

2)  Furthermore, there are also quirks in the visibility of the data in the ‘private constraints’ that can lead to misinterpretation of the MMS results.

That’s where I’ll have to leave this for now…