ez2view v9.6.1.99 released (last version compatible with MMS v5.0)

On 10th February 2023 we released the first permutation of ez2view v9.6.* (this one was v9.6.1.4) … and on 9th May 2023 we released the last permutation of v9.6.* (this one was v9.6.1.99).

… In between those two dates there were 18 discrete upgrades released, to be made available on this ez2view Installer page.

The reason why v9.6.1.99 is significant is because we pushed the version number up to v9.7.* for releases later in May 2023 in conjunction with the AEMO’s release of EMMS v5.2.

The release of the EMMS v5.2 is especially significant, so we’ve left v9.6 where it is with this 9th May 2023 release and have (belatedly) put together this Release Note now (and back-dated it to 9th May) to document all that changed since we released v9.5.1.216 on 4th October 2022.

… this MMS upgrade is an important one. It contains a number of new tables and fields that we’ll be progressively building into ez2view v9.7 from this point forwards

(a) For future upgrades (beyond v9.6.1.99), you will require EMMS v5.2

(b) We’ve started this process, and there’s a separate release note for v9.7.1.20 coming soon

(A) About this release (a view ‘inside the sausage machine’)

In recent weeks we’ve fielded calls from a number of clients asking about specific versions that were on the ez2view installer page. We provided them an explanation along the lines of what follows – they found this useful, so we thought it would be worthwhile to share this with readers here.

Note 1) We’re pretty much continuously working on ez2view, and build new versions of ez2view on a weekly basis, sometimes several times each week.

Note 2) Internally, these builds work through the following sequential steps:

Step 1 = we run some Automated Unit Tests with the build process

… if these pass, the build is marked ‘Pre-Release’ for us to use and test internally.

… so this is what I tend to try to use the latest of (for instance) although I can’t keep on top of how frequent they are.

Step 2 = we then run some Automated Screenshot* Tests:

… if these pass, the mark on the build is changed to ‘Release Candidate’

… if this happens, it is uploaded to this site:

… https://installers.global-roam.com/ez2viewaustralia/[INSTALLER WITH VERSION NUMBER]

Step 3 = if we have a flag turned on in the process …

… then this switches the ‘latest bleeding edge release’ flag automatically in the process

… which then adjusts the version number (and the URL) linked in the right-hand column of the the ez2view installer page.

… this column has been labelled ‘Latest and Greatest’ to reflect what it is.

Step 4 = at this point, there are still a couple of things we occasionally do manually that have not yet been done for that release:

4a) We have a test matrix specifying a full batch of systematic manual platform tests (e.g. upgrade from v9.X to v9.Y on Windows Version Z):

i. Sometimes these identify specific bugs that we then correct (and repeat steps 1 to 4)

ii. However note these tend to be corner-cases, as we (and some particular external users we work closely with) are always using the ‘Latest and Greatest’ so come across and resolve most problems without needing to wait for this step.

4b) Occasionally, as well, we’ll update the Widget Guides (a manual process) to reflect all of the enhancements made to particular widgets to that point.

Following from this explanation, note that the ‘Latest and Greatest’ has not yet gone through Steps 4a and Step 4b.

(B) Some of the enhancements

It’s a long way back to v9.5.1.216 (7 months in real time, but seems like an age in NEM time) so there’s been lots of enhancements released for ez2view since that time … through v9.5.* and into v9.6.*.

… more specifically, 37 incremental version upgrades over 217 days (averaging a new version every 5.9 days inside the ‘sausage machine’).

We’ll try to sum up the highlights here, but can’t guarantee we cover everything.

B1) Upgraded Schematics

As with all upgrades to the software, we’ve endeavoured to ensure the Regional Schematics widgets have kept pace with new unit & station additions, and also

1) In the QLD Region we added a number of new units/stations, including:

• WANDSF1 (Wandoan Solar Farm)

2) In the NSW region, the additions have included:

• AVLSF1 (Avonlie Solar Farm)
• WYASF1 (Wyalong)
• WOLARSF1 (Wollar Solar Farm)
• RESS1G and RESS1L (Riverina 1 BESS)

3) In the VIC region, the additions have included:

• HBESSG1 and HBESSL1 (Hazelwood BESS)
• BRYB2WF2 (Berrybank 2 Wind Farm)

4) In the SA region, you can now see:

• TIBG1 and TIBL1 (Torrens Island BESS)

5) No new additions to the TAS Region

… and we’re also thinking through more strategic enhancements to these widgets.

B2) Better utilisation of MT PASA DUID Availability Data

Back on 20th February 2020 the AEMC made a Final Determination that agreed with much of what ERM had proposed in their two rule change requests.

1) Since that time we’ve been pleased to be able to provide visibility of this data … through:

(a) the ‘MT PASA DUID Availability’ widget, and

(b) the ‘Generator Outages’ widget.

2) Worth noting that we’re still hopeful that the scope of the rule might be expanded to (also) encompass Semi-Scheduled units, as well.

With the upgrade to v9.6 we’ve invested considerable effort in back-end caching of the data to ensure it’s faster to load data now over three different widgets as follows:

B2a) ‘Forecast Convergence’ widget

It was not possible before to add the data into ‘Forecast Convergence’ widget … just too large a data set (a matrix of 3 years of historical forecasts 3 years into the future).

