vSPD-online: Getting started and fundamentals

  • Discussion is sticky
  • 4K Views
  • Last post 18 February 2021
Phil Bishop posted this 18 May 2016

vSPD-online is a web-based implementation of the Authority’s vectorised Scheduling, Pricing and Dispatch (vSPD) model.

Unlike the standalone vSPD, users do not require a GAMS license to operate vSPD-online. Behind the scenes, vSPD-online employs exactly the same model codes and solution algorithms as the standalone vSPD, and it calls upon the same collection of input data files. In other words, vSPD-online is mathematically identical to standalone vSPD.

However, the data inputs that vSPD-online users are able to modify are restricted compared to standalone vSPD. Initially, only the demand parameters can be changed. Once users have gained a little familiarity with vSPD-online, we will enable the various offer parameters to be modified as well.

Registration

Users must first register in order to use vSPD-online. A single sign-on facility enables access to all parts of the EMI website that require sign-on. This is a one-time task and requires users to provide a username, an email address, and an affiliation. In the interests of openness and transparency, we would encourage users to use their actual first and last names as their username, and current workplace for affiliation. You can edit your user profile details at any time after you've registered.

vSPD-online concepts

There are really only two actions users need to undertake in order to use vSPD-online:

- Create an override

- Create a job.

Create an override

An override is a named collection of user-specified data values that defines an experiment, or counterfactual scenario. It is called an override because the specified data values literally 'override' the existing or base case values in the model. In other words, creating an override is the mechanism by which a vSPD-online user implements a ‘what if’ question, e.g. what if North Island demand increased by 10%?

An override may contain one or more components. For example, one component may be to increase North Island demand by 10% in all trading periods of the day whereas a second component might decrease South Island demand by 3% in trading periods 30-36. Users add components one at a time until they’ve finished building the override, and then they submit it. After an override has been submitted it is stored in the system and is then available for all vSPD-online users to make use of.

Three ways to modify input data

When specifying how the base case input data is to be modified, three methods are available:

- Scale – scale the existing base case data by some scalar, e.g. 0.95 to reduce by 5% or 1.1 to increase by 10%.

- Increment – increase or decrease the existing base case data by some specified amount, e.g. 7.3 to increase demand by 7.3MW or -5 to decrease demand by 5MW.

- Replace – replace the existing base case data with a new value.

Three ways to create an override component

Three approaches to adding a new component to an override are available:

- Create a new component from scratch.

- Use an existing override as a starting point and edit it to create new override components for the current override.

- Upload the required data from a CSV or an Excel file – this first requires first downloading an override component so that a file template is available for editing. An opportunity to download an override component as a CSV or an Excel file exists during the process of adding components to an override.

Create a job

Activating the 'create a job' function causes the vSPD-online user to be stepped through the process of configuring an instance of the vSPD model to be solved.

The job must be given a name and description – users should try to make these as meaningful as possible, as the name and description will appear in the vSPD dashboard for all to see. If an override is to be applied, then the relevant override must be selected.

Solving vSPD without using an override simply causes the base case for the selected days and trading periods to be solved. In other words, the prices, dispatch, branch flows etc that actually occurred in the final pricing run of SPD for the day and trading periods selected will be reproduced. It is reasonable to do this if you want to compare the base case solution with one or more counterfactual solutions.

vSPD-online users are restricted to solving no more than seven contiguous days in one job. Within that 7-day interval, users may select any or all of the trading periods to be solved on any or all of the days.

Once the job has been submitted, it will appear as a record in the vSPD dashboard. When the job is finished, the user will receive an email containing a link to the vSPD output files, which can then be downloaded. Any other user can download the output files as well, directly from the vSPD dashboard.

Order by: Standard | Newest | Votes
Phil Bishop posted this 26 May 2016

Date and trading period ranges for overrides

In order to use vSPD-online efficiently, it’s important to grasp the concept that overrides are distinct from jobs.

The construction of an override is usually, although it doesn’t have to be, completely divorced from any specific date. Moreover, once constructed, the override can be used by any number of jobs. When creating a component to go into an override, it is necessary to specify a time frame for the override. The options are to use a date range or to use one or more trading periods.

The more common approach would be to use trading periods. If this option is selected, you are then required to specify either: all trading periods, a single trading period, or a range of trading periods. The choice you make then applies to all of the days for which the job making use of this override is solved over.

If the override is specific to a particular day, or group of contiguous days, then date range must be selected when choosing a time frame. It is then necessary to specify a start date and start trading period, followed by an end date and an end trading period.

For example, if you selected 1 April 2016, trading period 20 as the start of the date range, and 15 May 2016, trading period 40 as the end of the date range, then the particular component of the override being constructed would apply to every trading period from TP 20 on 1 April through to TP 40 on 15 May. To be absolutely clear, this means that the override would apply to all 48 trading periods each day from 2 April through to 14 May and fewer than all 48 trading periods on 1 April and 15 May. Of course, vSPD-online can only be solved (at this time) for a maximum of seven contiguous days so conducting an experiment spanning 45 days would require the submission of seven jobs.

Finally, and just to be perfectly clear, an override that was constructed to be applied for a specific date range would have absolutely no impact on any job using that override if the job was set to solve for days outside of the override's date range. For example, the override described above was constructed to apply between 1 April and 15 May 2016. The solution to any job using this override and solved for any day prior to 1 April 2016 or after 15 May 2016 would look identical to the actual outcome (base case) for those solved days.

 

zawaung posted this 21 November 2017

Phil,

model link https://www.emi.ea.govt.nz/Tools/vSPD is showing 404 Page not found.

Thanks!

 

Phil Bishop posted this 21 November 2017

The link to the vSPD model should be working now - see also https://www.emi.ea.govt.nz/Wholesale/Tools/vSPD.

 

 

 

Chets posted this 18 February 2021

Hi Phil

Can i please make a request to get data on the entire "bus" which is used in vSPD.

I am trying to reconcile the TX grid setup between PSSE (raw) and vSPD. And in the GDX files, not all bus numbers have a corresponding node name. e.g. in image below showing (input GDX, element # 102 when pasted into Excel) items 1-3 & 5, 6 are missing.

  

 

and when i am trying to understand the mapping data contained within the element #104 (image below), i am not able to understand the mapping so very successfully.

Note in some cases it is obvious and in other cases it is not. Hence my request.

 

Thanks

Chets

Phil Bishop posted this 18 February 2021

Hi Chets

The only data that goes into a GDX file is extracted from the SPD case files and all of the final pricing case files since the middle of 2009 are published here. So maybe you can find what you want in the case files?

I will let Tuong know about this post and he may have something to add; it is Tuong that maintains the code to make a GDX file out of a case file.

Cheers

Phil

Tuong Nguyen posted this 18 February 2021

Hi Chets,

May I answer your question in bullet points?

1. All the Buses and Nodes are there in the GDX file

2. Buses are like the points where transmission lines are connected to each other.

3. Nodes are like generation plant, or demand feed. Nodes are a layer on top of Buses 

4. So, not all Buses are connected/mapped to a bus.

5. Node and Bus are mapped and related through NodeBusAllocation factor. 

If you have any more questions and want to take it offline, please contact me through tuong.nguyen@ea.govt.nz

Cheers

Tuong Nguyen