The input data required to run vSPD is published in the form of a daily GDX file. Our entire collection of vSPD GDX files associated with final pricing SPD cases can be downloaded from EMI Datasets, or accessed directly from our FTP server using anonymous FTP.

GDX stands for GAMS data exchange and represents a binary file format for use with GAMS. The files are a convenient way to store the input data to be used by a GAMS-based model such as vSPD, and to import the data at model run time.

Final pricing GDX files are generated from SPD final pricing case files. The naming convention for the final pricing GDX files is FP_YYYYMMDDx_X.gdx where:

  • FP denotes final pricing
  • YYYY denotes year
  • MM denotes month
  • DD denotes day
  • The lower case x, which is generally not present, denotes that SPD and vSPD have yielded different prices for at least one node in at least one trading period
  • The upper case X denotes the status of final prices and may take on the values of P, I, F, or there may be no value at all, where:
    • P stands for provisional
    • I stands for interim
    • F stands for final
    • The absence of a value means that no status has yet been assigned by the pricing manager.

YYYYMMDD together denote the trading day, midnight to midnight, to which the file relates. 

Part 13 of the Code describes how final prices are to be determined and published. The process is quite involved and doesn’t lend itself to being easily described in a sentence or two. Generally, though, the pricing manager will have declared final prices to be final by 2:00pm two business days following the trading day, if not before.

Final pricing GDX files are published on EMI Datasets immediately after we have received and processed the SPD case file. Hence, a GDX file can appear on EMI Datasets before any status (P, I or F) is assigned to it by the pricing manager. Furthermore, the pricing status indicator may not appear on the GDX file until some time after the pricing manager has determined the status. It is worth noting that the status indication on the GDX file can change but this does not neccessarily mean that a new file has been generated; rather, we simply rename the file once the new status has been obtained.

Only one GDX file per day is published. If a subsequent final pricing case is generated, we process it to produce the new GDX file, and remove the previous GDX file from EMI.  

SPD, and it’s mathematical replica, vSPD, are large linear programming problems and thus may be degenerate. An explanation of degeneracy in LP problems is beyond the scope of this discussion. Suffice it to say, degeneracy in SPD means that there can be a tie between two candidate prices at a node that give rise to an identical (optimal) objective function value. In other words, while the solution is optimal in both cases, it is arbitrary as to which price is selected to break the tie. SPD and vSPD have not been aligned in terms of tie-breaking rules. The practical implication of degeneracy is that the model has at least one redundant constraint – this is an extremely common occurence in large models.

Any instance of vSPD and SPD producing different prices is investigated. If it is not due to degeneracy, the cause is rectified.

The Authority receives all published SPD case files. Each SPD case file contains all of the inputs required for that case and all of the outputs generated by SPD for that case. The final pricing case files are published on EMI Datasets.