Page Comparison

Prioritising Shortfalls
Introduction
This specification has been created to try and develop a simple and effective system that allows Ordering priorities allow users in Source to specify how shortfalls are prioritised between different demands in Source. Currently Previously, Source tries tried to shortfall all demands equally within the model, this specification will hopefully provide functionality provides a solution to address the following situations encountered in water resource models such as the following:

• Supplying a minimum flow requirement in preference to upstream water diverters,
• Supplying diverters in preference to meeting a downstream storage target,
• Preference the delivery of irrigation water over environmental water or vice versa.

The specification aims to influence Prioritisation influences how water is taken by water users , not how it is distributed by the system e.g. on and how a storage with multiple outlets it will not prioritise prioritises releases down the different outlets based on the priority levels on each outlet. The existing code to determine releases on regulated structures will determine the distribution of volume down outlet paths.
What it does not propose to do is prioritise the distribution of water at nodes representing regulating structures i.e. storage nodes with multiple outlets and regulated splitters. The current functionality in Source will continue to decide how to distribute flow down these paths.
What it should do is . A model with prioritisation configured is able to provide information on how water is supplied to users along regulated river reaches between regulating structures. Assumptions/Overview

...

Principal developers

Ordering priorities were implemented for the Victorian government Department of Environment, Water, Land and Planning by eWater with the assistance of Murray Darling Basin Authority and NSW Department of Primary Industries. 

Version

Source full version 4.1.1

Assumptions and Dependencies

 A rules based ordering system must be active in Source. For a rules based ordering system to operate in Source, the "New rules based ordering system" option must be selected as the ordering algorithm. At least one supply or demand node must be present in the system.

The current behaviour for sharing shortfalls in Source is maintained as the default behaviour (distribute shortfalls equally)

...

. This is reflected as all nodes receiving a priority of 1 initially in the priority table

Priorities are assigned in levels of 0 to n, with the lower n level having the highest priority

A priority array is calculated during the order phase which shows the proportion of the total order for all defined priority levels. The sum of this priority array must always equal 1 (within some pragmatic tolerance)

The priority array is calculated during the order phase for each elements minimum order time

The priority array must be kept for order times (0...min order time) at all elements. This should be managed in the ordering recorder much like constraint factors

The priority array at 0 time should be used in the flow array to determine whether a supply point can extract water

Where orders are increased/decreased for

...

losses (evaporation, seepage

...

) and gains (tributary inflows, rainfall, groundwater

...

Then ), then the priority ratios are not changed as these adjustments are assumed to be required to supply the downstream order.  

Variables

• n number of priorities specified
• pNode Node priority applies to things which can place orders
• dsOrder(min) ds order at a node at min flow time
• order(min) order propagated upstream at min flow time
• nPriority(n) output array of n priorities for the node
• dsPriority(n) array of n priorities being passed into the node
• sumDSPriorityG sum of dsPriority(n) where n < pNode
• sumDSPriorityGE sum of dsPriority(n) where n <= pNode
• sumDSPriorityL sum of dsPriority(n) where n > pNode
• sumDSPriorityLE sum of dsPriority(n) where n >= pNode
• sumnPriorityG sum of nPriority(n) where n < p
• MinFlowReq minimum flow requirement
• SupplyPointOrderOrder generated by water user and passed to supply point
• dsMainPriority(p) Priorities arriving at a splitter from the main branch
• dsMainOrder Order arriving at a splitter from the main branch
• dsEffPriority(p) Priorities arriving at a splitter from the effluent branch
• dsEffOrder Order arriving at a splitter from the effluent branch

Min Minimum Flow Node
The minimum flow node needs to have a priority assigned to it (pNode) by the user. The priority assigned to the minimum flow requirement can change the proportions of the priorities being passed upstream. There are essentially two scenarios that can occur

...

Supply Point
There are essentially four scenarios in how a supply point node can be configured for the rules based-ordering, shown in Table 1. Note that if a Supply Point is selected as groundwater then it should not be part of the ordering network i.e. it should not be allowed to generate orders (this does not appear to happen in the model, maybe more validation for that setting?)
As the Supply Point can extract water from the system we need to consider how the priorities affect both the order phase and the flow phase.

...