Ordering with Priorities - SRG

Ordering priorities allow users in Source to specify how shortfalls are prioritised between different demands in Source. Previously, Source tried to shortfall all demands equally within the model, this functionality provides a solution to address 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.

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.

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 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

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 greater than or equal to the downstream order, so the upstream order is increased and priorities need to be recalculated
2. The minimum flow requirement is less than or equal to the downstream order, so the 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)

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.

Table 1 Supply Point configuration

Order Phase
Adjustment of orders will only occur when "Allow Order" has been selected. If

1. If "Allow Order" = True Then
   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
2. If "Allow Order" = False Then nPriority(p) = dsOrder(p)

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 are maintained and equalises water 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.

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)

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)/ sumOutletOrder

Re-regulating the orders 

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

User needs to associate a priority level for supply priority (downstream priority) and operational priority
If (usOrder(min) <= dsOrder(min) )THEN

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

If (usOrder(min) > dsOrder(min) )THEN Supply priority volume = usOrder(min) at prioirity level

• Supply priority ratio = DsOrder(min)/UsOrder(min) at priority level
• operational priority ratio = (USOrder(min) –DsOrder(min))/UsOrder(min) at priority level

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)

Confluence
Possibly the most difficult one to address. As we are passing up the values at min order time, it is possible for a confluences regulated upstream branches to have different min travel times. At least one of those branches will have the same min travel time as

• Just split the ratios upstream

Controlled Splitter
Set the new upstream ratios as the weighted average of the orders from both branches

1. Loop on priorities p = 0 to n
2. nPriority(p) = (dsMainPriority(p)*dsMainOrder + dsEffPriority(p)*dsEffOrder)/( dsMainOrder+ dsEffOrder)

Bulk Licensing
??