EMO Wiki - User contributions [en]

EMO:Constraint Overview

2016-02-24T01:52:08Z

NelsonM: /* 'Current SPS (Feb-16) */

''References:
# [http://www.systemoperator.co.nz/documents/reports/system-security-forecast System Security Forecast (SSF), Part B, Section 7]
# [http://www.systemoperator.co.nz/system-operations/security-management/security-constraints Security constraints overview]

The SSF states that "Security Constraints may be applied [in SPD] to manage circuit loading:
* to ensure post-event circuit loading does not exceed short term ratings (15 minute off-load times);
* to ensure system stability is maintained following a contingent event;
* to ensure sufficient reactive power is available to maintain voltage levels following a contingent event."

The "'''15 minute off-load time'''" is the internationally recognised time required for the SO to redispatch after a contingency. Shorter off-load times may be in place with Special Protection Schemes ('''SPS''') in some cases.

The SSF states that "thermal current ratings ('''thermal ratings''') are determined from the maximum permissible temperature of the conductors to avoid excessive sag or long-term annealing of the conductors. The calculation does not consider environmental factors that may cool the conductor, therefore it is recognised that these static ratings are typically conservative and at times may result in under utilisation of circuits." The SO uses seasonal default ratings or variable line ratings for each line.

There three basic types of constraint: maunal constraints, SFT constraints and Special Protection Schemes.

==SFT Constraints==
From 28-Mar-11 the majority of constraints are formulated by the SO's Simultaneous Feasibility Test (SFT) software tool. SFT formuates constraints that protect circuits in the event of an N-1 failure of the grid. The constraint equation has the form

A x Protected Branch Flow + B x Contingent Branch Flow ≤ RHS

A and B are coefficients calculated by SFT. The RHS limit ensures that if the contingent branch fails, then the loading on the protected branch remains safe during the 15 off-load time, where 'safe' refers to the amount of sag in the line post-contingency.

==Manual Constraints==
Constraints that are not automatically generated by SFT may relate to Special Protection Schemes (see below) or may be created manually based on studies undertaken offline. Typical examples are the four voltge stability constraints that are there to ensure voltage is stable after a contingency in one of the main load centres, or over long lines.

The Manual Constraints can be permanent or only apply during outages, and are updated at http://www.systemoperator.co.nz/system-operations/security-management/security-constraints (see mid way down this page under Security Constraints and "Manual constraints under SFT ....xls".

==Special Protection Schemes==
Automatic SPS' are also known as "operational intertripping schemes" and the SPS activates "within the period of voltage recovery following fault clearance". In most cases, SPS' are designed to operate to avoid security violations without the need for additional constraints in SPD. According to the SSF, the following constraint equations relate specifically to SPS':

* Te Mihi Special Protection Scheme, constrain transfer from WRK bus.

1.24 * RPO_TNG1.1 + 0.50 * THI_WKM1.1 <= 315 MW

* Special Protection Schemes at KAW: Generation at KAW bus may need to be constrained in the event of high generation at KAW bus or sudden loss of interruptible loads. Security constraints on KAW are highly dependent on system configuration and conditions.

There are several types of SPS.

'''Overload Protection Schemes'''

A.k.a. intertripping schemes, these SPS open circuits that would otherwise overload. They trip the circuit if overloading continues for a specfied minimum time, allowing time for auto-reclose to work.

SPS that involve the action of busbar section circuit breakers to regulate power flows on the system are referred to as Auto Busbar Splitting Schemes (ABSS).

An intertrip that results in a system split is referred to as a System Split Intertrip Scheme (SSIS).

'''Planned Automatic Load Shedding'''

Typical examples are a load shedding scheme for Automatic Under Voltage Load Shedding (AUVLS) using voltage-sensitive relays and occuring within an 8 second time period. The load shedding scheme trips feeders in a sequence to bring load below an overload trip setpoint, or to bring voltage to within allowable limits.

'''Generation Run Back'''

These SPS automatically reduce generation to a pre-arranged value to remove circuit overloads or generator instability. If the circuit loading is not reduced within an inverse time-dependent period after a runback scheme operation has been initiated, the circuit will be tripped. Currenty Transpower has automatic runback schemes installed at Arapuni, Cobb, Maraetai and Te Apiti. Runback schemes may allow operation to 5 or 10 minute off-load times on monitored circuits rather than the standard 15 minute criteria.

'''Reactive Devices'''

The SO dispatches reactive devices so that dynamic reactive reserves are available to provide voltage support for Contingent Events and Extended Contingent Events.

=='Current SPS (Feb-16)==

Data from System Security Forecast - Transpower Dec-15
http://www.systemoperator.co.nz/documents/reports/system-security-forecast

''Information page'' is the location of further information on the SPS found in '''Transpower System Security Forecast 2014''' Part D - Power System Security Analysis, for that Grid Zone

{| class="wikitable"
|-
! Transpower Grid Zone GZ1
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ1
! Jun-15
! Hepburn-Roskill 110 kV Overload Protection Scheme
! Normally Enabled
! Line protection from Outage
! Pg4, section 4.1
!
|-
! GZ1
! Jun-15
! Penrose Reactor Bypass Scheme
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.2
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ2
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ2
! Nov-15
! Penrose Circuit Overload Protection Scheme
! Normally Disabled
! Line protection from Outage
! Pg3, section 4.1
!
|-
! GZ2
! Nov-15
! Hepburn-Roskill 110 kV Overload Protection Scheme
! Normally Enabled
! Line protection from Outage
! Pg3, section 4.2
!
|-
! GZ2
! Nov-15
! Bombay 110 kV System Split Intertrip Scheme
! Normally Disabled
! Line protection from Outage
! Pg3, section 4.3
!
|-
! GZ2
! Nov-15
! Bombay_Otahuhu Overload Protecton Scheme
! Normally Disabled
! Line protection from Bus Split
! Pg4, section 4.4
!
|-
! GZ2
! Nov-15
! Penrose Reactor Bypass Scheme
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.5
!
|-
! GZ2
! Nov-15
! Otahuhu 110 kV Bus Split
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.6
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ3
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ3
! Jun-15
! Arapuni Runback Scheme
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.1
! Manages Generation constraints
|-
! GZ3
! Jun-15
! Arapuni Bus Split
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.2
! Manages Generation constraints
|-
! GZ3
! Jun-15
! Bombay 110 kV System Split Intertrip Scheme
! Normally Disabled
! Line protection from Outage
! Pg5, section 4.3
!
|-
! GZ3
! Jun-15
! Arapuni - Kinleith 110 kV Overload Protection Scheme
! Normally Disabled
! Line protection from Outage
! Pg5, section 4.4
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ4
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ4
! Jun-15
! Arapuni - Kinleith 110 kV Overload Protection Scheme
! Normally Disabled
! Line protection from Outage
! Pg5, section 4.1
!
|-
! GZ4
! Jun-15
! Kaitimaki Intertrip Scheme
! Normally Enabled
! Overload & line outage protection
! Pg5, section 4.2
! Manages Circuit overload
|-
! GZ4
! Jun-15
! Tokannu 128 Intertrip Scheme
! Normally Enabled
! Line protection from Outage
! Pg5, section 4.3
!
|-
! GZ4
! Jun-15
! Te Mihi Intertrip Scheme
! Line outage Criteria enabled
! Line protection from Outage
! Pg6, section 4.4
!
|-
! GZ4
! Jun-15
! Edgecumbe-Kawerau 1 & 2 Overload Protection Scheme
! Normally Enabled
! Line protection from Outage
! Pg6, section 4.5
!
|-
! GZ4
! Jun-15
! Edgecumbe-Owhata 2 Overload Proteciton Scheme
! Normally Enabled
! Overload Protection
! Pg6, section 4.6
! Manages Generation constraints
|-
! GZ4
! Jun-15
! Kawerau T13 Overload Proteciton Scheme
! Normally Disabled
! not required
! Pg6, section 4.7
!
|-
! GZ4
! Jun-15
! Maraetai Runback
! Normally enabled
!
! Pg6, section 4.8
! Manages Generation constraints
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ5
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ5
! Jun-15
! Redclyffe interconnecting Transformers Overload Protection Scheme
! Commission 2016
! Transformer protection
! Pg3, section 4.1
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ6
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ6
! Dec-14
! Hawera Reactor and Automatic Bus Splitting Scheme (ABSS)
! Not required
! Line protection from Outage
! Pg3, section 4.1
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ7
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ7
! Dec-14
! Tokannu 128 Intertrip Scheme
! Normally Enabled
! Line protection from Outage
! Pg4, section 4.1
!
|-
! GZ7
! Dec-14
! Bunnythorpe - Woodville 1 and 2 Overload Protection Scheme
! Normally enabled
! Line protection from overloading
! Pg4, section 4.2
! Manages Circuit overload
|-
! GZ7
! Dec-14
! Woodville 110 kV Bus Overload Protection Scheme
! usually Disabled
! Bus protection from overloading
! Pg4, section 4.3
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ8
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ8
! Jun-15
! Bunnythorpe - Woodville 1 and 2 Overload Protection Scheme
! Normally enabled
! Line protection from overloading
! Pg4, section 4.1
! Manages Circuit overload
|-
! GZ8
! Jun-15
! Bunnythorpe - Woodville 1 and 2 Overload Protection Scheme
! Normally enabled
! Line protection from overloading
! Pg4, section 4.1
! Manages Circuit overload
|-
! GZ8
! Jun-15
! Central Park Transformer Overload Protection Scheme
! usually Disabled
! Transformer Protection from overloading
! Pg5, section 4.2
!
|-
! GZ8
! Jun-15
! Mangamaire Overload Trip and Autochange Over Scheme (MGM OTAS)
! usually Disabled
! Line protection from overloading
! Pg5, section 4.3
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ9
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ9
! Dec-14
! Blenheim_Kikawa 110kV Circuit Overload Protection Scheme
! Normally enabled
! Line protection from Outage
! Pg4, section 4.1
!
|-
! GZ9
! Dec-14
! Kikiwa-Stoke 220 kV Outage Intertrip Scheme
! Normally Disabled
! Line protection from Outage
! Pg5, section 4.2
!
|-
! GZ9
! Dec-14
! Stoke T7 Outage interip Scheme
! Normally Disabled
! Transformer protection low generation
! Pg5, section 4.3
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ10 & GZ11
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ10&GZ11
! Jun-15
! Bells Pond Waitaki Overload Protection Scheme
! Normally Enabled
! Line protection from overloading
! Pg6, section 4.1
! Manages Circuit overload
|-
! GZ10&GZ11
! Jun-15
! Timaru Transformer Overloading Scheme
! Normally Enabled
! Transformer protection low generation
! Pg6, section 4.2
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ12
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ12
! Dec-14
! Coleridge Intertrip Scheme
! Normally Enabled
! Line protection from Outage
! Pg3, section 4.1
!
|-
! GZ12
! Dec-14
! Hororata Automatic Under Voltage
! Normally Enabled
! Load scheding from Line outage
! Pg3, section 4.2
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ13
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ13
! Jun-15
! Bells Pond Waitaki Overload Protection Scheme
! Normally Enabled
! Line protection from overloading
! Pg6, section 4.1
! Manages Circuit overload
|-
! GZ13
! Jun-15
! Roxburgh Export Overload Protection Scheme (REOLP)
! Normally Enabled
! Line protection from overloading
! Pg6, section 4.2
! Manages Circuit overload
|-
! GZ13
! Jun-15
! Roxburgh Import Overload Protection Scheme
! Enabled Southward Flow
! Line protection from overloading (increase Manapouri Generation)
! Pg7, section 4.4
! Manages Circuit overload
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ14
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ14
! Nov-15
! Manapouri Intertrip Scheme
! Normally Enabled
! Line protection from Outage
! Pg6, section 4.1
! Manages Generation constraints
|-
! GZ14
! Nov-15
! Halfway Bush Reverse power Protection Scheme
! Normally Enabled
! Line protection from Outage
! Pg6, section 4.2
!
|-
! GZ14
! Nov-15
! Roxburgh Import Overload Protection Scheme
! Enabled Southward Flow
! Line protection from overloading (increase Manapouri Generation)
! Pg7, section 4.4
! Manages Circuit overload
|-
! GZ14
! Nov-15
! Roxburgh Export Overload Protection Scheme (REOLP)
! Normally enabled
! Overload Protection
! Pg6, section 4.3
! Manages Circuit overload
|}

EMO:Constraint Overview

2016-02-24T01:51:34Z

NelsonM: /* 'Current SPS (Feb-16) */

''References:
# [http://www.systemoperator.co.nz/documents/reports/system-security-forecast System Security Forecast (SSF), Part B, Section 7]
# [http://www.systemoperator.co.nz/system-operations/security-management/security-constraints Security constraints overview]

The SSF states that "Security Constraints may be applied [in SPD] to manage circuit loading:
* to ensure post-event circuit loading does not exceed short term ratings (15 minute off-load times);
* to ensure system stability is maintained following a contingent event;
* to ensure sufficient reactive power is available to maintain voltage levels following a contingent event."

The "'''15 minute off-load time'''" is the internationally recognised time required for the SO to redispatch after a contingency. Shorter off-load times may be in place with Special Protection Schemes ('''SPS''') in some cases.

The SSF states that "thermal current ratings ('''thermal ratings''') are determined from the maximum permissible temperature of the conductors to avoid excessive sag or long-term annealing of the conductors. The calculation does not consider environmental factors that may cool the conductor, therefore it is recognised that these static ratings are typically conservative and at times may result in under utilisation of circuits." The SO uses seasonal default ratings or variable line ratings for each line.

There three basic types of constraint: maunal constraints, SFT constraints and Special Protection Schemes.

==SFT Constraints==
From 28-Mar-11 the majority of constraints are formulated by the SO's Simultaneous Feasibility Test (SFT) software tool. SFT formuates constraints that protect circuits in the event of an N-1 failure of the grid. The constraint equation has the form

A x Protected Branch Flow + B x Contingent Branch Flow ≤ RHS

A and B are coefficients calculated by SFT. The RHS limit ensures that if the contingent branch fails, then the loading on the protected branch remains safe during the 15 off-load time, where 'safe' refers to the amount of sag in the line post-contingency.

==Manual Constraints==
Constraints that are not automatically generated by SFT may relate to Special Protection Schemes (see below) or may be created manually based on studies undertaken offline. Typical examples are the four voltge stability constraints that are there to ensure voltage is stable after a contingency in one of the main load centres, or over long lines.

The Manual Constraints can be permanent or only apply during outages, and are updated at http://www.systemoperator.co.nz/system-operations/security-management/security-constraints (see mid way down this page under Security Constraints and "Manual constraints under SFT ....xls".

==Special Protection Schemes==
Automatic SPS' are also known as "operational intertripping schemes" and the SPS activates "within the period of voltage recovery following fault clearance". In most cases, SPS' are designed to operate to avoid security violations without the need for additional constraints in SPD. According to the SSF, the following constraint equations relate specifically to SPS':

* Te Mihi Special Protection Scheme, constrain transfer from WRK bus.

1.24 * RPO_TNG1.1 + 0.50 * THI_WKM1.1 <= 315 MW

* Special Protection Schemes at KAW: Generation at KAW bus may need to be constrained in the event of high generation at KAW bus or sudden loss of interruptible loads. Security constraints on KAW are highly dependent on system configuration and conditions.

There are several types of SPS.

'''Overload Protection Schemes'''

A.k.a. intertripping schemes, these SPS open circuits that would otherwise overload. They trip the circuit if overloading continues for a specfied minimum time, allowing time for auto-reclose to work.

SPS that involve the action of busbar section circuit breakers to regulate power flows on the system are referred to as Auto Busbar Splitting Schemes (ABSS).

An intertrip that results in a system split is referred to as a System Split Intertrip Scheme (SSIS).

'''Planned Automatic Load Shedding'''

Typical examples are a load shedding scheme for Automatic Under Voltage Load Shedding (AUVLS) using voltage-sensitive relays and occuring within an 8 second time period. The load shedding scheme trips feeders in a sequence to bring load below an overload trip setpoint, or to bring voltage to within allowable limits.

'''Generation Run Back'''

These SPS automatically reduce generation to a pre-arranged value to remove circuit overloads or generator instability. If the circuit loading is not reduced within an inverse time-dependent period after a runback scheme operation has been initiated, the circuit will be tripped. Currenty Transpower has automatic runback schemes installed at Arapuni, Cobb, Maraetai and Te Apiti. Runback schemes may allow operation to 5 or 10 minute off-load times on monitored circuits rather than the standard 15 minute criteria.

'''Reactive Devices'''

The SO dispatches reactive devices so that dynamic reactive reserves are available to provide voltage support for Contingent Events and Extended Contingent Events.

=='Current SPS (Feb-16)==

Data from System Security Forecast - Transpower Dec-15
http://www.systemoperator.co.nz/documents/reports/system-security-forecast

''Information page'' is the location of further information on the SPS found '''Transpower System Security Forecast 2014''' Part D Power System Security Analysis for that Grid Zone

{| class="wikitable"
|-
! Transpower Grid Zone GZ1
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ1
! Jun-15
! Hepburn-Roskill 110 kV Overload Protection Scheme
! Normally Enabled
! Line protection from Outage
! Pg4, section 4.1
!
|-
! GZ1
! Jun-15
! Penrose Reactor Bypass Scheme
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.2
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ2
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ2
! Nov-15
! Penrose Circuit Overload Protection Scheme
! Normally Disabled
! Line protection from Outage
! Pg3, section 4.1
!
|-
! GZ2
! Nov-15
! Hepburn-Roskill 110 kV Overload Protection Scheme
! Normally Enabled
! Line protection from Outage
! Pg3, section 4.2
!
|-
! GZ2
! Nov-15
! Bombay 110 kV System Split Intertrip Scheme
! Normally Disabled
! Line protection from Outage
! Pg3, section 4.3
!
|-
! GZ2
! Nov-15
! Bombay_Otahuhu Overload Protecton Scheme
! Normally Disabled
! Line protection from Bus Split
! Pg4, section 4.4
!
|-
! GZ2
! Nov-15
! Penrose Reactor Bypass Scheme
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.5
!
|-
! GZ2
! Nov-15
! Otahuhu 110 kV Bus Split
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.6
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ3
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ3
! Jun-15
! Arapuni Runback Scheme
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.1
! Manages Generation constraints
|-
! GZ3
! Jun-15
! Arapuni Bus Split
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.2
! Manages Generation constraints
|-
! GZ3
! Jun-15
! Bombay 110 kV System Split Intertrip Scheme
! Normally Disabled
! Line protection from Outage
! Pg5, section 4.3
!
|-
! GZ3
! Jun-15
! Arapuni - Kinleith 110 kV Overload Protection Scheme
! Normally Disabled
! Line protection from Outage
! Pg5, section 4.4
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ4
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ4
! Jun-15
! Arapuni - Kinleith 110 kV Overload Protection Scheme
! Normally Disabled
! Line protection from Outage
! Pg5, section 4.1
!
|-
! GZ4
! Jun-15
! Kaitimaki Intertrip Scheme
! Normally Enabled
! Overload & line outage protection
! Pg5, section 4.2
! Manages Circuit overload
|-
! GZ4
! Jun-15
! Tokannu 128 Intertrip Scheme
! Normally Enabled
! Line protection from Outage
! Pg5, section 4.3
!
|-
! GZ4
! Jun-15
! Te Mihi Intertrip Scheme
! Line outage Criteria enabled
! Line protection from Outage
! Pg6, section 4.4
!
|-
! GZ4
! Jun-15
! Edgecumbe-Kawerau 1 & 2 Overload Protection Scheme
! Normally Enabled
! Line protection from Outage
! Pg6, section 4.5
!
|-
! GZ4
! Jun-15
! Edgecumbe-Owhata 2 Overload Proteciton Scheme
! Normally Enabled
! Overload Protection
! Pg6, section 4.6
! Manages Generation constraints
|-
! GZ4
! Jun-15
! Kawerau T13 Overload Proteciton Scheme
! Normally Disabled
! not required
! Pg6, section 4.7
!
|-
! GZ4
! Jun-15
! Maraetai Runback
! Normally enabled
!
! Pg6, section 4.8
! Manages Generation constraints
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ5
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ5
! Jun-15
! Redclyffe interconnecting Transformers Overload Protection Scheme
! Commission 2016
! Transformer protection
! Pg3, section 4.1
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ6
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ6
! Dec-14
! Hawera Reactor and Automatic Bus Splitting Scheme (ABSS)
! Not required
! Line protection from Outage
! Pg3, section 4.1
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ7
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ7
! Dec-14
! Tokannu 128 Intertrip Scheme
! Normally Enabled
! Line protection from Outage
! Pg4, section 4.1
!
|-
! GZ7
! Dec-14
! Bunnythorpe - Woodville 1 and 2 Overload Protection Scheme
! Normally enabled
! Line protection from overloading
! Pg4, section 4.2
! Manages Circuit overload
|-
! GZ7
! Dec-14
! Woodville 110 kV Bus Overload Protection Scheme
! usually Disabled
! Bus protection from overloading
! Pg4, section 4.3
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ8
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ8
! Jun-15
! Bunnythorpe - Woodville 1 and 2 Overload Protection Scheme
! Normally enabled
! Line protection from overloading
! Pg4, section 4.1
! Manages Circuit overload
|-
! GZ8
! Jun-15
! Bunnythorpe - Woodville 1 and 2 Overload Protection Scheme
! Normally enabled
! Line protection from overloading
! Pg4, section 4.1
! Manages Circuit overload
|-
! GZ8
! Jun-15
! Central Park Transformer Overload Protection Scheme
! usually Disabled
! Transformer Protection from overloading
! Pg5, section 4.2
!
|-
! GZ8
! Jun-15
! Mangamaire Overload Trip and Autochange Over Scheme (MGM OTAS)
! usually Disabled
! Line protection from overloading
! Pg5, section 4.3
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ9
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ9
! Dec-14
! Blenheim_Kikawa 110kV Circuit Overload Protection Scheme
! Normally enabled
! Line protection from Outage
! Pg4, section 4.1
!
|-
! GZ9
! Dec-14
! Kikiwa-Stoke 220 kV Outage Intertrip Scheme
! Normally Disabled
! Line protection from Outage
! Pg5, section 4.2
!
|-
! GZ9
! Dec-14
! Stoke T7 Outage interip Scheme
! Normally Disabled
! Transformer protection low generation
! Pg5, section 4.3
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ10 & GZ11
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ10&GZ11
! Jun-15
! Bells Pond Waitaki Overload Protection Scheme
! Normally Enabled
! Line protection from overloading
! Pg6, section 4.1
! Manages Circuit overload
|-
! GZ10&GZ11
! Jun-15
! Timaru Transformer Overloading Scheme
! Normally Enabled
! Transformer protection low generation
! Pg6, section 4.2
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ12
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ12
! Dec-14
! Coleridge Intertrip Scheme
! Normally Enabled
! Line protection from Outage
! Pg3, section 4.1
!
|-
! GZ12
! Dec-14
! Hororata Automatic Under Voltage
! Normally Enabled
! Load scheding from Line outage
! Pg3, section 4.2
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ13
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ13
! Jun-15
! Bells Pond Waitaki Overload Protection Scheme
! Normally Enabled
! Line protection from overloading
! Pg6, section 4.1
! Manages Circuit overload
|-
! GZ13
! Jun-15
! Roxburgh Export Overload Protection Scheme (REOLP)
! Normally Enabled
! Line protection from overloading
! Pg6, section 4.2
! Manages Circuit overload
|-
! GZ13
! Jun-15
! Roxburgh Import Overload Protection Scheme
! Enabled Southward Flow
! Line protection from overloading (increase Manapouri Generation)
! Pg7, section 4.4
! Manages Circuit overload
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ14
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ14
! Nov-15
! Manapouri Intertrip Scheme
! Normally Enabled
! Line protection from Outage
! Pg6, section 4.1
! Manages Generation constraints
|-
! GZ14
! Nov-15
! Halfway Bush Reverse power Protection Scheme
! Normally Enabled
! Line protection from Outage
! Pg6, section 4.2
!
|-
! GZ14
! Nov-15
! Roxburgh Import Overload Protection Scheme
! Enabled Southward Flow
! Line protection from overloading (increase Manapouri Generation)
! Pg7, section 4.4
! Manages Circuit overload
|-
! GZ14
! Nov-15
! Roxburgh Export Overload Protection Scheme (REOLP)
! Normally enabled
! Overload Protection
! Pg6, section 4.3
! Manages Circuit overload
|}

EMO:Constraint Overview

2016-02-24T01:50:27Z

NelsonM: /* 'Current SPS (Feb-16) */

''References:
# [http://www.systemoperator.co.nz/documents/reports/system-security-forecast System Security Forecast (SSF), Part B, Section 7]
# [http://www.systemoperator.co.nz/system-operations/security-management/security-constraints Security constraints overview]

The SSF states that "Security Constraints may be applied [in SPD] to manage circuit loading:
* to ensure post-event circuit loading does not exceed short term ratings (15 minute off-load times);
* to ensure system stability is maintained following a contingent event;
* to ensure sufficient reactive power is available to maintain voltage levels following a contingent event."

The "'''15 minute off-load time'''" is the internationally recognised time required for the SO to redispatch after a contingency. Shorter off-load times may be in place with Special Protection Schemes ('''SPS''') in some cases.

The SSF states that "thermal current ratings ('''thermal ratings''') are determined from the maximum permissible temperature of the conductors to avoid excessive sag or long-term annealing of the conductors. The calculation does not consider environmental factors that may cool the conductor, therefore it is recognised that these static ratings are typically conservative and at times may result in under utilisation of circuits." The SO uses seasonal default ratings or variable line ratings for each line.

There three basic types of constraint: maunal constraints, SFT constraints and Special Protection Schemes.

==SFT Constraints==
From 28-Mar-11 the majority of constraints are formulated by the SO's Simultaneous Feasibility Test (SFT) software tool. SFT formuates constraints that protect circuits in the event of an N-1 failure of the grid. The constraint equation has the form

A x Protected Branch Flow + B x Contingent Branch Flow ≤ RHS

A and B are coefficients calculated by SFT. The RHS limit ensures that if the contingent branch fails, then the loading on the protected branch remains safe during the 15 off-load time, where 'safe' refers to the amount of sag in the line post-contingency.

==Manual Constraints==
Constraints that are not automatically generated by SFT may relate to Special Protection Schemes (see below) or may be created manually based on studies undertaken offline. Typical examples are the four voltge stability constraints that are there to ensure voltage is stable after a contingency in one of the main load centres, or over long lines.

The Manual Constraints can be permanent or only apply during outages, and are updated at http://www.systemoperator.co.nz/system-operations/security-management/security-constraints (see mid way down this page under Security Constraints and "Manual constraints under SFT ....xls".

==Special Protection Schemes==
Automatic SPS' are also known as "operational intertripping schemes" and the SPS activates "within the period of voltage recovery following fault clearance". In most cases, SPS' are designed to operate to avoid security violations without the need for additional constraints in SPD. According to the SSF, the following constraint equations relate specifically to SPS':

* Te Mihi Special Protection Scheme, constrain transfer from WRK bus.

1.24 * RPO_TNG1.1 + 0.50 * THI_WKM1.1 <= 315 MW

* Special Protection Schemes at KAW: Generation at KAW bus may need to be constrained in the event of high generation at KAW bus or sudden loss of interruptible loads. Security constraints on KAW are highly dependent on system configuration and conditions.

There are several types of SPS.

'''Overload Protection Schemes'''

A.k.a. intertripping schemes, these SPS open circuits that would otherwise overload. They trip the circuit if overloading continues for a specfied minimum time, allowing time for auto-reclose to work.

SPS that involve the action of busbar section circuit breakers to regulate power flows on the system are referred to as Auto Busbar Splitting Schemes (ABSS).

An intertrip that results in a system split is referred to as a System Split Intertrip Scheme (SSIS).

'''Planned Automatic Load Shedding'''

Typical examples are a load shedding scheme for Automatic Under Voltage Load Shedding (AUVLS) using voltage-sensitive relays and occuring within an 8 second time period. The load shedding scheme trips feeders in a sequence to bring load below an overload trip setpoint, or to bring voltage to within allowable limits.

'''Generation Run Back'''

These SPS automatically reduce generation to a pre-arranged value to remove circuit overloads or generator instability. If the circuit loading is not reduced within an inverse time-dependent period after a runback scheme operation has been initiated, the circuit will be tripped. Currenty Transpower has automatic runback schemes installed at Arapuni, Cobb, Maraetai and Te Apiti. Runback schemes may allow operation to 5 or 10 minute off-load times on monitored circuits rather than the standard 15 minute criteria.

'''Reactive Devices'''

The SO dispatches reactive devices so that dynamic reactive reserves are available to provide voltage support for Contingent Events and Extended Contingent Events.

=='Current SPS (Feb-16)==

Data from System Security Forecast - Transpower Dec-15
http://www.systemoperator.co.nz/documents/reports/system-security-forecast

Information page relates to page and section in ''Transpower System Security Forecast 2014'' Part D Power System Security Analysis for that Grid Zone on the SPS

{| class="wikitable"
|-
! Transpower Grid Zone GZ1
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ1
! Jun-15
! Hepburn-Roskill 110 kV Overload Protection Scheme
! Normally Enabled
! Line protection from Outage
! Pg4, section 4.1
!
|-
! GZ1
! Jun-15
! Penrose Reactor Bypass Scheme
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.2
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ2
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ2
! Nov-15
! Penrose Circuit Overload Protection Scheme
! Normally Disabled
! Line protection from Outage
! Pg3, section 4.1
!
|-
! GZ2
! Nov-15
! Hepburn-Roskill 110 kV Overload Protection Scheme
! Normally Enabled
! Line protection from Outage
! Pg3, section 4.2
!
|-
! GZ2
! Nov-15
! Bombay 110 kV System Split Intertrip Scheme
! Normally Disabled
! Line protection from Outage
! Pg3, section 4.3
!
|-
! GZ2
! Nov-15
! Bombay_Otahuhu Overload Protecton Scheme
! Normally Disabled
! Line protection from Bus Split
! Pg4, section 4.4
!
|-
! GZ2
! Nov-15
! Penrose Reactor Bypass Scheme
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.5
!
|-
! GZ2
! Nov-15
! Otahuhu 110 kV Bus Split
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.6
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ3
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ3
! Jun-15
! Arapuni Runback Scheme
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.1
! Manages Generation constraints
|-
! GZ3
! Jun-15
! Arapuni Bus Split
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.2
! Manages Generation constraints
|-
! GZ3
! Jun-15
! Bombay 110 kV System Split Intertrip Scheme
! Normally Disabled
! Line protection from Outage
! Pg5, section 4.3
!
|-
! GZ3
! Jun-15
! Arapuni - Kinleith 110 kV Overload Protection Scheme
! Normally Disabled
! Line protection from Outage
! Pg5, section 4.4
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ4
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ4
! Jun-15
! Arapuni - Kinleith 110 kV Overload Protection Scheme
! Normally Disabled
! Line protection from Outage
! Pg5, section 4.1
!
|-
! GZ4
! Jun-15
! Kaitimaki Intertrip Scheme
! Normally Enabled
! Overload & line outage protection
! Pg5, section 4.2
! Manages Circuit overload
|-
! GZ4
! Jun-15
! Tokannu 128 Intertrip Scheme
! Normally Enabled
! Line protection from Outage
! Pg5, section 4.3
!
|-
! GZ4
! Jun-15
! Te Mihi Intertrip Scheme
! Line outage Criteria enabled
! Line protection from Outage
! Pg6, section 4.4
!
|-
! GZ4
! Jun-15
! Edgecumbe-Kawerau 1 & 2 Overload Protection Scheme
! Normally Enabled
! Line protection from Outage
! Pg6, section 4.5
!
|-
! GZ4
! Jun-15
! Edgecumbe-Owhata 2 Overload Proteciton Scheme
! Normally Enabled
! Overload Protection
! Pg6, section 4.6
! Manages Generation constraints
|-
! GZ4
! Jun-15
! Kawerau T13 Overload Proteciton Scheme
! Normally Disabled
! not required
! Pg6, section 4.7
!
|-
! GZ4
! Jun-15
! Maraetai Runback
! Normally enabled
!
! Pg6, section 4.8
! Manages Generation constraints
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ5
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ5
! Jun-15
! Redclyffe interconnecting Transformers Overload Protection Scheme
! Commission 2016
! Transformer protection
! Pg3, section 4.1
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ6
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ6
! Dec-14
! Hawera Reactor and Automatic Bus Splitting Scheme (ABSS)
! Not required
! Line protection from Outage
! Pg3, section 4.1
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ7
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ7
! Dec-14
! Tokannu 128 Intertrip Scheme
! Normally Enabled
! Line protection from Outage
! Pg4, section 4.1
!
|-
! GZ7
! Dec-14
! Bunnythorpe - Woodville 1 and 2 Overload Protection Scheme
! Normally enabled
! Line protection from overloading
! Pg4, section 4.2
! Manages Circuit overload
|-
! GZ7
! Dec-14
! Woodville 110 kV Bus Overload Protection Scheme
! usually Disabled
! Bus protection from overloading
! Pg4, section 4.3
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ8
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ8
! Jun-15
! Bunnythorpe - Woodville 1 and 2 Overload Protection Scheme
! Normally enabled
! Line protection from overloading
! Pg4, section 4.1
! Manages Circuit overload
|-
! GZ8
! Jun-15
! Bunnythorpe - Woodville 1 and 2 Overload Protection Scheme
! Normally enabled
! Line protection from overloading
! Pg4, section 4.1
! Manages Circuit overload
|-
! GZ8
! Jun-15
! Central Park Transformer Overload Protection Scheme
! usually Disabled
! Transformer Protection from overloading
! Pg5, section 4.2
!
|-
! GZ8
! Jun-15
! Mangamaire Overload Trip and Autochange Over Scheme (MGM OTAS)
! usually Disabled
! Line protection from overloading
! Pg5, section 4.3
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ9
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ9
! Dec-14
! Blenheim_Kikawa 110kV Circuit Overload Protection Scheme
! Normally enabled
! Line protection from Outage
! Pg4, section 4.1
!
|-
! GZ9
! Dec-14
! Kikiwa-Stoke 220 kV Outage Intertrip Scheme
! Normally Disabled
! Line protection from Outage
! Pg5, section 4.2
!
|-
! GZ9
! Dec-14
! Stoke T7 Outage interip Scheme
! Normally Disabled
! Transformer protection low generation
! Pg5, section 4.3
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ10 & GZ11
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ10&GZ11
! Jun-15
! Bells Pond Waitaki Overload Protection Scheme
! Normally Enabled
! Line protection from overloading
! Pg6, section 4.1
! Manages Circuit overload
|-
! GZ10&GZ11
! Jun-15
! Timaru Transformer Overloading Scheme
! Normally Enabled
! Transformer protection low generation
! Pg6, section 4.2
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ12
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ12
! Dec-14
! Coleridge Intertrip Scheme
! Normally Enabled
! Line protection from Outage
! Pg3, section 4.1
!
|-
! GZ12
! Dec-14
! Hororata Automatic Under Voltage
! Normally Enabled
! Load scheding from Line outage
! Pg3, section 4.2
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ13
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ13
! Jun-15
! Bells Pond Waitaki Overload Protection Scheme
! Normally Enabled
! Line protection from overloading
! Pg6, section 4.1
! Manages Circuit overload
|-
! GZ13
! Jun-15
! Roxburgh Export Overload Protection Scheme (REOLP)
! Normally Enabled
! Line protection from overloading
! Pg6, section 4.2
! Manages Circuit overload
|-
! GZ13
! Jun-15
! Roxburgh Import Overload Protection Scheme
! Enabled Southward Flow
! Line protection from overloading (increase Manapouri Generation)
! Pg7, section 4.4
! Manages Circuit overload
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ14
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ14
! Nov-15
! Manapouri Intertrip Scheme
! Normally Enabled
! Line protection from Outage
! Pg6, section 4.1
! Manages Generation constraints
|-
! GZ14
! Nov-15
! Halfway Bush Reverse power Protection Scheme
! Normally Enabled
! Line protection from Outage
! Pg6, section 4.2
!
|-
! GZ14
! Nov-15
! Roxburgh Import Overload Protection Scheme
! Enabled Southward Flow
! Line protection from overloading (increase Manapouri Generation)
! Pg7, section 4.4
! Manages Circuit overload
|-
! GZ14
! Nov-15
! Roxburgh Export Overload Protection Scheme (REOLP)
! Normally enabled
! Overload Protection
! Pg6, section 4.3
! Manages Circuit overload
|}

