Page Comparison

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

• 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 how water is taken by water users, not how it is distributed by the system e.g. on a storage with multiple outlets it will not prioritise releases down 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 provide information on how water is supplied to users along regulated river reaches between regulating structures.
Assumptions/Overview

1. That the current behaviour for sharing shortfalls in Source is maintained as the default behaviour (distribute shortfalls equally)
2. Prioritising Shortfalls is enabled as a special feature, where the user is able to specify priorities for nodes which generate orders
   1. Supply Points
   2. Environmental Demand Nodes
   3. Minimum Flow Requirements
   4. Storage Nodes
3. Priorities are assigned in levels of 0 to n, with the lower n level having the highest priority
4. 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)
5. The priority array is calculated during the order phase for each elements minimum order time
6. 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
7. The priority array at 0 time should be used in the flow array to determine whether a supply point can extract water
8. Where orders are increased/decreased for the following expected behaviours
   1. Losses – evaporation, seepage
   2. 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 output array of n priorities for the node
• dsPriority array of n priorities being passed into the node
• sumDSPriorityG sum of dsPriority where n < pNode
• sumDSPriorityGE sum of dsPriority where n <= pNode
• sumDSPriorityL sum of dsPriority where n > pNode
• sumDSPriorityLE sum of dsPriority where n >= pNode
• sumnPriorityG sum of nPriority 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 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. 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 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 where n <= p
   2. If p <= pNode then
      1. sumDSPriorityG = sum of dsPriority 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 > 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.

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 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 should have two options

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

Need to work out how to implement this in the GUI
Storage
Two options at a storage node

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

1. Re-regulating the orders – Far more complex as we have a number of issues
   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

1. If "PassThroughOrder" = false Then

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

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

Bulk Licensing
??