EMK:Water Values and Hydro Offers - Revision history

WoodsM: Undo revision 4044 by WoodsM (talk)

2013-04-02T21:30:47Z

Undo revision 4044 by WoodsM (talk)

WoodsM: /* Summary */

2013-04-02T21:26:47Z

Summary

Sisep: /* Other Features */

2012-11-28T04:10:58Z

Other Features

Sisep: /* Impact of Spill Penalties */

2012-11-28T03:54:05Z

Impact of Spill Penalties

Sisep: /* List of Parameters */

2012-11-28T03:51:24Z

List of Parameters

Sisep: /* List of Parameters */

2012-11-28T03:41:50Z

List of Parameters

Sisep: /* List of Parameters */

2012-11-28T02:59:39Z

List of Parameters

Sisep: /* List of Parameters */

2012-11-28T02:55:45Z

List of Parameters

Sisep: /* List of Parameters */

2012-11-28T02:51:07Z

List of Parameters

Sisep: /* List of Parameters */

2012-11-28T02:47:09Z

List of Parameters

@@ Line 19: / Line 19: @@
 The concept of a marginal water value is useful in this context and defines the expected future value of the next cubic meter of water arriving in storage for generation.  The water values calculated by ''EMarket'' and used in its full simulation runs are stored and viewed as water value contours, or curves of constant water value on a chart of storage versus time.  Contour values are chosen to match the offer prices of thermal plant configured in each run.
-''EMarket’s'' water values have the following property: if the contour price is P<sub>c</sub> then if the inflow scenarios entered into ''EMarket'' are projected forward until they meet the bottom or top of the reservoir then the average marginal value of water at the projection endpoints, plus any benefits/penalties on marginal water incurred along the path, will be equal to the original price.
+''EMarket’s'' water values have the following property: if the contour price is P<sub>c</sub> then if the inflow scenarios entered into ''EMarket'' are projected forward using market dispatch with hydro offers at the constant value P<sub>c</sub>, the number of scenarios that hit the bottom of the reservoir is equal to [[File:Equ 1.jpg|80px]] where F is the number of annual inflow scenarios entered into ''EMarket'', N the security factor defined by the 1 in N security criterion used in New Zealand, and P the average nodal price for the simulation run.
-''EMarket’s'' water values are calculated using a much simplified, weekly version of the full simulation run which does not use full nodal dispatch and pricing, but retains the HVDC constraint.  During the full simulation run the water values are adjusted using relative prices across the grid to allow for this simplified modelling and to ensure that the hydros offer their output at a price consistent with the optimum release at any particular time of year and storage value.
+If the water value is equal to [[File:P.jpg|15px]] and if F = N then the number of inflow scenarios which will hit bottom of the reservoir when projected forward using market dispatch and constant offer price [[File:P.jpg|15px]], is equal to 1.
 The offers of the major hydro systems modelled in ''EMarket'' can also be distributed optimally across injection nodes along their respective hydro systems, thus providing accurate modelling of nodal prices, losses and line constraints within and around the major hydro systems.

@@ Line 19: / Line 19: @@
 The concept of a marginal water value is useful in this context and defines the expected future value of the next cubic meter of water arriving in storage for generation.  The water values calculated by ''EMarket'' and used in its full simulation runs are stored and viewed as water value contours, or curves of constant water value on a chart of storage versus time.  Contour values are chosen to match the offer prices of thermal plant configured in each run.
-''EMarket’s'' water values have the following property: if the contour price is P<sub>c</sub> then if the inflow scenarios entered into ''EMarket'' are projected forward using market dispatch with hydro offers at the constant value P<sub>c</sub>, the number of scenarios that hit the bottom of the reservoir is equal to [[File:Equ 1.jpg|80px]] where F is the number of annual inflow scenarios entered into ''EMarket'', N the security factor defined by the 1 in N security criterion used in New Zealand, and P the average nodal price for the simulation run.
+''EMarket’s'' water values have the following property: if the contour price is P<sub>c</sub> then if the inflow scenarios entered into ''EMarket'' are projected forward until they meet the bottom or top of the reservoir then the average marginal value of water at the projection endpoints, plus any benefits/penalties on marginal water incurred along the path, will be equal to the original price.
-If the water value is equal to [[File:P.jpg|15px]] and if F = N then the number of inflow scenarios which will hit bottom of the reservoir when projected forward using market dispatch and constant offer price [[File:P.jpg|15px]], is equal to 1.
+''EMarket’s'' water values are calculated using a much simplified, weekly version of the full simulation run which does not use full nodal dispatch and pricing, but retains the HVDC constraint.  During the full simulation run the water values are adjusted using relative prices across the grid to allow for this simplified modelling and to ensure that the hydros offer their output at a price consistent with the optimum release at any particular time of year and storage value.
 The offers of the major hydro systems modelled in ''EMarket'' can also be distributed optimally across injection nodes along their respective hydro systems, thus providing accurate modelling of nodal prices, losses and line constraints within and around the major hydro systems.

