Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

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.

Principal developer

Version

Source full version 4.1.1


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

...


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.

Anchor
_Ref411330922
_Ref411330922
Table 1 Supply Point configuration

Scenario

Allow Order

Extract Water

Notes

1

True

True

Standard case

2

True

False

Just restrict the extraction in the flow phase – should not be an issue

3

False

True

Water will be extracted independently of the priorities

4

False

False

Nothing occurs

...