EMO:Constraint Overview

2016-02-24T01:47:00Z

NelsonM: /* Special Protection Schemes */

''References:
# [http://www.systemoperator.co.nz/documents/reports/system-security-forecast System Security Forecast (SSF), Part B, Section 7]
# [http://www.systemoperator.co.nz/system-operations/security-management/security-constraints Security constraints overview]

The SSF states that "Security Constraints may be applied [in SPD] to manage circuit loading:
* to ensure post-event circuit loading does not exceed short term ratings (15 minute off-load times);
* to ensure system stability is maintained following a contingent event;
* to ensure sufficient reactive power is available to maintain voltage levels following a contingent event."

The "'''15 minute off-load time'''" is the internationally recognised time required for the SO to redispatch after a contingency. Shorter off-load times may be in place with Special Protection Schemes ('''SPS''') in some cases.

The SSF states that "thermal current ratings ('''thermal ratings''') are determined from the maximum permissible temperature of the conductors to avoid excessive sag or long-term annealing of the conductors. The calculation does not consider environmental factors that may cool the conductor, therefore it is recognised that these static ratings are typically conservative and at times may result in under utilisation of circuits." The SO uses seasonal default ratings or variable line ratings for each line.

There three basic types of constraint: maunal constraints, SFT constraints and Special Protection Schemes.

==SFT Constraints==
From 28-Mar-11 the majority of constraints are formulated by the SO's Simultaneous Feasibility Test (SFT) software tool. SFT formuates constraints that protect circuits in the event of an N-1 failure of the grid. The constraint equation has the form

A x Protected Branch Flow + B x Contingent Branch Flow ≤ RHS

A and B are coefficients calculated by SFT. The RHS limit ensures that if the contingent branch fails, then the loading on the protected branch remains safe during the 15 off-load time, where 'safe' refers to the amount of sag in the line post-contingency.

==Manual Constraints==
Constraints that are not automatically generated by SFT may relate to Special Protection Schemes (see below) or may be created manually based on studies undertaken offline. Typical examples are the four voltge stability constraints that are there to ensure voltage is stable after a contingency in one of the main load centres, or over long lines.

The Manual Constraints can be permanent or only apply during outages, and are updated at http://www.systemoperator.co.nz/system-operations/security-management/security-constraints (see mid way down this page under Security Constraints and "Manual constraints under SFT ....xls".

==Special Protection Schemes==
Automatic SPS' are also known as "operational intertripping schemes" and the SPS activates "within the period of voltage recovery following fault clearance". In most cases, SPS' are designed to operate to avoid security violations without the need for additional constraints in SPD. According to the SSF, the following constraint equations relate specifically to SPS':

* Te Mihi Special Protection Scheme, constrain transfer from WRK bus.

1.24 * RPO_TNG1.1 + 0.50 * THI_WKM1.1 <= 315 MW

* Special Protection Schemes at KAW: Generation at KAW bus may need to be constrained in the event of high generation at KAW bus or sudden loss of interruptible loads. Security constraints on KAW are highly dependent on system configuration and conditions.

There are several types of SPS.

'''Overload Protection Schemes'''

A.k.a. intertripping schemes, these SPS open circuits that would otherwise overload. They trip the circuit if overloading continues for a specfied minimum time, allowing time for auto-reclose to work.

SPS that involve the action of busbar section circuit breakers to regulate power flows on the system are referred to as Auto Busbar Splitting Schemes (ABSS).

An intertrip that results in a system split is referred to as a System Split Intertrip Scheme (SSIS).

'''Planned Automatic Load Shedding'''

Typical examples are a load shedding scheme for Automatic Under Voltage Load Shedding (AUVLS) using voltage-sensitive relays and occuring within an 8 second time period. The load shedding scheme trips feeders in a sequence to bring load below an overload trip setpoint, or to bring voltage to within allowable limits.

'''Generation Run Back'''

These SPS automatically reduce generation to a pre-arranged value to remove circuit overloads or generator instability. If the circuit loading is not reduced within an inverse time-dependent period after a runback scheme operation has been initiated, the circuit will be tripped. Currenty Transpower has automatic runback schemes installed at Arapuni, Cobb, Maraetai and Te Apiti. Runback schemes may allow operation to 5 or 10 minute off-load times on monitored circuits rather than the standard 15 minute criteria.

'''Reactive Devices'''

The SO dispatches reactive devices so that dynamic reactive reserves are available to provide voltage support for Contingent Events and Extended Contingent Events.

=='Current SPS (Feb-16)==

Data from System Security Forecast - Transpower Dec-15
http://www.systemoperator.co.nz/documents/reports/system-security-forecast

{| class="wikitable"
|-
! Transpower Grid Zone GZ1
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ1
! Jun-15
! Hepburn-Roskill 110 kV Overload Protection Scheme
! Normally Enabled
! Line protection from Outage
! Pg4, section 4.1
!
|-
! GZ1
! Jun-15
! Penrose Reactor Bypass Scheme
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.2
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ2
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ2
! Nov-15
! Penrose Circuit Overload Protection Scheme
! Normally Disabled
! Line protection from Outage
! Pg3, section 4.1
!
|-
! GZ2
! Nov-15
! Hepburn-Roskill 110 kV Overload Protection Scheme
! Normally Enabled
! Line protection from Outage
! Pg3, section 4.2
!
|-
! GZ2
! Nov-15
! Bombay 110 kV System Split Intertrip Scheme
! Normally Disabled
! Line protection from Outage
! Pg3, section 4.3
!
|-
! GZ2
! Nov-15
! Bombay_Otahuhu Overload Protecton Scheme
! Normally Disabled
! Line protection from Bus Split
! Pg4, section 4.4
!
|-
! GZ2
! Nov-15
! Penrose Reactor Bypass Scheme
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.5
!
|-
! GZ2
! Nov-15
! Otahuhu 110 kV Bus Split
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.6
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ3
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ3
! Jun-15
! Arapuni Runback Scheme
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.1
! Manages Generation constraints
|-
! GZ3
! Jun-15
! Arapuni Bus Split
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.2
! Manages Generation constraints
|-
! GZ3
! Jun-15
! Bombay 110 kV System Split Intertrip Scheme
! Normally Disabled
! Line protection from Outage
! Pg5, section 4.3
!
|-
! GZ3
! Jun-15
! Arapuni - Kinleith 110 kV Overload Protection Scheme
! Normally Disabled
! Line protection from Outage
! Pg5, section 4.4
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ4
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ4
! Jun-15
! Arapuni - Kinleith 110 kV Overload Protection Scheme
! Normally Disabled
! Line protection from Outage
! Pg5, section 4.1
!
|-
! GZ4
! Jun-15
! Kaitimaki Intertrip Scheme
! Normally Enabled
! Overload & line outage protection
! Pg5, section 4.2
! Manages Circuit overload
|-
! GZ4
! Jun-15
! Tokannu 128 Intertrip Scheme
! Normally Enabled
! Line protection from Outage
! Pg5, section 4.3
!
|-
! GZ4
! Jun-15
! Te Mihi Intertrip Scheme
! Line outage Criteria enabled
! Line protection from Outage
! Pg6, section 4.4
!
|-
! GZ4
! Jun-15
! Edgecumbe-Kawerau 1 & 2 Overload Protection Scheme
! Normally Enabled
! Line protection from Outage
! Pg6, section 4.5
!
|-
! GZ4
! Jun-15
! Edgecumbe-Owhata 2 Overload Proteciton Scheme
! Normally Enabled
! Overload Protection
! Pg6, section 4.6
! Manages Generation constraints
|-
! GZ4
! Jun-15
! Kawerau T13 Overload Proteciton Scheme
! Normally Disabled
! not required
! Pg6, section 4.7
!
|-
! GZ4
! Jun-15
! Maraetai Runback
! Normally enabled
!
! Pg6, section 4.8
! Manages Generation constraints
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ5
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ5
! Jun-15
! Redclyffe interconnecting Transformers Overload Protection Scheme
! Commission 2016
! Transformer protection
! Pg3, section 4.1
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ6
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ6
! Dec-14
! Hawera Reactor and Automatic Bus Splitting Scheme (ABSS)
! Not required
! Line protection from Outage
! Pg3, section 4.1
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ7
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ7
! Dec-14
! Tokannu 128 Intertrip Scheme
! Normally Enabled
! Line protection from Outage
! Pg4, section 4.1
!
|-
! GZ7
! Dec-14
! Bunnythorpe - Woodville 1 and 2 Overload Protection Scheme
! Normally enabled
! Line protection from overloading
! Pg4, section 4.2
! Manages Circuit overload
|-
! GZ7
! Dec-14
! Woodville 110 kV Bus Overload Protection Scheme
! usually Disabled
! Bus protection from overloading
! Pg4, section 4.3
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ8
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ8
! Jun-15
! Bunnythorpe - Woodville 1 and 2 Overload Protection Scheme
! Normally enabled
! Line protection from overloading
! Pg4, section 4.1
! Manages Circuit overload
|-
! GZ8
! Jun-15
! Bunnythorpe - Woodville 1 and 2 Overload Protection Scheme
! Normally enabled
! Line protection from overloading
! Pg4, section 4.1
! Manages Circuit overload
|-
! GZ8
! Jun-15
! Central Park Transformer Overload Protection Scheme
! usually Disabled
! Transformer Protection from overloading
! Pg5, section 4.2
!
|-
! GZ8
! Jun-15
! Mangamaire Overload Trip and Autochange Over Scheme (MGM OTAS)
! usually Disabled
! Line protection from overloading
! Pg5, section 4.3
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ9
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ9
! Dec-14
! Blenheim_Kikawa 110kV Circuit Overload Protection Scheme
! Normally enabled
! Line protection from Outage
! Pg4, section 4.1
!
|-
! GZ9
! Dec-14
! Kikiwa-Stoke 220 kV Outage Intertrip Scheme
! Normally Disabled
! Line protection from Outage
! Pg5, section 4.2
!
|-
! GZ9
! Dec-14
! Stoke T7 Outage interip Scheme
! Normally Disabled
! Transformer protection low generation
! Pg5, section 4.3
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ10 & GZ11
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ10&GZ11
! Jun-15
! Bells Pond Waitaki Overload Protection Scheme
! Normally Enabled
! Line protection from overloading
! Pg6, section 4.1
! Manages Circuit overload
|-
! GZ10&GZ11
! Jun-15
! Timaru Transformer Overloading Scheme
! Normally Enabled
! Transformer protection low generation
! Pg6, section 4.2
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ12
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ12
! Dec-14
! Coleridge Intertrip Scheme
! Normally Enabled
! Line protection from Outage
! Pg3, section 4.1
!
|-
! GZ12
! Dec-14
! Hororata Automatic Under Voltage
! Normally Enabled
! Load scheding from Line outage
! Pg3, section 4.2
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ13
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ13
! Jun-15
! Bells Pond Waitaki Overload Protection Scheme
! Normally Enabled
! Line protection from overloading
! Pg6, section 4.1
! Manages Circuit overload
|-
! GZ13
! Jun-15
! Roxburgh Export Overload Protection Scheme (REOLP)
! Normally Enabled
! Line protection from overloading
! Pg6, section 4.2
! Manages Circuit overload
|-
! GZ13
! Jun-15
! Roxburgh Import Overload Protection Scheme
! Enabled Southward Flow
! Line protection from overloading (increase Manapouri Generation)
! Pg7, section 4.4
! Manages Circuit overload
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ14
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ14
! Nov-15
! Manapouri Intertrip Scheme
! Normally Enabled
! Line protection from Outage
! Pg6, section 4.1
! Manages Generation constraints
|-
! GZ14
! Nov-15
! Halfway Bush Reverse power Protection Scheme
! Normally Enabled
! Line protection from Outage
! Pg6, section 4.2
!
|-
! GZ14
! Nov-15
! Roxburgh Import Overload Protection Scheme
! Enabled Southward Flow
! Line protection from overloading (increase Manapouri Generation)
! Pg7, section 4.4
! Manages Circuit overload
|-
! GZ14
! Nov-15
! Roxburgh Export Overload Protection Scheme (REOLP)
! Normally enabled
! Overload Protection
! Pg6, section 4.3
! Manages Circuit overload
|}

EMO:Constraint Overview

2016-02-24T01:46:28Z

NelsonM: /* Special Protection Schemes */

''References:
# [http://www.systemoperator.co.nz/documents/reports/system-security-forecast System Security Forecast (SSF), Part B, Section 7]
# [http://www.systemoperator.co.nz/system-operations/security-management/security-constraints Security constraints overview]

The SSF states that "Security Constraints may be applied [in SPD] to manage circuit loading:
* to ensure post-event circuit loading does not exceed short term ratings (15 minute off-load times);
* to ensure system stability is maintained following a contingent event;
* to ensure sufficient reactive power is available to maintain voltage levels following a contingent event."

The "'''15 minute off-load time'''" is the internationally recognised time required for the SO to redispatch after a contingency. Shorter off-load times may be in place with Special Protection Schemes ('''SPS''') in some cases.

The SSF states that "thermal current ratings ('''thermal ratings''') are determined from the maximum permissible temperature of the conductors to avoid excessive sag or long-term annealing of the conductors. The calculation does not consider environmental factors that may cool the conductor, therefore it is recognised that these static ratings are typically conservative and at times may result in under utilisation of circuits." The SO uses seasonal default ratings or variable line ratings for each line.

There three basic types of constraint: maunal constraints, SFT constraints and Special Protection Schemes.

==SFT Constraints==
From 28-Mar-11 the majority of constraints are formulated by the SO's Simultaneous Feasibility Test (SFT) software tool. SFT formuates constraints that protect circuits in the event of an N-1 failure of the grid. The constraint equation has the form

A x Protected Branch Flow + B x Contingent Branch Flow ≤ RHS

A and B are coefficients calculated by SFT. The RHS limit ensures that if the contingent branch fails, then the loading on the protected branch remains safe during the 15 off-load time, where 'safe' refers to the amount of sag in the line post-contingency.

==Manual Constraints==
Constraints that are not automatically generated by SFT may relate to Special Protection Schemes (see below) or may be created manually based on studies undertaken offline. Typical examples are the four voltge stability constraints that are there to ensure voltage is stable after a contingency in one of the main load centres, or over long lines.

The Manual Constraints can be permanent or only apply during outages, and are updated at http://www.systemoperator.co.nz/system-operations/security-management/security-constraints (see mid way down this page under Security Constraints and "Manual constraints under SFT ....xls".

==Special Protection Schemes==
Automatic SPS' are also known as "operational intertripping schemes" and the SPS activates "within the period of voltage recovery following fault clearance". In most cases, SPS' are designed to operate to avoid security violations without the need for additional constraints in SPD. According to the SSF, the following constraint equations relate specifically to SPS':

* Te Mihi Special Protection Scheme, constrain transfer from WRK bus.

1.24 * RPO_TNG1.1 + 0.50 * THI_WKM1.1 <= 315 MW

* Special Protection Schemes at KAW: Generation at KAW bus may need to be constrained in the event of high generation at KAW bus or sudden loss of interruptible loads. Security constraints on KAW are highly dependent on system configuration and conditions.

There are several types of SPS.

'''Overload Protection Schemes'''

A.k.a. intertripping schemes, these SPS open circuits that would otherwise overload. They trip the circuit if overloading continues for a specfied minimum time, allowing time for auto-reclose to work.

SPS that involve the action of busbar section circuit breakers to regulate power flows on the system are referred to as Auto Busbar Splitting Schemes (ABSS).

An intertrip that results in a system split is referred to as a System Split Intertrip Scheme (SSIS).

'''Planned Automatic Load Shedding'''

Typical examples are a load shedding scheme for Automatic Under Voltage Load Shedding (AUVLS) using voltage-sensitive relays and occuring within an 8 second time period. The load shedding scheme trips feeders in a sequence to bring load below an overload trip setpoint, or to bring voltage to within allowable limits.

'''Generation Run Back'''

These SPS automatically reduce generation to a pre-arranged value to remove circuit overloads or generator instability. If the circuit loading is not reduced within an inverse time-dependent period after a runback scheme operation has been initiated, the circuit will be tripped. Currenty Transpower has automatic runback schemes installed at Arapuni, Cobb, Maraetai and Te Apiti. Runback schemes may allow operation to 5 or 10 minute off-load times on monitored circuits rather than the standard 15 minute criteria.

'''Reactive Devices'''

The SO dispatches reactive devices so that dynamic reactive reserves are available to provide voltage support for Contingent Events and Extended Contingent Events.

'''Current SPS (Feb-16)'''

Data from System Security Forecast - Transpower Dec-15
http://www.systemoperator.co.nz/documents/reports/system-security-forecast

{| class="wikitable"
|-
! Transpower Grid Zone GZ1
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ1
! Jun-15
! Hepburn-Roskill 110 kV Overload Protection Scheme
! Normally Enabled
! Line protection from Outage
! Pg4, section 4.1
!
|-
! GZ1
! Jun-15
! Penrose Reactor Bypass Scheme
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.2
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ2
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ2
! Nov-15
! Penrose Circuit Overload Protection Scheme
! Normally Disabled
! Line protection from Outage
! Pg3, section 4.1
!
|-
! GZ2
! Nov-15
! Hepburn-Roskill 110 kV Overload Protection Scheme
! Normally Enabled
! Line protection from Outage
! Pg3, section 4.2
!
|-
! GZ2
! Nov-15
! Bombay 110 kV System Split Intertrip Scheme
! Normally Disabled
! Line protection from Outage
! Pg3, section 4.3
!
|-
! GZ2
! Nov-15
! Bombay_Otahuhu Overload Protecton Scheme
! Normally Disabled
! Line protection from Bus Split
! Pg4, section 4.4
!
|-
! GZ2
! Nov-15
! Penrose Reactor Bypass Scheme
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.5
!
|-
! GZ2
! Nov-15
! Otahuhu 110 kV Bus Split
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.6
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ3
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ3
! Jun-15
! Arapuni Runback Scheme
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.1
! Manages Generation constraints
|-
! GZ3
! Jun-15
! Arapuni Bus Split
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.2
! Manages Generation constraints
|-
! GZ3
! Jun-15
! Bombay 110 kV System Split Intertrip Scheme
! Normally Disabled
! Line protection from Outage
! Pg5, section 4.3
!
|-
! GZ3
! Jun-15
! Arapuni - Kinleith 110 kV Overload Protection Scheme
! Normally Disabled
! Line protection from Outage
! Pg5, section 4.4
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ4
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ4
! Jun-15
! Arapuni - Kinleith 110 kV Overload Protection Scheme
! Normally Disabled
! Line protection from Outage
! Pg5, section 4.1
!
|-
! GZ4
! Jun-15
! Kaitimaki Intertrip Scheme
! Normally Enabled
! Overload & line outage protection
! Pg5, section 4.2
! Manages Circuit overload
|-
! GZ4
! Jun-15
! Tokannu 128 Intertrip Scheme
! Normally Enabled
! Line protection from Outage
! Pg5, section 4.3
!
|-
! GZ4
! Jun-15
! Te Mihi Intertrip Scheme
! Line outage Criteria enabled
! Line protection from Outage
! Pg6, section 4.4
!
|-
! GZ4
! Jun-15
! Edgecumbe-Kawerau 1 & 2 Overload Protection Scheme
! Normally Enabled
! Line protection from Outage
! Pg6, section 4.5
!
|-
! GZ4
! Jun-15
! Edgecumbe-Owhata 2 Overload Proteciton Scheme
! Normally Enabled
! Overload Protection
! Pg6, section 4.6
! Manages Generation constraints
|-
! GZ4
! Jun-15
! Kawerau T13 Overload Proteciton Scheme
! Normally Disabled
! not required
! Pg6, section 4.7
!
|-
! GZ4
! Jun-15
! Maraetai Runback
! Normally enabled
!
! Pg6, section 4.8
! Manages Generation constraints
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ5
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ5
! Jun-15
! Redclyffe interconnecting Transformers Overload Protection Scheme
! Commission 2016
! Transformer protection
! Pg3, section 4.1
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ6
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ6
! Dec-14
! Hawera Reactor and Automatic Bus Splitting Scheme (ABSS)
! Not required
! Line protection from Outage
! Pg3, section 4.1
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ7
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ7
! Dec-14
! Tokannu 128 Intertrip Scheme
! Normally Enabled
! Line protection from Outage
! Pg4, section 4.1
!
|-
! GZ7
! Dec-14
! Bunnythorpe - Woodville 1 and 2 Overload Protection Scheme
! Normally enabled
! Line protection from overloading
! Pg4, section 4.2
! Manages Circuit overload
|-
! GZ7
! Dec-14
! Woodville 110 kV Bus Overload Protection Scheme
! usually Disabled
! Bus protection from overloading
! Pg4, section 4.3
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ8
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ8
! Jun-15
! Bunnythorpe - Woodville 1 and 2 Overload Protection Scheme
! Normally enabled
! Line protection from overloading
! Pg4, section 4.1
! Manages Circuit overload
|-
! GZ8
! Jun-15
! Bunnythorpe - Woodville 1 and 2 Overload Protection Scheme
! Normally enabled
! Line protection from overloading
! Pg4, section 4.1
! Manages Circuit overload
|-
! GZ8
! Jun-15
! Central Park Transformer Overload Protection Scheme
! usually Disabled
! Transformer Protection from overloading
! Pg5, section 4.2
!
|-
! GZ8
! Jun-15
! Mangamaire Overload Trip and Autochange Over Scheme (MGM OTAS)
! usually Disabled
! Line protection from overloading
! Pg5, section 4.3
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ9
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ9
! Dec-14
! Blenheim_Kikawa 110kV Circuit Overload Protection Scheme
! Normally enabled
! Line protection from Outage
! Pg4, section 4.1
!
|-
! GZ9
! Dec-14
! Kikiwa-Stoke 220 kV Outage Intertrip Scheme
! Normally Disabled
! Line protection from Outage
! Pg5, section 4.2
!
|-
! GZ9
! Dec-14
! Stoke T7 Outage interip Scheme
! Normally Disabled
! Transformer protection low generation
! Pg5, section 4.3
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ10 & GZ11
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ10&GZ11
! Jun-15
! Bells Pond Waitaki Overload Protection Scheme
! Normally Enabled
! Line protection from overloading
! Pg6, section 4.1
! Manages Circuit overload
|-
! GZ10&GZ11
! Jun-15
! Timaru Transformer Overloading Scheme
! Normally Enabled
! Transformer protection low generation
! Pg6, section 4.2
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ12
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ12
! Dec-14
! Coleridge Intertrip Scheme
! Normally Enabled
! Line protection from Outage
! Pg3, section 4.1
!
|-
! GZ12
! Dec-14
! Hororata Automatic Under Voltage
! Normally Enabled
! Load scheding from Line outage
! Pg3, section 4.2
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ13
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ13
! Jun-15
! Bells Pond Waitaki Overload Protection Scheme
! Normally Enabled
! Line protection from overloading
! Pg6, section 4.1
! Manages Circuit overload
|-
! GZ13
! Jun-15
! Roxburgh Export Overload Protection Scheme (REOLP)
! Normally Enabled
! Line protection from overloading
! Pg6, section 4.2
! Manages Circuit overload
|-
! GZ13
! Jun-15
! Roxburgh Import Overload Protection Scheme
! Enabled Southward Flow
! Line protection from overloading (increase Manapouri Generation)
! Pg7, section 4.4
! Manages Circuit overload
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ14
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ14
! Nov-15
! Manapouri Intertrip Scheme
! Normally Enabled
! Line protection from Outage
! Pg6, section 4.1
! Manages Generation constraints
|-
! GZ14
! Nov-15
! Halfway Bush Reverse power Protection Scheme
! Normally Enabled
! Line protection from Outage
! Pg6, section 4.2
!
|-
! GZ14
! Nov-15
! Roxburgh Import Overload Protection Scheme
! Enabled Southward Flow
! Line protection from overloading (increase Manapouri Generation)
! Pg7, section 4.4
! Manages Circuit overload
|-
! GZ14
! Nov-15
! Roxburgh Export Overload Protection Scheme (REOLP)
! Normally enabled
! Overload Protection
! Pg6, section 4.3
! Manages Circuit overload
|}

EMO:Constraint Overview

2016-02-24T01:45:02Z

NelsonM: /* Special Protection Schemes */

''References:
# [http://www.systemoperator.co.nz/documents/reports/system-security-forecast System Security Forecast (SSF), Part B, Section 7]
# [http://www.systemoperator.co.nz/system-operations/security-management/security-constraints Security constraints overview]

The SSF states that "Security Constraints may be applied [in SPD] to manage circuit loading:
* to ensure post-event circuit loading does not exceed short term ratings (15 minute off-load times);
* to ensure system stability is maintained following a contingent event;
* to ensure sufficient reactive power is available to maintain voltage levels following a contingent event."

The "'''15 minute off-load time'''" is the internationally recognised time required for the SO to redispatch after a contingency. Shorter off-load times may be in place with Special Protection Schemes ('''SPS''') in some cases.

The SSF states that "thermal current ratings ('''thermal ratings''') are determined from the maximum permissible temperature of the conductors to avoid excessive sag or long-term annealing of the conductors. The calculation does not consider environmental factors that may cool the conductor, therefore it is recognised that these static ratings are typically conservative and at times may result in under utilisation of circuits." The SO uses seasonal default ratings or variable line ratings for each line.

There three basic types of constraint: maunal constraints, SFT constraints and Special Protection Schemes.

==SFT Constraints==
From 28-Mar-11 the majority of constraints are formulated by the SO's Simultaneous Feasibility Test (SFT) software tool. SFT formuates constraints that protect circuits in the event of an N-1 failure of the grid. The constraint equation has the form

A x Protected Branch Flow + B x Contingent Branch Flow ≤ RHS

A and B are coefficients calculated by SFT. The RHS limit ensures that if the contingent branch fails, then the loading on the protected branch remains safe during the 15 off-load time, where 'safe' refers to the amount of sag in the line post-contingency.

==Manual Constraints==
Constraints that are not automatically generated by SFT may relate to Special Protection Schemes (see below) or may be created manually based on studies undertaken offline. Typical examples are the four voltge stability constraints that are there to ensure voltage is stable after a contingency in one of the main load centres, or over long lines.

The Manual Constraints can be permanent or only apply during outages, and are updated at http://www.systemoperator.co.nz/system-operations/security-management/security-constraints (see mid way down this page under Security Constraints and "Manual constraints under SFT ....xls".

==Special Protection Schemes==
Automatic SPS' are also known as "operational intertripping schemes" and the SPS activates "within the period of voltage recovery following fault clearance". In most cases, SPS' are designed to operate to avoid security violations without the need for additional constraints in SPD. According to the SSF, the following constraint equations relate specifically to SPS':

* Te Mihi Special Protection Scheme, constrain transfer from WRK bus.

1.24 * RPO_TNG1.1 + 0.50 * THI_WKM1.1 <= 315 MW

* Special Protection Schemes at KAW: Generation at KAW bus may need to be constrained in the event of high generation at KAW bus or sudden loss of interruptible loads. Security constraints on KAW are highly dependent on system configuration and conditions.

There are several types of SPS.

'''Overload Protection Schemes'''

A.k.a. intertripping schemes, these SPS open circuits that would otherwise overload. They trip the circuit if overloading continues for a specfied minimum time, allowing time for auto-reclose to work.

SPS that involve the action of busbar section circuit breakers to regulate power flows on the system are referred to as Auto Busbar Splitting Schemes (ABSS).

An intertrip that results in a system split is referred to as a System Split Intertrip Scheme (SSIS).

'''Planned Automatic Load Shedding'''

Typical examples are a load shedding scheme for Automatic Under Voltage Load Shedding (AUVLS) using voltage-sensitive relays and occuring within an 8 second time period. The load shedding scheme trips feeders in a sequence to bring load below an overload trip setpoint, or to bring voltage to within allowable limits.

'''Generation Run Back'''

These SPS automatically reduce generation to a pre-arranged value to remove circuit overloads or generator instability. If the circuit loading is not reduced within an inverse time-dependent period after a runback scheme operation has been initiated, the circuit will be tripped. Currenty Transpower has automatic runback schemes installed at Arapuni, Cobb, Maraetai and Te Apiti. Runback schemes may allow operation to 5 or 10 minute off-load times on monitored circuits rather than the standard 15 minute criteria.

'''Reactive Devices'''

The SO dispatches reactive devices so that dynamic reactive reserves are available to provide voltage support for Contingent Events and Extended Contingent Events.

'''Current SPS (Feb-16)'''

Data from System Security Forecast - Transpower Dec-15
http://www.systemoperator.co.nz/documents/reports/system-security-forecast

{| class="wikitable"
|-
! Transpower Grid Zone GZ1
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ1
! Jun-15
! Hepburn-Roskill 110 kV Overload Protection Scheme
! Normally Enabled
! Line protection from Outage
! Pg4, section 4.1
!
|-
! GZ1
! Jun-15
! Penrose Reactor Bypass Scheme
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.2
!
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ2
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ2
! Nov-15
! Penrose Circuit Overload Protection Scheme
! Normally Disabled
! Line protection from Outage
! Pg3, section 4.1
!
|-
! GZ2
! Nov-15
! Hepburn-Roskill 110 kV Overload Protection Scheme
! Normally Enabled
! Line protection from Outage
! Pg3, section 4.2
!
|-
! GZ2
! Nov-15
! Bombay 110 kV System Split Intertrip Scheme
! Normally Disabled
! Line protection from Outage
! Pg3, section 4.3
!
|-
! GZ2
! Nov-15
! Bombay_Otahuhu Overload Protecton Scheme
! Normally Disabled
! Line protection from Bus Split
! Pg4, section 4.4
!
|-
! GZ2
! Nov-15
! Penrose Reactor Bypass Scheme
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.5
!
|-
! GZ2
! Nov-15
! Otahuhu 110 kV Bus Split
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.6
!
|-
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ3
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ3
! Jun-15
! Arapuni Runback Scheme
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.1
! Manages Generation constraints
|-
! GZ3
! Jun-15
! Arapuni Bus Split
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.2
! Manages Generation constraints
|-
! GZ3
! Jun-15
! Bombay 110 kV System Split Intertrip Scheme
! Normally Disabled
! Line protection from Outage
! Pg5, section 4.3
!
|-
! GZ3
! Jun-15
! Arapuni - Kinleith 110 kV Overload Protection Scheme
! Normally Disabled
! Line protection from Outage
! Pg5, section 4.4
!
|-
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ4
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ4
! Jun-15
! Arapuni - Kinleith 110 kV Overload Protection Scheme
! Normally Disabled
! Line protection from Outage
! Pg5, section 4.1
!
|-
! GZ4
! Jun-15
! Kaitimaki Intertrip Scheme
! Normally Enabled
! Overload & line outage protection
! Pg5, section 4.2
! Manages Circuit overload
|-
! GZ4
! Jun-15
! Tokannu 128 Intertrip Scheme
! Normally Enabled
! Line protection from Outage
! Pg5, section 4.3
!
|-
! GZ4
! Jun-15
! Te Mihi Intertrip Scheme
! Line outage Criteria enabled
! Line protection from Outage
! Pg6, section 4.4
!
|-
! GZ4
! Jun-15
! Edgecumbe-Kawerau 1 & 2 Overload Protection Scheme
! Normally Enabled
! Line protection from Outage
! Pg6, section 4.5
!
|-
! GZ4
! Jun-15
! Edgecumbe-Owhata 2 Overload Proteciton Scheme
! Normally Enabled
! Overload Protection
! Pg6, section 4.6
! Manages Generation constraints
|-
! GZ4
! Jun-15
! Kawerau T13 Overload Proteciton Scheme
! Normally Disabled
! not required
! Pg6, section 4.7
!
|-
! GZ4
! Jun-15
! Maraetai Runback
! Normally enabled
!
! Pg6, section 4.8
! Manages Generation constraints
|-
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ5
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ5
! Jun-15
! Redclyffe interconnecting Transformers Overload Protection Scheme
! Commission 2016
! Transformer protection
! Pg3, section 4.1
!
|-
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ6
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ6
! Dec-14
! Hawera Reactor and Automatic Bus Splitting Scheme (ABSS)
! Not required
! Line protection from Outage
! Pg3, section 4.1
!
|-
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ7
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ7
! Dec-14
! Tokannu 128 Intertrip Scheme
! Normally Enabled
! Line protection from Outage
! Pg4, section 4.1
!
|-
! GZ7
! Dec-14
! Bunnythorpe - Woodville 1 and 2 Overload Protection Scheme
! Normally enabled
! Line protection from overloading
! Pg4, section 4.2
! Manages Circuit overload
|-
! GZ7
! Dec-14
! Woodville 110 kV Bus Overload Protection Scheme
! usually Disabled
! Bus protection from overloading
! Pg4, section 4.3
!
|-
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ8
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ8
! Jun-15
! Bunnythorpe - Woodville 1 and 2 Overload Protection Scheme
! Normally enabled
! Line protection from overloading
! Pg4, section 4.1
! Manages Circuit overload
|-
! GZ8
! Jun-15
! Bunnythorpe - Woodville 1 and 2 Overload Protection Scheme
! Normally enabled
! Line protection from overloading
! Pg4, section 4.1
! Manages Circuit overload
|-
! GZ8
! Jun-15
! Central Park Transformer Overload Protection Scheme
! usually Disabled
! Transformer Protection from overloading
! Pg5, section 4.2
!
|-
! GZ8
! Jun-15
! Mangamaire Overload Trip and Autochange Over Scheme (MGM OTAS)
! usually Disabled
! Line protection from overloading
! Pg5, section 4.3
!
|-
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ9
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ9
! Dec-14
! Blenheim_Kikawa 110kV Circuit Overload Protection Scheme
! Normally enabled
! Line protection from Outage
! Pg4, section 4.1
!
|-
! GZ9
! Dec-14
! Kikiwa-Stoke 220 kV Outage Intertrip Scheme
! Normally Disabled
! Line protection from Outage
! Pg5, section 4.2
!
|-
! GZ9
! Dec-14
! Stoke T7 Outage interip Scheme
! Normally Disabled
! Transformer protection low generation
! Pg5, section 4.3
!
|-
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ10 & GZ11
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ10&GZ11
! Jun-15
! Bells Pond Waitaki Overload Protection Scheme
! Normally Enabled
! Line protection from overloading
! Pg6, section 4.1
! Manages Circuit overload
|-
! GZ10&GZ11
! Jun-15
! Timaru Transformer Overloading Scheme
! Normally Enabled
! Transformer protection low generation
! Pg6, section 4.2
!
|-
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ12
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ12
! Dec-14
! Coleridge Intertrip Scheme
! Normally Enabled
! Line protection from Outage
! Pg3, section 4.1
!
|-
! GZ12
! Dec-14
! Hororata Automatic Under Voltage
! Normally Enabled
! Load scheding from Line outage
! Pg3, section 4.2
!
|-
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ13
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ13
! Jun-15
! Bells Pond Waitaki Overload Protection Scheme
! Normally Enabled
! Line protection from overloading
! Pg6, section 4.1
! Manages Circuit overload
|-
! GZ13
! Jun-15
! Roxburgh Export Overload Protection Scheme (REOLP)
! Normally Enabled
! Line protection from overloading
! Pg6, section 4.2
! Manages Circuit overload
|-
! GZ13
! Jun-15
! Roxburgh Import Overload Protection Scheme
! Enabled Southward Flow
! Line protection from overloading (increase Manapouri Generation)
! Pg7, section 4.4
! Manages Circuit overload
|-
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ14
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ14
! Nov-15
! Manapouri Intertrip Scheme
! Normally Enabled
! Line protection from Outage
! Pg6, section 4.1
! Manages Generation constraints
|-
! GZ14
! Nov-15
! Halfway Bush Reverse power Protection Scheme
! Normally Enabled
! Line protection from Outage
! Pg6, section 4.2
!
|-
! GZ14
! Nov-15
! Roxburgh Import Overload Protection Scheme
! Enabled Southward Flow
! Line protection from overloading (increase Manapouri Generation)
! Pg7, section 4.4
! Manages Circuit overload
|-
! GZ14
! Nov-15
! Roxburgh Export Overload Protection Scheme (REOLP)
! Normally enabled
! Overload Protection
! Pg6, section 4.3
! Manages Circuit overload
|-
|}

EMO:Constraint Overview

2016-02-24T01:43:18Z

NelsonM: /* Special Protection Schemes */

''References:
# [http://www.systemoperator.co.nz/documents/reports/system-security-forecast System Security Forecast (SSF), Part B, Section 7]
# [http://www.systemoperator.co.nz/system-operations/security-management/security-constraints Security constraints overview]

