When I get more time, will progress with this page – for now, details are copied in from this article here…
—————-
It’s important for readers to understand that the electricity grid that supports the Australian National Electricity Market is a very complex interconnected piece of electrical and mechanical machinery that stretches thousands of kilometres. This is governed by complex sets of engineering principles … of things such as System Strength above.
However , it is just as important to understand that (in the dispatch time horizon, at least, remembering Stephen Wilson’s timescales diagram) the National Electricity Market is actually more correctly viewed as a complex mathematical model represented in the ‘NEMDE’ Dispatch Engine. What happened on Tuesday 13th October is best understood by the maths that was at work … particularly in relation to how there was a different outcome on Friday 16th October despite there being similar underlying grid conditions …. because the form of the maths had changed.
(1) NEMDE and the Objective Function
For each individual dispatch interval, NEMDE tries to find the ‘least cost’ approach to supplying what AEMO sees as the assumed level of demand to meet at the end of that dispatch interval and supply the relevant FCAS services … by using generator offers (called ‘bids’ in NEM lingo) as a proxy for input costs.
Progressively over time we’ve been building up materials in WattClarity® to explain how dispatch works, and how prices are set in the NEM via the Glossary. You might find them useful.
(2) Constraints on possible solution sets
In resolving the ‘least cost’ resolution of the ‘Objective Function’ that NEMDE tries to solve for, the job for NEMDE is necessarily made more difficult by imposing boundaries on the possible solutions to take account of the diverse range of network (and other) limitations that always act in different ways on the ‘long skinny’ nature of the national electricity grid.
The ez2view software makes it easier to understand which constraints are being used at any given point in time, from a library that the AEMO has assembled of 1,000s of possible Constraint Equations:
1) The ‘Dispatch Constraints’ Widget looks at just those constraint equations invoked (i.e. fancy AEMO term for ‘used’) in the current Dispatch Interval; whereas
2) The ‘Constraints Equations’ Widget also looks forward into predispatch to see what’s currently forecast to be invoked in the P30 predispatch time horizon:
(a) This widget will typically show between 600 and 1,000 constraint equations being used by AEMO at any given point in time (during ‘outage season’ there are more being used).
(b) On 13th October at 09:45 there were 1,032 constraint equations invoked, or forecast to be invoked in predispatch (i.e. one of the busier times in the NEM, not just in northern Queensland).
(3) The form of Constraint Equations
In most occasions (with FCAS constraints being a notable exception, but not the only one) the form of the constraint is as follows:
LHS ≤ RHS
… where the Left-Hand Side (LHS) contains all the terms that NEMDE tries to influence in the co-optimisation process assembled in a linear equation, such as:
LHS = Factor1 x Var1 + Factor2 x Var2 + … FactorN x VarN
… and the Var1, Var2 … VarN are DUIDs and interconnector elements that NEMDE gives Dispatch Targets to.
Whereas the Right-Hand Side (RHS) reflects the things that generally NEMDE can’t control, but essentially treats as an constant for the given dispatch interval.
(4) Constraints in Constraint Sets
All Constraint Equations are invoked (i.e. fancy AEMO term for ‘used’) in Constraint Sets:
1) Because of the mis-match between the need for constraint equations to be of linear form and the complex realities of the electricity grid
2) Because underlying network conditions (or a change such as removing a flow path) can impose multiple different limitations on dispatch, so each set of constraints essentially represents a related group of limitations jointly imposed by a given network configuration in some part of the NEM.
3) Because it also greatly simplifies AEMO’s task in managing outage-related changes in constraints (i.e. it’s ‘just’ a constraint set that needs to be invoked to address limitations imposed by an outage).