← Older revision		Revision as of 04:10, 28 November 2012
Line 788:		Line 788:

	== Other Features ==		== Other Features ==
		+	This section provides a brief list of other important features in ''EMarket''.
		+
		+	'''Nodal Dispatch and Pricing'''
		+
		+	For use in New Zealand, ''EMarket'' dispatches generation offers at each step in the full simulation (Not the simplified weekly dispatch used in the simulation phase of water value calculation) using the methodology contained in the Electricity Governance Rules which specify that dispatch and pricing should take into account losses, line constraints and instantaneous reserves. ''EMarket’s'' “IQP” dispatch and pricing algorithm has been benchmarked against the SPD model used by the System Operator and Pricing Manager to dispatch and price generators and electricity in the wholesale spot market.
		+
		+
		+	'''Instantaneous Reserves'''
		+
		+	''EMarket'' allows generators to be set up to offer reserve and these offers are dispatched along with energy offers by ''EMarket’s'' IQP dispatch and pricing algorithm.
		+
		+
		+	''Grid Modelling''
		+
		+	The grid modelling in ''EMarket'' may contain all approximately 450 nodes and 800 lines and transformers modelled in SPD. In practice, however, highly accurate results are obtained with an aggregated grid of about 180 nodes and 200 lines, with a consequent benefit in reducing the time taken for each dispatch.
		+
		+	This level of detail allows the users to obtain highly accurate nodal prices, power flows and line constraint information from ''EMarket'' simulation runs.
		+
		+
		+	'''Demand Modelling'''
		+
		+	''EMarket'' can run at resolutions from half hourly up to weekly. Because of this, it accepts demand data in a half hourly format. Demand profiles can be updated annually, for example, based on actual demand data. Users can set up their own demand regions on the grid and set the ''EMarket'' Schedule up to vary demand in each region separately to demand in the other regions. This provides the user with a high degree of flexibility in modelling demand over extended periods as demand grows, for example.
		+
		+
		+	'''Thermal Generators'''
		+
		+	Thermal generators offers may be setup in a number of ways in ''EMarket''. For example, they can be set up on a static time-based schedule where they change quantity and/or price at specified dates.
		+
		+	Or they can be manipulated in complex ways in the ''EMarket'' Schedule, or offered as a fixed profile at a specified price. They can even be linked to internal Monte Carlo models of fuel prices to simulate how offers might change over time with natural gas, coal or oil prices, for example.
		+
		+
		+	'''Monte Carlo Fuel Prices'''
		+
		+	This facility allow fuel prices to be modelled as varying over time based on a starting price, a process which adds normally distributed noise to fuel prices, and a process which tends to pull fuel prices back to a longer term mean value over time. This approach to modelling fuel prices has received a high degree of attention in the literature in the last few years and has proven to be simple yet effective in a variety of applications.
		+
		+	The Monte Carlo feature uses a mean-reverting model and has recently been applied, as a first approximation, to the modelling of wind farms.
		+
		+
		+	'''Schedule Programming'''
		+
		+	The ''EMarket'' Schedule is effectively a simple programming language embedded within ''EMarket'' which allows the user to read and change parameters, for example those listed in Table 4 - during full simulation runs. Any new variables created within the Schedule can also be read, changed and output just like the predefined ''EMarket'' parameters.
		+
		+
		+	'''Productivity Enhancements - Outputs and Reports'''
		+
		+	The user has high degree of control over how much output data is saved from each full simulation run, and how the saved data is formatted in summary reports. Given the large amount of data (The user is actually free to set the outputs they actually want to save and this can be quite minimal) that ''EMarket'' may produce, the ability to list and/or summarise certain data into customised files which are easier for the user to work with, is of great benefit.
		+
		+
		+	'''Productivity Enhancements - Time Resolutions'''
		+
		+	Users have a high degree of control over the resolution of each full simulation run – half hourly up to weekly may be specified. Furthermore, modes can be mixed, e.g. a run may proceed in a weekly mode until a specified date at which point it switches to half hourly – an advantage if half hourly values are only required for a short period but the user wishes to have the simulation run execute at great speed.
		+
		+
		+	'''Company Optimisation'''
		+
		+	The user may define companies within ''EMarket'' which own generation, and have retail load and hedging contracts. Company optimisation can be turned on for a company so that it optimises gross profit given its generation and retail portfolio. This feature provides a way for the user to investigate, for example, how a large hydro generator might vary its offers away from water value by using market power.
		+
		+	'''STRCO'''
		+
		+	The Short Term River Chain Optimiser can be turned on for each major hydro system. This is a dynamic program which optimises offers for each major hydro taking account of current market prices and the detailed characteristics and constraints in the river chain.
		+
		+
		+	[[EMK:Water Values Bulletins \| Back to Water Values Technical Bulletins]]