The SSF states that "Security Constraints may be applied [in SPD] to manage circuit loading:
* to ensure post-event circuit loading does not exceed short term ratings (15 minute off-load times);
* to ensure system stability is maintained following a contingent event;
* to ensure sufficient reactive power is available to maintain voltage levels following a contingent event."

The "'''15 minute off-load time'''" is the internationally recognised time required for the SO to redispatch after a contingency. Shorter off-load times may be in place with Special Protection Schemes ('''SPS''') in some cases.

The SSF states that "thermal current ratings ('''thermal ratings''') are determined from the maximum permissible temperature of the conductors to avoid excessive sag or long-term annealing of the conductors. The calculation does not consider environmental factors that may cool the conductor, therefore it is recognised that these static ratings are typically conservative and at times may result in under utilisation of circuits." The SO uses seasonal default ratings or variable line ratings for each line.

There three basic types of constraint: maunal constraints, SFT constraints and Special Protection Schemes.

==SFT Constraints==
From 28-Mar-11 the majority of constraints are formulated by the SO's Simultaneous Feasibility Test (SFT) software tool. SFT formuates constraints that protect circuits in the event of an N-1 failure of the grid. The constraint equation has the form

A x Protected Branch Flow + B x Contingent Branch Flow ≤ RHS

A and B are coefficients calculated by SFT. The RHS limit ensures that if the contingent branch fails, then the loading on the protected branch remains safe during the 15 off-load time, where 'safe' refers to the amount of sag in the line post-contingency.

==Manual Constraints==
Constraints that are not automatically generated by SFT may relate to Special Protection Schemes (see below) or may be created manually based on studies undertaken offline. Typical examples are the four voltge stability constraints that are there to ensure voltage is stable after a contingency in one of the main load centres, or over long lines.

The Manual Constraints can be permanent or only apply during outages, and are updated at http://www.systemoperator.co.nz/system-operations/security-management/security-constraints (see mid way down this page under Security Constraints and "Manual constraints under SFT ....xls".

==Special Protection Schemes==
Automatic SPS' are also known as "operational intertripping schemes" and the SPS activates "within the period of voltage recovery following fault clearance". In most cases, SPS' are designed to operate to avoid security violations without the need for additional constraints in SPD. According to the SSF, the following constraint equations relate specifically to SPS':

* Te Mihi Special Protection Scheme, constrain transfer from WRK bus.

1.24 * RPO_TNG1.1 + 0.50 * THI_WKM1.1 <= 315 MW

* Special Protection Schemes at KAW: Generation at KAW bus may need to be constrained in the event of high generation at KAW bus or sudden loss of interruptible loads. Security constraints on KAW are highly dependent on system configuration and conditions.

There are several types of SPS.

'''Overload Protection Schemes'''

A.k.a. intertripping schemes, these SPS open circuits that would otherwise overload. They trip the circuit if overloading continues for a specfied minimum time, allowing time for auto-reclose to work.

SPS that involve the action of busbar section circuit breakers to regulate power flows on the system are referred to as Auto Busbar Splitting Schemes (ABSS).

An intertrip that results in a system split is referred to as a System Split Intertrip Scheme (SSIS).

'''Planned Automatic Load Shedding'''

Typical examples are a load shedding scheme for Automatic Under Voltage Load Shedding (AUVLS) using voltage-sensitive relays and occuring within an 8 second time period. The load shedding scheme trips feeders in a sequence to bring load below an overload trip setpoint, or to bring voltage to within allowable limits.

'''Generation Run Back'''

These SPS automatically reduce generation to a pre-arranged value to remove circuit overloads or generator instability. If the circuit loading is not reduced within an inverse time-dependent period after a runback scheme operation has been initiated, the circuit will be tripped. Currenty Transpower has automatic runback schemes installed at Arapuni, Cobb, Maraetai and Te Apiti. Runback schemes may allow operation to 5 or 10 minute off-load times on monitored circuits rather than the standard 15 minute criteria.

'''Reactive Devices'''

The SO dispatches reactive devices so that dynamic reactive reserves are available to provide voltage support for Contingent Events and Extended Contingent Events.

'''Current SPS (Feb-16)'''

Data from System Security Forecast - Transpower Dec-15
http://www.systemoperator.co.nz/documents/reports/system-security-forecast

{| class="wikitable"
|-
! Transpower Grid Zone GZ1
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ1
! Jun-15
! Hepburn-Roskill 110 kV Overload Protection Scheme
! Normally Enabled
! Line protection from Outage
! Pg4, section 4.1
!
|-
! GZ1
! Jun-15
! Penrose Reactor Bypass Scheme
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.2
!
|-
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ2
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ2
! Nov-15
! Penrose Circuit Overload Protection Scheme
! Normally Disabled
! Line protection from Outage
! Pg3, section 4.1
!
|-
! GZ2
! Nov-15
! Hepburn-Roskill 110 kV Overload Protection Scheme
! Normally Enabled
! Line protection from Outage
! Pg3, section 4.2
!
|-
! GZ2
! Nov-15
! Bombay 110 kV System Split Intertrip Scheme
! Normally Disabled
! Line protection from Outage
! Pg3, section 4.3
!
|-
! GZ2
! Nov-15
! Bombay_Otahuhu Overload Protecton Scheme
! Normally Disabled
! Line protection from Bus Split
! Pg4, section 4.4
!
|-
! GZ2
! Nov-15
! Penrose Reactor Bypass Scheme
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.5
!
|-
! GZ2
! Nov-15
! Otahuhu 110 kV Bus Split
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.6
!
|-
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ3
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ3
! Jun-15
! Arapuni Runback Scheme
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.1
! Manages Generation constraints
|-
! GZ3
! Jun-15
! Arapuni Bus Split
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.2
! Manages Generation constraints
|-
! GZ3
! Jun-15
! Bombay 110 kV System Split Intertrip Scheme
! Normally Disabled
! Line protection from Outage
! Pg5, section 4.3
!
|-
! GZ3
! Jun-15
! Arapuni - Kinleith 110 kV Overload Protection Scheme
! Normally Disabled
! Line protection from Outage
! Pg5, section 4.4
!
|-
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ4
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ4
! Jun-15
! Arapuni - Kinleith 110 kV Overload Protection Scheme
! Normally Disabled
! Line protection from Outage
! Pg5, section 4.1
!
|-
! GZ4
! Jun-15
! Kaitimaki Intertrip Scheme
! Normally Enabled
! Overload & line outage protection
! Pg5, section 4.2
! Manages Circuit overload
|-
! GZ4
! Jun-15
! Tokannu 128 Intertrip Scheme
! Normally Enabled
! Line protection from Outage
! Pg5, section 4.3
!
|-
! GZ4
! Jun-15
! Te Mihi Intertrip Scheme
! Line outage Criteria enabled
! Line protection from Outage
! Pg6, section 4.4
!
|-
! GZ4
! Jun-15
! Edgecumbe-Kawerau 1 & 2 Overload Protection Scheme
! Normally Enabled
! Line protection from Outage
! Pg6, section 4.5
!
|-
! GZ4
! Jun-15
! Edgecumbe-Owhata 2 Overload Proteciton Scheme
! Normally Enabled
! Overload Protection
! Pg6, section 4.6
! Manages Generation constraints
|-
! GZ4
! Jun-15
! Kawerau T13 Overload Proteciton Scheme
! Normally Disabled
! not required
! Pg6, section 4.7
!
|-
! GZ4
! Jun-15
! Maraetai Runback
! Normally enabled
!
! Pg6, section 4.8
! Manages Generation constraints
|-
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ5
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ5
! Jun-15
! Redclyffe interconnecting Transformers Overload Protection Scheme
! Commission 2016
! Transformer protection
! Pg3, section 4.1
!
|-
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ6
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ6
! Dec-14
! Hawera Reactor and Automatic Bus Splitting Scheme (ABSS)
! Not required
! Line protection from Outage
! Pg3, section 4.1
!
|-
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ7
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ7
! Dec-14
! Tokannu 128 Intertrip Scheme
! Normally Enabled
! Line protection from Outage
! Pg4, section 4.1
!
|-
! GZ7
! Dec-14
! Bunnythorpe - Woodville 1 and 2 Overload Protection Scheme
! Normally enabled
! Line protection from overloading
! Pg4, section 4.2
! Manages Circuit overload
|-
! GZ7
! Dec-14
! Woodville 110 kV Bus Overload Protection Scheme
! usually Disabled
! Bus protection from overloading
! Pg4, section 4.3
!
|-
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ8
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ8
! Jun-15
! Bunnythorpe - Woodville 1 and 2 Overload Protection Scheme
! Normally enabled
! Line protection from overloading
! Pg4, section 4.1
! Manages Circuit overload
|-
! GZ8
! Jun-15
! Bunnythorpe - Woodville 1 and 2 Overload Protection Scheme
! Normally enabled
! Line protection from overloading
! Pg4, section 4.1
! Manages Circuit overload
|-
! GZ8
! Jun-15
! Central Park Transformer Overload Protection Scheme
! usually Disabled
! Transformer Protection from overloading
! Pg5, section 4.2
!
|-
! GZ8
! Jun-15
! Mangamaire Overload Trip and Autochange Over Scheme (MGM OTAS)
! usually Disabled
! Line protection from overloading
! Pg5, section 4.3
!
|-
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ9
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ9
! Dec-14
! Blenheim_Kikawa 110kV Circuit Overload Protection Scheme
! Normally enabled
! Line protection from Outage
! Pg4, section 4.1
!
|-
! GZ9
! Dec-14
! Kikiwa-Stoke 220 kV Outage Intertrip Scheme
! Normally Disabled
! Line protection from Outage
! Pg5, section 4.2
!
|-
! GZ9
! Dec-14
! Stoke T7 Outage interip Scheme
! Normally Disabled
! Transformer protection low generation
! Pg5, section 4.3
!
|-
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ10 & GZ11
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ10&GZ11
! Jun-15
! Bells Pond Waitaki Overload Protection Scheme
! Normally Enabled
! Line protection from overloading
! Pg6, section 4.1
! Manages Circuit overload
|-
! GZ10&GZ11
! Jun-15
! Timaru Transformer Overloading Scheme
! Normally Enabled
! Transformer protection low generation
! Pg6, section 4.2
!
|-
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ12
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ12
! Dec-14
! Coleridge Intertrip Scheme
! Normally Enabled
! Line protection from Outage
! Pg3, section 4.1
!
|-
! GZ12
! Dec-14
! Hororata Automatic Under Voltage
! Normally Enabled
! Load scheding from Line outage
! Pg3, section 4.2
!
|-
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ13
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ13
! Jun-15
! Bells Pond Waitaki Overload Protection Scheme
! Normally Enabled
! Line protection from overloading
! Pg6, section 4.1
! Manages Circuit overload
|-
! GZ13
! Jun-15
! Roxburgh Export Overload Protection Scheme (REOLP)
! Normally Enabled
! Line protection from overloading
! Pg6, section 4.2
! Manages Circuit overload
|-
! GZ13
! Jun-15
! Roxburgh Import Overload Protection Scheme
! Enabled Southward Flow
! Line protection from overloading (increase Manapouri Generation)
! Pg7, section 4.4
! Manages Circuit overload
|-
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ14
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ14
! Nov-15
! Manapouri Intertrip Scheme
! Normally Enabled
! Line protection from Outage
! Pg6, section 4.1
! Manages Generation constraints
|-
! GZ14
! Nov-15
! Halfway Bush Reverse power Protection Scheme
! Normally Enabled
! Line protection from Outage
! Pg6, section 4.2
!
|-
! GZ14
! Nov-15
! Roxburgh Import Overload Protection Scheme
! Enabled Southward Flow
! Line protection from overloading (increase Manapouri Generation)
! Pg7, section 4.4
! Manages Circuit overload
|-
! GZ14
! Nov-15
! Roxburgh Export Overload Protection Scheme (REOLP)
! Normally enabled
! Overload Protection
! Pg6, section 4.3
! Manages Circuit overload
|-
|}

EMO:Constraint Overview

2016-02-24T01:39:24Z

NelsonM: /* Special Protection Schemes */

''References:
# [http://www.systemoperator.co.nz/documents/reports/system-security-forecast System Security Forecast (SSF), Part B, Section 7]
# [http://www.systemoperator.co.nz/system-operations/security-management/security-constraints Security constraints overview]

The SSF states that "Security Constraints may be applied [in SPD] to manage circuit loading:
* to ensure post-event circuit loading does not exceed short term ratings (15 minute off-load times);
* to ensure system stability is maintained following a contingent event;
* to ensure sufficient reactive power is available to maintain voltage levels following a contingent event."

The "'''15 minute off-load time'''" is the internationally recognised time required for the SO to redispatch after a contingency. Shorter off-load times may be in place with Special Protection Schemes ('''SPS''') in some cases.

The SSF states that "thermal current ratings ('''thermal ratings''') are determined from the maximum permissible temperature of the conductors to avoid excessive sag or long-term annealing of the conductors. The calculation does not consider environmental factors that may cool the conductor, therefore it is recognised that these static ratings are typically conservative and at times may result in under utilisation of circuits." The SO uses seasonal default ratings or variable line ratings for each line.

There three basic types of constraint: maunal constraints, SFT constraints and Special Protection Schemes.

==SFT Constraints==
From 28-Mar-11 the majority of constraints are formulated by the SO's Simultaneous Feasibility Test (SFT) software tool. SFT formuates constraints that protect circuits in the event of an N-1 failure of the grid. The constraint equation has the form

A x Protected Branch Flow + B x Contingent Branch Flow ≤ RHS

A and B are coefficients calculated by SFT. The RHS limit ensures that if the contingent branch fails, then the loading on the protected branch remains safe during the 15 off-load time, where 'safe' refers to the amount of sag in the line post-contingency.

==Manual Constraints==
Constraints that are not automatically generated by SFT may relate to Special Protection Schemes (see below) or may be created manually based on studies undertaken offline. Typical examples are the four voltge stability constraints that are there to ensure voltage is stable after a contingency in one of the main load centres, or over long lines.

The Manual Constraints can be permanent or only apply during outages, and are updated at http://www.systemoperator.co.nz/system-operations/security-management/security-constraints (see mid way down this page under Security Constraints and "Manual constraints under SFT ....xls".

==Special Protection Schemes==
Automatic SPS' are also known as "operational intertripping schemes" and the SPS activates "within the period of voltage recovery following fault clearance". In most cases, SPS' are designed to operate to avoid security violations without the need for additional constraints in SPD. According to the SSF, the following constraint equations relate specifically to SPS':

* Te Mihi Special Protection Scheme, constrain transfer from WRK bus.

1.24 * RPO_TNG1.1 + 0.50 * THI_WKM1.1 <= 315 MW

* Special Protection Schemes at KAW: Generation at KAW bus may need to be constrained in the event of high generation at KAW bus or sudden loss of interruptible loads. Security constraints on KAW are highly dependent on system configuration and conditions.

There are several types of SPS.

'''Overload Protection Schemes'''

A.k.a. intertripping schemes, these SPS open circuits that would otherwise overload. They trip the circuit if overloading continues for a specfied minimum time, allowing time for auto-reclose to work.

SPS that involve the action of busbar section circuit breakers to regulate power flows on the system are referred to as Auto Busbar Splitting Schemes (ABSS).

An intertrip that results in a system split is referred to as a System Split Intertrip Scheme (SSIS).

'''Planned Automatic Load Shedding'''

Typical examples are a load shedding scheme for Automatic Under Voltage Load Shedding (AUVLS) using voltage-sensitive relays and occuring within an 8 second time period. The load shedding scheme trips feeders in a sequence to bring load below an overload trip setpoint, or to bring voltage to within allowable limits.

'''Generation Run Back'''

These SPS automatically reduce generation to a pre-arranged value to remove circuit overloads or generator instability. If the circuit loading is not reduced within an inverse time-dependent period after a runback scheme operation has been initiated, the circuit will be tripped. Currenty Transpower has automatic runback schemes installed at Arapuni, Cobb, Maraetai and Te Apiti. Runback schemes may allow operation to 5 or 10 minute off-load times on monitored circuits rather than the standard 15 minute criteria.

'''Reactive Devices'''

The SO dispatches reactive devices so that dynamic reactive reserves are available to provide voltage support for Contingent Events and Extended Contingent Events.

'''Current SPS (Feb-16)'''

Data from System Security Forecast - Transpower Dec-15
http://www.systemoperator.co.nz/documents/reports/system-security-forecast

{| class="wikitable"
|-
! Transpower Grid Zone GZ1
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ1
! Jun-15
! Hepburn-Roskill 110 kV Overload Protection Scheme
! Normally Enabled
! Line protection from Outage
! Pg4, section 4.1
!
|-
! GZ1
! Jun-15
! Penrose Reactor Bypass Scheme
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.2
!
|-
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ2
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ2
! Nov-15
! Penrose Circuit Overload Protection Scheme
! Normally Disabled
! Line protection from Outage
! Pg3, section 4.1
!
|-
! GZ2
! Nov-15
! Hepburn-Roskill 110 kV Overload Protection Scheme
! Normally Enabled
! Line protection from Outage
! Pg3, section 4.2
!
|-
! GZ2
! Nov-15
! Bombay 110 kV System Split Intertrip Scheme
! Normally Disabled
! Line protection from Outage
! Pg3, section 4.3
!
|-
! GZ2
! Nov-15
! Bombay_Otahuhu Overload Protecton Scheme
! Normally Disabled
! Line protection from Bus Split
! Pg4, section 4.4
!
|-
! GZ2
! Nov-15
! Penrose Reactor Bypass Scheme
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.5
!
|-
! GZ2
! Nov-15
! Otahuhu 110 kV Bus Split
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.6
!
|-
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ3
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ3
! Jun-15
! Arapuni Runback Scheme
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.1
! Manages Generation constraints
|-
! GZ3
! Jun-15
! Arapuni Bus Split
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.2
! Manages Generation constraints
|-
! GZ3
! Jun-15
! Bombay 110 kV System Split Intertrip Scheme
! Normally Disabled
! Line protection from Outage
! Pg5, section 4.3
!
|-
! GZ3
! Jun-15
! Arapuni - Kinleith 110 kV Overload Protection Scheme
! Normally Disabled
! Line protection from Outage
! Pg5, section 4.4
!
|-
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ4
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ4
! Jun-15
! Arapuni - Kinleith 110 kV Overload Protection Scheme
! Normally Disabled
! Line protection from Outage
! Pg5, section 4.1
!
|-
! GZ4
! Jun-15
! Kaitimaki Intertrip Scheme
! Normally Enabled
! Overload & line outage protection
! Pg5, section 4.2
! Manages Circuit overload
|-
! GZ4
! Jun-15
! Tokannu 128 Intertrip Scheme
! Normally Enabled
! Line protection from Outage
! Pg5, section 4.3
!
|-
! GZ4
! Jun-15
! Te Mihi Intertrip Scheme
! Line outage Criteria enabled
! Line protection from Outage
! Pg6, section 4.4
!
|-
! GZ4
! Jun-15
! Edgecumbe-Kawerau 1 & 2 Overload Protection Scheme
! Normally Enabled
! Line protection from Outage
! Pg6, section 4.5
!
|-
! GZ4
! Jun-15
! Edgecumbe-Owhata 2 Overload Proteciton Scheme
! Normally Enabled
! Overload Protection
! Pg6, section 4.6
! Manages Generation constraints
|-
! GZ4
! Jun-15
! Kawerau T13 Overload Proteciton Scheme
! Normally Disabled
! not required
! Pg6, section 4.7
!
|-
! GZ4
! Jun-15
! Maraetai Runback
! Normally enabled
!
! Pg6, section 4.8
! Manages Generation constraints
|-
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ5
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ5
! Jun-15
! Redclyffe interconnecting Transformers Overload Protection Scheme
! Commission 2016
! Transformer protection
! Pg3, section 4.1
!
|-
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ6
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ6
! Dec-14
! Hawera Reactor and Automatic Bus Splitting Scheme (ABSS)
! Not required
! Line protection from Outage
! Pg3, section 4.1
!
|-
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ7
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ7
! Dec-14
! Tokannu 128 Intertrip Scheme
! Normally Enabled
! Line protection from Outage
! Pg4, section 4.1
!
|-
! GZ7
! Dec-14
! Bunnythorpe - Woodville 1 and 2 Overload Protection Scheme
! Normally enabled
! Line protection from overloading
! Pg4, section 4.2
! Manages Circuit overload
|-
! GZ7
! Dec-14
! Woodville 110 kV Bus Overload Protection Scheme
! usually Disabled
! Bus protection from overloading
! Pg4, section 4.3
!
|-
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ8
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ8
! Jun-15
! Bunnythorpe - Woodville 1 and 2 Overload Protection Scheme
! Normally enabled
! Line protection from overloading
! Pg4, section 4.1
! Manages Circuit overload
|-
! GZ8
! Jun-15
! Bunnythorpe - Woodville 1 and 2 Overload Protection Scheme
! Normally enabled
! Line protection from overloading
! Pg4, section 4.1
! Manages Circuit overload
|-
! GZ8
! Jun-15
! Central Park Transformer Overload Protection Scheme
! usually Disabled
! Transformer Protection from overloading
! Pg5, section 4.2
!
|-
! GZ8
! Jun-15
! Mangamaire Overload Trip and Autochange Over Scheme (MGM OTAS)
! usually Disabled
! Line protection from overloading
! Pg5, section 4.3
!
|-
|}

EMO:Constraint Overview

2016-02-24T01:37:46Z

NelsonM: /* Special Protection Schemes */

''References:
# [http://www.systemoperator.co.nz/documents/reports/system-security-forecast System Security Forecast (SSF), Part B, Section 7]
# [http://www.systemoperator.co.nz/system-operations/security-management/security-constraints Security constraints overview]

The SSF states that "Security Constraints may be applied [in SPD] to manage circuit loading:
* to ensure post-event circuit loading does not exceed short term ratings (15 minute off-load times);
* to ensure system stability is maintained following a contingent event;
* to ensure sufficient reactive power is available to maintain voltage levels following a contingent event."

The "'''15 minute off-load time'''" is the internationally recognised time required for the SO to redispatch after a contingency. Shorter off-load times may be in place with Special Protection Schemes ('''SPS''') in some cases.

The SSF states that "thermal current ratings ('''thermal ratings''') are determined from the maximum permissible temperature of the conductors to avoid excessive sag or long-term annealing of the conductors. The calculation does not consider environmental factors that may cool the conductor, therefore it is recognised that these static ratings are typically conservative and at times may result in under utilisation of circuits." The SO uses seasonal default ratings or variable line ratings for each line.

There three basic types of constraint: maunal constraints, SFT constraints and Special Protection Schemes.

==SFT Constraints==
From 28-Mar-11 the majority of constraints are formulated by the SO's Simultaneous Feasibility Test (SFT) software tool. SFT formuates constraints that protect circuits in the event of an N-1 failure of the grid. The constraint equation has the form

A x Protected Branch Flow + B x Contingent Branch Flow ≤ RHS

A and B are coefficients calculated by SFT. The RHS limit ensures that if the contingent branch fails, then the loading on the protected branch remains safe during the 15 off-load time, where 'safe' refers to the amount of sag in the line post-contingency.

==Manual Constraints==
Constraints that are not automatically generated by SFT may relate to Special Protection Schemes (see below) or may be created manually based on studies undertaken offline. Typical examples are the four voltge stability constraints that are there to ensure voltage is stable after a contingency in one of the main load centres, or over long lines.

The Manual Constraints can be permanent or only apply during outages, and are updated at http://www.systemoperator.co.nz/system-operations/security-management/security-constraints (see mid way down this page under Security Constraints and "Manual constraints under SFT ....xls".

==Special Protection Schemes==
Automatic SPS' are also known as "operational intertripping schemes" and the SPS activates "within the period of voltage recovery following fault clearance". In most cases, SPS' are designed to operate to avoid security violations without the need for additional constraints in SPD. According to the SSF, the following constraint equations relate specifically to SPS':

* Te Mihi Special Protection Scheme, constrain transfer from WRK bus.

1.24 * RPO_TNG1.1 + 0.50 * THI_WKM1.1 <= 315 MW

* Special Protection Schemes at KAW: Generation at KAW bus may need to be constrained in the event of high generation at KAW bus or sudden loss of interruptible loads. Security constraints on KAW are highly dependent on system configuration and conditions.

There are several types of SPS.

'''Overload Protection Schemes'''

A.k.a. intertripping schemes, these SPS open circuits that would otherwise overload. They trip the circuit if overloading continues for a specfied minimum time, allowing time for auto-reclose to work.

SPS that involve the action of busbar section circuit breakers to regulate power flows on the system are referred to as Auto Busbar Splitting Schemes (ABSS).

An intertrip that results in a system split is referred to as a System Split Intertrip Scheme (SSIS).

'''Planned Automatic Load Shedding'''

Typical examples are a load shedding scheme for Automatic Under Voltage Load Shedding (AUVLS) using voltage-sensitive relays and occuring within an 8 second time period. The load shedding scheme trips feeders in a sequence to bring load below an overload trip setpoint, or to bring voltage to within allowable limits.

'''Generation Run Back'''

These SPS automatically reduce generation to a pre-arranged value to remove circuit overloads or generator instability. If the circuit loading is not reduced within an inverse time-dependent period after a runback scheme operation has been initiated, the circuit will be tripped. Currenty Transpower has automatic runback schemes installed at Arapuni, Cobb, Maraetai and Te Apiti. Runback schemes may allow operation to 5 or 10 minute off-load times on monitored circuits rather than the standard 15 minute criteria.

'''Reactive Devices'''

The SO dispatches reactive devices so that dynamic reactive reserves are available to provide voltage support for Contingent Events and Extended Contingent Events.

'''Current SPS (Feb-16)'''

Data from System Security Forecast - Transpower Dec-15
http://www.systemoperator.co.nz/documents/reports/system-security-forecast

{| class="wikitable"
|-
! Transpower Grid Zone GZ1
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ1
! Jun-15
! Hepburn-Roskill 110 kV Overload Protection Scheme
! Normally Enabled
! Line protection from Outage
! Pg4, section 4.1
!
|-
! GZ1
! Jun-15
! Penrose Reactor Bypass Scheme
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.2
!
|-
|}

{| class="wikitable"
|-
! Transpower Grid Zone GZ2
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ2
! Nov-15
! Penrose Circuit Overload Protection Scheme
! Normally Disabled
! Line protection from Outage
! Pg3, section 4.1
!
|-
! GZ2
! Nov-15
! Hepburn-Roskill 110 kV Overload Protection Scheme
! Normally Enabled
! Line protection from Outage
! Pg3, section 4.2
!
|-
! GZ2
! Nov-15
! Bombay 110 kV System Split Intertrip Scheme
! Normally Disabled
! Line protection from Outage
! Pg3, section 4.3
!
|-
! GZ2
! Nov-15
! Bombay_Otahuhu Overload Protecton Scheme
! Normally Disabled
! Line protection from Bus Split
! Pg4, section 4.4
!
|-
! GZ2
! Nov-15
! Penrose Reactor Bypass Scheme
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.5
!
|-
! GZ2
! Nov-15
! Otahuhu 110 kV Bus Split
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.6
!
|-
! GZ3
! Jun-15
! Arapuni Runback Scheme
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.1
! Manages Generation constraints
|-
! GZ3
! Jun-15
! Arapuni Bus Split
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.2
! Manages Generation constraints
|-
! GZ3
! Jun-15
! Bombay 110 kV System Split Intertrip Scheme
! Normally Disabled
! Line protection from Outage
! Pg5, section 4.3
!
|-
! GZ3
! Jun-15
! Arapuni - Kinleith 110 kV Overload Protection Scheme
! Normally Disabled
! Line protection from Outage
! Pg5, section 4.4
!
|-
! GZ4
! Jun-15
! Arapuni - Kinleith 110 kV Overload Protection Scheme
! Normally Disabled
! Line protection from Outage
! Pg5, section 4.1
!
|-
! GZ4
! Jun-15
! Kaitimaki Intertrip Scheme
! Normally Enabled
! Overload & line outage protection
! Pg5, section 4.2
! Manages Circuit overload
|-
! GZ4
! Jun-15
! Tokannu 128 Intertrip Scheme
! Normally Enabled
! Line protection from Outage
! Pg5, section 4.3
!
|-
! GZ4
! Jun-15
! Te Mihi Intertrip Scheme
! Line outage Criteria enabled
! Line protection from Outage
! Pg6, section 4.4
!
|-
! GZ4
! Jun-15
! Edgecumbe-Kawerau 1 & 2 Overload Protection Scheme
! Normally Enabled
! Line protection from Outage
! Pg6, section 4.5
!
|-
! GZ4
! Jun-15
! Edgecumbe-Owhata 2 Overload Proteciton Scheme
! Normally Enabled
! Overload Protection
! Pg6, section 4.6
! Manages Generation constraints
|-
! GZ4
! Jun-15
! Kawerau T13 Overload Proteciton Scheme
! Normally Disabled
! not required
! Pg6, section 4.7
!
|-
! GZ4
! Jun-15
! Maraetai Runback
! Normally enabled
!
! Pg6, section 4.8
! Manages Generation constraints
|-
! GZ5
! Jun-15
! Redclyffe interconnecting Transformers Overload Protection Scheme
! Commission 2016
! Transformer protection
! Pg3, section 4.1
!
|-
! GZ6
! Dec-14
! Hawera Reactor and Automatic Bus Splitting Scheme (ABSS)
! Not required
! Line protection from Outage
! Pg3, section 4.1
!
|-
! GZ7
! Dec-14
! Tokannu 128 Intertrip Scheme
! Normally Enabled
! Line protection from Outage
! Pg4, section 4.1
!
|-
! GZ7
! Dec-14
! Bunnythorpe - Woodville 1 and 2 Overload Protection Scheme
! Normally enabled
! Line protection from overloading
! Pg4, section 4.2
! Manages Circuit overload
|-
! GZ7
! Dec-14
! Woodville 110 kV Bus Overload Protection Scheme
! usually Disabled
! Bus protection from overloading
! Pg4, section 4.3
!
|-
! GZ8
! Jun-15
! Bunnythorpe - Woodville 1 and 2 Overload Protection Scheme
! Normally enabled
! Line protection from overloading
! Pg4, section 4.1
! Manages Circuit overload
|-
! GZ8
! Jun-15
! Bunnythorpe - Woodville 1 and 2 Overload Protection Scheme
! Normally enabled
! Line protection from overloading
! Pg4, section 4.1
! Manages Circuit overload
|-
! GZ8
! Jun-15
! Central Park Transformer Overload Protection Scheme
! usually Disabled
! Transformer Protection from overloading
! Pg5, section 4.2
!
|-
! GZ8
! Jun-15
! Mangamaire Overload Trip and Autochange Over Scheme (MGM OTAS)
! usually Disabled
! Line protection from overloading
! Pg5, section 4.3
!
|-
|}

EMO:Constraint Overview

2016-02-24T01:36:13Z

NelsonM: /* Special Protection Schemes */

''References:
# [http://www.systemoperator.co.nz/documents/reports/system-security-forecast System Security Forecast (SSF), Part B, Section 7]
# [http://www.systemoperator.co.nz/system-operations/security-management/security-constraints Security constraints overview]

The SSF states that "Security Constraints may be applied [in SPD] to manage circuit loading:
* to ensure post-event circuit loading does not exceed short term ratings (15 minute off-load times);
* to ensure system stability is maintained following a contingent event;
* to ensure sufficient reactive power is available to maintain voltage levels following a contingent event."

The "'''15 minute off-load time'''" is the internationally recognised time required for the SO to redispatch after a contingency. Shorter off-load times may be in place with Special Protection Schemes ('''SPS''') in some cases.

The SSF states that "thermal current ratings ('''thermal ratings''') are determined from the maximum permissible temperature of the conductors to avoid excessive sag or long-term annealing of the conductors. The calculation does not consider environmental factors that may cool the conductor, therefore it is recognised that these static ratings are typically conservative and at times may result in under utilisation of circuits." The SO uses seasonal default ratings or variable line ratings for each line.

There three basic types of constraint: maunal constraints, SFT constraints and Special Protection Schemes.

==SFT Constraints==
From 28-Mar-11 the majority of constraints are formulated by the SO's Simultaneous Feasibility Test (SFT) software tool. SFT formuates constraints that protect circuits in the event of an N-1 failure of the grid. The constraint equation has the form

A x Protected Branch Flow + B x Contingent Branch Flow ≤ RHS

A and B are coefficients calculated by SFT. The RHS limit ensures that if the contingent branch fails, then the loading on the protected branch remains safe during the 15 off-load time, where 'safe' refers to the amount of sag in the line post-contingency.

==Manual Constraints==
Constraints that are not automatically generated by SFT may relate to Special Protection Schemes (see below) or may be created manually based on studies undertaken offline. Typical examples are the four voltge stability constraints that are there to ensure voltage is stable after a contingency in one of the main load centres, or over long lines.

The Manual Constraints can be permanent or only apply during outages, and are updated at http://www.systemoperator.co.nz/system-operations/security-management/security-constraints (see mid way down this page under Security Constraints and "Manual constraints under SFT ....xls".

==Special Protection Schemes==
Automatic SPS' are also known as "operational intertripping schemes" and the SPS activates "within the period of voltage recovery following fault clearance". In most cases, SPS' are designed to operate to avoid security violations without the need for additional constraints in SPD. According to the SSF, the following constraint equations relate specifically to SPS':

* Te Mihi Special Protection Scheme, constrain transfer from WRK bus.

1.24 * RPO_TNG1.1 + 0.50 * THI_WKM1.1 <= 315 MW

* Special Protection Schemes at KAW: Generation at KAW bus may need to be constrained in the event of high generation at KAW bus or sudden loss of interruptible loads. Security constraints on KAW are highly dependent on system configuration and conditions.

There are several types of SPS.

'''Overload Protection Schemes'''

A.k.a. intertripping schemes, these SPS open circuits that would otherwise overload. They trip the circuit if overloading continues for a specfied minimum time, allowing time for auto-reclose to work.

SPS that involve the action of busbar section circuit breakers to regulate power flows on the system are referred to as Auto Busbar Splitting Schemes (ABSS).

An intertrip that results in a system split is referred to as a System Split Intertrip Scheme (SSIS).

'''Planned Automatic Load Shedding'''

Typical examples are a load shedding scheme for Automatic Under Voltage Load Shedding (AUVLS) using voltage-sensitive relays and occuring within an 8 second time period. The load shedding scheme trips feeders in a sequence to bring load below an overload trip setpoint, or to bring voltage to within allowable limits.

'''Generation Run Back'''

These SPS automatically reduce generation to a pre-arranged value to remove circuit overloads or generator instability. If the circuit loading is not reduced within an inverse time-dependent period after a runback scheme operation has been initiated, the circuit will be tripped. Currenty Transpower has automatic runback schemes installed at Arapuni, Cobb, Maraetai and Te Apiti. Runback schemes may allow operation to 5 or 10 minute off-load times on monitored circuits rather than the standard 15 minute criteria.

'''Reactive Devices'''

The SO dispatches reactive devices so that dynamic reactive reserves are available to provide voltage support for Contingent Events and Extended Contingent Events.

'''Current SPS (Feb-16)'''

Data from System Security Forecast - Transpower Dec-15
http://www.systemoperator.co.nz/documents/reports/system-security-forecast