But now it’s there, as seen in this snapshot of the changing return to service profile for Callide C3 and C4 following the announced delay in RTS on 30th May 2023:

It’s also worth noting, with respect to ‘Forecast Convergence’ widget that:

i. We’ve also added in the ability to select NEM-wide totals for some parameters (like Demand, UIGF and Available Generation):

ii. We also fixed the bug identified in GR Case 00006122

B2b) ‘MT PASA DUID Availability’ widget

This now loads more quickly as a result of the caching noted above.

We also fixed the bug identified in GR Case 00006148.

B2c) ‘Generator Outages’ widget

This now loads more quickly as a result of the caching noted above.

Worth noting that this is one of the enhancements we’ll be enhancing further in v9.7 in order to provide visibility of new data to available from 9th October 2023 as a result of the MT PASA Enhancement Rule Change.

B3) Improved visibility of Constraints

With the upgrade to v9.5.1.216 we made a big enhancement to the visibility of constraints with respect to the newly released ‘Constraint Dashboards’ widget.

With the upgrade to v9.6 we have made enhancements to this, and other widgets – such as the following:

B3a) ‘Dispatch Constraints’ widget and ‘Constraint Equations’ widgets

These two widgets work in tandem to show the range of Constraint Equations invoked:
(1) In ‘Dispatch Constraints’ widget, just for the current Dispatch Interval; but
(2) In ‘Constraint Equations’ widget, also scheduled to be invoked in P5 and P30 predispatch.

We received several requests for the enhancement of the sorting and (colour-coded) alerting on these widgets, so we decided to implement a common approach across the two as shown in this image, and as described underneath:

With respect to both widgets, the way they now work is as follows:

Colour-based alerting in each widget

There are now three levels of alert colour used in both widgets for constraint equations, based on Violation Degree and Marginal Value:

(a) Within the current dispatch interval (both widgets), the colours are:

i. Red = VD > 0 for current DI
ii. Orange = abs(MV) > 10
iii. Yellow = abs(MV) > 0

… noting that it is possible for a constraint equation to be bound, but to have a Marginal Value of 0 as explained here on 9th June 2022.

(b) Within the predispatch time horizon (‘Constraint Equations’ widget), the colours are:

i. Red = VD > 0 anywhere in PD
ii. Orange = abs(MV) > 10 anywhere in PD
iii. Yellow = abs(MV) > 0 anywhere in PD

Sort Order in each widget

By default, both widgets now sort the same way (though note the user can adjust in each):

i. by Violation Degree descending
ii. then by Marginal Value in current DI descending
iii. then by Headroom ascending in current DI
iv. then alphabetically by constraint ID

In the ‘Constraint Equations’ widget, if the user selects the ‘Max MV’ option, this looks through the data in predispatch and sorts as follows:

i. by Violation Degree descending in P5 or P30 (if any >0)
ii. then by Marginal Value in current DI descending in P5 or P30
iii. then by Headroom ascending in current DI
iv. then alphabetically by constraint ID

B3b) ‘Constraint Set Details’ Widget

Based on customer requests, there’s now much more history of the scheduled invocation of the constraint.

B3c) ‘MITC Analysis’ Widget

We fixed the bug that we identified with GR Case 00006118 (to do with the AER Exclusion 8)

B3d) Filtering with respect to Constraint Sets

We fixed the bug identified in GR Case 00006175.

B3e) ‘Constraint Dashboard’ widget

With respect to the ‘Constraint Dashboard’ widget (released with v9.5.1.216), we have taken some additional steps by:

(a) Making it the default hyperlink from any reference to a particular constraint equation in the software … the older ‘Constraint Details’ widget is retained for now (will appear in search within ez2view Explorer)

(b) Based on customer request (GR Case 00006117), we added the ability to manually scale the y-axis on Constraint Dashboard (e.g. useful in cases where the RHS contains some form of ‘swamping’ component).

i. Just click and drag to zoom in

ii. What to zoom out?

B4) Improved Alerting

With the upgrade to v9.6 we have made enhancements to this, and other widgets – such as the following:

B4a) ‘Notifications’ Widget, in the installed software

With respect to this installed widget, we have added in the ability to alert on FCAS prices …

(a) both prices now,

(b) But also expectations of FCAS prices into P5 or P30 predispatch.

B4b) ‘SMS Alarms’ Widget

In the SMS Alarms widget, we have changed the way that it works such that:

(a) By default alerts will come from ‘NEMalerts’

(b) The User can change this sender to be alphanumeric (indeed it can be different for different types of alerts … e.g. AlertPrice, AlertDemand) … but:
i. 1st character must be a letter (i.e. can’t mimic a phone number)
ii. Can’t have non alpha-numeric
iii. Can’t exceed a certain length … how long?

This change was made for several reasons,

B5) ‘NEM Prices’ enhancements

We also improved the capability of ‘NEM Prices’ widget to highlight all the different permutations of Suspension in the market (such as for 1 region only – as we saw on 17th March 2023 in NSW, and on 22nd April 2023 in Victoria .

(C) Bug fixes

In addition to the above, there’s been a range of other bug fixes implemented on the software (as clients have alerted us of them, or we’ve found them ourselves).

Some are noted above, but we won’t list them all here.