← Older revision		Revision as of 03:54, 28 November 2012
Line 782:		Line 782:

	[**] [[File:MWV1.jpg\|400px]]		[**] [[File:MWV1.jpg\|400px]]
		+
		+	where C<sub>spill</sub> is the spill penalty entered by the user for each hydro system.
		+
		+	The impact of a spill penalty is to lower contours that are nearer to the top of the reservoir, thus lowering the hydro’s offer earlier (than it would with a zero spill penalty) as the risk of spill rises. Referring to Figure 6, the scenarios hitting the top of the reservoir, being counted at C<sub>spill</sub> and not at zero, will reduce the calculated average of all scenarios, lowering the MWV of the point represented by S<sub>1</sub> at T<sub>1</sub>. Since this is already a contour, let’s say at price P<sub>c</sub>, P<sub>c</sub> will now exceed the calculated MWV, so the position of the contour will need to lower so that P<sub>c</sub> and the calculated MWV are once again the same. The amount of the lowering will depend how many forward projections hit top, so the impact on water value contours will be greater on lower priced contours than on higher priced contours.
		+
		+	== Other Features ==

← Older revision		Revision as of 03:51, 28 November 2012
Line 767:		Line 767:
	\| Region.DemandAct \|\| \|\| Not on the output list; Region.DemandRegion.DemandAdjRegion.DemandElast		\| Region.DemandAct \|\| \|\| Not on the output list; Region.DemandRegion.DemandAdjRegion.DemandElast
	\|}		\|}
		+
		+	=== Highly Constrained Hydro Systems ===
		+	Some hydro systems, Manapouri for example, are highly constrained by the requirements of their resource consents. Where these are not capture by water values, the user may also directly alter the offer strategy by modifying some of the hydro parameters shown in the previous section using ''EMarket’s'' Schedule.
		+
		+	=== Multi-year runs ===
		+	Although not directly related to the detailed modelling of hydro systems, this important feature allows single year runs to be daisy chained together with the final storage from inflow scenario x in run n being used in run n + 1 as the starting storage for inflow scenario x + 1. For example, a series of 10 runs can be set up to model a full decade with 1931 scenario final storage in the first year giving the start storage for 1932 in the second year, and so on.
		+
		+	Prior to this enhancement, multi-year runs could be set up but water values were not updated each year. Single year runs could only be linked with considerable manual intervention, but this enhancement makes the linkage automatic, with new water values calculated for each year.
		+
		+	=== Impact of Spill Penalties ===
		+	The discussion of how water value contours are calculated up until now has used zero as the value of an additional unit of water arriving in an already full reservoir. But currently in New Zealand the major generators are required to report any and all spill, with the possibility of excessive or unnecessary spill attracting, at the least, negative publicity. ''EMarket'' allows the user to enter a spill penalty value for each major reservoir, which has the effect of making the value of an extra unit of water in an already full reservoir less than zero, i.e. it incurs a cost equal to the input spill penalty value.
		+
		+	The user may wish to enter a non-zero spill penalty if the reservoir is averse to spilling, for example, as many are in New Zealand given that all spill must be reported. This is recognised in the calculation of N<sub>c</sub> at equation [14], noting that the equation for P<sub>c</sub> is now
		+
		+	[**] [[File:MWV1.jpg\|400px]]

