Page Comparison

Document History

Overview

Description and rationale

...

Flow event triggers are based on flows exceeding flow thresholds at an OAN. These thresholds may be fixed numbers or a function and different thresholds can be specified for commencing and ending the off allocation event. The event triggers may be optionally constrained by a seasonal period and a maximum flow threshold, which may be a fixed number or function. The threshold can be configured to be based on total flow (Figure 1) or flow above orders (Figure 2). In the case where triggers are based on flow, the larger of orders and event trigger is adopted as the threshold. The off allocation volume may be determined as flow above threshold (Option 1 2 and 3 in respective Figures 1 and 2) or flow above orders (Option 2 1 and 4 in respective Figures 1 and 2).

...

...

Note that although Ownership is not configured directly for an off-allocation system, off-allocation flow sharing is always used in conjunction with a resource assessment system. When off-allocation sharing is configured for a scenario, it must be linked to an associated resource assessment system by the modeller. If ownership has been configured for the linked resource assessment system then that owner’s share of flow at the OAN is subject to owner shares of the off allocation volume.

Methodology

Variables Used

...

...

1. The total usage for all the accounts associated with each OAN is initialised by adding the initial account usage volumes as defined by the modeller (Note: If the account holder is a downstream OAN then the initial usage for the account type is the sum of all water users which have accounts at that OAN account type.)
   
   For each account a at the OAN (i.e. of its account type):

   1. Initialise usage for the account:
      
      

   2. If usage at the OAN is capped, the account is assigned its share of the usage cap, and the remaining balance to be used is determined:
      
       

      
      

      

2. The system's usage limit (usage remaining under system cap level) is initialised:

   1. If a system cap limit has been specified by the modeller, the remaining system cap is set, based on the cap and usages:
      
      

...

1. Save each owner's request for off-allocation water (the volume at the OAN; i.e. adjusted for losses).
   
   
   

2. If ownership is enabled and there is more than one owner, the owner loss contribution, Loss(wu, owner), in meeting the request for each water user at the OAN, are determined. Determine the loss contribution of each owner describes how this is done.
   
   
3. The volume of off-allocation water that is available, Vol_OffAlloc , is calculated. See Determine the off-allocation volume below for details.
   
   
4. The off-allocation water is allocated. If ownership is not enabled or there is only one owner, the steps below are only performed once. When there are multiple owners, they are repeated until either there is no off-allocation water to share, or all requests are met, or the system's usage limit has been reached (if there is such a limit).
   
   

   1. A check is made to see whether there is any off-allocation water to allocate, or not. If there is no off-allocation water (remaining) to share (ie. if Vol_OffAlloc = 0  or Vol_OffAlloc < lowest volume allocation level ), the allocation procedure stops here.

   2. How much of the total requested volume at the OAN can be met/supplied is determined.

       

      
      

      If met ≤ 0 , the allocation procedure stops here. 

      
      

   3. If there is a usage cap defined for the off-allocation system, a check is made to see if there is remaining usage capacity. This is calculated based on the current usages of all accounts a at every OAN in the off-allocation system:

       

      
      

      If LimitUsage(system) = 0 , there is no remaining system cap to share, so the allocation procedure stops here.

   4. The off-allocation delivery efficiency is determined for each account using the following equation:
      
      

      
      where a is the account for a downstream water user. (Recall that each water user which requires off-allocation flow to be allocated to them from a particular OAN in the river system holds one off-allocation account at that node.)
      
      

   5. Determine the maximum volume of a request remaining to be fulfilled for each off-allocation account a at downstream water users:

      1. If there is a usage cap configured, it is the smaller of the request and the remaining usage cap
         
         

      2. Otherwise, it is the requested volume
         
         
         
         
      3. If no account has LimitUsage(a) > 0 , the allocation procedure stops here.
         
         
   6. Off-allocation water is allocated to accounts at the OAN. At every priority level, in order from highest to lowest, the following occurs:
      1. If the equalise shares option has been selected, account allocations/usages at a given priority level are equalised based on their usage to shares ratio. Equalise shares of off-allocation water describes how this is done.
         
         
      2. Remaining off-allocation water is allocated to accounts at the given priority level according to account shares. Allocate off-allocation water to accounts based on shares describes how this is done.
         
         

   7. At this stage the OAN may have met each of the water user's owner requests and thus supplied more water than the water user requires – as the total request was placed for every owner. The steps that follow check for this and re-distribute any excess allocation – firstly to other water users of the same ownership, then to other water users. The process depends on how many owners there are:
      
      If ownership is disabled or there is only one owner, usage is simply updated:
      
      

      
      Otherwise (i.e. there is more than one owner):

      1. Any excess is redistributed according to the method described in Re-distribute off-allocation excess.
         
         
      2. The usage for this round of allocation is updated
         
         
         
         
      3. Return to step 3. The next round will redistribute any losses met by other owners to water user accounts with insufficient water to meet requests.
         
         

5. Account balances for every account at the OAN are updated
   
   

...

1. Limit the share volume for an account (Note that if LimitUsage(a) is not specified by the modeller its value defaults to a very big number):
   
   
   
   

   
   

2. Reduce the volume of off-allocation water available to share
   
   
   
   
3. Calculate the volume that this represents at the source
   
   
   
   

