Functional Architecture

From EMK Wiki
Jump to navigation Jump to search

This section describes the components which make EMarket work.

Functional Components

  1. Four 'Calculation Engines:'
    1. Water Value calculation module
    2. Dispatch module (SPD simulation)
    3. Short term river chain optimisation module
    4. Company optimisation module
  2. A 'Volatility Engine' which includes:
    1. A Volatility Matrix (incorporating inflow variability)
    2. A Monte Carlo series Generator
  3. A scripting language which includes:
    1. A script editor (effectively the EMarket user interface)
    2. A script interpreter (controls the system operation) the scripting language underlies all EMarket operations. It is used to:
      1. Describe the characteristics of all Resource Instances
      2. Control and coordinate the operation of the calculation and volatility engines
      3. Control the production and formatting of output data

The script for a complete EMarket working environment is contained in the Resources.txt file stored in the Data folder of the associated Working Directory. With a copy of this script it is possible to recreate the same working environment on a different computer running EMarket and produce the same Forecast Results. However to reproduce exactly the same Forecast Data on a different computer with a script, both computers must be running the same version of EMarket and be using the same Demand and Inflow data. Differences in Forecast output may also occur if the associated Run Definition relies on randomly seeded unit outages or data series created by the Monte Carlo Generator.

The Run

A Run is a unique execution of the EMarket model. It produces Forecast distributions of electricity market data from a set of pre-defined modelling assumptions. After production the Forecast data may be used as input into a risk management system for risk assessment or analysed in conjunction with data from other Runs to investigate interesting aspects of the electricity market. The Run uses a Run Definition to identify which input data to use and what form output data is to take. The Run is completely specified by the modelling and data formatting Resources assigned to it in the Run Definition.

A typical EMarket Run has three stages:

  1. Water Values Calculation
  2. Dispatch case solution (iterative)
  3. Run finalisation

Calculating Water Values

Water Values are used to derive Hydro System Offers at any stage of a Run, based on:

  • Reservoir storage levels
  • The Offers (marginal costs) of thermal Generators
  • The potential reservoir inflows

Typically Water Values are calculated in a single preliminary step at the start of a Run. However, it is possible pre-calculate Water Values as an independent operation, and to instruct EMarket to use these Water Values at run time.

For more information on Water Values see: Water Values

Iterative Dispatch

Once equipped with a set of Water Values and a valid Definition the Run progresses to solving a series of dispatch cases. Each case requires a single execution of the dispatch engine (and may include execution of the short term river chain optimisation, volatility and Company optimisation engines). A single case represents a basic unitary time period, called a Tick, which can range in duration from one half hour to one week. In most instances Forecast data produced by the Run will contain one value per Entity.Trait per Tick. The Tick duration and number of ticks (Forecast duration) for a Forecast are determined in the Run Window.

It is possible to have multiple Tick types in a single Run Definition. Forecast data produced from such a Definition will contain outputs at different levels of granularity (e.g. some half hourly and some four hourly data). However where a Run involves mixed Tick types the output data will be continuous from start to end over the whole Forecast (i.e. no gaps) and also contiguous (i.e. no overlaps).

The typical cycle of events for each Tick iteration is:

  1. Derive transmission system properties by checking for scheduled changes to:
    1. Line limits
    2. Equation constraint limits
  2. Derive Nodal Demand using:
    1. A Demand profile from the external Demand file
    2. The Region Demand figures entered into the Run Definition
    3. Any scheduled changes to Demand
  3. Derive Offers using:
    1. Thermal Offers entered into the Run Definition
    2. Hydro Offers derived from Water Values (this will involve running the Short Term River Chain Optimisation engine if this is enabled in the Run Definition)
    3. Any scheduled changes to Offers or Generator availability
    4. The Company optimisation engine (if enabled in the Run Definition)
    5. Any random Generator outages
  4. Execute the Dispatch Model
  5. Derive additional output data from dispatch results (e.g. Company Revenue)
  6. Write dispatch results and additional data to Binary file

Note: Derivation of the dispatch input data listed above may include the use of the volatility engine through the use of formulae in the Run Definition to express data item values.

Run Finalisation

During Run finalisation EMarket:

  1. Outputs data in text format
  2. Enters Run details in the System Log
  3. Creates the Run Resource text file capturing the entire context of the Run (effectively a script for the Run) to enable future Run recreation and analysis

The Run Definition

The Run Definition Resource determines how EMarket will execute a Run.

More information on how this is created can be found in the Run Window section.

Multiple Runs can be executed from a single Run Definition over time. However, a Run Definition can also be changed at any time even when Forecast data has already been produced using the Definition. In other words several differing sets of Results data can be made using the same Run Definition. To ensure that Results can always be interpreted against the exact Run Definition Instance used to produce them, each Run completed in EMarket is assigned a unique Batch number. The Batch number is used to name a sub-folder containing the Run Results data together with a copy of the Run Definition Instance used by the Run. This allows the context of a set of Results to be recreated at a future time (conditional upon certain input data such as Demand profiles being subject to appropriate version control and backup). The numbered sub-folder is located in the Results data folder in the current Working Directory, under the name of the relevant Run Definition.

Note: Where a Batch contains more than one Run Definition, each Run will receive the same Batch Number (but the results will be saved under different Run Definition Resource Names in the Results folder.

Warning: Submitting several identical Run Definitions into the same Batch will cause the results from each Run to over-write each other.


Back to User Manual Main Page