← Older revision		Revision as of 03:41, 28 November 2012
Line 722:		Line 722:
	\|-		\|-
	\| Company.GrossProfit<sup>#</sup> \|\| $/Hr \|\| Company.RetailRevenue + Company.ContractRevenue + Company.GeneratorRevenue – Company.RetailCost – Company.GeneratorCost		\| Company.GrossProfit<sup>#</sup> \|\| $/Hr \|\| Company.RetailRevenue + Company.ContractRevenue + Company.GeneratorRevenue – Company.RetailCost – Company.GeneratorCost
		+	\|-
		+	\| '''HydroStation''' \|\| \|\|
		+	\|-
		+	\| HydroStation.MaxStorage \|\| Mm<sup>3</sup> \|\| Input:Storage
		+	\|-
		+	\| HydroStation.MWperCumec \|\| MW/CM \|\| Input: MW/cumec
		+	\|-
		+	\| HydroStation.MaxGen \|\| MW \|\| Input: Max Gen
		+	\|-
		+	\| HydroStation.MinFlow \|\| m<sup>3</sup>/s \|\| c
		+	\|-
		+	\| HydroStation.MinGen \|\| MW \|\| Input: Schedule
		+	\|-
		+	\| HydroStation.Diversion \|\| m<sup>3</sup>/s \|\| Input: Schedule
		+	\|-
		+	\| HydroStation.HydroStorage<sup>#</sup> \|\| Mm<sup>3</sup> \|\| Hydro Model
		+	\|-
		+	\| HydroStation.HydroMWV \|\| $/CMH \|\| Hydro Model
		+	\|-
		+	\| HydroStation.HydroRelease \|\| m<sup>3</sup>/s \|\| Hydro Model
		+	\|-
		+	\| HydroStation.HydroSpill<sup>#</sup> \|\| m<sup>3</sup>/s \|\| Hydro Model
		+	\|-
		+	\| HydroStation.Inflows \|\| m<sup>3</sup>/s \|\| Hydro Model
		+	\|-
		+	\| '''HydroSystem''' \|\| \|\|
		+	\|-
		+	\| HydroSystem.SystemStorage<sup>#</sup> \|\| GWh \|\| Hydro Model
		+	\|-
		+	\| HydroSystem.SystemMWV \|\| $/MWh \|\| Hydro Model
		+	\|-
		+	\| HydroSystem.SystemRelease \|\| m<sup>3</sup>/s \|\| Hydro Model
		+	\|-
		+	\| HydroSystem.SystemSpill<sup>#</sup> \|\| MW \|\| Hydro Model
		+	\|-
		+	\| '''Region''' \|\| \|\|
		+	\|-
		+	\| Region.Demand<sup>#</sup> \|\| GWh \|\| Input: Schedule
		+	\|-
		+	\| Region.DemandAdj \|\| \|\| Input:Schedule
		+	\|-
		+	\| Region.DemandElast \|\| \|\| Not on the output list
		+	\|-
		+	\| Region.DemandAct \|\| \|\| Not on the output list; Region.DemandRegion.DemandAdjRegion.DemandElast
		+	\|}

@@ Line 719: / Line 719: @@
 | Company.GeneratorCost<sup>#</sup> || $/Hr || [[File:GCP.jpg|230px]] Where Generator &isin; Company
 |-
+| Company.GeneratorRevenue<sup>#</sup> || $/Hr || [[File:GRP.jpg|250px]] Where Generator &isin; Company

@@ Line 713: / Line 713: @@
 | Company.ContractQty || MW || [[File:HQ.jpg|110px]] Where Node &isin; Company
 |-
-| Company.ContractRevenue<sup>#</sup> || $/Hr || [[File:QSP.jpg|250px]]
+| Company.ContractRevenue<sup>#</sup> || $/Hr || [[File:QSP.jpg|250px]] Where Node &isin; Company
 |-
-| Company.Generation<sup>#</sup> || MW ||
+| Company.Generation<sup>#</sup> || MW || [[File:POGG.jpg|270px]] Where Generator &isin; Company

← Older revision		Revision as of 02:47, 28 November 2012
Line 712:		Line 712:
	\|-		\|-
	\| Company.ContractQty \|\| MW \|\| [[File:HQ.jpg\|110px]] Where Node ∈ Company		\| Company.ContractQty \|\| MW \|\| [[File:HQ.jpg\|110px]] Where Node ∈ Company
		+	\|-
		+	\| Company.ContractRevenue<sup>#</sup> \|\| $/Hr \|\| [[File:QSP.jpg\|250px]]
		+	\|-
		+	\| Company.Generation<sup>#</sup> \|\| MW \|\|