Page Comparison

Ordering priorities allow users in Source to specify how shortfalls are prioritised between different demands in Source. PreviouslyWithout a priority system enabled, Source tried to will shortfall all demands equally within the model, this functionality provides a solution to address . The priority ordering system addresses situations encountered in water resource models such as the following:

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

Prioritisation influences how water is taken by water users and how a storage with multiple outlets prioritises releases down the different outlets. A model with prioritisation configured is able to provide information on how water is supplied to users along regulated river reaches between regulating structures.outlet paths. 

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. 

...

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.

...

A priority array is calculated during the order phase which shows the proportion of the total order for all defined priority levels (priority ratios). The sum of this the priority array ratios 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 is 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 is used in the flow array phase 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 the priority ratios are not changed as these adjustments are assumed to be required to supply the downstream order.  or not. 

It is assumed that losses and gains are shared in proportion to the priority ratios.   

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

Minimum Flow Node

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

1. The minimum flow requirement is a greater volume than or equal to the downstream order volume, so the total upstream order is increased and priorities are reassigned based on the additional order required and priorities need to be recalculatedthe priorities of the downstream orders.
   
   
2. The minimum flow requirement is less than or equal to the downstream order, so the total upstream order is not changed but the priorities need to be calculated

The calculation procedure is below

1. Loop on priorities p = 0 to n
2. If the MinFlowReq >= dsOrder Then
   1. If p < pNode then nPriority(p) = dsPriority(p)*dsOrder/MinFlowReq
   2. If p = pNode then
      1. sumDSPriorityLE = sum of dsPriority(n) where n >= p
      2. nPriority(p) = ((MinFlowReq – dsOrder) + sumDSPriorityLE* dsOrder)/MinFlowReq
   3. If p > pNode then nPriority(p) = 0
3. If the MinFlowReq < dsOrder Then
   1. sumDSPriorityGE = sum of dsPriority(n) where n <= p
   2. If p <= pNode then
      1. sumDSPriorityG = sum of dsPriority(n) where n < p
      2. nPriority(p) = sumDSPriorityGE*dsOrder >= MinFlowReq ? dsPriority(p)*dsOrder/usOrder : (MinFowReq- sumDSPriorityG *dsOrder)/usOrder
   3. If p > Node(p) then
      1. sumDSPriorityL = sum of dsPriority(n) where n > p
      2. nPriority(p) = nPrioirity(p)/ sumDSPriorityL*(1- sumDSPriorityGE)

1. are reassigned based on the priorities of the downstream orders and the priority of the minimum flow requirement. e.g. if the downstream orders have a lower priority that the minimum flow requirement, the lower priorities are replaced by the higher priority level for the order up to that of minimum flow requirement. Priorities will remain in place for anything above it.  

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 is not be part of the ordering network i.e. it should does not be allowed to generate orders (this does not appear to happen in the model, maybe more validation for that setting?)generate orders 
As the Supply Point can extract water from the system we need to consider how the priorities it can affect both the order phase and the flow phase.

...

...

1. Loop on priorities p = 0 to n
2. If p = pNode Then nPriority(p) = (SupplyPointOrder + dsOrder(p)*DsOrder)/usOrder
3. If p != pNode Then nPriority(p) = (dsOrder(p)*DsOrder)/usOrder

Flow Phase
In the flow phase the shortfall priorities will inform the supply point on the volume of water it is able to extract. It tries to ensure that orders of higher volume of water priority are maintained and equalises water access at the supply point's priorities level. Lower priorities be damned!

1. If "Extract Water " = True Then
   1. Loop on priorities p = 0 to n
   2. sumnPriorityG = sum of nPriority(n) where p < pNode
   3. Max(0,Min(SupplyPointOrder, (UpstreamFlow- (sumnPriorityGOrder))(SupplyPointOrder/(nPriority(p)*Order))))
2. If "Extract Water" = False Then Continue

Environmental Demand Node

If Inclusive of Orders = True Then
It acts like a minimum flow node and we will need to adjust ratios
If Inclusive of Orders = False Then
It acts like a supply point and is generating an additional order

Gauge Node, Straight Through routing, lagged routing, Off allocation
Pass through the priority array

Inflow Node, Loss Node, Hydraulic Connecter Nodes & Storage Routing Links
Pass through the priority array, noting that order volumes are most likely going to change. Assume that any change in orders are required to meet downstream and are shared across the priorities. I guess this assumes that if the highest priority has 50% of the order then 50% of the associated loss/gain are associated with delivery of the water. This assumption may have some holes but keeps it simple for now. As priority shortfalls are independent of ownership it should have minimal impact.

priority level. 

Transfer of Ownership
The transfer of ownership has two options regarding ordering priorities

1. Maintain downstream ratio
2. Override ratios and assign to one priority level (re-prioritise orders - see user guide)

Storage

Evaporation based orders...

operating target based orders...

Two options at a storage node that have an impact on the prioritisation of orders

Pass Orders Through – simply sum the volumes at each priority level across all outlets and divide by total volume being passed up all outlets to get proportions, assume evap/seepage does not effect storage ratios

sumOutletOrder = Sum the total order from all outlets

OutletOrders(p) += dsOrder(p) * OutletOrder

nPriority(p) = OutletOrders(p)/ sumOutletOrderThe priority of the upstream orders will be the same as that of the downstream orders. 

Re-regulating the orders 

1. 1. Downstream orders
   2. Storage losses
   3. Different upstream min order time
   4. Operational targets being met

...

• Supply priority ratio = 1.0 at priority level
• operational priority ratio = 0 at priority level

...

orders (default)

If pass orders through is not selected, the default behaviour is for the storage to re-regulate the flows. As a result, orders will be passed to upstream storages under two priorities, supply priority (specified by the user), and operational priority, which is always the lowest priority. The supply priority order is the minimum of the upstream and downstream orders at the storage. The operational-priority order is the greater of the upstream order minus the downstream order, or zero.   

Maximum Order
The maximum order can truncate orders being passed upstream to a specified value. If this is the case we try and preserve the highest priority volume of water being passed upstream. Therefore we need to adjust the ratios to reflect the change.

1. If MaxOrder < dsOrder Then
   1. Loop on priorities p = 0 to n
   2. sumDSPriorityG = sum of dsPriority(n) where n < p
   3. If(sumDSPriorityG*dsOrder>MaxOrder,0,Min(MaxOrder - sumDSPriorityG*dsOrder, dsPriority(p)*dsOrder/MaxOrder))
2. If MaxOrder > dsOrder Then…. For all p nPriority(p) = dsPriority(p)

...

• Just split the ratios upstream

...

This is done by removing the lower priority orders until the total is less the maximum specified. 

Confluence

The confluence maintains the ratio of priorities up both branches. 

Bulk Licensing
??