Duplicates in SPD case files

  • Last post 15 December 2022
jordan posted this 14 December 2022

I'm trying to collate the 30-minute pricing data at each node, and I've noticed that on occasion the same INTERVAL is present in more than 1 SPD case file - as an example, between cases 61012022121905054 and 61012022121905055. I'm just hoping to clarify how to correctly calculate the 30-minute settlement price from individual cases, particularly where there are two cases for the same INTERVAL, or, conversely, where there are no cases for a 5-minute INTERVAL.



Order by: Standard | Newest | Votes
Phil Bishop posted this 14 December 2022

Hi Jordan

First of all, the case files you highlight are not duplicates. To state the obvious, they have different Case IDs and different run times (see RunDateTime in image below) - clearly two different cases.

But they do both pertain to the same 5-min interval (the 2nd 5-min interval as it happens) of trading period 17 on 7 Dec 2022 - see the column called IntervalDateTime in image below.

It is my understanding that RTD cases are run on a schedule every 5 minutes (i.e. automatically) and whenever the operator on the desk at the system operator hits the go button. This can give rise to two RTD cases for the same 5-min interval. See the column in image below called CaseName - the first has Auto in the name while the second has Oper (presumably short for Operator). 

You should be aware that not all RTD cases get published. Again it is my understanding, the RTD cases are published if a dispatch instruction is derived from the case. With real-time pricing, an RTD case is always published for the first 5-min interval in a trading period, and some indeterminate number of cases are published thereafter for that period. Although we've never seen it, I believe it is conceivable that an entire trading period could go by with just a single RTD schedule being published - if that were to happen, the dispatch prices from that single case would be the interim/final prices for that period.

Typically we see 4 or 5 RTD cases per trading period and it is not uncommon to see more than one per 5-min interval.

I think the notion of a 5-min interval is now a bit redundant. It seems to me it's a holderover from the pre real-time pricing days when 5-min or indicativce prices were generated and published every 5 minutes.   

Some of the narrative here, here, and here might also be instructive.


jordan posted this 15 December 2022

Thanks for your response, Phil.

I note that the published (interim/final) 30-min settlement price is calculated as a time-weighted average of the constituent RTD case prices. To clarify, in the above cases (cases 61012022121905054 and 61012022121905055), 61012022121905054 would apply for 60 seconds (from 8:05:00.000 to 8:06:00.000) and 61012022121905055 would apply from 8:06 until the next published case file begins (61012022121905056), at 8:10:00.000? This method appears to get me close to the published 30-minute prices, however it is not exact, so I suspect I am missing something.

I greatly appreciate any assistance on this,


Phil Bishop posted this 15 December 2022

Correct, it will get you close (sort of) but will never get you all the way to where you're trying to get to. That's because the time-weighting doesn't make use of the RunDateTime. Rather, it uses the 'PublishDateTime' as determined and published by the pricing manager. See the narrative and the files published here. Dispatch prices are extracted from the solution of an RTD SPD case.

But even the use of the publish times will let you down because sometimes (quite often in fact), there are portions of the 30-min trading period when no dispatch price applies, particularly at the start of a trading period. In such situations, prices from the most recently published PRSS case for that trading period are used. But the most recent one isn't necessarily the last one - it depends on the precise time that the PRSS prices are published. Note that under real-time pricing, it is necessary to have an applicable price for all 1800 seconds of the trading period in order to calculate the interim price (time-weighted average 'dispatch' price) at the close of the period.

We have a request in with WITS to provide us a file each day containing all of the case types, case IDs, and publish times of all prices that go into interim (and ultimately final) prices. When that file starts coming to us, we'll be able to enhance what we present on EMI.