Page Comparison

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:

...

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

...

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 where (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.

...

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 should have has two options regarding ordering priorities

1. Maintain downstream ratio
2. Override ratios and assign to one priority level

...

1. (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

...

Re-regulating the

...

orders 

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

Process

1. If "PassThroughOrder" = true Then
   1. sumOutletOrder = Sum the total order from all outlets
   2. Loop on priorities p = 0 to n
      1. Loop on outlets
      2. OutletOrders(p) += dsOrder(p) * OutletOrder
      3. nPriority(p) = OutletOrders(p)/ sumOutletOrder

...