{| class="wikitable"
|-
! Transpower Grid Zone
! Updated
! Scheme Name
! Status
! Reason
! Information page
! Comments
|-
! GZ1
! Jun-15
! Hepburn-Roskill 110 kV Overload Protection Scheme
! Normally Enabled
! Line protection from Outage
! Pg4, section 4.1
!
|-
! GZ1
! Jun-15
! Penrose Reactor Bypass Scheme
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.2
!
|-
! GZ2
! Nov-15
! Penrose Circuit Overload Protection Scheme
! Normally Disabled
! Line protection from Outage
! Pg3, section 4.1
!
|-
! GZ2
! Nov-15
! Hepburn-Roskill 110 kV Overload Protection Scheme
! Normally Enabled
! Line protection from Outage
! Pg3, section 4.2
!
|-
! GZ2
! Nov-15
! Bombay 110 kV System Split Intertrip Scheme
! Normally Disabled
! Line protection from Outage
! Pg3, section 4.3
!
|-
! GZ2
! Nov-15
! Bombay_Otahuhu Overload Protecton Scheme
! Normally Disabled
! Line protection from Bus Split
! Pg4, section 4.4
!
|-
! GZ2
! Nov-15
! Penrose Reactor Bypass Scheme
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.5
!
|-
! GZ2
! Nov-15
! Otahuhu 110 kV Bus Split
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.6
!
|-
! GZ3
! Jun-15
! Arapuni Runback Scheme
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.1
! Manages Generation constraints
|-
! GZ3
! Jun-15
! Arapuni Bus Split
! Normally Enabled
! Line protection from overloading
! Pg4, section 4.2
! Manages Generation constraints
|-
! GZ3
! Jun-15
! Bombay 110 kV System Split Intertrip Scheme
! Normally Disabled
! Line protection from Outage
! Pg5, section 4.3
!
|-
! GZ3
! Jun-15
! Arapuni - Kinleith 110 kV Overload Protection Scheme
! Normally Disabled
! Line protection from Outage
! Pg5, section 4.4
!
|-
! GZ4
! Jun-15
! Arapuni - Kinleith 110 kV Overload Protection Scheme
! Normally Disabled
! Line protection from Outage
! Pg5, section 4.1
!
|-
! GZ4
! Jun-15
! Kaitimaki Intertrip Scheme
! Normally Enabled
! Overload & line outage protection
! Pg5, section 4.2
! Manages Circuit overload
|-
! GZ4
! Jun-15
! Tokannu 128 Intertrip Scheme
! Normally Enabled
! Line protection from Outage
! Pg5, section 4.3
!
|-
! GZ4
! Jun-15
! Te Mihi Intertrip Scheme
! Line outage Criteria enabled
! Line protection from Outage
! Pg6, section 4.4
!
|-
! GZ4
! Jun-15
! Edgecumbe-Kawerau 1 & 2 Overload Protection Scheme
! Normally Enabled
! Line protection from Outage
! Pg6, section 4.5
!
|-
! GZ4
! Jun-15
! Edgecumbe-Owhata 2 Overload Proteciton Scheme
! Normally Enabled
! Overload Protection
! Pg6, section 4.6
! Manages Generation constraints
|-
! GZ4
! Jun-15
! Kawerau T13 Overload Proteciton Scheme
! Normally Disabled
! not required
! Pg6, section 4.7
!
|-
! GZ4
! Jun-15
! Maraetai Runback
! Normally enabled
!
! Pg6, section 4.8
! Manages Generation constraints
|-
! GZ5
! Jun-15
! Redclyffe interconnecting Transformers Overload Protection Scheme
! Commission 2016
! Transformer protection
! Pg3, section 4.1
!
|-
! GZ6
! Dec-14
! Hawera Reactor and Automatic Bus Splitting Scheme (ABSS)
! Not required
! Line protection from Outage
! Pg3, section 4.1
!
|-
! GZ7
! Dec-14
! Tokannu 128 Intertrip Scheme
! Normally Enabled
! Line protection from Outage
! Pg4, section 4.1
!
|-
! GZ7
! Dec-14
! Bunnythorpe - Woodville 1 and 2 Overload Protection Scheme
! Normally enabled
! Line protection from overloading
! Pg4, section 4.2
! Manages Circuit overload
|-
! GZ7
! Dec-14
! Woodville 110 kV Bus Overload Protection Scheme
! usually Disabled
! Bus protection from overloading
! Pg4, section 4.3
!
|-
! GZ8
! Jun-15
! Bunnythorpe - Woodville 1 and 2 Overload Protection Scheme
! Normally enabled
! Line protection from overloading
! Pg4, section 4.1
! Manages Circuit overload
|-
! GZ8
! Jun-15
! Bunnythorpe - Woodville 1 and 2 Overload Protection Scheme
! Normally enabled
! Line protection from overloading
! Pg4, section 4.1
! Manages Circuit overload
|-
! GZ8
! Jun-15
! Central Park Transformer Overload Protection Scheme
! usually Disabled
! Transformer Protection from overloading
! Pg5, section 4.2
!
|-
! GZ8
! Jun-15
! Mangamaire Overload Trip and Autochange Over Scheme (MGM OTAS)
! usually Disabled
! Line protection from overloading
! Pg5, section 4.3
!
|-
|}

EMO:Constraint Overview

2016-02-24T01:22:00Z

NelsonM: /* Special Protection Schemes */

Special:Badtitle/NS108:Main Page

2013-11-04T03:40:34Z

NelsonM:

{{#hidens:}}

; Current Release Version of EMarket: ''EMarket 5.4.1''

''[[Release Notes | EMarket_5_Release_Notes]]''

'''[[EMK:EMarket User Manual | EMarket User Manual]]'''

'''[[EMK:EMarket 5 Notes | EMarket 5 Release Commentary]]'''

'''[[EMK:EMarket Development | EMarket Development Path and Requests]]'''

Special:Badtitle/NS108:EMarket 5 Release Notes

2013-11-04T03:39:33Z

NelsonM:

{{#hidens:}}

;EMarket 5.3.8 -> 5.4.1
* Change to water valuation - all values at zero storage are now evaluated as storage constrained. This fixes a bug where a system with a tributary system was evaluated without buffers and failed to calculate any shortage values. This change effects all water values but is a valid approach to generating shortage values and more robust than the previous method of projecting zero storage forward if there is enough inflow to lift it over zero.

;EMarket 5.3.6 -> 5.3.8
* Added a single resource report line menu item when a resource is right clicked

;EMarket 5.3.5 -> 5.3.6
* Enhanced auditing tools and information through log.
* Logging via text from command line "-1 drive:\Dir\file.ext
* Command Line Reports bug fix

;EMarket 5.3.4 -> 5.3.5
* When EMarket is run from the command line it will not run if a manually opened EMarket is using the working directory - and vice versa,

;EMarket 5.3.3 -> 5.3.4
*Added Line.Outage trait which can be used to set full or partial outages, value should be from 0 to 1. Note that capacities are adjusted when this value is set.

;EMarket 5.3.2 -> 5.3.3
* Fixed error with output spec occasionally reporting an extra, non-existent version
* Added RunningAverage function, parameters DateTime, Value and HalfLife (days)
* The log window now has a 'copy all' button for copying the log entries to the clipboard

;EMarket 5.3.1 -> 5.3.2
* Fixed a bug with random walk and random outage generation, the bug caused zero values in morning periods.
* Run check now warns if the file in File function does not exist

;EMarket 5.3.0 -> 5.3.1
* Fixed bug where hydro potentials were unable to be calculated when MaxGen and MinGen were set to the same value. This caused SystemStorage to go to zero.

;EMarket 5.2.7 -> 5.3.0
* Equation versions can now be created in the Grid resource. Setting the Equation.Version determines the version in use (default is 0). Setting Equation.Version to -1 or a number greater than the highest version will disable the equation.
* Allows trading periods in date literals in the Schedule, the format is <date>:<trading period> e.g. 1 Mar 2013:8 returns the date and time starting at the beginning of the 8th trading period

;EMarket 5.2.6 -> 5.2.7
* Logs are now named with the run name and resource number appended
* Added RandomSeed variable, which is defined using the "Random Seed" (formerly "Random Outage Seed")option in the Run definition
* Added RandomBinaryState and MRJD functions
* Added traits Generator.Availability and Generator.AverageOutageDuration which can be redefined to change the random outage behavior of a generation over time
* Added trait Generator.Outage, by default this is defined "RandomBinaryState(RandomSeed,DateTime,.Availability,.AverageOutageDuration)"
* The run form is now resizeable

;EMarket 5.2.4 -> 5.2.6
* Random outage modelling is now done on a half hourly basis
* Fixed a bug where water values were incorrectly calculated near the end of the run
* Added Calc Extra Water Value Weeks to the run parameters, this allows water values to be calculated beyond the end of the run.

;EMarket 5.2.3 -> 5.2.4
* Fixed bug that put extra divisions in 3h Output Spec partition
* Version dimension partitons in the OS. Useful if there are more than one variable in the volatility matrix. partitions by a single variable in the volatility matrix Syntax: "Version(<dimension name>):All" e.g. "Version(InflowYear):All"

;EMarket 5.2.2 -> 5.2.3
* Improved eaccuracy of demand monthly input process
* Fixed bug that lost the EMarket version entry in the log file
* Saved Run Resource is now named <RunName>_Resource.txt

;EMarket 5.2.1 -> 5.2.2
* Output spec functions First() and Last() have been added

;EMarket 5.1.4 -> 5.2.1
* The table for creating profiled offers has been changed in the generator offer screen. The table now has the option to profile by month, options for division by weekday and options for division by the time of day
* 1h 2h 3h, 8h, DN and DN6 schedule functions have been added
* The OutputSpec has some more partition options: 1h 2h 3h 6h and 8h, which divide by the time of day
* The Help menu item now opens the EMarket help wiki.
* Made directory creation more robust against race conditions (more than one EMarket trying to create a directory). This avoids sporadic errors when running more than one copy of EMarket at a time.

;EMarket 5.1.2 -> 5.1.4

* Added 1h, 2h and 3h time steps model run

;EMarket 5.0.9 -> 5.1.2

* Added Line.Excess and Line.Losses built in traits
* Fixed generator revenue for generators with distributed offers
* Added the use run results offers feature - requires '-RO(<run name>)' in the run description
* Water value grid simplification can deal with 4 or more character node names. There must still be only one HVDC attached to a nodes with names starting with 'BEN' and 'HAY'
* Adjusted the months required by the demand input settings, so that it needs to cover the period over which water values are calculated
* Fixed bugs caused calculating run end dates and water value periods

;EMarket 4.3.1 -> 5.0.7

*OutputSpecs can now create multiple files. A File partition set has been added and a file is created for each resulting partition.
*Output Spec 'Year' partition has been added, this divides the OS report into each year the forecast covers
*Output Spec 'MonthOfYear' partition has been added, this divides the OS report in 12, one division for each month of the year ( as opposed to the 'Month' partition which creates one for every month in the forecast)
*The headers for each File partition can be added to either the row or column headers

* The number of decimal places to be written to output spec reports can now be specified by adding a :<n> suffix in the function specification. E.g. Function: Tot(Generator.Generation):1
* Monthly Demand Input added, this feature facilitates the specification of regional demand by month by allowing expected average demand rates to be entered either as average demand for weekday or other day or a single value representing average demand for a 5 week day / 2 other day week. The monthly demand input requires the entry of demand rates for all regions and all months covering the duration of the run and the twenty four months following the run. The extra twenty four months of demand is required so that water value modelling can be done.
* MonthDiff schedule function added.
* Fixed bug with LastVal not picking up zero values
* Added a checks for badly assigned reserve regions, avoids accidental assignment of nodes to the wrong island (which impacts water value calculation).
* Added command line running functionality, including the ability to start runs on opening and execute specified volatility values
* Fixed bug with reading grid resource where nodes were wrongly assigned to lines when they were out of alphabetical order
* Grid Versions enabled
* Multi-Year Water Values implemented
* New output database, split by version
* WVs only feature, and Wait for WVs feature

[[EMK:Release Notes|Back]]

Special:Badtitle/NS108:EMarket 5 Release Notes

2013-11-04T03:38:38Z

NelsonM:

{{#hidens:}}

;EMarket 5.3.8 -> 5.4.1
* Change to water valuation - all values at zero storage are now evaluated as storage constrained. This fixes a bug where a system with a tributary system was evaluated without buffers and failed to calculate any shortage values. This change effects all water values but is a valid approach to generating shortage values and more robust than the previous method of projecting zero storage forward if there is enough inflow to lift it over zero.

;EMarket 5.3.6 -> 5.3.8
* Added a single resource report line menu item when a resource is right clicked

;EMarket 5.3.5 -> 5.3.6
* Enhanced auditing tools and information through log.
* Logging via text from command line "-1 drive:\Dir\file.ext
* Command Line Reports bug fix

EMarket 5.3.4 -> 5.3.5
* When EMarket is run from the command line it will not run if a manually opened EMarket is using the working directory - and vice versa,

;EMarket 5.3.3 -> 5.3.4
*Added Line.Outage trait which can be used to set full or partial outages, value should be from 0 to 1
Note that capacities are adjusted when this value is set.

;EMarket 5.3.2 -> 5.3.3
* Fixed error with output spec occasionally reporting an extra, non-existent version
* Added RunningAverage function, parameters DateTime, Value and HalfLife (days)
* The log window now has a 'copy all' button for copying the log entries to the clipboard

;EMarket 5.3.1 -> 5.3.2
* Fixed a bug with random walk and random outage generation, the bug caused zero values in morning periods.
* Run check now warns if the file in File function does not exist

;EMarket 5.3.0 -> 5.3.1
* Fixed bug where hydro potentials were unable to be calculated when MaxGen and MinGen were set to the same value. This caused SystemStorage to go to zero.

;EMarket 5.2.7 -> 5.3.0
* Equation versions can now be created in the Grid resource. Setting the Equation.Version determines the version in use (default is 0). Setting Equation.Version to -1 or a number greater than the highest version will disable the equation.
* Allows trading periods in date literals in the Schedule, the format is <date>:<trading period> e.g. 1 Mar 2013:8 returns the date and time starting at the beginning of the 8th trading period

;EMarket 5.2.6 -> 5.2.7
* Logs are now named with the run name and resource number appended
* Added RandomSeed variable, which is defined using the "Random Seed" (formerly "Random Outage Seed")option in the Run definition
* Added RandomBinaryState and MRJD functions
* Added traits Generator.Availability and Generator.AverageOutageDuration which can be redefined to change the random outage behavior of a generation over time
* Added trait Generator.Outage, by default this is defined "RandomBinaryState(RandomSeed,DateTime,.Availability,.AverageOutageDuration)"
* The run form is now resizeable

;EMarket 5.2.4 -> 5.2.6
* Random outage modelling is now done on a half hourly basis
* Fixed a bug where water values were incorrectly calculated near the end of the run
* Added Calc Extra Water Value Weeks to the run parameters, this allows water values to be calculated beyond the end of the run.

;EMarket 5.2.3 -> 5.2.4
* Fixed bug that put extra divisions in 3h Output Spec partition
* Version dimension partitons in the OS. Useful if there are more than one variable in the volatility matrix. partitions by a single variable in the volatility matrix Syntax: "Version(<dimension name>):All" e.g. "Version(InflowYear):All"

;EMarket 5.2.2 -> 5.2.3
* Improved eaccuracy of demand monthly input process
* Fixed bug that lost the EMarket version entry in the log file
* Saved Run Resource is now named <RunName>_Resource.txt

;EMarket 5.2.1 -> 5.2.2
* Output spec functions First() and Last() have been added

;EMarket 5.1.4 -> 5.2.1
* The table for creating profiled offers has been changed in the generator offer screen. The table now has the option to profile by month, options for division by weekday and options for division by the time of day
* 1h 2h 3h, 8h, DN and DN6 schedule functions have been added
* The OutputSpec has some more partition options: 1h 2h 3h 6h and 8h, which divide by the time of day
* The Help menu item now opens the EMarket help wiki.
* Made directory creation more robust against race conditions (more than one EMarket trying to create a directory). This avoids sporadic errors when running more than one copy of EMarket at a time.

;EMarket 5.1.2 -> 5.1.4

* Added 1h, 2h and 3h time steps model run

;EMarket 5.0.9 -> 5.1.2

* Added Line.Excess and Line.Losses built in traits
* Fixed generator revenue for generators with distributed offers
* Added the use run results offers feature - requires '-RO(<run name>)' in the run description
* Water value grid simplification can deal with 4 or more character node names. There must still be only one HVDC attached to a nodes with names starting with 'BEN' and 'HAY'
* Adjusted the months required by the demand input settings, so that it needs to cover the period over which water values are calculated
* Fixed bugs caused calculating run end dates and water value periods

;EMarket 4.3.1 -> 5.0.7

*OutputSpecs can now create multiple files. A File partition set has been added and a file is created for each resulting partition.
*Output Spec 'Year' partition has been added, this divides the OS report into each year the forecast covers
*Output Spec 'MonthOfYear' partition has been added, this divides the OS report in 12, one division for each month of the year ( as opposed to the 'Month' partition which creates one for every month in the forecast)
*The headers for each File partition can be added to either the row or column headers

* The number of decimal places to be written to output spec reports can now be specified by adding a :<n> suffix in the function specification. E.g. Function: Tot(Generator.Generation):1
* Monthly Demand Input added, this feature facilitates the specification of regional demand by month by allowing expected average demand rates to be entered either as average demand for weekday or other day or a single value representing average demand for a 5 week day / 2 other day week. The monthly demand input requires the entry of demand rates for all regions and all months covering the duration of the run and the twenty four months following the run. The extra twenty four months of demand is required so that water value modelling can be done.
* MonthDiff schedule function added.
* Fixed bug with LastVal not picking up zero values
* Added a checks for badly assigned reserve regions, avoids accidental assignment of nodes to the wrong island (which impacts water value calculation).
* Added command line running functionality, including the ability to start runs on opening and execute specified volatility values
* Fixed bug with reading grid resource where nodes were wrongly assigned to lines when they were out of alphabetical order
* Grid Versions enabled
* Multi-Year Water Values implemented
* New output database, split by version
* WVs only feature, and Wait for WVs feature

[[EMK:Release Notes|Back]]

Special:Badtitle/NS108:Main Page

2013-11-04T03:37:12Z

NelsonM:

{{#hidens:}}

; Current Release Version of EMarket: ''EMarket 5.4.1''

''[[Release Notes | EMarket 5 Release Notes]]''

'''[[EMK:EMarket User Manual | EMarket User Manual]]'''

'''[[EMK:EMarket 5 Notes | EMarket 5 Release Commentary]]'''

'''[[EMK:EMarket Development | EMarket Development Path and Requests]]'''

Special:Badtitle/NS108:Entity.Traits

2013-07-10T23:41:31Z

NelsonM:

{{#hidens:}}
When a run is executed a set of binary files is created in a 'database' folder under the results directory (see [[EMK:Physical Architecture | Physical Architecture]]). These files are collectively called the Results database, and their internal structure reflects EMarket's Entity.Trait data model. This model captures EMarket's approach to data handling in which objects of interest - such as Generators or Nodes - are called entities, and the values describing an entity are its traits (e.g. Nodal Price or Generator Name).

An entity is a logical concept that represents a 'thing' about which EMarket needs to keep data. Things with similar modelling characteristics are classed under the same Entity type. In other words, Entities are typed by the object they represent in the 'modelled' world (e.g. 'Node' or 'Generator'). Different objects of the same entity type are called instances of the entity. So, for example, ABY and TKU are instances of the entity type: Node.

The characteristics describing an entity are its traits. In data handling terms it is the traits that differentiate Instances of the same entity type. The trait 'Node.Name', for example, differentiates the 'ABY' Node entity instance from the 'TKU' Node entity instance.

In EMarket entities and traits are given names that can be used to reference specific data items in the Run Definitions and their values in the associated output. Within a Run Definition Entity.Trait references can be used in any data entry field that accepts a formula expression (the Schedule and all Resource editors). The value of these expressions is calculated at run time and may vary significantly from Tick to Tick, especially if the formula refers to traits derived during the previous Tick.

Entity.Traits syntax: ''<entity>:<name of particular entity>.<trait>''

E.g. Reference to the electricity generated by Generator: GEN01 for a specific period would look like this: ''Generator:GEN01.Generation''

'''Warning:''' Entity.Trait references are case sensitive.

A complete list of EMarket Entity.Traits can be found in the '''''Entity.Trait List''''' below.

Special cases exist for the following Entity.Trait types:

===Offer Band Entity===
Offer Band entities must be referred to using the name of the Generator to which the Offers belong, as follows:

''OfferBand:<Generator name>_<Offer type><Offer Band number>.<Trait>

where Offer type is E, FR, SR for energy, Fast reserve and Slow Reserve respectively.

===Global Traits===
Global Traits are user-defined variables that extend EMarket's Entity.Trait model. Global traits can be referred to in formulae in a similar manner as entity traits. Global variables can be defined through the:
*'''''[[EMK:Run Window | Run Window]]''''' - through the '''''Volatility Matrix''''', the '''''File Data''''' or '''''MRJD''''' features; or
*'''''[[EMK:Schedules | Schedule Window]]'''''

The syntax for referring to Global traits is: ''Global.<Global variable name>''

===Demand Elasticity===
Demand elasticity is controlled through an internal variable in EMarket. The syntax is: Region'':<RegionName>.''DemandElast

where ''RegionName'' is the name of a Demand Region defined in the Regions Resource Instance.

For example, if NI and SI are regions for your Run, their Demand elasticity might be given in the schedule as:
{|class="wikitable"
|-
| '''Variable''' || '''Definition'''
|-
| Region:NI.DemandElast || 0.8
|-
| Region:SI.DemandElast || 0.2
|}
Note: Demand elasticity is defined as a proportion of the usual Demand, so a Demand elasticity setting of 0.8 sets the Demand to 0.8 of its usual value. The PieceWiseLinear function can be used to define the Demand elasticity.

===Entity.Trait List===
EMarket Entity.Traits are listed below. Traits marked with an asterisk (*) are either currently not used or are not accessible to users. Some traits should also be regarded as "read-only" traits, in the sense that their values are derived within the model and attempts to change the values are ignored. Such traits are indicated by a hashtag (#). Traits marked with a ^ are "static", that is, although their values are user-defined they cannot be altered during a Run.

'''Node'''
{|class="wikitable"
|-
| Region* || Region name if Node is defined in a Demand Region
|-
| Injection# || Total MW being injected at Node this Tick
|-
| Price# || Nodal price in $/MWh this Tick
|-
| Demand# || Total Demand off-take at this Tick in MW. Node.Demand represents the Demand - after the losses have been added
|-
| LocalDemand || Demand at the retail side can be accessed via the Node.LocalDemand trait
|-
| Resistance || the resistance between the retail supply Nodes and those on the grid
|-
| DirectDemand || Non-profile demand - i.e. an amount of demand in MW applied at a Node in addition to that calculated through the Demand Profile for the Node
|}

'''ResRegion'''
{|class="wikitable"
|-
| RefNode* || Reference Node for the Reserve Region, e.g. HAY2201 for North Island of New Zealand
|-
| RAFFR || RAF for Fast Reserve Class this Tick
|-
| RAFSR || RAF for Slow Reserve Class this Tick
|-
| BaseRisk || Reserve Risk this Tick in MW
|-
| PriceFR# || Fast Reserve price this Tick in $/MWh
|-
| PriceSR# || Slow reserve price this Tick in $/MWh
|-
| ImportSubtractor || Where electricity is imported (via the HVDC) this quantity is subtracted from the risk represented by the import quantity.
|}

'''Generator'''
{|class="wikitable"
|-
| Node* || Node at which Generator injects
|-
| Capacity || Maximum generating capacity in MW
|-
| CommDate || Commissioning date
|-
| MothDate || Mothball date
|-
| Outage || The proportion of capacity currently taken out of service
|-
| CurrentCapacity# || Current Capacity of the plant. Zero before Comm.Date and after Moth.Date, and also if the plant has an outage during the run
|-
| UnitSize || Unit size in MW. Used in determining the risk set by a Generator when modelling Reserves
|-
| Ramp_Rate* || Currently not used in EMarket
|-
| Generation# || This is the dispatched generation for the Generator in the current Tick in MW
|-
| Cost# || Aggregated cost of supplying energy and Reserve supply over all Offer Bands
|-
| ReserveCost# || The cost of Reserve provision calculated from the marginal costs for each Offer Band
|-
| Efficiency || Plant generation efficiency as a percentage
|-
| NonFuelMC || Non-fuel marginal cost in $/MWh
|-
| GenType* || Descriptive text only
|-
| FuelType* || Descriptive text only
|-
| Revenue# || Revenue earned by sales from generation and Reserve provision
|-
| PLSRSlope^ || Used to determine the amount of Reserve that can be provided by a Generic Generator based on energy Offers. This trait is only accessible when the ''Dispatch Mode'' field in the Run Window is set to Nodal+Reserves
|-
| DispatchFR# || The quantity of Fast Reserve dispatched this Tick in MW
|-
| DispatchSR# || The quantity of Slow Reserve dispatched this Tick in MW
|}

'''HydroStation'''
{|class="wikitable"
|-
| HydroRelease# || The amount of water (in cumecs), passing through a station. The figure includes spill
|-
| Hydrospill# || The amount of water (in cumecs) spilled by a hydro station
|-
| Diversion || Used to set the amount of water (in cumecs) that is diverted past a station. Care should be taken when assigning values to this trait, for example, when a large diversion figure (say 1,000 cumecs) is entered for a station at the head of a Hydro System. Although the model will make every attempt to meet minimum flow requirements for station downstream, if there is simply not enough water an infeasibility will occur and such things as negative system storages can result. Note that you can also enter negative diversion values and divert water into a station's reservoir.
|-
| MinGen || The MinGen trait defines a minimum generation in (MW) that the station must meet. It is not possible to control the minimum output of a hydro station that is part of a group.
|-
| MaxGen || Defines the maximum output of a hydro station in MW. It is not possible to control the maximum outage of a hydro station that is part of a group.
|-
| Inflows || The amount of water (in cumecs) into the reservoir
|-
| MaxStorage || Maximum storage capacity of a hydro reservoir in Mm3
|-
| HydroStorage# || The storage capacity of the reservoir in Mm3
|-
| MWperCumec || The conversion rate of the station in MW/Cumec
|-
| MinFlow || Minimum release of water immediately below the station in (cumecs).
|}

'''OfferBand'''
{|class="wikitable"
|-
| Generator* || Name of Generator to which this band applies
|-
| BandNo* || Offer Band number
|-
| OfferType* || 0, 1, 2 for energy, Fast Reserve and Slow Reserve respectively
|-
| InitPrice || The initial price set for the Offer in $/MWh. This can differ from the final price when Company Optimisation operating
|-
| InitQuantity || The initial quantity set for the Offer in MW. This can differ from the final quantity when Offer quantities exceed current capacity
|-
| Price || The price offered into the market in $/MWh
|-
| Quantity || The quantity offered into the market in MW
|-
| MarginalCost || The marginal cost of the Offer Band in $/MWh
|-
| Dispatch || The quantity of dispatch attributed to the Offer Band in MW
|-
| Cost || Dispatch * Marginal Cost (in $/hr)
|}

'''Line'''
{|class="wikitable"
|-
| NodeFrom* || First Node defined at end of line
|-
| NodeTo* || Second Node defined at other end of line
|-
| Resistance^ || Per unit resistance of the line
|-
| Reactance^ || Per unit reactance of the line
|-
| Capacity || Forward capacity of the line in MW
|-
| RevCapacity || Capacity of the line in MW in the 'reverse' direction as defined by the line name
|-
| FixedLosses*^ || Fixed losses in MW associated with the line, e.g. transformer losses
|-
| PowerFlow# || Power flowing on the line this Tick - can be either positive or negative
|-
| LM# || Lagrange multiplier for this Tick in $/MWh. This is the additional price differential across the line if it is constrained, i.e. at its limit. LM is zero when the line is unconstrained.
|}

'''Company'''
{|class="wikitable"
|-
| Name* || Company's full
|-
| RetailCost# || Total retail cost for the Company this Tick in $/hr
|-
| RetailRevenue# || Total retail revenue for the Company this Tick in $/hr
|-
| ContractRevenue# || Total revenue/cost from all hedging contracts this Tick in $/hr
|-
| GeneratorCost# || Total cost of generation for the Company this Tick in $/hr
|-
| GeneratorRevenue# || Total generation revenue for the Company this Tick in $/hr
|-
| GrossProfit# || The total of revenues less costs above this Tick in $/hr
|-
| OptOn# || 1 if Company optimisation is being done on this company, zero otherwise
|}

'''Region'''
{|class="wikitable"
|-
| Demand# || Annual Demand in GWh at all Nodes in the named Region
|-
| DemandAdj || Load multiplier for the purposes of general load adjustment as a proportion, e.g. setting Region:<Region name>.DemandAdj to 1.13 in the schedule will increase overall Demand for that Region by 13%
|-
| DemandElast || Load multiplier for the purposes of modelling Demand elasticity. Applied as a proportion of the current Demand as per DemandAdj
|}

'''Global'''
{|class="wikitable"
|-
| <user-defined variable name> || User-defined
|}

[[EMK:EMarket User Manual | Back to User Manual Main Page]]

Special:Badtitle/NS108:Formulae and Functions

2013-07-10T22:10:56Z

NelsonM: /* Time Functions */

{{#hidens:}}
Formulae can be entered as substitutes for specific values into most fields in EMarket to control the derivation of variable values at run time. A formula can contain any combination of:
*Constants
*Variables
*Operators
*'''''[[EMK:Entity.Traits | Entities and Traits]]'''''
*'''''Functions'''''

'''Constants'''

Constants can be:
*''Numbers:'' Integers or Reals (e.g. 1, 2.5, -3), they can also be entered in scientific notation e.g. '3E+10'.
*''Strings:'' Written inside double quotes e.g. "A Node"
*''Dates:'' Must be enclosed in single quotes e.g '1/3/2004' or '14 April 2005'

'''Warning:''' The format for entering dates should compatible with the computer's local date (locality) setting

'''Variables'''

Variables can be regarded as user-defined Entity.Traits which can be defined in the '''''Volatility Matrix''''' or the '''''Schedule.''''' Previously defined variables can be used in formulae.

Note: EMarket provides a 'system' variable the user need not define: 'DateTime' which is of type 'Date' and gives the current simulation date as the model runs.

==Operators==

Operators are all pre-defined in EMarket. Their purpose is to separate a formula into parts that are then combined to give a single value.

The following operators are shown in descending order of precedence.
{|class="wikitable"
! Operator !! Meaning !! Example !! Parameter Type !! Return Type
|-
| \ || Integer Division || 3\2 = 1 || Real; Int || Int
|-
| % || Modulus || 7%5 = 2 || Real; Int || Int
|-
| / || Division || 3/2 = 1.5 || Real; Int || Real
|-
| * || Multiplication || 5*4.2 = 21 || Real; Int || Real
|-
| - || Subtraction || 7-3.2 = 3.8 || Real; Int || Real
|-
| + || Addition || 3.5+1.5 = 5 || Real; Int || Real
|}

==Functions==
Functions provide a powerful mechanism for deriving field and variable data values from input parameters.

A function has the form FunctionName(Parameter1, Parameter2, ...)

An operator is used in a Function in the following form: <Parameter1>Operator<Parameter2>.

EMarket provides the following function types:
*Arithmetic functions
*Logic functions
*Run information functions
*Time functions
*Other functions

Note: Logic operators and functions evaluate to one for a result that is true (for example 6 = 6), and zero for false.

===Arithmetic Functions===

The following table lists EMarket's Arithmetic functions:
{|class="wikitable"
! Function !! Purpose !! Parameters !! Return Type !! Example !! Result
|-
| Sqrt || Square root of a number || Integer or Real || Real || Sqrt(546.94) || 23.387
|-
| Abs || Absolute value of a number || Integer or Real || Real || Abs(-19.1) || 19.1
|-
| Int || Integer portion of a number || Integer or Real || Integer || Int(45.786) || 45
|-
| Sum || Total value of numbers in an array || Value Array (Exclude Value), Integer or Real || Real || Sum(Node.Price) ||
|-
| Max || Maximum value of numbers in an array, optionally excluding values with value over an exclude value || Value Array (Exclude Value), Integer or Real || Real || Max(Generator.Generation) ||
|-
| Min || Minimum value of numbers in an array || Value Array (Exclude Value), Integer or Real || Real || Min(Generator.Generation) ||
|-
| StdDev || Standard deviation of numbers in an array || Value Array (Exclude Value), Integer or Real || Real || StdDev(Generator.Generation) ||
|-
| Avg || Average value of numbers in an array || Value Array (Exclude Value), Integer or Real || Real || Avg(Generator.Generation) ||
|-
| WgtAvg || Average of numbers in an array, weighted by numbers in another array || Value Array (Weights Array), Integer or Real || Real || WgtAvg(Generator.Generation,Generator.Cost) ||
|-
| Choke || Returns a collared value (i.e. the value of the referenced variable is returned if it falls within the specified range otherwise the relevant minimum or maximum value is returned) || Integer or Real || Real || Choke(500,200,Generator.Generation)||
|}

===Logic Functions===

The following table lists EMarket3's Logic functions:
{|class="wikitable"
! Operator !! Purpose !! Parameters !! Return Value !! Example !! Result
|-
| = || Whether two numbers are Equal || 2 numbers, Integer or Real || 0 or 1 || 5 = 6 || 0
|-
| < || Whether first number is less than the second || 2 numbers, Integer or Real || 0 or 1 || -2 < 7 || 1
|-
| > || Whether first number is Greater than the second || 2 numbers, Integer or Real || 0 or 1 || 9 > 7 || 1
|-
| AND || Whether two numbers are both non-zero || 2 numbers, Integer or Real || 0 or 1 || And(6=6,4<3) || 0
|-
| OR || Whether either of two numbers are non-zero || 2 numbers, Integer or Real || 0 or 1 || OR(3<5, 2>3) || 1
|-
| Between || Whether a number is between two limits || Number: lower limit; upper limit, Integer, real or date || 0 or 1 || Between(5.7,9.7) || 0
|}

===Run Information Functions===

The following table lists EMarket's Run information functions:
{|class="wikitable"
! Function !! Purpose !! Parameters !! Return Type
|-
| Date || Date of current Tick || None || Date
|-
| TP || TP number of current Tick || None || Integer
|-
| Version || The position of a Run in a Batch sequence. For first Run, Version is zero. || None || Integer
|}

===Time Functions===

The following table lists EMarket's Time functions:
{|class="wikitable"
! Function !! Purpose !! Parameters !! Return Type !! Example !! Result
|-
| GetDate || Converts a date to a day number || Date || Integer || GetDate('1/4/2004') ||
|-
| hh || Gets the half hourly TP from a date || 'DateTime' || Integer || hh(DateTime) ||
|-
| 4h || Gets the number of the block of 4 hourly trading periods for a given date (e.g. 1 = TP 1-8) || 'DateTime' || Integer || 4h(DateTime) ||
|-
| 6h || Gets the number of the block of 6 hourly trading periods for a given date (e.g. 0 = TP 1-12) || 'DateTime' || Integer || 6h(DateTime) ||
|-
| DOW || Gets the weekday for a date, 0 = Sunday || Date || Integer || Dow('14/6/2004') || 1
|-
| WO || Whether a date is a week day rather than a weekend or holiday, 1 = Weekend; 0 = Weekday || Date || 0 or 1 || WO('13/6/2004') || 1
|-
| WODN || 0=Week Night(WN); 1=Week Day(WD); 2=Other Night(ON); 3=Other Day(OF) || Date (and time) || 0 to 3 || WODN('1/5/2004 22:00') || 3
|-
| WODN6 || 0=Week Night(WN); 1=Week Day(WD); 2=Other Night(ON); 3=Other Day(OF). Using A night period running from Midnight to 6am (not to 8am as in WODN) || Date (and time) || 0 to 3 || WODN6('1/5/2004 22:00') || 3
|-
| Month || Gets the month from a date, 0 = January || Date || 0 to 11 || Month('1/5/2004') || 4
|-
| WeekOfYear || Gets the week from a date, 0 = 1st full week in April || Date || 0 to 51 || WeekOfYear('1/5/2004') || 4
|-
| DateDiff || Calculates the number of days between two date/times || Date 1, Date2 || Real || DateDiff('1/5/2004', '5/5/004') || 4
|-
| DateSeq || Gets the position of a required date within a list of ordered dates || Date required, Lists of dates || Integer || DateSeq('5 / 4 / 2004', '1 / 4 / 2004', '2 / 4 / 2004', '3 / 4 / 2004', '4 / 4 / 2004', '5 / 4 / 2004') || 5
|-
| TimeSeries || Given a date ordered sequence of values, finds the value for a required date. Date format is Date:TimePeriod 'DD/MM/YYYY:TP' , if no TP then TP '01' is used || List of (Initial value, first date and time period applies for value2, value2 , ....) || Real || TimeSeries(735 , '1/04/2004:24', 760 , ' 1/04/2005', 840) ||
|}

===Other Functions===

The following table lists EMarket's other functions:
{|class="wikitable"
! Function !! Purpose !! Parameters !! Return Type !! Example !! Result
|-
| ArrayTable || Uses two indices to retrieve a value from an array (matrix) || Index1, Index2, Value array. May be real or Integer || Real or Integer || ArrayTable(p,q,m,n, V00, V01, V02, ...V0m, V10, V11, ... Vnm) where p,q represent the position of the array; m,n represent the numbers of columns and rows in the array; 0<= p < m and 0 <= q < n would return Vpq. E.g. ArrayTable(1, 1, 2, 3, 4, 32.1, 6.3, 1.8, 31, 5). This defines a 2 * 3 matrix, and looks for the entry indexed by 1, 1. Note that if the indices are out of bounds no error will be given, and an indeterminate value will be returned. || 31
|-
| Index || Gets the number in given position (index) in a list of numbers. First number has position zero. || 1 or more numbers, can be integers or real || Real || Index(p, V0, V1, V2, ... Vm) where p is the position (index) in a list of numbers. E.g. Index(3, 4.5, 7, 8.9, -23.4) || -23.4
|-
| PieceWiseLinear || Generates a value based on an extrapolation of existing data. Given a target value (p) and a set of x, y pairings defining a function, the PieceWiseLinear function will find the y value corresponding to p. This function is included primarily for use in defining Demand elasticity. || Set of x,y value pairings, can be integers or real || Real or Integer || PieceWiseLinear(p, x1, y1, x2, y2, ...xn, yn) where p is the target value. Note that you can use internal model variables as the target value, as in this example: PieceWiseLinear(HydroSystem:Waitaki.SystemMWV, 0, 1, 80, 1, 150, 0.8, 400, 0.64) ||
|}

===Random Functions===

the following random functions create a random sequence, the results of which depend on the seed given, the start date of the sequence and the order of definition and exact formula used to define the function. The RandomSeed variable should usually be used as the seed as this will ensure a unique sequence is generated based on the "Random Seed" option chosen for the run

{|class="wikitable"
! Function !! Purpose !! Parameters !! Return Type !! Example
|-
| RandomBinaryState || Returns values from a random sequence of values which are either 0 or 1 with the properties that proportion of the time spent in the zero state is a given proportion and the average length of time spent in the one state is a given number of days || Seed for random sequence, Date/Time, Zero state proportion, Average One state length || Real || RandomBinaryState(Seed, DateTime, 0.95, 4), will return a random 0/1 series with 0.05 time spent in the one state and an average four day span of each one state
|-
| MRJD || Returns a value that follows a mean reverting random walk on a logarithmic scale || Seed for random sequence, Date/Time, Starting Value, Mean, Reversion Rate, Volatility[,ProportionalJump, JumpVolatility, JumpFrequency] || Real ||MRJD(RandomSeed, DateTime, 5, 10, 11, 5), will return a random walk starting with the value 5 where the average log value is equal to log(10), reversion rate of 10 (half reversion in 1/10 year), volatility of 5 (two times diffusion in 1/5 year). The jump parameters are optional
|}

[[EMK:EMarket User Manual | Back to User Manual Main Page]]

Special:Badtitle/NS108:Formulae and Functions

2013-07-10T22:08:50Z

NelsonM: /* Time Functions */

{{#hidens:}}
Formulae can be entered as substitutes for specific values into most fields in EMarket to control the derivation of variable values at run time. A formula can contain any combination of:
*Constants
*Variables
*Operators
*'''''[[EMK:Entity.Traits | Entities and Traits]]'''''
*'''''Functions'''''

'''Constants'''

Constants can be:
*''Numbers:'' Integers or Reals (e.g. 1, 2.5, -3), they can also be entered in scientific notation e.g. '3E+10'.
*''Strings:'' Written inside double quotes e.g. "A Node"
*''Dates:'' Must be enclosed in single quotes e.g '1/3/2004' or '14 April 2005'

'''Warning:''' The format for entering dates should compatible with the computer's local date (locality) setting

'''Variables'''

Variables can be regarded as user-defined Entity.Traits which can be defined in the '''''Volatility Matrix''''' or the '''''Schedule.''''' Previously defined variables can be used in formulae.

Note: EMarket provides a 'system' variable the user need not define: 'DateTime' which is of type 'Date' and gives the current simulation date as the model runs.

==Operators==

Operators are all pre-defined in EMarket. Their purpose is to separate a formula into parts that are then combined to give a single value.

The following operators are shown in descending order of precedence.
{|class="wikitable"
! Operator !! Meaning !! Example !! Parameter Type !! Return Type
|-
| \ || Integer Division || 3\2 = 1 || Real; Int || Int
|-
| % || Modulus || 7%5 = 2 || Real; Int || Int
|-
| / || Division || 3/2 = 1.5 || Real; Int || Real
|-
| * || Multiplication || 5*4.2 = 21 || Real; Int || Real
|-
| - || Subtraction || 7-3.2 = 3.8 || Real; Int || Real
|-
| + || Addition || 3.5+1.5 = 5 || Real; Int || Real
|}

==Functions==
Functions provide a powerful mechanism for deriving field and variable data values from input parameters.

A function has the form FunctionName(Parameter1, Parameter2, ...)

An operator is used in a Function in the following form: <Parameter1>Operator<Parameter2>.

EMarket provides the following function types:
*Arithmetic functions
*Logic functions
*Run information functions
*Time functions
*Other functions

Note: Logic operators and functions evaluate to one for a result that is true (for example 6 = 6), and zero for false.

===Arithmetic Functions===

The following table lists EMarket's Arithmetic functions:
{|class="wikitable"
! Function !! Purpose !! Parameters !! Return Type !! Example !! Result
|-
| Sqrt || Square root of a number || Integer or Real || Real || Sqrt(546.94) || 23.387
|-
| Abs || Absolute value of a number || Integer or Real || Real || Abs(-19.1) || 19.1
|-
| Int || Integer portion of a number || Integer or Real || Integer || Int(45.786) || 45
|-
| Sum || Total value of numbers in an array || Value Array (Exclude Value), Integer or Real || Real || Sum(Node.Price) ||
|-
| Max || Maximum value of numbers in an array, optionally excluding values with value over an exclude value || Value Array (Exclude Value), Integer or Real || Real || Max(Generator.Generation) ||
|-
| Min || Minimum value of numbers in an array || Value Array (Exclude Value), Integer or Real || Real || Min(Generator.Generation) ||
|-
| StdDev || Standard deviation of numbers in an array || Value Array (Exclude Value), Integer or Real || Real || StdDev(Generator.Generation) ||
|-
| Avg || Average value of numbers in an array || Value Array (Exclude Value), Integer or Real || Real || Avg(Generator.Generation) ||
|-
| WgtAvg || Average of numbers in an array, weighted by numbers in another array || Value Array (Weights Array), Integer or Real || Real || WgtAvg(Generator.Generation,Generator.Cost) ||
|-
| Choke || Returns a collared value (i.e. the value of the referenced variable is returned if it falls within the specified range otherwise the relevant minimum or maximum value is returned) || Integer or Real || Real || Choke(500,200,Generator.Generation)||
|}

===Logic Functions===

The following table lists EMarket3's Logic functions:
{|class="wikitable"
! Operator !! Purpose !! Parameters !! Return Value !! Example !! Result
|-
| = || Whether two numbers are Equal || 2 numbers, Integer or Real || 0 or 1 || 5 = 6 || 0
|-
| < || Whether first number is less than the second || 2 numbers, Integer or Real || 0 or 1 || -2 < 7 || 1
|-
| > || Whether first number is Greater than the second || 2 numbers, Integer or Real || 0 or 1 || 9 > 7 || 1
|-
| AND || Whether two numbers are both non-zero || 2 numbers, Integer or Real || 0 or 1 || And(6=6,4<3) || 0
|-
| OR || Whether either of two numbers are non-zero || 2 numbers, Integer or Real || 0 or 1 || OR(3<5, 2>3) || 1
|-
| Between || Whether a number is between two limits || Number: lower limit; upper limit, Integer, real or date || 0 or 1 || Between(5.7,9.7) || 0
|}

===Run Information Functions===

The following table lists EMarket's Run information functions:
{|class="wikitable"
! Function !! Purpose !! Parameters !! Return Type
|-
| Date || Date of current Tick || None || Date
|-
| TP || TP number of current Tick || None || Integer
|-
| Version || The position of a Run in a Batch sequence. For first Run, Version is zero. || None || Integer
|}

===Time Functions===

The following table lists EMarket's Time functions:
{|class="wikitable"
! Function !! Purpose !! Parameters !! Return Type !! Example !! Result
|-
| GetDate || Converts a date to a day number || Date || Integer || GetDate('1/4/2004') ||
|-
| hh || Gets the half hourly TP from a date || 'DateTime' || Integer || hh(DateTime) ||
|-
| 4h || Gets the number of the block of 4 hourly trading periods for a given date (e.g. 1 = TP 1-8) || 'DateTime' || Integer || 4h(DateTime) ||
|-
| 6h || Gets the number of the block of 6 hourly trading periods for a given date (e.g. 0 = TP 1-12) || 'DateTime' || Integer || 6h(DateTime) ||
|-
| DOW || Gets the weekday for a date, 0 = Sunday || Date || Integer || Dow('14/6/2004') || 1
|-
| WO || Whether a date is a week day rather than a weekend or holiday, 1 = Weekend; 0 = Weekday || Date || 0 or 1 || WO('13/6/2004') || 1
|-
| WODN || 0=Week Night(WN); 1=Week Day(WD); 2=Other Night(ON); 3=Other Day(OF) || Date (and time) || 0 to 3 || WODN('1/5/2004 22:00') || 3
|-
| WODN6 || 0=Week Night(WN); 1=Week Day(WD); 2=Other Night(ON); 3=Other Day(OF). Using A night period running from Midnight to 6am (not to 8am as in WODN) || Date (and time) || 0 to 3 || WODN6('1/5/2004 22:00') || 3
|-
| Month || Gets the month from a date, 0 = January || Date || 0 to 11 || Month('1/5/2004') || 4
|-
| WeekOfYear || Gets the week from a date, 0 = 1st full week in April || Date || 0 to 51 || WeekOfYear('1/5/2004') || 4
|-
| DateDiff || Calculates the number of days between two date/times || Date 1, Date2 || Real || DateDiff('1/5/2004', '5/5/004') || 4
|-
| DateSeq || Gets the position of a required date within a list of ordered dates || Date required, Lists of dates || Integer || DateSeq('5 / 4 / 2004', '1 / 4 / 2004', '2 / 4 / 2004', '3 / 4 / 2004', '4 / 4 / 2004', '5 / 4 / 2004') || 5
|-
| TimeSeries || Given a date ordered sequence of values, finds the value for a required date. Date format is Date:TimePeriod 'dd/mm/yyy:TP' , if no TP then TP '01' is used || List of (value, first date and time period applies) || Real || TimeSeries(735 , '1/04/2004:24', 760 , ' 1/04/2005', 840) ||
|}

===Other Functions===

The following table lists EMarket's other functions:
{|class="wikitable"
! Function !! Purpose !! Parameters !! Return Type !! Example !! Result
|-
| ArrayTable || Uses two indices to retrieve a value from an array (matrix) || Index1, Index2, Value array. May be real or Integer || Real or Integer || ArrayTable(p,q,m,n, V00, V01, V02, ...V0m, V10, V11, ... Vnm) where p,q represent the position of the array; m,n represent the numbers of columns and rows in the array; 0<= p < m and 0 <= q < n would return Vpq. E.g. ArrayTable(1, 1, 2, 3, 4, 32.1, 6.3, 1.8, 31, 5). This defines a 2 * 3 matrix, and looks for the entry indexed by 1, 1. Note that if the indices are out of bounds no error will be given, and an indeterminate value will be returned. || 31
|-
| Index || Gets the number in given position (index) in a list of numbers. First number has position zero. || 1 or more numbers, can be integers or real || Real || Index(p, V0, V1, V2, ... Vm) where p is the position (index) in a list of numbers. E.g. Index(3, 4.5, 7, 8.9, -23.4) || -23.4
|-
| PieceWiseLinear || Generates a value based on an extrapolation of existing data. Given a target value (p) and a set of x, y pairings defining a function, the PieceWiseLinear function will find the y value corresponding to p. This function is included primarily for use in defining Demand elasticity. || Set of x,y value pairings, can be integers or real || Real or Integer || PieceWiseLinear(p, x1, y1, x2, y2, ...xn, yn) where p is the target value. Note that you can use internal model variables as the target value, as in this example: PieceWiseLinear(HydroSystem:Waitaki.SystemMWV, 0, 1, 80, 1, 150, 0.8, 400, 0.64) ||
|}

===Random Functions===

the following random functions create a random sequence, the results of which depend on the seed given, the start date of the sequence and the order of definition and exact formula used to define the function. The RandomSeed variable should usually be used as the seed as this will ensure a unique sequence is generated based on the "Random Seed" option chosen for the run

{|class="wikitable"
! Function !! Purpose !! Parameters !! Return Type !! Example
|-
| RandomBinaryState || Returns values from a random sequence of values which are either 0 or 1 with the properties that proportion of the time spent in the zero state is a given proportion and the average length of time spent in the one state is a given number of days || Seed for random sequence, Date/Time, Zero state proportion, Average One state length || Real || RandomBinaryState(Seed, DateTime, 0.95, 4), will return a random 0/1 series with 0.05 time spent in the one state and an average four day span of each one state
|-
| MRJD || Returns a value that follows a mean reverting random walk on a logarithmic scale || Seed for random sequence, Date/Time, Starting Value, Mean, Reversion Rate, Volatility[,ProportionalJump, JumpVolatility, JumpFrequency] || Real ||MRJD(RandomSeed, DateTime, 5, 10, 11, 5), will return a random walk starting with the value 5 where the average log value is equal to log(10), reversion rate of 10 (half reversion in 1/10 year), volatility of 5 (two times diffusion in 1/5 year). The jump parameters are optional
|}

[[EMK:EMarket User Manual | Back to User Manual Main Page]]

Special:Badtitle/NS108:Formulae and Functions

2013-07-10T22:05:07Z

NelsonM: /* Time Functions */

{{#hidens:}}
Formulae can be entered as substitutes for specific values into most fields in EMarket to control the derivation of variable values at run time. A formula can contain any combination of:
*Constants
*Variables
*Operators
*'''''[[EMK:Entity.Traits | Entities and Traits]]'''''
*'''''Functions'''''

'''Constants'''

Constants can be:
*''Numbers:'' Integers or Reals (e.g. 1, 2.5, -3), they can also be entered in scientific notation e.g. '3E+10'.
*''Strings:'' Written inside double quotes e.g. "A Node"
*''Dates:'' Must be enclosed in single quotes e.g '1/3/2004' or '14 April 2005'

'''Warning:''' The format for entering dates should compatible with the computer's local date (locality) setting

'''Variables'''

Variables can be regarded as user-defined Entity.Traits which can be defined in the '''''Volatility Matrix''''' or the '''''Schedule.''''' Previously defined variables can be used in formulae.

Note: EMarket provides a 'system' variable the user need not define: 'DateTime' which is of type 'Date' and gives the current simulation date as the model runs.

==Operators==

Operators are all pre-defined in EMarket. Their purpose is to separate a formula into parts that are then combined to give a single value.

The following operators are shown in descending order of precedence.
{|class="wikitable"
! Operator !! Meaning !! Example !! Parameter Type !! Return Type
|-
| \ || Integer Division || 3\2 = 1 || Real; Int || Int
|-
| % || Modulus || 7%5 = 2 || Real; Int || Int
|-
| / || Division || 3/2 = 1.5 || Real; Int || Real
|-
| * || Multiplication || 5*4.2 = 21 || Real; Int || Real
|-
| - || Subtraction || 7-3.2 = 3.8 || Real; Int || Real
|-
| + || Addition || 3.5+1.5 = 5 || Real; Int || Real
|}

==Functions==
Functions provide a powerful mechanism for deriving field and variable data values from input parameters.

A function has the form FunctionName(Parameter1, Parameter2, ...)

An operator is used in a Function in the following form: <Parameter1>Operator<Parameter2>.

EMarket provides the following function types:
*Arithmetic functions
*Logic functions
*Run information functions
*Time functions
*Other functions

Note: Logic operators and functions evaluate to one for a result that is true (for example 6 = 6), and zero for false.

===Arithmetic Functions===

The following table lists EMarket's Arithmetic functions:
{|class="wikitable"
! Function !! Purpose !! Parameters !! Return Type !! Example !! Result
|-
| Sqrt || Square root of a number || Integer or Real || Real || Sqrt(546.94) || 23.387
|-
| Abs || Absolute value of a number || Integer or Real || Real || Abs(-19.1) || 19.1
|-
| Int || Integer portion of a number || Integer or Real || Integer || Int(45.786) || 45
|-
| Sum || Total value of numbers in an array || Value Array (Exclude Value), Integer or Real || Real || Sum(Node.Price) ||
|-
| Max || Maximum value of numbers in an array, optionally excluding values with value over an exclude value || Value Array (Exclude Value), Integer or Real || Real || Max(Generator.Generation) ||
|-
| Min || Minimum value of numbers in an array || Value Array (Exclude Value), Integer or Real || Real || Min(Generator.Generation) ||
|-
| StdDev || Standard deviation of numbers in an array || Value Array (Exclude Value), Integer or Real || Real || StdDev(Generator.Generation) ||
|-
| Avg || Average value of numbers in an array || Value Array (Exclude Value), Integer or Real || Real || Avg(Generator.Generation) ||
|-
| WgtAvg || Average of numbers in an array, weighted by numbers in another array || Value Array (Weights Array), Integer or Real || Real || WgtAvg(Generator.Generation,Generator.Cost) ||
|-
| Choke || Returns a collared value (i.e. the value of the referenced variable is returned if it falls within the specified range otherwise the relevant minimum or maximum value is returned) || Integer or Real || Real || Choke(500,200,Generator.Generation)||
|}

===Logic Functions===

The following table lists EMarket3's Logic functions:
{|class="wikitable"
! Operator !! Purpose !! Parameters !! Return Value !! Example !! Result
|-
| = || Whether two numbers are Equal || 2 numbers, Integer or Real || 0 or 1 || 5 = 6 || 0
|-
| < || Whether first number is less than the second || 2 numbers, Integer or Real || 0 or 1 || -2 < 7 || 1
|-
| > || Whether first number is Greater than the second || 2 numbers, Integer or Real || 0 or 1 || 9 > 7 || 1
|-
| AND || Whether two numbers are both non-zero || 2 numbers, Integer or Real || 0 or 1 || And(6=6,4<3) || 0
|-
| OR || Whether either of two numbers are non-zero || 2 numbers, Integer or Real || 0 or 1 || OR(3<5, 2>3) || 1
|-
| Between || Whether a number is between two limits || Number: lower limit; upper limit, Integer, real or date || 0 or 1 || Between(5.7,9.7) || 0
|}

===Run Information Functions===

The following table lists EMarket's Run information functions:
{|class="wikitable"
! Function !! Purpose !! Parameters !! Return Type
|-
| Date || Date of current Tick || None || Date
|-
| TP || TP number of current Tick || None || Integer
|-
| Version || The position of a Run in a Batch sequence. For first Run, Version is zero. || None || Integer
|}

===Time Functions===

The following table lists EMarket's Time functions:
{|class="wikitable"
! Function !! Purpose !! Parameters !! Return Type !! Example !! Result
|-
| GetDate || Converts a date to a day number || Date || Integer || GetDate('1/4/2004') ||
|-
| hh || Gets the half hourly TP from a date || 'DateTime' || Integer || hh(DateTime) ||
|-
| 4h || Gets the number of the block of 4 hourly trading periods for a given date (e.g. 1 = TP 1-8) || 'DateTime' || Integer || 4h(DateTime) ||
|-
| 6h || Gets the number of the block of 6 hourly trading periods for a given date (e.g. 0 = TP 1-12) || 'DateTime' || Integer || 6h(DateTime) ||
|-
| DOW || Gets the weekday for a date, 0 = Sunday || Date || Integer || Dow('14/6/2004') || 1
|-
| WO || Whether a date is a week day rather than a weekend or holiday, 1 = Weekend; 0 = Weekday || Date || 0 or 1 || WO('13/6/2004') || 1
|-
| WODN || 0=Week Night(WN); 1=Week Day(WD); 2=Other Night(ON); 3=Other Day(OF) || Date (and time) || 0 to 3 || WODN('1/5/2004 22:00') || 3
|-
| WODN6 || 0=Week Night(WN); 1=Week Day(WD); 2=Other Night(ON); 3=Other Day(OF). Using A night period running from Midnight to 6am (not to 8am as in WODN) || Date (and time) || 0 to 3 || WODN6('1/5/2004 22:00') || 3
|-
| Month || Gets the month from a date, 0 = January || Date || 0 to 11 || Month('1/5/2004') || 4
|-
| WeekOfYear || Gets the week from a date, 0 = 1st full week in April || Date || 0 to 51 || WeekOfYear('1/5/2004') || 4
|-
| DateDiff || Calculates the number of days between two date/times || Date 1, Date2 || Real || DateDiff('1/5/2004', '5/5/004') || 4
|-
| DateSeq || Gets the position of a required date within a list of ordered dates || Date required, Lists of dates || Integer || DateSeq('5 / 4 / 2004', '1 / 4 / 2004', '2 / 4 / 2004', '3 / 4 / 2004', '4 / 4 / 2004', '5 / 4 / 2004') || 5
|-
| TimeSeries || Given a date ordered sequence of values, finds the value for a required date || List of (value, first date and time period applies) || Real || TimeSeries(735 , ' 1/04/2004:24 ', 760 , ' 1/04/2005:01 ', 840) ||
|}

===Other Functions===

The following table lists EMarket's other functions:
{|class="wikitable"
! Function !! Purpose !! Parameters !! Return Type !! Example !! Result
|-
| ArrayTable || Uses two indices to retrieve a value from an array (matrix) || Index1, Index2, Value array. May be real or Integer || Real or Integer || ArrayTable(p,q,m,n, V00, V01, V02, ...V0m, V10, V11, ... Vnm) where p,q represent the position of the array; m,n represent the numbers of columns and rows in the array; 0<= p < m and 0 <= q < n would return Vpq. E.g. ArrayTable(1, 1, 2, 3, 4, 32.1, 6.3, 1.8, 31, 5). This defines a 2 * 3 matrix, and looks for the entry indexed by 1, 1. Note that if the indices are out of bounds no error will be given, and an indeterminate value will be returned. || 31
|-
| Index || Gets the number in given position (index) in a list of numbers. First number has position zero. || 1 or more numbers, can be integers or real || Real || Index(p, V0, V1, V2, ... Vm) where p is the position (index) in a list of numbers. E.g. Index(3, 4.5, 7, 8.9, -23.4) || -23.4
|-
| PieceWiseLinear || Generates a value based on an extrapolation of existing data. Given a target value (p) and a set of x, y pairings defining a function, the PieceWiseLinear function will find the y value corresponding to p. This function is included primarily for use in defining Demand elasticity. || Set of x,y value pairings, can be integers or real || Real or Integer || PieceWiseLinear(p, x1, y1, x2, y2, ...xn, yn) where p is the target value. Note that you can use internal model variables as the target value, as in this example: PieceWiseLinear(HydroSystem:Waitaki.SystemMWV, 0, 1, 80, 1, 150, 0.8, 400, 0.64) ||
|}

===Random Functions===

the following random functions create a random sequence, the results of which depend on the seed given, the start date of the sequence and the order of definition and exact formula used to define the function. The RandomSeed variable should usually be used as the seed as this will ensure a unique sequence is generated based on the "Random Seed" option chosen for the run

{|class="wikitable"
! Function !! Purpose !! Parameters !! Return Type !! Example
|-
| RandomBinaryState || Returns values from a random sequence of values which are either 0 or 1 with the properties that proportion of the time spent in the zero state is a given proportion and the average length of time spent in the one state is a given number of days || Seed for random sequence, Date/Time, Zero state proportion, Average One state length || Real || RandomBinaryState(Seed, DateTime, 0.95, 4), will return a random 0/1 series with 0.05 time spent in the one state and an average four day span of each one state
|-
| MRJD || Returns a value that follows a mean reverting random walk on a logarithmic scale || Seed for random sequence, Date/Time, Starting Value, Mean, Reversion Rate, Volatility[,ProportionalJump, JumpVolatility, JumpFrequency] || Real ||MRJD(RandomSeed, DateTime, 5, 10, 11, 5), will return a random walk starting with the value 5 where the average log value is equal to log(10), reversion rate of 10 (half reversion in 1/10 year), volatility of 5 (two times diffusion in 1/5 year). The jump parameters are optional
|}

[[EMK:EMarket User Manual | Back to User Manual Main Page]]

Special:Badtitle/NS108:Main Page

2013-06-20T03:37:39Z

NelsonM:

{{#hidens:}}

; Current Release Version of EMarket: ''EMarket 5.3.6''

''[[Release Notes | EMarket 5 Release Notes]]''

'''[[EMK:EMarket User Manual | EMarket User Manual]]'''

'''[[EMK:EMarket 5 Notes | EMarket 5 Release Commentary]]'''

'''[[EMK:EMarket Development | EMarket Development Path and Requests]]'''

Special:Badtitle/NS108:Main Page

2013-06-20T03:36:23Z

NelsonM:

{{#hidens:}}

; Current Release Version of EMarket: ''EMarket 5.3.6''

'''[[EMK:EMarket User Manual | EMarket User Manual]]'''

'''[[EMK:EMarket 5 Notes | EMarket 5 Release Commentary]]'''

'''[[EMK:EMarket Development | EMarket Development Path and Requests]]'''

Special:Badtitle/NS108:EMarket 5 Release Notes

2013-06-20T03:35:35Z

NelsonM:

{{#hidens:}}
;EMarket 5.3.5 -> 5.3.6
* Enhanced auditing tools and information through log.
* Logging via text from command line "-1 drive:\Dir\file.ext
* Command Line Reports bug fix

EMarket 5.3.4 -> 5.3.5
* When EMarket is run from the command line it will not run if a manually opened EMarket is using the working directory - and vice versa,

;EMarket 5.3.3 -> 5.3.4
*Added Line.Outage trait which can be used to set full or partial outages, value should be from 0 to 1
Note that capacities are adjusted when this value is set.

;EMarket 5.3.2 -> 5.3.3
* Fixed error with output spec occasionally reporting an extra, non-existent version
* Added RunningAverage function, parameters DateTime, Value and HalfLife (days)
* The log window now has a 'copy all' button for copying the log entries to the clipboard

;EMarket 5.3.1 -> 5.3.2
* Fixed a bug with random walk and random outage generation, the bug caused zero values in morning periods.
* Run check now warns if the file in File function does not exist

;EMarket 5.3.0 -> 5.3.1
* Fixed bug where hydro potentials were unable to be calculated when MaxGen and MinGen were set to the same value. This caused SystemStorage to go to zero.

;EMarket 5.2.7 -> 5.3.0
* Equation versions can now be created in the Grid resource. Setting the Equation.Version determines the version in use (default is 0). Setting Equation.Version to -1 or a number greater than the highest version will disable the equation.
* Allows trading periods in date literals in the Schedule, the format is <date>:<trading period> e.g. 1 Mar 2013:8 returns the date and time starting at the beginning of the 8th trading period

;EMarket 5.2.6 -> 5.2.7
* Logs are now named with the run name and resource number appended
* Added RandomSeed variable, which is defined using the "Random Seed" (formerly "Random Outage Seed")option in the Run definition
* Added RandomBinaryState and MRJD functions
* Added traits Generator.Availability and Generator.AverageOutageDuration which can be redefined to change the random outage behavior of a generation over time
* Added trait Generator.Outage, by default this is defined "RandomBinaryState(RandomSeed,DateTime,.Availability,.AverageOutageDuration)"
* The run form is now resizeable

;EMarket 5.2.4 -> 5.2.6
* Random outage modelling is now done on a half hourly basis
* Fixed a bug where water values were incorrectly calculated near the end of the run
* Added Calc Extra Water Value Weeks to the run parameters, this allows water values to be calculated beyond the end of the run.

;EMarket 5.2.3 -> 5.2.4
* Fixed bug that put extra divisions in 3h Output Spec partition
* Version dimension partitons in the OS. Useful if there are more than one variable in the volatility matrix. partitions by a single variable in the volatility matrix Syntax: "Version(<dimension name>):All" e.g. "Version(InflowYear):All"

;EMarket 5.2.2 -> 5.2.3
* Improved eaccuracy of demand monthly input process
* Fixed bug that lost the EMarket version entry in the log file
* Saved Run Resource is now named <RunName>_Resource.txt

;EMarket 5.2.1 -> 5.2.2
* Output spec functions First() and Last() have been added

;EMarket 5.1.4 -> 5.2.1
* The table for creating profiled offers has been changed in the generator offer screen. The table now has the option to profile by month, options for division by weekday and options for division by the time of day
* 1h 2h 3h, 8h, DN and DN6 schedule functions have been added
* The OutputSpec has some more partition options: 1h 2h 3h 6h and 8h, which divide by the time of day
* The Help menu item now opens the EMarket help wiki.
* Made directory creation more robust against race conditions (more than one EMarket trying to create a directory). This avoids sporadic errors when running more than one copy of EMarket at a time.

;EMarket 5.1.2 -> 5.1.4

* Added 1h, 2h and 3h time steps model run

;EMarket 5.0.9 -> 5.1.2

* Added Line.Excess and Line.Losses built in traits
* Fixed generator revenue for generators with distributed offers
* Added the use run results offers feature - requires '-RO(<run name>)' in the run description
* Water value grid simplification can deal with 4 or more character node names. There must still be only one HVDC attached to a nodes with names starting with 'BEN' and 'HAY'
* Adjusted the months required by the demand input settings, so that it needs to cover the period over which water values are calculated
* Fixed bugs caused calculating run end dates and water value periods

;EMarket 4.3.1 -> 5.0.7

*OutputSpecs can now create multiple files. A File partition set has been added and a file is created for each resulting partition.
*Output Spec 'Year' partition has been added, this divides the OS report into each year the forecast covers
*Output Spec 'MonthOfYear' partition has been added, this divides the OS report in 12, one division for each month of the year ( as opposed to the 'Month' partition which creates one for every month in the forecast)
*The headers for each File partition can be added to either the row or column headers

* The number of decimal places to be written to output spec reports can now be specified by adding a :<n> suffix in the function specification. E.g. Function: Tot(Generator.Generation):1
* Monthly Demand Input added, this feature facilitates the specification of regional demand by month by allowing expected average demand rates to be entered either as average demand for weekday or other day or a single value representing average demand for a 5 week day / 2 other day week. The monthly demand input requires the entry of demand rates for all regions and all months covering the duration of the run and the twenty four months following the run. The extra twenty four months of demand is required so that water value modelling can be done.
* MonthDiff schedule function added.
* Fixed bug with LastVal not picking up zero values
* Added a checks for badly assigned reserve regions, avoids accidental assignment of nodes to the wrong island (which impacts water value calculation).
* Added command line running functionality, including the ability to start runs on opening and execute specified volatility values
* Fixed bug with reading grid resource where nodes were wrongly assigned to lines when they were out of alphabetical order
* Grid Versions enabled
* Multi-Year Water Values implemented
* New output database, split by version
* WVs only feature, and Wait for WVs feature

[[EMK:Release Notes|Back]]

Special:Badtitle/NS108:EMarket 5 Release Notes

2013-06-20T03:35:01Z

NelsonM:

{{#hidens:}}
;EMarket 5.3.5 -> 5.3.6
* Enhanced auditing tools and information through log.
* Logging via text from command line "-1 drive:\Dir\file.ext
* Command Line Reports bug fix

;EMarket 5.3.3 -> 5.3.4
*Added Line.Outage trait which can be used to set full or partial outages, value should be from 0 to 1
Note that capacities are adjusted when this value is set.

;EMarket 5.3.2 -> 5.3.3
* Fixed error with output spec occasionally reporting an extra, non-existent version
* Added RunningAverage function, parameters DateTime, Value and HalfLife (days)
* The log window now has a 'copy all' button for copying the log entries to the clipboard

;EMarket 5.3.1 -> 5.3.2
* Fixed a bug with random walk and random outage generation, the bug caused zero values in morning periods.
* Run check now warns if the file in File function does not exist

;EMarket 5.3.0 -> 5.3.1
* Fixed bug where hydro potentials were unable to be calculated when MaxGen and MinGen were set to the same value. This caused SystemStorage to go to zero.

;EMarket 5.2.7 -> 5.3.0
* Equation versions can now be created in the Grid resource. Setting the Equation.Version determines the version in use (default is 0). Setting Equation.Version to -1 or a number greater than the highest version will disable the equation.
* Allows trading periods in date literals in the Schedule, the format is <date>:<trading period> e.g. 1 Mar 2013:8 returns the date and time starting at the beginning of the 8th trading period

;EMarket 5.2.6 -> 5.2.7
* Logs are now named with the run name and resource number appended
* Added RandomSeed variable, which is defined using the "Random Seed" (formerly "Random Outage Seed")option in the Run definition
* Added RandomBinaryState and MRJD functions
* Added traits Generator.Availability and Generator.AverageOutageDuration which can be redefined to change the random outage behavior of a generation over time
* Added trait Generator.Outage, by default this is defined "RandomBinaryState(RandomSeed,DateTime,.Availability,.AverageOutageDuration)"
* The run form is now resizeable

;EMarket 5.2.4 -> 5.2.6
* Random outage modelling is now done on a half hourly basis
* Fixed a bug where water values were incorrectly calculated near the end of the run
* Added Calc Extra Water Value Weeks to the run parameters, this allows water values to be calculated beyond the end of the run.

;EMarket 5.2.3 -> 5.2.4
* Fixed bug that put extra divisions in 3h Output Spec partition
* Version dimension partitons in the OS. Useful if there are more than one variable in the volatility matrix. partitions by a single variable in the volatility matrix Syntax: "Version(<dimension name>):All" e.g. "Version(InflowYear):All"

;EMarket 5.2.2 -> 5.2.3
* Improved eaccuracy of demand monthly input process
* Fixed bug that lost the EMarket version entry in the log file
* Saved Run Resource is now named <RunName>_Resource.txt

;EMarket 5.2.1 -> 5.2.2
* Output spec functions First() and Last() have been added

;EMarket 5.1.4 -> 5.2.1
* The table for creating profiled offers has been changed in the generator offer screen. The table now has the option to profile by month, options for division by weekday and options for division by the time of day
* 1h 2h 3h, 8h, DN and DN6 schedule functions have been added
* The OutputSpec has some more partition options: 1h 2h 3h 6h and 8h, which divide by the time of day
* The Help menu item now opens the EMarket help wiki.
* Made directory creation more robust against race conditions (more than one EMarket trying to create a directory). This avoids sporadic errors when running more than one copy of EMarket at a time.

;EMarket 5.1.2 -> 5.1.4

* Added 1h, 2h and 3h time steps model run

;EMarket 5.0.9 -> 5.1.2

* Added Line.Excess and Line.Losses built in traits
* Fixed generator revenue for generators with distributed offers
* Added the use run results offers feature - requires '-RO(<run name>)' in the run description
* Water value grid simplification can deal with 4 or more character node names. There must still be only one HVDC attached to a nodes with names starting with 'BEN' and 'HAY'
* Adjusted the months required by the demand input settings, so that it needs to cover the period over which water values are calculated
* Fixed bugs caused calculating run end dates and water value periods

;EMarket 4.3.1 -> 5.0.7

*OutputSpecs can now create multiple files. A File partition set has been added and a file is created for each resulting partition.
*Output Spec 'Year' partition has been added, this divides the OS report into each year the forecast covers
*Output Spec 'MonthOfYear' partition has been added, this divides the OS report in 12, one division for each month of the year ( as opposed to the 'Month' partition which creates one for every month in the forecast)
*The headers for each File partition can be added to either the row or column headers

* The number of decimal places to be written to output spec reports can now be specified by adding a :<n> suffix in the function specification. E.g. Function: Tot(Generator.Generation):1
* Monthly Demand Input added, this feature facilitates the specification of regional demand by month by allowing expected average demand rates to be entered either as average demand for weekday or other day or a single value representing average demand for a 5 week day / 2 other day week. The monthly demand input requires the entry of demand rates for all regions and all months covering the duration of the run and the twenty four months following the run. The extra twenty four months of demand is required so that water value modelling can be done.
* MonthDiff schedule function added.
* Fixed bug with LastVal not picking up zero values
* Added a checks for badly assigned reserve regions, avoids accidental assignment of nodes to the wrong island (which impacts water value calculation).
* Added command line running functionality, including the ability to start runs on opening and execute specified volatility values
* Fixed bug with reading grid resource where nodes were wrongly assigned to lines when they were out of alphabetical order
* Grid Versions enabled
* Multi-Year Water Values implemented
* New output database, split by version
* WVs only feature, and Wait for WVs feature

[[EMK:Release Notes|Back]]

Special:Badtitle/NS108:EMarket 5 Release Notes

2013-05-23T03:34:45Z

NelsonM:

{{#hidens:}}
;EMarket 5.3.3 -> 5.3.4
*Added Line.Outage trait which can be used to set full or partial outages, value should be from 0 to 1
Note that capacities are adjusted when this value is set.

;EMarket 5.3.2 -> 5.3.3
* Fixed error with output spec occasionally reporting an extra, non-existent version
* Added RunningAverage function, parameters DateTime, Value and HalfLife (days)
* The log window now has a 'copy all' button for copying the log entries to the clipboard

;EMarket 5.3.1 -> 5.3.2
* Fixed a bug with random walk and random outage generation, the bug caused zero values in morning periods.
* Run check now warns if the file in File function does not exist

;EMarket 5.3.0 -> 5.3.1
* Fixed bug where hydro potentials were unable to be calculated when MaxGen and MinGen were set to the same value. This caused SystemStorage to go to zero.

;EMarket 5.2.7 -> 5.3.0
* Equation versions can now be created in the Grid resource. Setting the Equation.Version determines the version in use (default is 0). Setting Equation.Version to -1 or a number greater than the highest version will disable the equation.
* Allows trading periods in date literals in the Schedule, the format is <date>:<trading period> e.g. 1 Mar 2013:8 returns the date and time starting at the beginning of the 8th trading period

;EMarket 5.2.6 -> 5.2.7
* Logs are now named with the run name and resource number appended
* Added RandomSeed variable, which is defined using the "Random Seed" (formerly "Random Outage Seed")option in the Run definition
* Added RandomBinaryState and MRJD functions
* Added traits Generator.Availability and Generator.AverageOutageDuration which can be redefined to change the random outage behavior of a generation over time
* Added trait Generator.Outage, by default this is defined "RandomBinaryState(RandomSeed,DateTime,.Availability,.AverageOutageDuration)"
* The run form is now resizeable

;EMarket 5.2.4 -> 5.2.6
* Random outage modelling is now done on a half hourly basis
* Fixed a bug where water values were incorrectly calculated near the end of the run
* Added Calc Extra Water Value Weeks to the run parameters, this allows water values to be calculated beyond the end of the run.

;EMarket 5.2.3 -> 5.2.4
* Fixed bug that put extra divisions in 3h Output Spec partition
* Version dimension partitons in the OS. Useful if there are more than one variable in the volatility matrix. partitions by a single variable in the volatility matrix Syntax: "Version(<dimension name>):All" e.g. "Version(InflowYear):All"

;EMarket 5.2.2 -> 5.2.3
* Improved eaccuracy of demand monthly input process
* Fixed bug that lost the EMarket version entry in the log file
* Saved Run Resource is now named <RunName>_Resource.txt

;EMarket 5.2.1 -> 5.2.2
* Output spec functions First() and Last() have been added

;EMarket 5.1.4 -> 5.2.1
* The table for creating profiled offers has been changed in the generator offer screen. The table now has the option to profile by month, options for division by weekday and options for division by the time of day
* 1h 2h 3h, 8h, DN and DN6 schedule functions have been added
* The OutputSpec has some more partition options: 1h 2h 3h 6h and 8h, which divide by the time of day
* The Help menu item now opens the EMarket help wiki.
* Made directory creation more robust against race conditions (more than one EMarket trying to create a directory). This avoids sporadic errors when running more than one copy of EMarket at a time.

;EMarket 5.1.2 -> 5.1.4

* Added 1h, 2h and 3h time steps model run

;EMarket 5.0.9 -> 5.1.2

* Added Line.Excess and Line.Losses built in traits
* Fixed generator revenue for generators with distributed offers
* Added the use run results offers feature - requires '-RO(<run name>)' in the run description
* Water value grid simplification can deal with 4 or more character node names. There must still be only one HVDC attached to a nodes with names starting with 'BEN' and 'HAY'
* Adjusted the months required by the demand input settings, so that it needs to cover the period over which water values are calculated
* Fixed bugs caused calculating run end dates and water value periods

;EMarket 4.3.1 -> 5.0.7

*OutputSpecs can now create multiple files. A File partition set has been added and a file is created for each resulting partition.
*Output Spec 'Year' partition has been added, this divides the OS report into each year the forecast covers
*Output Spec 'MonthOfYear' partition has been added, this divides the OS report in 12, one division for each month of the year ( as opposed to the 'Month' partition which creates one for every month in the forecast)
*The headers for each File partition can be added to either the row or column headers

* The number of decimal places to be written to output spec reports can now be specified by adding a :<n> suffix in the function specification. E.g. Function: Tot(Generator.Generation):1
* Monthly Demand Input added, this feature facilitates the specification of regional demand by month by allowing expected average demand rates to be entered either as average demand for weekday or other day or a single value representing average demand for a 5 week day / 2 other day week. The monthly demand input requires the entry of demand rates for all regions and all months covering the duration of the run and the twenty four months following the run. The extra twenty four months of demand is required so that water value modelling can be done.
* MonthDiff schedule function added.
* Fixed bug with LastVal not picking up zero values
* Added a checks for badly assigned reserve regions, avoids accidental assignment of nodes to the wrong island (which impacts water value calculation).
* Added command line running functionality, including the ability to start runs on opening and execute specified volatility values
* Fixed bug with reading grid resource where nodes were wrongly assigned to lines when they were out of alphabetical order
* Grid Versions enabled
* Multi-Year Water Values implemented
* New output database, split by version
* WVs only feature, and Wait for WVs feature

[[EMK:Release Notes|Back]]

Special:Badtitle/NS108:Main Page

2013-05-23T03:33:52Z

NelsonM:

{{#hidens:}}

; Current Release Version of EMarket: ''EMarket 5.3.4''

'''[[EMK:EMarket User Manual | EMarket User Manual]]'''

'''[[EMK:EMarket 5 Notes | EMarket 5 Release Commentary]]'''

'''[[EMK:EMarket Development | EMarket Development Path and Requests]]'''

Special:Badtitle/NS108:EMarket 5 Release Notes

2013-05-15T22:05:40Z

NelsonM:

{{#hidens:}}
;EMarket 5.3.2 -> 5.3.3
* Fixed error with output spec occasionally reporting an extra, non-existent version
* Added RunningAverage function, parameters DateTime, Value and HalfLife (days)
* The log window now has a 'copy all' button for copying the log entries to the clipboard

;EMarket 5.3.1 -> 5.3.2
* Fixed a bug with random walk and random outage generation, the bug caused zero values in morning periods.
* Run check now warns if the file in File function does not exist

;EMarket 5.3.0 -> 5.3.1
* Fixed bug where hydro potentials were unable to be calculated when MaxGen and MinGen were set to the same value. This caused SystemStorage to go to zero.

;EMarket 5.2.7 -> 5.3.0
* Equation versions can now be created in the Grid resource. Setting the Equation.Version determines the version in use (default is 0). Setting Equation.Version to -1 or a number greater than the highest version will disable the equation.
* Allows trading periods in date literals in the Schedule, the format is <date>:<trading period> e.g. 1 Mar 2013:8 returns the date and time starting at the beginning of the 8th trading period

;EMarket 5.2.6 -> 5.2.7
* Logs are now named with the run name and resource number appended
* Added RandomSeed variable, which is defined using the "Random Seed" (formerly "Random Outage Seed")option in the Run definition
* Added RandomBinaryState and MRJD functions
* Added traits Generator.Availability and Generator.AverageOutageDuration which can be redefined to change the random outage behavior of a generation over time
* Added trait Generator.Outage, by default this is defined "RandomBinaryState(RandomSeed,DateTime,.Availability,.AverageOutageDuration)"
* The run form is now resizeable

;EMarket 5.2.4 -> 5.2.6
* Random outage modelling is now done on a half hourly basis
* Fixed a bug where water values were incorrectly calculated near the end of the run
* Added Calc Extra Water Value Weeks to the run parameters, this allows water values to be calculated beyond the end of the run.

;EMarket 5.2.3 -> 5.2.4
* Fixed bug that put extra divisions in 3h Output Spec partition
* Version dimension partitons in the OS. Useful if there are more than one variable in the volatility matrix. partitions by a single variable in the volatility matrix Syntax: "Version(<dimension name>):All" e.g. "Version(InflowYear):All"

;EMarket 5.2.2 -> 5.2.3
* Improved eaccuracy of demand monthly input process
* Fixed bug that lost the EMarket version entry in the log file
* Saved Run Resource is now named <RunName>_Resource.txt

;EMarket 5.2.1 -> 5.2.2
* Output spec functions First() and Last() have been added

;EMarket 5.1.4 -> 5.2.1
* The table for creating profiled offers has been changed in the generator offer screen. The table now has the option to profile by month, options for division by weekday and options for division by the time of day
* 1h 2h 3h, 8h, DN and DN6 schedule functions have been added
* The OutputSpec has some more partition options: 1h 2h 3h 6h and 8h, which divide by the time of day
* The Help menu item now opens the EMarket help wiki.
* Made directory creation more robust against race conditions (more than one EMarket trying to create a directory). This avoids sporadic errors when running more than one copy of EMarket at a time.

;EMarket 5.1.2 -> 5.1.4

* Added 1h, 2h and 3h time steps model run

;EMarket 5.0.9 -> 5.1.2

* Added Line.Excess and Line.Losses built in traits
* Fixed generator revenue for generators with distributed offers
* Added the use run results offers feature - requires '-RO(<run name>)' in the run description
* Water value grid simplification can deal with 4 or more character node names. There must still be only one HVDC attached to a nodes with names starting with 'BEN' and 'HAY'
* Adjusted the months required by the demand input settings, so that it needs to cover the period over which water values are calculated
* Fixed bugs caused calculating run end dates and water value periods

;EMarket 4.3.1 -> 5.0.7

*OutputSpecs can now create multiple files. A File partition set has been added and a file is created for each resulting partition.
*Output Spec 'Year' partition has been added, this divides the OS report into each year the forecast covers
*Output Spec 'MonthOfYear' partition has been added, this divides the OS report in 12, one division for each month of the year ( as opposed to the 'Month' partition which creates one for every month in the forecast)
*The headers for each File partition can be added to either the row or column headers

* The number of decimal places to be written to output spec reports can now be specified by adding a :<n> suffix in the function specification. E.g. Function: Tot(Generator.Generation):1
* Monthly Demand Input added, this feature facilitates the specification of regional demand by month by allowing expected average demand rates to be entered either as average demand for weekday or other day or a single value representing average demand for a 5 week day / 2 other day week. The monthly demand input requires the entry of demand rates for all regions and all months covering the duration of the run and the twenty four months following the run. The extra twenty four months of demand is required so that water value modelling can be done.
* MonthDiff schedule function added.
* Fixed bug with LastVal not picking up zero values
* Added a checks for badly assigned reserve regions, avoids accidental assignment of nodes to the wrong island (which impacts water value calculation).
* Added command line running functionality, including the ability to start runs on opening and execute specified volatility values
* Fixed bug with reading grid resource where nodes were wrongly assigned to lines when they were out of alphabetical order
* Grid Versions enabled
* Multi-Year Water Values implemented
* New output database, split by version
* WVs only feature, and Wait for WVs feature

[[EMK:Release Notes|Back]]

Special:Badtitle/NS108:EMarket 5 Release Notes

2013-05-15T22:05:22Z

NelsonM:

{{#hidens:}}
;EMarket 5.3.1 -> 5.3.3
* Fixed error with output spec occasionally reporting an extra, non-existent version
* Added RunningAverage function, parameters DateTime, Value and HalfLife (days)
* The log window now has a 'copy all' button for copying the log entries to the clipboard

;EMarket 5.3.1 -> 5.3.2
* Fixed a bug with random walk and random outage generation, the bug caused zero values in morning periods.
* Run check now warns if the file in File function does not exist

;EMarket 5.3.0 -> 5.3.1
* Fixed bug where hydro potentials were unable to be calculated when MaxGen and MinGen were set to the same value. This caused SystemStorage to go to zero.

;EMarket 5.2.7 -> 5.3.0
* Equation versions can now be created in the Grid resource. Setting the Equation.Version determines the version in use (default is 0). Setting Equation.Version to -1 or a number greater than the highest version will disable the equation.
* Allows trading periods in date literals in the Schedule, the format is <date>:<trading period> e.g. 1 Mar 2013:8 returns the date and time starting at the beginning of the 8th trading period

;EMarket 5.2.6 -> 5.2.7
* Logs are now named with the run name and resource number appended
* Added RandomSeed variable, which is defined using the "Random Seed" (formerly "Random Outage Seed")option in the Run definition
* Added RandomBinaryState and MRJD functions
* Added traits Generator.Availability and Generator.AverageOutageDuration which can be redefined to change the random outage behavior of a generation over time
* Added trait Generator.Outage, by default this is defined "RandomBinaryState(RandomSeed,DateTime,.Availability,.AverageOutageDuration)"
* The run form is now resizeable

;EMarket 5.2.4 -> 5.2.6
* Random outage modelling is now done on a half hourly basis
* Fixed a bug where water values were incorrectly calculated near the end of the run
* Added Calc Extra Water Value Weeks to the run parameters, this allows water values to be calculated beyond the end of the run.

;EMarket 5.2.3 -> 5.2.4
* Fixed bug that put extra divisions in 3h Output Spec partition
* Version dimension partitons in the OS. Useful if there are more than one variable in the volatility matrix. partitions by a single variable in the volatility matrix Syntax: "Version(<dimension name>):All" e.g. "Version(InflowYear):All"

;EMarket 5.2.2 -> 5.2.3
* Improved eaccuracy of demand monthly input process
* Fixed bug that lost the EMarket version entry in the log file
* Saved Run Resource is now named <RunName>_Resource.txt

;EMarket 5.2.1 -> 5.2.2
* Output spec functions First() and Last() have been added

;EMarket 5.1.4 -> 5.2.1
* The table for creating profiled offers has been changed in the generator offer screen. The table now has the option to profile by month, options for division by weekday and options for division by the time of day
* 1h 2h 3h, 8h, DN and DN6 schedule functions have been added
* The OutputSpec has some more partition options: 1h 2h 3h 6h and 8h, which divide by the time of day
* The Help menu item now opens the EMarket help wiki.
* Made directory creation more robust against race conditions (more than one EMarket trying to create a directory). This avoids sporadic errors when running more than one copy of EMarket at a time.

;EMarket 5.1.2 -> 5.1.4

* Added 1h, 2h and 3h time steps model run

;EMarket 5.0.9 -> 5.1.2

* Added Line.Excess and Line.Losses built in traits
* Fixed generator revenue for generators with distributed offers
* Added the use run results offers feature - requires '-RO(<run name>)' in the run description
* Water value grid simplification can deal with 4 or more character node names. There must still be only one HVDC attached to a nodes with names starting with 'BEN' and 'HAY'
* Adjusted the months required by the demand input settings, so that it needs to cover the period over which water values are calculated
* Fixed bugs caused calculating run end dates and water value periods

;EMarket 4.3.1 -> 5.0.7

*OutputSpecs can now create multiple files. A File partition set has been added and a file is created for each resulting partition.
*Output Spec 'Year' partition has been added, this divides the OS report into each year the forecast covers
*Output Spec 'MonthOfYear' partition has been added, this divides the OS report in 12, one division for each month of the year ( as opposed to the 'Month' partition which creates one for every month in the forecast)
*The headers for each File partition can be added to either the row or column headers

* The number of decimal places to be written to output spec reports can now be specified by adding a :<n> suffix in the function specification. E.g. Function: Tot(Generator.Generation):1
* Monthly Demand Input added, this feature facilitates the specification of regional demand by month by allowing expected average demand rates to be entered either as average demand for weekday or other day or a single value representing average demand for a 5 week day / 2 other day week. The monthly demand input requires the entry of demand rates for all regions and all months covering the duration of the run and the twenty four months following the run. The extra twenty four months of demand is required so that water value modelling can be done.
* MonthDiff schedule function added.
* Fixed bug with LastVal not picking up zero values
* Added a checks for badly assigned reserve regions, avoids accidental assignment of nodes to the wrong island (which impacts water value calculation).
* Added command line running functionality, including the ability to start runs on opening and execute specified volatility values
* Fixed bug with reading grid resource where nodes were wrongly assigned to lines when they were out of alphabetical order
* Grid Versions enabled
* Multi-Year Water Values implemented
* New output database, split by version
* WVs only feature, and Wait for WVs feature

[[EMK:Release Notes|Back]]

Special:Badtitle/NS108:Main Page

2013-05-15T22:03:29Z

NelsonM:

{{#hidens:}}

; Current Release Version of EMarket: ''EMarket 5.3.3''

'''[[EMK:EMarket User Manual | EMarket User Manual]]'''

'''[[EMK:EMarket 5 Notes | EMarket 5 Release Commentary]]'''

'''[[EMK:EMarket Development | EMarket Development Path and Requests]]'''

Special:Badtitle/NS108:EMarket 5 Release Notes

2013-04-23T01:05:20Z

NelsonM:

{{#hidens:}}
;EMarket 5.2.7 -> 5.3.0
* Equation versions can now be created in the Grid resource. Setting the Equation.Version determines the version in use (default is 0). Setting Equation.Version to -1 or a number greater than the highest version will disable the equation.
*Allows trading periods in date literals in the Schedule, the format is <date>:<trading period> e.g. 1 Mar 2013:8 returns the date and time starting at the beginning of the 8th trading period

;EMarket 5.2.6 -> 5.2.7
* Logs are now named with the run name and resource number appended
* Added RandomSeed variable, which is defined using the "Random Seed" (formerly "Random Outage Seed")option in the Run definition
* Added RandomBinaryState and MRJD functions
* Added traits Generator.Availability and Generator.AverageOutageDuration which can be redefined to change the random outage behavior of a generation over time
* Added trait Generator.Outage, by default this is defined "RandomBinaryState(RandomSeed,DateTime,.Availability,.AverageOutageDuration)"
* The run form is now resizeable

;EMarket 5.2.4 -> 5.2.6
* Random outage modelling is now done on a half hourly basis
* Fixed a bug where water values were incorrectly calculated near the end of the run
* Added Calc Extra Water Value Weeks to the run parameters, this allows water values to be calculated beyond the end of the run.

;EMarket 5.2.3 -> 5.2.4
* Fixed bug that put extra divisions in 3h Output Spec partition
* Version dimension partitons in the OS. Useful if there are more than one variable in the volatility matrix. partitions by a single variable in the volatility matrix Syntax: "Version(<dimension name>):All" e.g. "Version(InflowYear):All"

;EMarket 5.2.2 -> 5.2.3
* Improved eaccuracy of demand monthly input process
* Fixed bug that lost the EMarket version entry in the log file
* Saved Run Resource is now named <RunName>_Resource.txt

;EMarket 5.2.1 -> 5.2.2
* Output spec functions First() and Last() have been added

;EMarket 5.1.4 -> 5.2.1
* The table for creating profiled offers has been changed in the generator offer screen. The table now has the option to profile by month, options for division by weekday and options for division by the time of day
* 1h 2h 3h, 8h, DN and DN6 schedule functions have been added
* The OutputSpec has some more partition options: 1h 2h 3h 6h and 8h, which divide by the time of day
* The Help menu item now opens the EMarket help wiki.
* Made directory creation more robust against race conditions (more than one EMarket trying to create a directory). This avoids sporadic errors when running more than one copy of EMarket at a time.

;EMarket 5.1.2 -> 5.1.4

* Added 1h, 2h and 3h time steps model run

;EMarket 5.0.9 -> 5.1.2

* Added Line.Excess and Line.Losses built in traits
* Fixed generator revenue for generators with distributed offers
* Added the use run results offers feature - requires '-RO(<run name>)' in the run description
* Water value grid simplification can deal with 4 or more character node names. There must still be only one HVDC attached to a nodes with names starting with 'BEN' and 'HAY'
* Adjusted the months required by the demand input settings, so that it needs to cover the period over which water values are calculated
* Fixed bugs caused calculating run end dates and water value periods

;EMarket 4.3.1 -> 5.0.7

*OutputSpecs can now create multiple files. A File partition set has been added and a file is created for each resulting partition.
*Output Spec 'Year' partition has been added, this divides the OS report into each year the forecast covers
*Output Spec 'MonthOfYear' partition has been added, this divides the OS report in 12, one division for each month of the year ( as opposed to the 'Month' partition which creates one for every month in the forecast)
*The headers for each File partition can be added to either the row or column headers

* The number of decimal places to be written to output spec reports can now be specified by adding a :<n> suffix in the function specification. E.g. Function: Tot(Generator.Generation):1
* Monthly Demand Input added, this feature facilitates the specification of regional demand by month by allowing expected average demand rates to be entered either as average demand for weekday or other day or a single value representing average demand for a 5 week day / 2 other day week. The monthly demand input requires the entry of demand rates for all regions and all months covering the duration of the run and the twenty four months following the run. The extra twenty four months of demand is required so that water value modelling can be done.
* MonthDiff schedule function added.
* Fixed bug with LastVal not picking up zero values
* Added a checks for badly assigned reserve regions, avoids accidental assignment of nodes to the wrong island (which impacts water value calculation).
* Added command line running functionality, including the ability to start runs on opening and execute specified volatility values
* Fixed bug with reading grid resource where nodes were wrongly assigned to lines when they were out of alphabetical order
* Grid Versions enabled
* Multi-Year Water Values implemented
* New output database, split by version
* WVs only feature, and Wait for WVs feature

[[EMK:Release Notes|Back]]

Special:Badtitle/NS108:EMarket 5 Release Notes

2013-04-22T22:43:09Z

NelsonM:

{{#hidens:}}
;EMarket 5.2.7 -> 5.3.0
* Equation versions can now be created in the Grid resource. Setting the Equation.Version determines the version in use (default is 0). Setting Equation.Version to -1 or a number greater than the highest version will disable the equation.

;EMarket 5.2.6 -> 5.2.7
* Logs are now named with the run name and resource number appended
* Added RandomSeed variable, which is defined using the "Random Seed" (formerly "Random Outage Seed")option in the Run definition
* Added RandomBinaryState and MRJD functions
* Added traits Generator.Availability and Generator.AverageOutageDuration which can be redefined to change the random outage behavior of a generation over time
* Added trait Generator.Outage, by default this is defined "RandomBinaryState(RandomSeed,DateTime,.Availability,.AverageOutageDuration)"
* The run form is now resizeable

;EMarket 5.2.4 -> 5.2.6
* Random outage modelling is now done on a half hourly basis
* Fixed a bug where water values were incorrectly calculated near the end of the run
* Added Calc Extra Water Value Weeks to the run parameters, this allows water values to be calculated beyond the end of the run.

;EMarket 5.2.3 -> 5.2.4
* Fixed bug that put extra divisions in 3h Output Spec partition
* Version dimension partitons in the OS. Useful if there are more than one variable in the volatility matrix. partitions by a single variable in the volatility matrix Syntax: "Version(<dimension name>):All" e.g. "Version(InflowYear):All"

;EMarket 5.2.2 -> 5.2.3
* Improved eaccuracy of demand monthly input process
* Fixed bug that lost the EMarket version entry in the log file
* Saved Run Resource is now named <RunName>_Resource.txt

;EMarket 5.2.1 -> 5.2.2
* Output spec functions First() and Last() have been added

;EMarket 5.1.4 -> 5.2.1
* The table for creating profiled offers has been changed in the generator offer screen. The table now has the option to profile by month, options for division by weekday and options for division by the time of day
* 1h 2h 3h, 8h, DN and DN6 schedule functions have been added
* The OutputSpec has some more partition options: 1h 2h 3h 6h and 8h, which divide by the time of day
* The Help menu item now opens the EMarket help wiki.
* Made directory creation more robust against race conditions (more than one EMarket trying to create a directory). This avoids sporadic errors when running more than one copy of EMarket at a time.

;EMarket 5.1.2 -> 5.1.4

* Added 1h, 2h and 3h time steps model run

;EMarket 5.0.9 -> 5.1.2

* Added Line.Excess and Line.Losses built in traits
* Fixed generator revenue for generators with distributed offers
* Added the use run results offers feature - requires '-RO(<run name>)' in the run description
* Water value grid simplification can deal with 4 or more character node names. There must still be only one HVDC attached to a nodes with names starting with 'BEN' and 'HAY'
* Adjusted the months required by the demand input settings, so that it needs to cover the period over which water values are calculated
* Fixed bugs caused calculating run end dates and water value periods

;EMarket 4.3.1 -> 5.0.7

*OutputSpecs can now create multiple files. A File partition set has been added and a file is created for each resulting partition.
*Output Spec 'Year' partition has been added, this divides the OS report into each year the forecast covers
*Output Spec 'MonthOfYear' partition has been added, this divides the OS report in 12, one division for each month of the year ( as opposed to the 'Month' partition which creates one for every month in the forecast)
*The headers for each File partition can be added to either the row or column headers

* The number of decimal places to be written to output spec reports can now be specified by adding a :<n> suffix in the function specification. E.g. Function: Tot(Generator.Generation):1
* Monthly Demand Input added, this feature facilitates the specification of regional demand by month by allowing expected average demand rates to be entered either as average demand for weekday or other day or a single value representing average demand for a 5 week day / 2 other day week. The monthly demand input requires the entry of demand rates for all regions and all months covering the duration of the run and the twenty four months following the run. The extra twenty four months of demand is required so that water value modelling can be done.
* MonthDiff schedule function added.
* Fixed bug with LastVal not picking up zero values
* Added a checks for badly assigned reserve regions, avoids accidental assignment of nodes to the wrong island (which impacts water value calculation).
* Added command line running functionality, including the ability to start runs on opening and execute specified volatility values
* Fixed bug with reading grid resource where nodes were wrongly assigned to lines when they were out of alphabetical order
* Grid Versions enabled
* Multi-Year Water Values implemented
* New output database, split by version
* WVs only feature, and Wait for WVs feature

[[EMK:Release Notes|Back]]

Special:Badtitle/NS108:EMarket 5 Release Notes

2013-04-22T22:41:57Z

NelsonM:

{{#hidens:}}
;EMarket 5.2.7 -> 5.3.0
- Equation versions can now be created in the Grid resource. Setting the Equation.Version determines the version in use (default is 0). Setting Equation.Version to -1 or a number greater than the highest version will disable the equation.

;EMarket 5.2.6 -> 5.2.7
* Logs are now named with the run name and resource number appended
* Added RandomSeed variable, which is defined using the "Random Seed" (formerly "Random Outage Seed")option in the Run definition
* Added RandomBinaryState and MRJD functions
* Added traits Generator.Availability and Generator.AverageOutageDuration which can be redefined to change the random outage behavior of a generation over time
* Added trait Generator.Outage, by default this is defined "RandomBinaryState(RandomSeed,DateTime,.Availability,.AverageOutageDuration)"
* The run form is now resizeable

;EMarket 5.2.4 -> 5.2.6
- Random outage modelling is now done on a half hourly basis
- Fixed a bug where water values were incorrectly calculated near the end of the run
- Added Calc Extra Water Value Weeks to the run parameters, this allows water values to be calculated beyond the end of the run.

;EMarket 5.2.3 -> 5.2.4
- Fixed bug that put extra divisions in 3h Output Spec partition
- Version dimension partitons in the OS. Useful if there are more than one variable in the volatility matrix. partitions by a single variable in the volatility matrix Syntax: "Version(<dimension name>):All" e.g. "Version(InflowYear):All"

;EMarket 5.2.2 -> 5.2.3
- Improved eaccuracy of demand monthly input process
- Fixed bug that lost the EMarket version entry in the log file
- Saved Run Resource is now named <RunName>_Resource.txt

;EMarket 5.2.1 -> 5.2.2
- Output spec functions First() and Last() have been added

;EMarket 5.1.4 -> 5.2.1
- The table for creating profiled offers has been changed in the generator offer screen. The table now has the option to profile by month, options for division by weekday and options for division by the time of day
- 1h 2h 3h, 8h, DN and DN6 schedule functions have been added
- The OutputSpec has some more partition options: 1h 2h 3h 6h and 8h, which divide by the time of day
- The Help menu item now opens the EMarket help wiki.
- Made directory creation more robust against race conditions (more than one EMarket trying to create a directory). This avoids sporadic errors when running more than one copy of EMarket at a time.

;EMarket 5.1.2 -> 5.1.4

- Added 1h, 2h and 3h time steps model run

;EMarket 5.0.9 -> 5.1.2

- Added Line.Excess and Line.Losses built in traits
- Fixed generator revenue for generators with distributed offers
- Added the use run results offers feature - requires '-RO(<run name>)' in the run description
- Water value grid simplification can deal with 4 or more character node names. There must still be only one HVDC attached to a nodes with names starting with 'BEN' and 'HAY'
- Adjusted the months required by the demand input settings, so that it needs to cover the period over which water values are calculated
- Fixed bugs caused calculating run end dates and water value periods

;EMarket 4.3.1 -> 5.0.7

-OutputSpecs can now create multiple files. A File partition set has been added and a file is created for each resulting partition.
-Output Spec 'Year' partition has been added, this divides the OS report into each year the forecast covers
-Output Spec 'MonthOfYear' partition has been added, this divides the OS report in 12, one division for each month of the year ( as opposed to the 'Month' partition which creates one for every month in the forecast)
-The headers for each File partition can be added to either the row or column headers

- The number of decimal places to be written to output spec reports can now be specified by adding a :<n> suffix in the function specification. E.g. Function: Tot(Generator.Generation):1
- Monthly Demand Input added, this feature facilitates the specification of regional demand by month by allowing expected average demand rates to be entered either as average demand for weekday or other day or a single value representing average demand for a 5 week day / 2 other day week. The monthly demand input requires the entry of demand rates for all regions and all months covering the duration of the run and the twenty four months following the run. The extra twenty four months of demand is required so that water value modelling can be done.
- MonthDiff schedule function added.
- Fixed bug with LastVal not picking up zero values
- Added a checks for badly assigned reserve regions, avoids accidental assignment of nodes to the wrong island (which impacts water value calculation).
- Added command line running functionality, including the ability to start runs on opening and execute specified volatility values
- Fixed bug with reading grid resource where nodes were wrongly assigned to lines when they were out of alphabetical order
- Grid Versions enabled
- Multi-Year Water Values implemented
- New output database, split by version
- WVs only feature, and Wait for WVs feature

[[EMK:Release Notes|Back]]

Special:Badtitle/NS108:EMarket 5 Release Notes

2013-04-22T22:41:35Z

NelsonM:

{{#hidens:}}
;EMarket 5.2.7 -> 5.3.0
- Equation versions can now be created in the Grid resource. Setting the Equation.Version determines the version in use (default is 0). Setting Equation.Version to -1 or a number greater than the highest version will disable the equation.

;EMarket 5.2.6 -> 5.2.7
- Logs are now named with the run name and resource number appended
- Added RandomSeed variable, which is defined using the "Random Seed" (formerly "Random Outage Seed")option in the Run definition
- Added RandomBinaryState and MRJD functions
- Added traits Generator.Availability and Generator.AverageOutageDuration which can be redefined to change the random outage behavior of a generation over time
- Added trait Generator.Outage, by default this is defined "RandomBinaryState(RandomSeed,DateTime,.Availability,.AverageOutageDuration)"
- The run form is now resizeable

;EMarket 5.2.4 -> 5.2.6
- Random outage modelling is now done on a half hourly basis
- Fixed a bug where water values were incorrectly calculated near the end of the run
- Added Calc Extra Water Value Weeks to the run parameters, this allows water values to be calculated beyond the end of the run.

;EMarket 5.2.3 -> 5.2.4
- Fixed bug that put extra divisions in 3h Output Spec partition
- Version dimension partitons in the OS. Useful if there are more than one variable in the volatility matrix. partitions by a single variable in the volatility matrix Syntax: "Version(<dimension name>):All" e.g. "Version(InflowYear):All"

;EMarket 5.2.2 -> 5.2.3
- Improved eaccuracy of demand monthly input process
- Fixed bug that lost the EMarket version entry in the log file
- Saved Run Resource is now named <RunName>_Resource.txt

;EMarket 5.2.1 -> 5.2.2
- Output spec functions First() and Last() have been added

;EMarket 5.1.4 -> 5.2.1
- The table for creating profiled offers has been changed in the generator offer screen. The table now has the option to profile by month, options for division by weekday and options for division by the time of day
- 1h 2h 3h, 8h, DN and DN6 schedule functions have been added
- The OutputSpec has some more partition options: 1h 2h 3h 6h and 8h, which divide by the time of day
- The Help menu item now opens the EMarket help wiki.
- Made directory creation more robust against race conditions (more than one EMarket trying to create a directory). This avoids sporadic errors when running more than one copy of EMarket at a time.

;EMarket 5.1.2 -> 5.1.4

- Added 1h, 2h and 3h time steps model run

;EMarket 5.0.9 -> 5.1.2

- Added Line.Excess and Line.Losses built in traits
- Fixed generator revenue for generators with distributed offers
- Added the use run results offers feature - requires '-RO(<run name>)' in the run description
- Water value grid simplification can deal with 4 or more character node names. There must still be only one HVDC attached to a nodes with names starting with 'BEN' and 'HAY'
- Adjusted the months required by the demand input settings, so that it needs to cover the period over which water values are calculated
- Fixed bugs caused calculating run end dates and water value periods

;EMarket 4.3.1 -> 5.0.7

-OutputSpecs can now create multiple files. A File partition set has been added and a file is created for each resulting partition.
-Output Spec 'Year' partition has been added, this divides the OS report into each year the forecast covers
-Output Spec 'MonthOfYear' partition has been added, this divides the OS report in 12, one division for each month of the year ( as opposed to the 'Month' partition which creates one for every month in the forecast)
-The headers for each File partition can be added to either the row or column headers

- The number of decimal places to be written to output spec reports can now be specified by adding a :<n> suffix in the function specification. E.g. Function: Tot(Generator.Generation):1
- Monthly Demand Input added, this feature facilitates the specification of regional demand by month by allowing expected average demand rates to be entered either as average demand for weekday or other day or a single value representing average demand for a 5 week day / 2 other day week. The monthly demand input requires the entry of demand rates for all regions and all months covering the duration of the run and the twenty four months following the run. The extra twenty four months of demand is required so that water value modelling can be done.
- MonthDiff schedule function added.
- Fixed bug with LastVal not picking up zero values
- Added a checks for badly assigned reserve regions, avoids accidental assignment of nodes to the wrong island (which impacts water value calculation).
- Added command line running functionality, including the ability to start runs on opening and execute specified volatility values
- Fixed bug with reading grid resource where nodes were wrongly assigned to lines when they were out of alphabetical order
- Grid Versions enabled
- Multi-Year Water Values implemented
- New output database, split by version
- WVs only feature, and Wait for WVs feature

[[EMK:Release Notes|Back]]

Special:Badtitle/NS108:Main Page

2013-04-22T22:40:22Z

NelsonM:

{{#hidens:}}

; Current Release Version of EMarket: ''EMarket 5.3.0''

'''[[EMK:EMarket User Manual | EMarket User Manual]]'''

'''[[EMK:EMarket 5 Notes | EMarket 5 Release Commentary]]'''

'''[[EMK:EMarket Development | EMarket Development Path and Requests]]'''

Special:Badtitle/NS108:Main Page

2013-04-18T03:27:06Z

NelsonM:

{{#hidens:}}

; Current Release Version of EMarket: ''EMarket 5.2.7''

'''[[EMK:EMarket User Manual | EMarket User Manual]]'''

'''[[EMK:EMarket 5 Notes | EMarket 5 Release Commentary]]'''

'''[[EMK:EMarket Development | EMarket Development Path and Requests]]'''

Special:Badtitle/NS108:EMarket 5 Release Notes

2013-04-15T05:33:40Z

NelsonM:

{{#hidens:}}

;EMarket 5.2.4 -> 5.2.6
- Random outage modelling is now done on a half hourly basis
- Fixed a bug where water values were incorrectly calculated near the end of the run
- Added Calc Extra Water Value Weeks to the run parameters, this allows water values to be calculated beyond the end of the run.

;EMarket 5.2.3 -> 5.2.4
- Fixed bug that put extra divisions in 3h Output Spec partition
- Version dimension partitons in the OS. Useful if there are more than one variable in the volatility matrix. partitions by a single variable in the volatility matrix Syntax: "Version(<dimension name>):All" e.g. "Version(InflowYear):All"

;EMarket 5.2.2 -> 5.2.3
- Improved eaccuracy of demand monthly input process
- Fixed bug that lost the EMarket version entry in the log file
- Saved Run Resource is now named <RunName>_Resource.txt

;EMarket 5.2.1 -> 5.2.2
- Output spec functions First() and Last() have been added

;EMarket 5.1.4 -> 5.2.1
- The table for creating profiled offers has been changed in the generator offer screen. The table now has the option to profile by month, options for division by weekday and options for division by the time of day
- 1h 2h 3h, 8h, DN and DN6 schedule functions have been added
- The OutputSpec has some more partition options: 1h 2h 3h 6h and 8h, which divide by the time of day
- The Help menu item now opens the EMarket help wiki.
- Made directory creation more robust against race conditions (more than one EMarket trying to create a directory). This avoids sporadic errors when running more than one copy of EMarket at a time.

;EMarket 5.1.2 -> 5.1.4

- Added 1h, 2h and 3h time steps model run

;EMarket 5.0.9 -> 5.1.2

- Added Line.Excess and Line.Losses built in traits
- Fixed generator revenue for generators with distributed offers
- Added the use run results offers feature - requires '-RO(<run name>)' in the run description
- Water value grid simplification can deal with 4 or more character node names. There must still be only one HVDC attached to a nodes with names starting with 'BEN' and 'HAY'
- Adjusted the months required by the demand input settings, so that it needs to cover the period over which water values are calculated
- Fixed bugs caused calculating run end dates and water value periods

;EMarket 4.3.1 -> 5.0.7

-OutputSpecs can now create multiple files. A File partition set has been added and a file is created for each resulting partition.
-Output Spec 'Year' partition has been added, this divides the OS report into each year the forecast covers
-Output Spec 'MonthOfYear' partition has been added, this divides the OS report in 12, one division for each month of the year ( as opposed to the 'Month' partition which creates one for every month in the forecast)
-The headers for each File partition can be added to either the row or column headers

- The number of decimal places to be written to output spec reports can now be specified by adding a :<n> suffix in the function specification. E.g. Function: Tot(Generator.Generation):1
- Monthly Demand Input added, this feature facilitates the specification of regional demand by month by allowing expected average demand rates to be entered either as average demand for weekday or other day or a single value representing average demand for a 5 week day / 2 other day week. The monthly demand input requires the entry of demand rates for all regions and all months covering the duration of the run and the twenty four months following the run. The extra twenty four months of demand is required so that water value modelling can be done.
- MonthDiff schedule function added.
- Fixed bug with LastVal not picking up zero values
- Added a checks for badly assigned reserve regions, avoids accidental assignment of nodes to the wrong island (which impacts water value calculation).
- Added command line running functionality, including the ability to start runs on opening and execute specified volatility values
- Fixed bug with reading grid resource where nodes were wrongly assigned to lines when they were out of alphabetical order
- Grid Versions enabled
- Multi-Year Water Values implemented
- New output database, split by version
- WVs only feature, and Wait for WVs feature

[[EMK:Release Notes|Back]]

Special:Badtitle/NS108:EMarket 5 Release Notes

2013-04-15T05:33:28Z

NelsonM:

Special:Badtitle/NS108:EMarket 5 Release Notes

2013-04-15T05:32:35Z

NelsonM:

{{#hidens:}}

;EMarket 5.2.4 -> 5.2.6
- Random outage modelling is now done on a half hourly basis
- Fixed a bug where water values were incorrectly calculated near the end of the run
- Added Calc Extra Water Value Weeks to the run parameters, this allows water values to be
calculated beyond the end of the run.

;EMarket 5.2.3 -> 5.2.4
- Fixed bug that put extra divisions in 3h Output Spec partition
- Version dimension partitons in the OS. Useful if there are more than one variable in the volatility matrix.
partitions by a single variable in the volatility matrix
Syntax: "Version(<dimension name>):All" e.g. "Version(InflowYear):All"

;EMarket 5.2.2 -> 5.2.3
- Improved eaccuracy of demand monthly input process
- Fixed bug that lost the EMarket version entry in the log file
- Saved Run Resource is now named <RunName>_Resource.txt

;EMarket 5.2.1 -> 5.2.2
- Output spec functions First() and Last() have been added

;EMarket 5.1.4 -> 5.2.1
- The table for creating profiled offers has been changed in the generator offer screen. The table now has the option to profile by month, options for division by weekday and options for division by the time of day
- 1h 2h 3h, 8h, DN and DN6 schedule functions have been added
- The OutputSpec has some more partition options: 1h 2h 3h 6h and 8h, which divide by the time of day
- The Help menu item now opens the EMarket help wiki.
- Made directory creation more robust against race conditions (more than one EMarket trying to create a directory). This avoids sporadic errors when running more than one copy of EMarket at a time.

;EMarket 5.1.2 -> 5.1.4

- Added 1h, 2h and 3h time steps model run

;EMarket 5.0.9 -> 5.1.2

- Added Line.Excess and Line.Losses built in traits
- Fixed generator revenue for generators with distributed offers
- Added the use run results offers feature - requires '-RO(<run name>)' in the run description
- Water value grid simplification can deal with 4 or more character node names. There must still be only one HVDC attached to a nodes with names starting with 'BEN' and 'HAY'
- Adjusted the months required by the demand input settings, so that it needs to cover the period over which water values are calculated
- Fixed bugs caused calculating run end dates and water value periods

;EMarket 4.3.1 -> 5.0.7

-OutputSpecs can now create multiple files. A File partition set has been added and a file is created for each resulting partition.
-Output Spec 'Year' partition has been added, this divides the OS report into each year the forecast covers
-Output Spec 'MonthOfYear' partition has been added, this divides the OS report in 12, one division for each month of the year ( as opposed to the 'Month' partition which creates one for every month in the forecast)
-The headers for each File partition can be added to either the row or column headers

- The number of decimal places to be written to output spec reports can now be specified by adding a :<n> suffix in the function specification. E.g. Function: Tot(Generator.Generation):1
- Monthly Demand Input added, this feature facilitates the specification of regional demand by month by allowing expected average demand rates to be entered either as average demand for weekday or other day or a single value representing average demand for a 5 week day / 2 other day week. The monthly demand input requires the entry of demand rates for all regions and all months covering the duration of the run and the twenty four months following the run. The extra twenty four months of demand is required so that water value modelling can be done.
- MonthDiff schedule function added.
- Fixed bug with LastVal not picking up zero values
- Added a checks for badly assigned reserve regions, avoids accidental assignment of nodes to the wrong island (which impacts water value calculation).
- Added command line running functionality, including the ability to start runs on opening and execute specified volatility values
- Fixed bug with reading grid resource where nodes were wrongly assigned to lines when they were out of alphabetical order
- Grid Versions enabled
- Multi-Year Water Values implemented
- New output database, split by version
- WVs only feature, and Wait for WVs feature

[[EMK:Release Notes|Back]]

Special:Badtitle/NS108:Main Page

2013-04-15T05:30:34Z

NelsonM:

{{#hidens:}}

; Current Release Version of EMarket: ''EMarket 5.2.6''

'''[[EMK:EMarket User Manual | EMarket User Manual]]'''

'''[[EMK:EMarket 5 Notes | EMarket 5 Release Commentary]]'''

'''[[EMK:EMarket Development | EMarket Development Path and Requests]]'''

Special:Badtitle/NS108:Main Page

2013-04-02T05:04:52Z

NelsonM:

{{#hidens:}}

; Current Release Version of EMarket: ''EMarket 5.2.3''

'''[[EMK:EMarket User Manual | EMarket User Manual]]'''

'''[[EMK:EMarket 5 Notes | EMarket 5 Release Commentary]]'''

'''[[EMK:EMarket Development | EMarket Development Path and Requests]]'''

Special:Badtitle/NS108:EMarket 5 Notes

2013-03-21T21:13:20Z

NelsonM: /* Additional Output Spec features */

{{#hidens:}}
;EMarket 5 - Details Release Notes/Commentary

==Major Enhancements==
*Multi-year water values
*Updated grid allowing versioning of lines and 4+ digit node names
*Demand input table
*Additional report spec outputs
*Command line running
*Additional Tick sizes (1,2,3 and 6 hours)
*Updated Profiled Generator entry allow for the new tick sizes
*Help information is now accessed through an EMarket Wiki

===Multi-year water values===
With the introduction of EMK 5, multi-year runs can now be set up from one run resource and the water values are calculated over the entire forecast period in one go.

Multi-year water values are more accurate because they anticipate changes in one year that occur in the next year. The new water values have also moved away from the approach of averaging non-hydro offers over the year, which means that water values respond more to changes within years.

In creating multi-year water values, other major changes have been made in how the model interpreted the model data. The model now samples offers (generation) as an average of weekly data rather than annual average as used in EM4. This allows the future impact of significant events (large new generation or decommission) to be reflected in the water values as increasing over a period of time before the event. In EM4 this effect depended on when during the year it occurred, either creating a step change or average over a whole year.

However to have meaning at the end of the water value period, we are now required to provide additional generation and demand outside of the forecast period. At present this is 24 months but we are still investigating whether this should be longer/shorter. Any feedback on this would be welcome.

We can also expect changes at the traditional interface between years modelled with EM5. EM4 required that the water values were effectively circular (i.e. because the model could start at any date, the water values from March to April had to be the same). This is obviously no longer the case.

The length of the run defines the length of the multi-year water value. As mentioned above, the additional offers and demand need to be incorporated into the run data.

The Water Value Viewer has been updated to cover all the data.

[[File:EM5 4 Example.JPG|600px|thumb|left|EM4 EM5 comparison]]

Our testing and analysis of the multi-year water values showed that on an annual average basis there is almost no difference between EM4 and EM5 average prices. However on a monthly basis we experienced a lower winter price, but a higher spring/early summer price. This is a direct result of the weekly generation sampling of EM5 (rather than annual average of EM4). The model now takes into account the higher availability of plant during winter, as well as (within this particular forecast) the lower availability in the spring and early summer.

===Grid updates===
We now have the ability of ‘version’ lines. Rather than having a series of grids to represent each year, we now have one but it can have multiple copies of the same line (versioned). This allows us to upgrade a line (including resistance and reactance) by just switching version on the fly. Where lines have been aggregated, we could of example have a single line version that could simulate a line outage.

Timeseries schedule elements are required to activate the lines version; The default lines version is zero.
Line:CYD2_ROX2.Version = Timeseries(0, '1/4/2015', 1)

Although this feature has always been available, we have further enhanced our ability to use multiple character nodes within the grid. This allows for separate modelling of the 220, 110 and 66 KV part of the grid as well as interconnecting transformers.

As part of the grid upgrade we discovered a ‘special’ Windows feature where a hidden copy of the map was being read rather than the copy in the program files directory. If you can’t correctly read the map data when you have overwrite the one in the ‘program files’ directory, please call us and we will try and help by finding the culprit.

===Demand input table===
This a request from users to create a easier way of entering monthly demand (especially now that the demand could be for multiple years).

Users now have the ability to input demand via the Monthly Demand Input table, which facilitates the specification of regional demand by month over an entire multi-year forecast.

Expected average demand rates can be entered either as average demand for week day or other day, or a single value representing average demand for a 5 week day / 2 other day week.

This input method is started using the demand button below the demand window in the main run window. Using the top table, demand can be entered either by ‘Total GWh/week’, or ‘MW average for Week Day’, or ‘MW average for OtherDay’.

Emarket calculates the other values and produces the monthly GWh totals (for checking purposes) in a table below. Once correct, click the Set Demand formulae button to write out the demand data into the run window.

A couple of thing to note;
*Emarket doesn’t save the original data, just the formulae;
*The calculations when entering a lot of month can be very slow, this is due to the time needed to generate the profiles for all months;
*The entry types are all in the top window (you may have scroll down) and are defined by various colours;
*The regions are how they are defined in the demand regions (as per EM4).
*Twenty four months of additional demand data is required the multi-ear water values.
*EMarket will calculate this formulas directly upon opening if the resource file contains the forecast data

If you don’t want to determine specific monthly values, demand can be entered as an annual time series or via a variable and the schedule. Examples are given in the resources file.

===Additional Output Spec features===
The use of a single run for outputs has the potential to result in some very large output files. To help with this we have created an extra ‘Partition’ in the OutputSpec call File. This allows an output spec to divide data up into small chunks. For example if Node is used in the File partition, then each node would be a separate output.

The output files can also be divided into years using the year function. Note that this also requires a new function is the Column or Row partition called ‘MonthofYear’ so that the correct months are allocated.

*Reduced digits in .Csv files.
You can now add a filter that will reduce to the number is digits after a decimal point. The format is ":n" after the function description: i.e. Function.Ave(Node.Price):2 would limit the result to 2 decimal places

===Command Line Emarket===
This feature is designed to assist in the automation of running Emarket. It also allows the running of multiple copies of Emarket using the same resources file and demand profile.

The command switches at present are;
*-wd <working directory> , sets the working directory in which EMarket starts up
*-r <batch runs>, causes EMarket to run a batch, runs are comma delimited in the argument. Emarket will close when the batch is finished
*-wvo, runs the batch with the 'Water Values Only' option
*-wwv, runs the batch with the 'Wait for Water Values' option
*-vm <volatility matrix>, sets the volatility matrix fo the run and directs the results to a partial database which can be merged with other executions of the same run. e.g. -vm "InflowYear:1940-1950,1980"
*-rb <reports batch> <run> [<minimum number of run parts>], runs a reports batch on the named run. If the minimum number of run parts is specified then EMarket will wait until at least this number of run outputs are produced in the latest version of the run results. This option also ensures the current batch number is iterated by 1 value.
*-?, displays this help message

===Additional Tick Sizes===
Emarket now has 4 new tick sizes. 1, 2, 3 and 6 hour ticks. Corresponding output functions have been added to the OutputSpec for reporting purposes.

===Updated Profiled Generation Entry===
With the new Tick sizes, we have also updated the way 'Profiled Generation' can be entered.

The generation offer table 'Quantity Profile' now varies to offer the greater range of offers sizes.

The vertial axis now has the option of
*Month (tick box) - If ticked has a separate representation for each month
*Day of Week - Adds all 7 days to each month
*Week Other - Adds Week Day and Week Night to each month

The horizontal axis is by time periods ranging from
{|class="wikitable"
|-
| DN || DayNight ||| 2 values from 12am-8am, 8am-12am
|-
| DN6 || DayNight6 ||| 2 values from 12am-6am, 6am-12am
|-
| 6h || 6 hourly ||| 4 values from 12am-6am, 6am-12pm, 12pm-6pm, 6pm-12am
|-
| 4h || 4 hourly ||| 6 values from 12am-4am, 4am-8am, 8am-12pm, 12pm-4pm, 4pm-8pn, 4pm-12am
|-
| 3h || 3 hourly ||| 8 values from 12am-3am, 3am-6am etc.
|-
| 2h || 2 hourly ||| 12 values from12am-2am, 2am-4am etc
|-
| 1h || 1 hourly ||| 24 values from 12am-1am, 1am-2am etc.
|-
| hh || half hourly ||| 48 values from 12.00am-12.30am, 12.20am-1.00am etc.
|-
|}

== Help files point to Wiki==
The help files now open this Wiki rather than specific on computer help files. This wiki superceeds the previous Manual and help files.

[[EMK:Main Page | Back to EMK Main Page]]

Special:Badtitle/NS108:EMarket 5 Notes

2013-03-21T21:11:42Z

NelsonM: /* Additional Output Spec features */

{{#hidens:}}
;EMarket 5 - Details Release Notes/Commentary

==Major Enhancements==
*Multi-year water values
*Updated grid allowing versioning of lines and 4+ digit node names
*Demand input table
*Additional report spec outputs
*Command line running
*Additional Tick sizes (1,2,3 and 6 hours)
*Updated Profiled Generator entry allow for the new tick sizes
*Help information is now accessed through an EMarket Wiki

===Multi-year water values===
With the introduction of EMK 5, multi-year runs can now be set up from one run resource and the water values are calculated over the entire forecast period in one go.

Multi-year water values are more accurate because they anticipate changes in one year that occur in the next year. The new water values have also moved away from the approach of averaging non-hydro offers over the year, which means that water values respond more to changes within years.

In creating multi-year water values, other major changes have been made in how the model interpreted the model data. The model now samples offers (generation) as an average of weekly data rather than annual average as used in EM4. This allows the future impact of significant events (large new generation or decommission) to be reflected in the water values as increasing over a period of time before the event. In EM4 this effect depended on when during the year it occurred, either creating a step change or average over a whole year.

However to have meaning at the end of the water value period, we are now required to provide additional generation and demand outside of the forecast period. At present this is 24 months but we are still investigating whether this should be longer/shorter. Any feedback on this would be welcome.

We can also expect changes at the traditional interface between years modelled with EM5. EM4 required that the water values were effectively circular (i.e. because the model could start at any date, the water values from March to April had to be the same). This is obviously no longer the case.

The length of the run defines the length of the multi-year water value. As mentioned above, the additional offers and demand need to be incorporated into the run data.

The Water Value Viewer has been updated to cover all the data.

[[File:EM5 4 Example.JPG|600px|thumb|left|EM4 EM5 comparison]]

Our testing and analysis of the multi-year water values showed that on an annual average basis there is almost no difference between EM4 and EM5 average prices. However on a monthly basis we experienced a lower winter price, but a higher spring/early summer price. This is a direct result of the weekly generation sampling of EM5 (rather than annual average of EM4). The model now takes into account the higher availability of plant during winter, as well as (within this particular forecast) the lower availability in the spring and early summer.

===Grid updates===
We now have the ability of ‘version’ lines. Rather than having a series of grids to represent each year, we now have one but it can have multiple copies of the same line (versioned). This allows us to upgrade a line (including resistance and reactance) by just switching version on the fly. Where lines have been aggregated, we could of example have a single line version that could simulate a line outage.

Timeseries schedule elements are required to activate the lines version; The default lines version is zero.
Line:CYD2_ROX2.Version = Timeseries(0, '1/4/2015', 1)

Although this feature has always been available, we have further enhanced our ability to use multiple character nodes within the grid. This allows for separate modelling of the 220, 110 and 66 KV part of the grid as well as interconnecting transformers.

As part of the grid upgrade we discovered a ‘special’ Windows feature where a hidden copy of the map was being read rather than the copy in the program files directory. If you can’t correctly read the map data when you have overwrite the one in the ‘program files’ directory, please call us and we will try and help by finding the culprit.

===Demand input table===
This a request from users to create a easier way of entering monthly demand (especially now that the demand could be for multiple years).

Users now have the ability to input demand via the Monthly Demand Input table, which facilitates the specification of regional demand by month over an entire multi-year forecast.

Expected average demand rates can be entered either as average demand for week day or other day, or a single value representing average demand for a 5 week day / 2 other day week.

This input method is started using the demand button below the demand window in the main run window. Using the top table, demand can be entered either by ‘Total GWh/week’, or ‘MW average for Week Day’, or ‘MW average for OtherDay’.

Emarket calculates the other values and produces the monthly GWh totals (for checking purposes) in a table below. Once correct, click the Set Demand formulae button to write out the demand data into the run window.

A couple of thing to note;
*Emarket doesn’t save the original data, just the formulae;
*The calculations when entering a lot of month can be very slow, this is due to the time needed to generate the profiles for all months;
*The entry types are all in the top window (you may have scroll down) and are defined by various colours;
*The regions are how they are defined in the demand regions (as per EM4).
*Twenty four months of additional demand data is required the multi-ear water values.
*EMarket will calculate this formulas directly upon opening if the resource file contains the forecast data

If you don’t want to determine specific monthly values, demand can be entered as an annual time series or via a variable and the schedule. Examples are given in the resources file.

===Additional Output Spec features===
The use of a single run for outputs has the potential to result in some very large output files. To help with this we have created an extra ‘Partition’ in the OutputSpec call File. This allows an output spec to divide data up into small chunks. For example if Node is used in the File partition, then each node would be a separate output.

The output files can also be divided into years using the year function. Note that this also requires a new function is the Column or Row partition called ‘MonthofYear’ so that the correct months are allocated.

*Reduced digits in .Csv files.
You can now add a filter that will reduce to the number is digits after a decimal point. The format is ":n" after the function description

===Command Line Emarket===
This feature is designed to assist in the automation of running Emarket. It also allows the running of multiple copies of Emarket using the same resources file and demand profile.

The command switches at present are;
*-wd <working directory> , sets the working directory in which EMarket starts up
*-r <batch runs>, causes EMarket to run a batch, runs are comma delimited in the argument. Emarket will close when the batch is finished
*-wvo, runs the batch with the 'Water Values Only' option
*-wwv, runs the batch with the 'Wait for Water Values' option
*-vm <volatility matrix>, sets the volatility matrix fo the run and directs the results to a partial database which can be merged with other executions of the same run. e.g. -vm "InflowYear:1940-1950,1980"
*-rb <reports batch> <run> [<minimum number of run parts>], runs a reports batch on the named run. If the minimum number of run parts is specified then EMarket will wait until at least this number of run outputs are produced in the latest version of the run results. This option also ensures the current batch number is iterated by 1 value.
*-?, displays this help message

===Additional Tick Sizes===
Emarket now has 4 new tick sizes. 1, 2, 3 and 6 hour ticks. Corresponding output functions have been added to the OutputSpec for reporting purposes.

===Updated Profiled Generation Entry===
With the new Tick sizes, we have also updated the way 'Profiled Generation' can be entered.

The generation offer table 'Quantity Profile' now varies to offer the greater range of offers sizes.

The vertial axis now has the option of
*Month (tick box) - If ticked has a separate representation for each month
*Day of Week - Adds all 7 days to each month
*Week Other - Adds Week Day and Week Night to each month

The horizontal axis is by time periods ranging from
{|class="wikitable"
|-
| DN || DayNight ||| 2 values from 12am-8am, 8am-12am
|-
| DN6 || DayNight6 ||| 2 values from 12am-6am, 6am-12am
|-
| 6h || 6 hourly ||| 4 values from 12am-6am, 6am-12pm, 12pm-6pm, 6pm-12am
|-
| 4h || 4 hourly ||| 6 values from 12am-4am, 4am-8am, 8am-12pm, 12pm-4pm, 4pm-8pn, 4pm-12am
|-
| 3h || 3 hourly ||| 8 values from 12am-3am, 3am-6am etc.
|-
| 2h || 2 hourly ||| 12 values from12am-2am, 2am-4am etc
|-
| 1h || 1 hourly ||| 24 values from 12am-1am, 1am-2am etc.
|-
| hh || half hourly ||| 48 values from 12.00am-12.30am, 12.20am-1.00am etc.
|-
|}

== Help files point to Wiki==
The help files now open this Wiki rather than specific on computer help files. This wiki superceeds the previous Manual and help files.

[[EMK:Main Page | Back to EMK Main Page]]

Special:Badtitle/NS108:EMarket 5 Notes

2013-03-21T21:11:11Z

NelsonM: /* Additional Output Spec features */

{{#hidens:}}
;EMarket 5 - Details Release Notes/Commentary

==Major Enhancements==
*Multi-year water values
*Updated grid allowing versioning of lines and 4+ digit node names
*Demand input table
*Additional report spec outputs
*Command line running
*Additional Tick sizes (1,2,3 and 6 hours)
*Updated Profiled Generator entry allow for the new tick sizes
*Help information is now accessed through an EMarket Wiki

===Multi-year water values===
With the introduction of EMK 5, multi-year runs can now be set up from one run resource and the water values are calculated over the entire forecast period in one go.

Multi-year water values are more accurate because they anticipate changes in one year that occur in the next year. The new water values have also moved away from the approach of averaging non-hydro offers over the year, which means that water values respond more to changes within years.

In creating multi-year water values, other major changes have been made in how the model interpreted the model data. The model now samples offers (generation) as an average of weekly data rather than annual average as used in EM4. This allows the future impact of significant events (large new generation or decommission) to be reflected in the water values as increasing over a period of time before the event. In EM4 this effect depended on when during the year it occurred, either creating a step change or average over a whole year.

However to have meaning at the end of the water value period, we are now required to provide additional generation and demand outside of the forecast period. At present this is 24 months but we are still investigating whether this should be longer/shorter. Any feedback on this would be welcome.

We can also expect changes at the traditional interface between years modelled with EM5. EM4 required that the water values were effectively circular (i.e. because the model could start at any date, the water values from March to April had to be the same). This is obviously no longer the case.

The length of the run defines the length of the multi-year water value. As mentioned above, the additional offers and demand need to be incorporated into the run data.

The Water Value Viewer has been updated to cover all the data.

[[File:EM5 4 Example.JPG|600px|thumb|left|EM4 EM5 comparison]]

Our testing and analysis of the multi-year water values showed that on an annual average basis there is almost no difference between EM4 and EM5 average prices. However on a monthly basis we experienced a lower winter price, but a higher spring/early summer price. This is a direct result of the weekly generation sampling of EM5 (rather than annual average of EM4). The model now takes into account the higher availability of plant during winter, as well as (within this particular forecast) the lower availability in the spring and early summer.

===Grid updates===
We now have the ability of ‘version’ lines. Rather than having a series of grids to represent each year, we now have one but it can have multiple copies of the same line (versioned). This allows us to upgrade a line (including resistance and reactance) by just switching version on the fly. Where lines have been aggregated, we could of example have a single line version that could simulate a line outage.

Timeseries schedule elements are required to activate the lines version; The default lines version is zero.
Line:CYD2_ROX2.Version = Timeseries(0, '1/4/2015', 1)

Although this feature has always been available, we have further enhanced our ability to use multiple character nodes within the grid. This allows for separate modelling of the 220, 110 and 66 KV part of the grid as well as interconnecting transformers.

As part of the grid upgrade we discovered a ‘special’ Windows feature where a hidden copy of the map was being read rather than the copy in the program files directory. If you can’t correctly read the map data when you have overwrite the one in the ‘program files’ directory, please call us and we will try and help by finding the culprit.

===Demand input table===
This a request from users to create a easier way of entering monthly demand (especially now that the demand could be for multiple years).

Users now have the ability to input demand via the Monthly Demand Input table, which facilitates the specification of regional demand by month over an entire multi-year forecast.

Expected average demand rates can be entered either as average demand for week day or other day, or a single value representing average demand for a 5 week day / 2 other day week.

This input method is started using the demand button below the demand window in the main run window. Using the top table, demand can be entered either by ‘Total GWh/week’, or ‘MW average for Week Day’, or ‘MW average for OtherDay’.

Emarket calculates the other values and produces the monthly GWh totals (for checking purposes) in a table below. Once correct, click the Set Demand formulae button to write out the demand data into the run window.

A couple of thing to note;
*Emarket doesn’t save the original data, just the formulae;
*The calculations when entering a lot of month can be very slow, this is due to the time needed to generate the profiles for all months;
*The entry types are all in the top window (you may have scroll down) and are defined by various colours;
*The regions are how they are defined in the demand regions (as per EM4).
*Twenty four months of additional demand data is required the multi-ear water values.
*EMarket will calculate this formulas directly upon opening if the resource file contains the forecast data

If you don’t want to determine specific monthly values, demand can be entered as an annual time series or via a variable and the schedule. Examples are given in the resources file.

===Additional Output Spec features===
The use of a single run for outputs has the potential to result in some very large output files. To help with this we have created an extra ‘Partition’ in the OutputSpec call File. This allows an output spec to divide data up into small chunks. For example if Node is used in the File partition, then each node would be a separate output.

The output files can also be divided into years using the year function. Note that this also requires a new function is the Column or Row partition called ‘MonthofYear’ so that the correct months are allocated.

Reduced digits in .Csv files.
You can now add a filter that will reduce to the number is digits after a decimal point. The format is ":n" after the function description

===Command Line Emarket===
This feature is designed to assist in the automation of running Emarket. It also allows the running of multiple copies of Emarket using the same resources file and demand profile.

The command switches at present are;
*-wd <working directory> , sets the working directory in which EMarket starts up
*-r <batch runs>, causes EMarket to run a batch, runs are comma delimited in the argument. Emarket will close when the batch is finished
*-wvo, runs the batch with the 'Water Values Only' option
*-wwv, runs the batch with the 'Wait for Water Values' option
*-vm <volatility matrix>, sets the volatility matrix fo the run and directs the results to a partial database which can be merged with other executions of the same run. e.g. -vm "InflowYear:1940-1950,1980"
*-rb <reports batch> <run> [<minimum number of run parts>], runs a reports batch on the named run. If the minimum number of run parts is specified then EMarket will wait until at least this number of run outputs are produced in the latest version of the run results. This option also ensures the current batch number is iterated by 1 value.
*-?, displays this help message

===Additional Tick Sizes===
Emarket now has 4 new tick sizes. 1, 2, 3 and 6 hour ticks. Corresponding output functions have been added to the OutputSpec for reporting purposes.

===Updated Profiled Generation Entry===
With the new Tick sizes, we have also updated the way 'Profiled Generation' can be entered.

The generation offer table 'Quantity Profile' now varies to offer the greater range of offers sizes.

The vertial axis now has the option of
*Month (tick box) - If ticked has a separate representation for each month
*Day of Week - Adds all 7 days to each month
*Week Other - Adds Week Day and Week Night to each month

The horizontal axis is by time periods ranging from
{|class="wikitable"
|-
| DN || DayNight ||| 2 values from 12am-8am, 8am-12am
|-
| DN6 || DayNight6 ||| 2 values from 12am-6am, 6am-12am
|-
| 6h || 6 hourly ||| 4 values from 12am-6am, 6am-12pm, 12pm-6pm, 6pm-12am
|-
| 4h || 4 hourly ||| 6 values from 12am-4am, 4am-8am, 8am-12pm, 12pm-4pm, 4pm-8pn, 4pm-12am
|-
| 3h || 3 hourly ||| 8 values from 12am-3am, 3am-6am etc.
|-
| 2h || 2 hourly ||| 12 values from12am-2am, 2am-4am etc
|-
| 1h || 1 hourly ||| 24 values from 12am-1am, 1am-2am etc.
|-
| hh || half hourly ||| 48 values from 12.00am-12.30am, 12.20am-1.00am etc.
|-
|}

== Help files point to Wiki==
The help files now open this Wiki rather than specific on computer help files. This wiki superceeds the previous Manual and help files.

[[EMK:Main Page | Back to EMK Main Page]]

Special:Badtitle/NS108:CreatingForecasts

2013-03-08T02:08:55Z

NelsonM:

[[EMK:Main Window | Main Window]]

[[EMK:Resources | Resources]] - Summary of the Resources and how to use them

[[EMK:Run Window | The EMarket Run]] - Where everything connects together

----

'''Additional Resource Data'''

[[EMK:Connections | Connections]] - Creating the physical Market

[[EMK:Schedules | Schedule]] - EMarket Scripts

[[EMK:Generators |Generator]] - Generator details: - Hydro Systems, hydros, thermal and profiled generatots

[[EMK:Companies | Company]] - Companies, Retail Load, Hedging and Company Optimisation

[[EMK:Regions | Regions]] - Demand Regions

[[EMK:Grid | Grid]] - Grid definitions:- lines, nodes and equation constraints

[[EMK:Reserves | Reserves]] - Reserve Offers

[[EMK:Binary Output | Binary Output]] - Output database definitions

[[EMK:Reports | Reports]] - Lists for creating data outputs

[[EMK:Output Specs | Output Specification]] - How the output data is described

[[EMK:Formulae and Functions | Formulae and Functions]] - Schedule and OutputSpec functions

[[EMK:Getting the Best out of EMarket | Getting the Best out of EMarket]]

[[EMK:EMarket_User_Manual | Return to User Manual]]

Special:Badtitle/NS108:EMarket User Manual

2013-03-08T02:08:25Z

NelsonM:

{{#hidens:}}

'''EMarket Wiki'''

This Wiki is for EMarket up to version 5.

----

[[EMK:Using the Manual|Using the Manual]]

[[EMK:Getting Started | Getting Started]] - Installation and System requirements

[[EMK:Concepts | EMarket Concepts]] - The Concepts behind EMarket and EMarket Modelling

[[EMK:CreatingForecasts | Creating Forecasts]] - All the parts to create an EMarket Model

[[EMK:UsingEmarket | Aditional EMarket Information]] - Commands, Glossary, Technical Bulletins and Help

[[EMK:ModellingData | External Modelling Data]] - Water Values, Demand profiles and file functions

[[EMK:Glossary | Glossary]]

[[EMK:Technical Bulletins | Technical Bulletins]]

[[EMK:Release Notes | Release Notes]]

[[EMK:Main Page | Back to EMK Main Page]]

Special:Badtitle/NS108:Main Page

2013-03-08T02:07:48Z

NelsonM:

{{#hidens:}}

; Current Release Version of EMarket: ''EMarket 5.2.1''

'''[[EMK:EMarket User Manual | EMarket User Manual]]'''

'''[[EMK:EMarket 5 Notes | EMarket 5 Release Commentary]]'''

'''[[EMK:EMarket Development | EMarket Development Path and Requests]]'''

Special:Badtitle/NS108:EMarket 5 Notes

2013-03-08T02:07:18Z

NelsonM: /* Multi-year water values */

{{#hidens:}}
;EMarket 5 - Details Release Notes/Commentary

==Major Enhancements==
*Multi-year water values
*Updated grid allowing versioning of lines and 4+ digit node names
*Demand input table
*Additional report spec outputs
*Command line running
*Additional Tick sizes (1,2,3 and 6 hours)
*Updated Profiled Generator entry allow for the new tick sizes
*Help information is now accessed through an EMarket Wiki

===Multi-year water values===
With the introduction of EMK 5, multi-year runs can now be set up from one run resource and the water values are calculated over the entire forecast period in one go.

Multi-year water values are more accurate because they anticipate changes in one year that occur in the next year. The new water values have also moved away from the approach of averaging non-hydro offers over the year, which means that water values respond more to changes within years.

In creating multi-year water values, other major changes have been made in how the model interpreted the model data. The model now samples offers (generation) as an average of weekly data rather than annual average as used in EM4. This allows the future impact of significant events (large new generation or decommission) to be reflected in the water values as increasing over a period of time before the event. In EM4 this effect depended on when during the year it occurred, either creating a step change or average over a whole year.

However to have meaning at the end of the water value period, we are now required to provide additional generation and demand outside of the forecast period. At present this is 24 months but we are still investigating whether this should be longer/shorter. Any feedback on this would be welcome.

We can also expect changes at the traditional interface between years modelled with EM5. EM4 required that the water values were effectively circular (i.e. because the model could start at any date, the water values from March to April had to be the same). This is obviously no longer the case.

The length of the run defines the length of the multi-year water value. As mentioned above, the additional offers and demand need to be incorporated into the run data.

The Water Value Viewer has been updated to cover all the data.

[[File:EM5 4 Example.JPG|600px|thumb|left|EM4 EM5 comparison]]

Our testing and analysis of the multi-year water values showed that on an annual average basis there is almost no difference between EM4 and EM5 average prices. However on a monthly basis we experienced a lower winter price, but a higher spring/early summer price. This is a direct result of the weekly generation sampling of EM5 (rather than annual average of EM4). The model now takes into account the higher availability of plant during winter, as well as (within this particular forecast) the lower availability in the spring and early summer.

===Grid updates===
We now have the ability of ‘version’ lines. Rather than having a series of grids to represent each year, we now have one but it can have multiple copies of the same line (versioned). This allows us to upgrade a line (including resistance and reactance) by just switching version on the fly. Where lines have been aggregated, we could of example have a single line version that could simulate a line outage.

Timeseries schedule elements are required to activate the lines version; The default lines version is zero.
Line:CYD2_ROX2.Version = Timeseries(0, '1/4/2015', 1)

Although this feature has always been available, we have further enhanced our ability to use multiple character nodes within the grid. This allows for separate modelling of the 220, 110 and 66 KV part of the grid as well as interconnecting transformers.

As part of the grid upgrade we discovered a ‘special’ Windows feature where a hidden copy of the map was being read rather than the copy in the program files directory. If you can’t correctly read the map data when you have overwrite the one in the ‘program files’ directory, please call us and we will try and help by finding the culprit.

===Demand input table===
This a request from users to create a easier way of entering monthly demand (especially now that the demand could be for multiple years).

Users now have the ability to input demand via the Monthly Demand Input table, which facilitates the specification of regional demand by month over an entire multi-year forecast.

Expected average demand rates can be entered either as average demand for week day or other day, or a single value representing average demand for a 5 week day / 2 other day week.

This input method is started using the demand button below the demand window in the main run window. Using the top table, demand can be entered either by ‘Total GWh/week’, or ‘MW average for Week Day’, or ‘MW average for OtherDay’.

Emarket calculates the other values and produces the monthly GWh totals (for checking purposes) in a table below. Once correct, click the Set Demand formulae button to write out the demand data into the run window.

A couple of thing to note;
*Emarket doesn’t save the original data, just the formulae;
*The calculations when entering a lot of month can be very slow, this is due to the time needed to generate the profiles for all months;
*The entry types are all in the top window (you may have scroll down) and are defined by various colours;
*The regions are how they are defined in the demand regions (as per EM4).
*Twenty four months of additional demand data is required the multi-ear water values.
*EMarket will calculate this formulas directly upon opening if the resource file contains the forecast data

If you don’t want to determine specific monthly values, demand can be entered as an annual time series or via a variable and the schedule. Examples are given in the resources file.

===Additional Output Spec features===
The use of a single run for outputs has the potential to result in some very large output files. To help with this we have created an extra ‘Partition’ in the OutputSpec call File. This allows an output spec to divide data up into small chunks. For example if Node is used in the File partition, then each node would be a separate output.

The output files can also be divided into years using the year function. Note that this also requires a new function is the Column or Row partition called ‘MonthofYear’ so that the correct months are allocated.

Examples are shown in the Resources files (‘Summary_byYear’ and’ Summary_byNode’)

===Command Line Emarket===
This feature is designed to assist in the automation of running Emarket. It also allows the running of multiple copies of Emarket using the same resources file and demand profile.

The command switches at present are;
*-wd <working directory> , sets the working directory in which EMarket starts up
*-r <batch runs>, causes EMarket to run a batch, runs are comma delimited in the argument. Emarket will close when the batch is finished
*-wvo, runs the batch with the 'Water Values Only' option
*-wwv, runs the batch with the 'Wait for Water Values' option
*-vm <volatility matrix>, sets the volatility matrix fo the run and directs the results to a partial database which can be merged with other executions of the same run. e.g. -vm "InflowYear:1940-1950,1980"
*-rb <reports batch> <run> [<minimum number of run parts>], runs a reports batch on the named run. If the minimum number of run parts is specified then EMarket will wait until at least this number of run outputs are produced in the latest version of the run results. This option also ensures the current batch number is iterated by 1 value.
*-?, displays this help message

===Additional Tick Sizes===
Emarket now has 4 new tick sizes. 1, 2, 3 and 6 hour ticks. Corresponding output functions have been added to the OutputSpec for reporting purposes.

===Updated Profiled Generation Entry===
With the new Tick sizes, we have also updated the way 'Profiled Generation' can be entered.

The generation offer table 'Quantity Profile' now varies to offer the greater range of offers sizes.

The vertial axis now has the option of
*Month (tick box) - If ticked has a separate representation for each month
*Day of Week - Adds all 7 days to each month
*Week Other - Adds Week Day and Week Night to each month

The horizontal axis is by time periods ranging from
{|class="wikitable"
|-
| DN || DayNight ||| 2 values from 12am-8am, 8am-12am
|-
| DN6 || DayNight6 ||| 2 values from 12am-6am, 6am-12am
|-
| 6h || 6 hourly ||| 4 values from 12am-6am, 6am-12pm, 12pm-6pm, 6pm-12am
|-
| 4h || 4 hourly ||| 6 values from 12am-4am, 4am-8am, 8am-12pm, 12pm-4pm, 4pm-8pn, 4pm-12am
|-
| 3h || 3 hourly ||| 8 values from 12am-3am, 3am-6am etc.
|-
| 2h || 2 hourly ||| 12 values from12am-2am, 2am-4am etc
|-
| 1h || 1 hourly ||| 24 values from 12am-1am, 1am-2am etc.
|-
| hh || half hourly ||| 48 values from 12.00am-12.30am, 12.20am-1.00am etc.
|-
|}

== Help files point to Wiki==
The help files now open this Wiki rather than specific on computer help files. This wiki superceeds the previous Manual and help files.

[[EMK:Main Page | Back to EMK Main Page]]

Special:Badtitle/NS108:EMarket 5 Notes

2013-03-08T02:06:10Z

NelsonM: /* Command Line Emarket */

{{#hidens:}}
;EMarket 5 - Details Release Notes/Commentary

==Major Enhancements==
*Multi-year water values
*Updated grid allowing versioning of lines and 4+ digit node names
*Demand input table
*Additional report spec outputs
*Command line running
*Additional Tick sizes (1,2,3 and 6 hours)
*Updated Profiled Generator entry allow for the new tick sizes
*Help information is now accessed through an EMarket Wiki

===Multi-year water values===
With the introduction of EMK 5, multi-year runs can now be set up from one run resource and the water values are calculated over the entire forecast period in one go.

Multi-year water values are more accurate because they anticipate changes in one year that occur in the next year. The new water values have also moved away from the approach of averaging non-hydro offers over the year, which means that water values respond more to changes within years.

In creating multi-year water values, other major changes have been made in how the model interpreted the model data. The model now samples offers (generation) as an average of weekly data rather than annual average as used in EM4. This allows the future impact of significant events (large new generation or decommission) to be reflected in the water values as increasing over a period of time before the event. In EM4 this effect depended on when during the year it occurred, either creating a step change or average over a whole year.

However to have meaning at the end of the water value period, we are now required to provide additional generation and demand outside of the forecast period. At present this is 24 months but we are still investigating whether this should be longer/shorter. Any feedback on this would be welcome.

We can also expect changes at the traditional interface between years modelled with EM5. EM4 required that the water values were effectively circular (i.e. because the model could start at any date, the water values from March to April had to be the same). This is obviously no longer the case.

The length of the run defines the length of the multi-year water value. As mentioned above, the additional offers and demand need to be incorporated into the run data.

[[File:EM5 4 Example.JPG|600px|thumb|left|EM4 EM5 comparison]]

Our testing and analysis of the multi-year water values showed that on an annual average basis there is almost no difference between EM4 and EM5 average prices. However on a monthly basis we experienced a lower winter price, but a higher spring/early summer price. This is a direct result of the weekly generation sampling of EM5 (rather than annual average of EM4). The model now takes into account the higher availability of plant during winter, as well as (within this particular forecast) the lower availability in the spring and early summer.

===Grid updates===
We now have the ability of ‘version’ lines. Rather than having a series of grids to represent each year, we now have one but it can have multiple copies of the same line (versioned). This allows us to upgrade a line (including resistance and reactance) by just switching version on the fly. Where lines have been aggregated, we could of example have a single line version that could simulate a line outage.

Timeseries schedule elements are required to activate the lines version; The default lines version is zero.
Line:CYD2_ROX2.Version = Timeseries(0, '1/4/2015', 1)

Although this feature has always been available, we have further enhanced our ability to use multiple character nodes within the grid. This allows for separate modelling of the 220, 110 and 66 KV part of the grid as well as interconnecting transformers.

As part of the grid upgrade we discovered a ‘special’ Windows feature where a hidden copy of the map was being read rather than the copy in the program files directory. If you can’t correctly read the map data when you have overwrite the one in the ‘program files’ directory, please call us and we will try and help by finding the culprit.

===Demand input table===
This a request from users to create a easier way of entering monthly demand (especially now that the demand could be for multiple years).

Users now have the ability to input demand via the Monthly Demand Input table, which facilitates the specification of regional demand by month over an entire multi-year forecast.

Expected average demand rates can be entered either as average demand for week day or other day, or a single value representing average demand for a 5 week day / 2 other day week.

This input method is started using the demand button below the demand window in the main run window. Using the top table, demand can be entered either by ‘Total GWh/week’, or ‘MW average for Week Day’, or ‘MW average for OtherDay’.

Emarket calculates the other values and produces the monthly GWh totals (for checking purposes) in a table below. Once correct, click the Set Demand formulae button to write out the demand data into the run window.

A couple of thing to note;
*Emarket doesn’t save the original data, just the formulae;
*The calculations when entering a lot of month can be very slow, this is due to the time needed to generate the profiles for all months;
*The entry types are all in the top window (you may have scroll down) and are defined by various colours;
*The regions are how they are defined in the demand regions (as per EM4).
*Twenty four months of additional demand data is required the multi-ear water values.
*EMarket will calculate this formulas directly upon opening if the resource file contains the forecast data

If you don’t want to determine specific monthly values, demand can be entered as an annual time series or via a variable and the schedule. Examples are given in the resources file.

===Additional Output Spec features===
The use of a single run for outputs has the potential to result in some very large output files. To help with this we have created an extra ‘Partition’ in the OutputSpec call File. This allows an output spec to divide data up into small chunks. For example if Node is used in the File partition, then each node would be a separate output.

The output files can also be divided into years using the year function. Note that this also requires a new function is the Column or Row partition called ‘MonthofYear’ so that the correct months are allocated.

Examples are shown in the Resources files (‘Summary_byYear’ and’ Summary_byNode’)

===Command Line Emarket===
This feature is designed to assist in the automation of running Emarket. It also allows the running of multiple copies of Emarket using the same resources file and demand profile.

The command switches at present are;
*-wd <working directory> , sets the working directory in which EMarket starts up
*-r <batch runs>, causes EMarket to run a batch, runs are comma delimited in the argument. Emarket will close when the batch is finished
*-wvo, runs the batch with the 'Water Values Only' option
*-wwv, runs the batch with the 'Wait for Water Values' option
*-vm <volatility matrix>, sets the volatility matrix fo the run and directs the results to a partial database which can be merged with other executions of the same run. e.g. -vm "InflowYear:1940-1950,1980"
*-rb <reports batch> <run> [<minimum number of run parts>], runs a reports batch on the named run. If the minimum number of run parts is specified then EMarket will wait until at least this number of run outputs are produced in the latest version of the run results. This option also ensures the current batch number is iterated by 1 value.
*-?, displays this help message

===Additional Tick Sizes===
Emarket now has 4 new tick sizes. 1, 2, 3 and 6 hour ticks. Corresponding output functions have been added to the OutputSpec for reporting purposes.

===Updated Profiled Generation Entry===
With the new Tick sizes, we have also updated the way 'Profiled Generation' can be entered.

The generation offer table 'Quantity Profile' now varies to offer the greater range of offers sizes.

The vertial axis now has the option of
*Month (tick box) - If ticked has a separate representation for each month
*Day of Week - Adds all 7 days to each month
*Week Other - Adds Week Day and Week Night to each month

The horizontal axis is by time periods ranging from
{|class="wikitable"
|-
| DN || DayNight ||| 2 values from 12am-8am, 8am-12am
|-
| DN6 || DayNight6 ||| 2 values from 12am-6am, 6am-12am
|-
| 6h || 6 hourly ||| 4 values from 12am-6am, 6am-12pm, 12pm-6pm, 6pm-12am
|-
| 4h || 4 hourly ||| 6 values from 12am-4am, 4am-8am, 8am-12pm, 12pm-4pm, 4pm-8pn, 4pm-12am
|-
| 3h || 3 hourly ||| 8 values from 12am-3am, 3am-6am etc.
|-
| 2h || 2 hourly ||| 12 values from12am-2am, 2am-4am etc
|-
| 1h || 1 hourly ||| 24 values from 12am-1am, 1am-2am etc.
|-
| hh || half hourly ||| 48 values from 12.00am-12.30am, 12.20am-1.00am etc.
|-
|}

== Help files point to Wiki==
The help files now open this Wiki rather than specific on computer help files. This wiki superceeds the previous Manual and help files.

[[EMK:Main Page | Back to EMK Main Page]]

Special:Badtitle/NS108:EMarket 5 Notes

2013-03-08T02:04:27Z

NelsonM: /* Grid updates */

{{#hidens:}}
;EMarket 5 - Details Release Notes/Commentary

==Major Enhancements==
*Multi-year water values
*Updated grid allowing versioning of lines and 4+ digit node names
*Demand input table
*Additional report spec outputs
*Command line running
*Additional Tick sizes (1,2,3 and 6 hours)
*Updated Profiled Generator entry allow for the new tick sizes
*Help information is now accessed through an EMarket Wiki

===Multi-year water values===
With the introduction of EMK 5, multi-year runs can now be set up from one run resource and the water values are calculated over the entire forecast period in one go.

Multi-year water values are more accurate because they anticipate changes in one year that occur in the next year. The new water values have also moved away from the approach of averaging non-hydro offers over the year, which means that water values respond more to changes within years.

In creating multi-year water values, other major changes have been made in how the model interpreted the model data. The model now samples offers (generation) as an average of weekly data rather than annual average as used in EM4. This allows the future impact of significant events (large new generation or decommission) to be reflected in the water values as increasing over a period of time before the event. In EM4 this effect depended on when during the year it occurred, either creating a step change or average over a whole year.

However to have meaning at the end of the water value period, we are now required to provide additional generation and demand outside of the forecast period. At present this is 24 months but we are still investigating whether this should be longer/shorter. Any feedback on this would be welcome.

We can also expect changes at the traditional interface between years modelled with EM5. EM4 required that the water values were effectively circular (i.e. because the model could start at any date, the water values from March to April had to be the same). This is obviously no longer the case.

The length of the run defines the length of the multi-year water value. As mentioned above, the additional offers and demand need to be incorporated into the run data.

[[File:EM5 4 Example.JPG|600px|thumb|left|EM4 EM5 comparison]]

Our testing and analysis of the multi-year water values showed that on an annual average basis there is almost no difference between EM4 and EM5 average prices. However on a monthly basis we experienced a lower winter price, but a higher spring/early summer price. This is a direct result of the weekly generation sampling of EM5 (rather than annual average of EM4). The model now takes into account the higher availability of plant during winter, as well as (within this particular forecast) the lower availability in the spring and early summer.

===Grid updates===
We now have the ability of ‘version’ lines. Rather than having a series of grids to represent each year, we now have one but it can have multiple copies of the same line (versioned). This allows us to upgrade a line (including resistance and reactance) by just switching version on the fly. Where lines have been aggregated, we could of example have a single line version that could simulate a line outage.

Timeseries schedule elements are required to activate the lines version; The default lines version is zero.
Line:CYD2_ROX2.Version = Timeseries(0, '1/4/2015', 1)

Although this feature has always been available, we have further enhanced our ability to use multiple character nodes within the grid. This allows for separate modelling of the 220, 110 and 66 KV part of the grid as well as interconnecting transformers.

As part of the grid upgrade we discovered a ‘special’ Windows feature where a hidden copy of the map was being read rather than the copy in the program files directory. If you can’t correctly read the map data when you have overwrite the one in the ‘program files’ directory, please call us and we will try and help by finding the culprit.

===Demand input table===
This a request from users to create a easier way of entering monthly demand (especially now that the demand could be for multiple years).

Users now have the ability to input demand via the Monthly Demand Input table, which facilitates the specification of regional demand by month over an entire multi-year forecast.

Expected average demand rates can be entered either as average demand for week day or other day, or a single value representing average demand for a 5 week day / 2 other day week.

This input method is started using the demand button below the demand window in the main run window. Using the top table, demand can be entered either by ‘Total GWh/week’, or ‘MW average for Week Day’, or ‘MW average for OtherDay’.

Emarket calculates the other values and produces the monthly GWh totals (for checking purposes) in a table below. Once correct, click the Set Demand formulae button to write out the demand data into the run window.

A couple of thing to note;
*Emarket doesn’t save the original data, just the formulae;
*The calculations when entering a lot of month can be very slow, this is due to the time needed to generate the profiles for all months;
*The entry types are all in the top window (you may have scroll down) and are defined by various colours;
*The regions are how they are defined in the demand regions (as per EM4).
*Twenty four months of additional demand data is required the multi-ear water values.
*EMarket will calculate this formulas directly upon opening if the resource file contains the forecast data

If you don’t want to determine specific monthly values, demand can be entered as an annual time series or via a variable and the schedule. Examples are given in the resources file.

===Additional Output Spec features===
The use of a single run for outputs has the potential to result in some very large output files. To help with this we have created an extra ‘Partition’ in the OutputSpec call File. This allows an output spec to divide data up into small chunks. For example if Node is used in the File partition, then each node would be a separate output.

The output files can also be divided into years using the year function. Note that this also requires a new function is the Column or Row partition called ‘MonthofYear’ so that the correct months are allocated.

Examples are shown in the Resources files (‘Summary_byYear’ and’ Summary_byNode’)

===Command Line Emarket===
This feature is designed to assist in the automation of running Emarket. It also allows the running of multiple copies of Emarket using the same resources file and demand profile.

The command switches at present are;
• -wd <working directory> , sets the working directory in which EMarket starts up
• -r <batch runs>, causes EMarket to run a batch, runs are comma delimited in the argument. Emarket will close when the batch is finished
• -wvo, runs the batch with the 'Water Values Only' option
• -wwv, runs the batch with the 'Wait for Water Values' option
• -vm <volatility matrix>, sets the volatility matrix fo the run and directs the results to a partial database which can be merged with other executions of the same run. e.g. -vm "InflowYear:1940-1950,1980"
• -rb <reports batch> <run> [<minimum number of run parts>], runs a reports batch on the named run. If the minimum number of run parts is specified then EMarket will wait until at least this number of run outputs are produced in the latest version of the run results. This option also ensures the current batch number is iterated by 1 value.
• -?, displays this help message

The report batch should be used in all cases as it iterates the next run number when the process is complete. If it is not used then Emarket will overwrite the last run number data.

We have attached and example batch file (.bat) that could be used to run command line Emarket.
The batch file will question some variable and show others that are assumed. You are free to edit it however you like, but if you come up with anything really clever variations we would be keen to see them.

Site specific things that need to be changed within the batch file are;
• Run directory (line 4)
• RunName (line 5)
• Reportsbatch (line 6)
• Directory of Emarket (line 13)
• Also the Emarket file name if it has been changes (Various lines)

===Additional Tick Sizes===
Emarket now has 4 new tick sizes. 1, 2, 3 and 6 hour ticks. Corresponding output functions have been added to the OutputSpec for reporting purposes.

===Updated Profiled Generation Entry===
With the new Tick sizes, we have also updated the way 'Profiled Generation' can be entered.

The generation offer table 'Quantity Profile' now varies to offer the greater range of offers sizes.

The vertial axis now has the option of
*Month (tick box) - If ticked has a separate representation for each month
*Day of Week - Adds all 7 days to each month
*Week Other - Adds Week Day and Week Night to each month

The horizontal axis is by time periods ranging from
{|class="wikitable"
|-
| DN || DayNight ||| 2 values from 12am-8am, 8am-12am
|-
| DN6 || DayNight6 ||| 2 values from 12am-6am, 6am-12am
|-
| 6h || 6 hourly ||| 4 values from 12am-6am, 6am-12pm, 12pm-6pm, 6pm-12am
|-
| 4h || 4 hourly ||| 6 values from 12am-4am, 4am-8am, 8am-12pm, 12pm-4pm, 4pm-8pn, 4pm-12am
|-
| 3h || 3 hourly ||| 8 values from 12am-3am, 3am-6am etc.
|-
| 2h || 2 hourly ||| 12 values from12am-2am, 2am-4am etc
|-
| 1h || 1 hourly ||| 24 values from 12am-1am, 1am-2am etc.
|-
| hh || half hourly ||| 48 values from 12.00am-12.30am, 12.20am-1.00am etc.
|-
|}

== Help files point to Wiki==
The help files now open this Wiki rather than specific on computer help files. This wiki superceeds the previous Manual and help files.

[[EMK:Main Page | Back to EMK Main Page]]

Special:Badtitle/NS108:EMarket 5 Notes

2013-03-08T01:52:54Z

NelsonM: /* Demand input table */

{{#hidens:}}
;EMarket 5 - Details Release Notes/Commentary

==Major Enhancements==
*Multi-year water values
*Updated grid allowing versioning of lines and 4+ digit node names
*Demand input table
*Additional report spec outputs
*Command line running
*Additional Tick sizes (1,2,3 and 6 hours)
*Updated Profiled Generator entry allow for the new tick sizes
*Help information is now accessed through an EMarket Wiki

===Multi-year water values===
With the introduction of EMK 5, multi-year runs can now be set up from one run resource and the water values are calculated over the entire forecast period in one go.

Multi-year water values are more accurate because they anticipate changes in one year that occur in the next year. The new water values have also moved away from the approach of averaging non-hydro offers over the year, which means that water values respond more to changes within years.

In creating multi-year water values, other major changes have been made in how the model interpreted the model data. The model now samples offers (generation) as an average of weekly data rather than annual average as used in EM4. This allows the future impact of significant events (large new generation or decommission) to be reflected in the water values as increasing over a period of time before the event. In EM4 this effect depended on when during the year it occurred, either creating a step change or average over a whole year.

However to have meaning at the end of the water value period, we are now required to provide additional generation and demand outside of the forecast period. At present this is 24 months but we are still investigating whether this should be longer/shorter. Any feedback on this would be welcome.

We can also expect changes at the traditional interface between years modelled with EM5. EM4 required that the water values were effectively circular (i.e. because the model could start at any date, the water values from March to April had to be the same). This is obviously no longer the case.

The length of the run defines the length of the multi-year water value. As mentioned above, the additional offers and demand need to be incorporated into the run data.

[[File:EM5 4 Example.JPG|600px|thumb|left|EM4 EM5 comparison]]

Our testing and analysis of the multi-year water values showed that on an annual average basis there is almost no difference between EM4 and EM5 average prices. However on a monthly basis we experienced a lower winter price, but a higher spring/early summer price. This is a direct result of the weekly generation sampling of EM5 (rather than annual average of EM4). The model now takes into account the higher availability of plant during winter, as well as (within this particular forecast) the lower availability in the spring and early summer.

===Grid updates===
We now have the ability of ‘version’ lines. Rather than having a series of grids to represent each year, we now have one but it can have multiple copies of the same line (versioned). This allows us to upgrade a line (including resistance and reactance) by just switching version on the fly. Where lines have been aggregated, we could of example have a single line version that could simulate a line outage.

Timeseries schedule elements are required to activate the lines version; The default lines version is zero.
Line:CYD2_ROX2.Version = Timeseries(0, '1/4/2015', 1)
(See the Transpower_DN6 schedule for more examples)

Although this feature has always been available, we have further enhanced our ability to use multiple character nodes within the grid. This allows for separate modelling of the 220, 110 and 66 KV part of the grid as well as interconnecting transformers. A demonstration grid is within the Resource file. Note the demand profile needs to be modified to match the characters in the grid.

The demonstration is still somewhat untested and may have some errors. It was created for testing purposes rather than as a proper forecast grid, although feedback on obvious errors would be welcome.

As part of the grid upgrade we discovered a ‘special’ Windows feature where a hidden copy of the map was being read rather than the copy in the program files directory. If you can’t correctly read the map data when you have overwrite the one in the ‘program files’ directory, please call us and we will try and help by finding the culprit.

===Demand input table===
This a request from users to create a easier way of entering monthly demand (especially now that the demand could be for multiple years).

Users now have the ability to input demand via the Monthly Demand Input table, which facilitates the specification of regional demand by month over an entire multi-year forecast.

Expected average demand rates can be entered either as average demand for week day or other day, or a single value representing average demand for a 5 week day / 2 other day week.

This input method is started using the demand button below the demand window in the main run window. Using the top table, demand can be entered either by ‘Total GWh/week’, or ‘MW average for Week Day’, or ‘MW average for OtherDay’.

Emarket calculates the other values and produces the monthly GWh totals (for checking purposes) in a table below. Once correct, click the Set Demand formulae button to write out the demand data into the run window.

A couple of thing to note;
*Emarket doesn’t save the original data, just the formulae;
*The calculations when entering a lot of month can be very slow, this is due to the time needed to generate the profiles for all months;
*The entry types are all in the top window (you may have scroll down) and are defined by various colours;
*The regions are how they are defined in the demand regions (as per EM4).
*Twenty four months of additional demand data is required the multi-ear water values.
*EMarket will calculate this formulas directly upon opening if the resource file contains the forecast data

If you don’t want to determine specific monthly values, demand can be entered as an annual time series or via a variable and the schedule. Examples are given in the resources file.

===Additional Output Spec features===
The use of a single run for outputs has the potential to result in some very large output files. To help with this we have created an extra ‘Partition’ in the OutputSpec call File. This allows an output spec to divide data up into small chunks. For example if Node is used in the File partition, then each node would be a separate output.

The output files can also be divided into years using the year function. Note that this also requires a new function is the Column or Row partition called ‘MonthofYear’ so that the correct months are allocated.

Examples are shown in the Resources files (‘Summary_byYear’ and’ Summary_byNode’)

===Command Line Emarket===
This feature is designed to assist in the automation of running Emarket. It also allows the running of multiple copies of Emarket using the same resources file and demand profile.

The command switches at present are;
• -wd <working directory> , sets the working directory in which EMarket starts up
• -r <batch runs>, causes EMarket to run a batch, runs are comma delimited in the argument. Emarket will close when the batch is finished
• -wvo, runs the batch with the 'Water Values Only' option
• -wwv, runs the batch with the 'Wait for Water Values' option
• -vm <volatility matrix>, sets the volatility matrix fo the run and directs the results to a partial database which can be merged with other executions of the same run. e.g. -vm "InflowYear:1940-1950,1980"
• -rb <reports batch> <run> [<minimum number of run parts>], runs a reports batch on the named run. If the minimum number of run parts is specified then EMarket will wait until at least this number of run outputs are produced in the latest version of the run results. This option also ensures the current batch number is iterated by 1 value.
• -?, displays this help message

The report batch should be used in all cases as it iterates the next run number when the process is complete. If it is not used then Emarket will overwrite the last run number data.

We have attached and example batch file (.bat) that could be used to run command line Emarket.
The batch file will question some variable and show others that are assumed. You are free to edit it however you like, but if you come up with anything really clever variations we would be keen to see them.

Site specific things that need to be changed within the batch file are;
• Run directory (line 4)
• RunName (line 5)
• Reportsbatch (line 6)
• Directory of Emarket (line 13)
• Also the Emarket file name if it has been changes (Various lines)

===Additional Tick Sizes===
Emarket now has 4 new tick sizes. 1, 2, 3 and 6 hour ticks. Corresponding output functions have been added to the OutputSpec for reporting purposes.

===Updated Profiled Generation Entry===
With the new Tick sizes, we have also updated the way 'Profiled Generation' can be entered.

The generation offer table 'Quantity Profile' now varies to offer the greater range of offers sizes.

The vertial axis now has the option of
*Month (tick box) - If ticked has a separate representation for each month
*Day of Week - Adds all 7 days to each month
*Week Other - Adds Week Day and Week Night to each month

The horizontal axis is by time periods ranging from
{|class="wikitable"
|-
| DN || DayNight ||| 2 values from 12am-8am, 8am-12am
|-
| DN6 || DayNight6 ||| 2 values from 12am-6am, 6am-12am
|-
| 6h || 6 hourly ||| 4 values from 12am-6am, 6am-12pm, 12pm-6pm, 6pm-12am
|-
| 4h || 4 hourly ||| 6 values from 12am-4am, 4am-8am, 8am-12pm, 12pm-4pm, 4pm-8pn, 4pm-12am
|-
| 3h || 3 hourly ||| 8 values from 12am-3am, 3am-6am etc.
|-
| 2h || 2 hourly ||| 12 values from12am-2am, 2am-4am etc
|-
| 1h || 1 hourly ||| 24 values from 12am-1am, 1am-2am etc.
|-
| hh || half hourly ||| 48 values from 12.00am-12.30am, 12.20am-1.00am etc.
|-
|}

== Help files point to Wiki==
The help files now open this Wiki rather than specific on computer help files. This wiki superceeds the previous Manual and help files.

[[EMK:Main Page | Back to EMK Main Page]]

Special:Badtitle/NS108:EMarket 5 Notes

2013-03-08T01:33:52Z

NelsonM: /* Multi-year water values */

{{#hidens:}}
;EMarket 5 - Details Release Notes/Commentary

==Major Enhancements==
*Multi-year water values
*Updated grid allowing versioning of lines and 4+ digit node names
*Demand input table
*Additional report spec outputs
*Command line running
*Additional Tick sizes (1,2,3 and 6 hours)
*Updated Profiled Generator entry allow for the new tick sizes
*Help information is now accessed through an EMarket Wiki

===Multi-year water values===
With the introduction of EMK 5, multi-year runs can now be set up from one run resource and the water values are calculated over the entire forecast period in one go.

Multi-year water values are more accurate because they anticipate changes in one year that occur in the next year. The new water values have also moved away from the approach of averaging non-hydro offers over the year, which means that water values respond more to changes within years.

In creating multi-year water values, other major changes have been made in how the model interpreted the model data. The model now samples offers (generation) as an average of weekly data rather than annual average as used in EM4. This allows the future impact of significant events (large new generation or decommission) to be reflected in the water values as increasing over a period of time before the event. In EM4 this effect depended on when during the year it occurred, either creating a step change or average over a whole year.

However to have meaning at the end of the water value period, we are now required to provide additional generation and demand outside of the forecast period. At present this is 24 months but we are still investigating whether this should be longer/shorter. Any feedback on this would be welcome.

We can also expect changes at the traditional interface between years modelled with EM5. EM4 required that the water values were effectively circular (i.e. because the model could start at any date, the water values from March to April had to be the same). This is obviously no longer the case.

The length of the run defines the length of the multi-year water value. As mentioned above, the additional offers and demand need to be incorporated into the run data.

[[File:EM5 4 Example.JPG|600px|thumb|left|EM4 EM5 comparison]]

Our testing and analysis of the multi-year water values showed that on an annual average basis there is almost no difference between EM4 and EM5 average prices. However on a monthly basis we experienced a lower winter price, but a higher spring/early summer price. This is a direct result of the weekly generation sampling of EM5 (rather than annual average of EM4). The model now takes into account the higher availability of plant during winter, as well as (within this particular forecast) the lower availability in the spring and early summer.

===Grid updates===
We now have the ability of ‘version’ lines. Rather than having a series of grids to represent each year, we now have one but it can have multiple copies of the same line (versioned). This allows us to upgrade a line (including resistance and reactance) by just switching version on the fly. Where lines have been aggregated, we could of example have a single line version that could simulate a line outage.

Timeseries schedule elements are required to activate the lines version; The default lines version is zero.
Line:CYD2_ROX2.Version = Timeseries(0, '1/4/2015', 1)
(See the Transpower_DN6 schedule for more examples)

Although this feature has always been available, we have further enhanced our ability to use multiple character nodes within the grid. This allows for separate modelling of the 220, 110 and 66 KV part of the grid as well as interconnecting transformers. A demonstration grid is within the Resource file. Note the demand profile needs to be modified to match the characters in the grid.

The demonstration is still somewhat untested and may have some errors. It was created for testing purposes rather than as a proper forecast grid, although feedback on obvious errors would be welcome.

As part of the grid upgrade we discovered a ‘special’ Windows feature where a hidden copy of the map was being read rather than the copy in the program files directory. If you can’t correctly read the map data when you have overwrite the one in the ‘program files’ directory, please call us and we will try and help by finding the culprit.

===Demand input table===
This a request from users to create a easier way of entering monthly demand (especially now that the demand could be for multiple years).

Users now have the ability to input demand via the Monthly Demand Input table, which facilitates the specification of regional demand by month over an entire multi-year forecast.

Expected average demand rates can be entered either as average demand for week day or other day, or a single value representing average demand for a 5 week day / 2 other day week.

This input method is started using the demand button below the demand window in the main run window. Using the top table, demand can be entered either by ‘Total GWh/week’, or ‘MW average for Week Day’, or ‘MW average for OtherDay’.

Emarket calculates the other values and produces the monthly GWh totals (for checking purposes) in a table below. Once correct, click the Set Demand formulae button to write out the demand data into the run window.

A couple of thing to note;
*Emarket doesn’t save the original data, just the formulae;
*The calculations when entering a lot of month can be very slow, this is due to the time needed to generate the profiles for all months;
*The entry types are all in the top window (you may have scroll down) and are defined by various colours;
*The regions are how they are defined in the demand regions (as per EM4).
*Twenty four months of additional demand data is required the multi-ear water values.

If you don’t want to determine specific monthly values, demand can be entered as an annual time series or via a variable and the schedule. Examples are given in the resources file.

===Additional Output Spec features===
The use of a single run for outputs has the potential to result in some very large output files. To help with this we have created an extra ‘Partition’ in the OutputSpec call File. This allows an output spec to divide data up into small chunks. For example if Node is used in the File partition, then each node would be a separate output.

The output files can also be divided into years using the year function. Note that this also requires a new function is the Column or Row partition called ‘MonthofYear’ so that the correct months are allocated.

Examples are shown in the Resources files (‘Summary_byYear’ and’ Summary_byNode’)

===Command Line Emarket===
This feature is designed to assist in the automation of running Emarket. It also allows the running of multiple copies of Emarket using the same resources file and demand profile.

The command switches at present are;
• -wd <working directory> , sets the working directory in which EMarket starts up
• -r <batch runs>, causes EMarket to run a batch, runs are comma delimited in the argument. Emarket will close when the batch is finished
• -wvo, runs the batch with the 'Water Values Only' option
• -wwv, runs the batch with the 'Wait for Water Values' option
• -vm <volatility matrix>, sets the volatility matrix fo the run and directs the results to a partial database which can be merged with other executions of the same run. e.g. -vm "InflowYear:1940-1950,1980"
• -rb <reports batch> <run> [<minimum number of run parts>], runs a reports batch on the named run. If the minimum number of run parts is specified then EMarket will wait until at least this number of run outputs are produced in the latest version of the run results. This option also ensures the current batch number is iterated by 1 value.
• -?, displays this help message

The report batch should be used in all cases as it iterates the next run number when the process is complete. If it is not used then Emarket will overwrite the last run number data.

We have attached and example batch file (.bat) that could be used to run command line Emarket.
The batch file will question some variable and show others that are assumed. You are free to edit it however you like, but if you come up with anything really clever variations we would be keen to see them.

Site specific things that need to be changed within the batch file are;
• Run directory (line 4)
• RunName (line 5)
• Reportsbatch (line 6)
• Directory of Emarket (line 13)
• Also the Emarket file name if it has been changes (Various lines)

===Additional Tick Sizes===
Emarket now has 4 new tick sizes. 1, 2, 3 and 6 hour ticks. Corresponding output functions have been added to the OutputSpec for reporting purposes.

===Updated Profiled Generation Entry===
With the new Tick sizes, we have also updated the way 'Profiled Generation' can be entered.

The generation offer table 'Quantity Profile' now varies to offer the greater range of offers sizes.

The vertial axis now has the option of
*Month (tick box) - If ticked has a separate representation for each month
*Day of Week - Adds all 7 days to each month
*Week Other - Adds Week Day and Week Night to each month

The horizontal axis is by time periods ranging from
{|class="wikitable"
|-
| DN || DayNight ||| 2 values from 12am-8am, 8am-12am
|-
| DN6 || DayNight6 ||| 2 values from 12am-6am, 6am-12am
|-
| 6h || 6 hourly ||| 4 values from 12am-6am, 6am-12pm, 12pm-6pm, 6pm-12am
|-
| 4h || 4 hourly ||| 6 values from 12am-4am, 4am-8am, 8am-12pm, 12pm-4pm, 4pm-8pn, 4pm-12am
|-
| 3h || 3 hourly ||| 8 values from 12am-3am, 3am-6am etc.
|-
| 2h || 2 hourly ||| 12 values from12am-2am, 2am-4am etc
|-
| 1h || 1 hourly ||| 24 values from 12am-1am, 1am-2am etc.
|-
| hh || half hourly ||| 48 values from 12.00am-12.30am, 12.20am-1.00am etc.
|-
|}

== Help files point to Wiki==
The help files now open this Wiki rather than specific on computer help files. This wiki superceeds the previous Manual and help files.

[[EMK:Main Page | Back to EMK Main Page]]