4. Calculate allocations for the account for each user and adjust the usage limits if required.
   
   
   
   
   
   

5. If a system cap has been specified and would be exceeded by allocations in the current time step, then allocations are reduced to fit within cap (otherwise this step is skipped).

   1. Sum the allocations for each user in the current priority level
      
      

   2. Calculate the volume by which the system cap would be exceeded based on potential allocations
      
      

   3. Calculate the proportion that each allocation would have to be reduced by to meet the system cap restriction
      
      

   4. For each OAS node account at the current priority level allocations are adjusted so that they do not exceed the system cap, taking into account the efficiency factors, then the limits for the adjustment are updated:
      
      
      
      
      
      
      
      

...

1. The excess off-allocation volume available for re-distribution is initialised:
   
   

2. For each water user, excess off-allocation water is redistributed:

   1. The access ratio for each off-allocation account and the total of these account ratios for each water user are determined, 
      where a is the account for water user and owner owner.
      
      

   2. The access ratio is checked to determine whether water in excess of the total request has been allocated:

      1. If AccessRatio ≤ 1 , there is no excess to redistribute. The remaining request to be met is calculated as:
         
         

         
         Skip to the next water user.
         
         

      2. Otherwise processing continues in order to redistribute excess between owner accounts.
         
         
      Distribution of a water user's excess off-allocation water
      Assuming that a water user will try and maximise its access to off allocation water, Source uses each owner's off-allocation water on the basis of its allocation (an indication of licence priority), or its remaining capacity to receive water if accounts are capped. The account with the largest allocation has this adjusted first until it is the same as the next largest, and so on. This cycle is repeated until all the excess off allocation water is allocated or accounts have no remaining capacity to receive water.
      
      
   3. The new allocation for each water user's off-allocation account is initialised:
      
      

      1. If accounts are capped:
         
         

         

      2. Otherwise
         
         

         
         where a is the account for water user and owner owner.

         

   4. The owner accounts for each water user are ranked in order of allocation, newAlloc(owner), from highest to lowest.
      
      

   5. Excess is allocated to owners in the ranked order until the total remaining request volume is met, but the allocation is equalised so that lower priority owners also get some water – the result is a new 'equalised' allocation, newAlloc(owner).

      Code Block

      remvol= Requestwu do i= 2, nowner sum= 0 do j= 1, i-1 sum= sum +rembal(ptr(j)) end do vol= min(remvol,sum-rembal(ptr(j)*(i-1)) do j= 1, i-1 rembal(ptr(j))= rembal(ptr(j))-vol/(i-1) end do remvol= remvol - vol If( remvol <= 0 ) exit end do if( remvol > 0 ) then sum = 0 do j= 1, nowner sum= sum + rembal(ptr(j)) end do vol= min(remvol,sum) do j= 1, nowner rembal(ptr(j))=rembal(ptr(j))-vol/nowner end do remvol= remvol- vol end if

   6. The allocation for this time step is updated for the re-distribution: 

      

   7. The remaining volume of off-allocation water not required by this water user is added to the total to be reallocated to other water users:

      

   8. The off-allocation volumes are adjusted for losses met by other owners:

      Every owner's ratio of the total off-allocation volume is calculated:
      

      The loss met by every other owner is their loss volume (calculated in Step 2 under Flow Phase (Resource Assessment and Allocation)) multiplied by their share of the off-allocation volume. This means that for a given owner, the off-allocation volume adjusted for other owner losses is:
      
      

3. Indicate that the water user's request has been met: 
   
   

   Request(a,owner) = 0

Examples

Opportunistic requests in parallel systems

...

Each OAN processes the orders for its direct users downstream (including the next downstream OAN) and passes the combined orders up to the next OAN (if there is one). This means that it is possible to share off allocation water between multiple downstream reaches.
In the example illustrated in Figure 6, below, OAN3 has a share component in OAN2 which also has a share component in OAN1. This means that the off-allocation requirements of water user 3 and 4 are accumulated up the system and are reported as the off-allocation requirement of OAN2. This means that the allocation of off-allocation water to reach 1 takes into consideration the downstream requirements. It is possible to give priority access to downstream requirements by assigning the highest priority to OAN2 in the OAN1 allocation table.
Note that while OAN1 assigns a volume of off-allocation water to OAN2, the processing of OAN2 may result in a change in the volume of off-allocation water available to that reach as the rules specific to OAN2 are used to calculate the available water.

Figure 6 — Example of multiple off allocation reaches

Off allocation and storages

...

Environmental Conditions - The declaration of an off-allocation flow event may be dependent upon whether the taking of water will prevent the beneficial watering of an environmental value or asset. This can be replicated by developing a water user with an environmental demand model. The highest allocation priority should be assigned to the associated Supply Point. It should be noted that if this Supply Point is in a downstream off-allocation reach, the downstream OAN would have to be assigned highest priority when evaluating the current off-allocation reach. This also means that other off-allocation demands in the downstream reach, such as for irrigation, would get highest priority, which may not be desirable.

Data

Input data
Details on input data are provided in the Source User Guide.

...

Off-allocation Account Type Parameters
Parameters input by the modeller at the account type level affect all associated accounts.
Table 4 —Account Type Configuration - Parameters

...

Output data

Table 7 — Recorded variables

Reference list

...

Bibliography