Page Comparison

Description and rationale

Functionality for modelling water use accounting systems is needed particularly in any modelling platform intended for reliable modelling of existing regulated river systems. Source provides a number of different options for modelling water use accounting systems, including Annual Accounting, Continuous Accounting, Continuous Sharing and a generic accounting system.

This section describes how a Continuous Accounting system, such as that used in the Namoi and Gwydir regulated river systems in NSW, is represented in Source. In Continuous Accounting, water resources are divided into user shares. For each user, water use, availability and carry over are tracked by a system of accounts.

The features that define Continuous Accounting systems are:

• The resource allocated by the system is typically water held in the system’s storages (rather than unregulated sources);
• At the system level, there is a defined reserve for storage losses. This is different to Continuous Sharing systems, which allocates such losses to individual water user/accounts via an ‘efficiency factor’; and
• At any time, the sum of all the system’s account allocations plus the reserve will normally equal the volume of active storage in the system. This is not usually the case for Annual Accounting systems, that can otherwise resemble Continuous Accounting systems if they have carryover. There are resource allocation systems that are effectively a hybrid of Continuous and Annual accounting, such as that used in the Lachlan river, where water is allocated to accounts before it arrives in system storages.

The representation of Continuous Accounting used in Source is designed to accommodate the following account types that are used in the Namoi and Gwydir systems:

• Annual high security: To meet essential water use requirements;
• General security accounts: For other water use requirements;
• Generic system share (GSS): To assign water to other resource allocation systems; and
• Storage loss reserve: To cater for losses from evaporation, seepage etc.

The actual methodology used in practice in the Gwydir and Namoi systems is supported by the following features:

• Ability to simulate more than one type of resource allocation and accounting method in the one Source scenario;
• Ability to relate storage volume to periodic announcements of water allocation (ie. the volume of water available to users);
• Ability for a continuous accounting system’s resource assessment to refer to existing allocations in another resource assessment system (of any type); and
• Ability to provide a continuous balance of all account volumes.

Scale

The volumes allocated to the Continuous Accounting system’s account types, and individual accounts within these, are updated at every model time-step. The concept of spatial scale is related to the fact that these systems can apply to various categories of water users spread through all or part of the length of a river system.

Principal developer

The original modelling representation of Continuous Accounting was developed by predecessors to the NSW Office of Water and incorporated into IQQM, in connection with developing water sharing plans. This was enhanced by eWater CRC and incorporated into Source. The enhancements include the features listed in the four points at the end of the section on Description and rationale above. They also include a number of features for better representing allocations during dry periods.

Scientific provenance

Continuous accounting has been implemented under:

• The Water Sharing Plan for the Gwydir Regulated River Water Source which commenced on 1 July 2004 (NSW Government, 2006); and
• The Water Sharing Plan for the Upper Namoi and Lower Namoi Regulated River Water Sources which commenced on 1 July 2004 (NSW Government, 2009).

Representation in Source is based on these implementations. Implementation of continuous accounting is consistent with Recommendation 29 from the Industry Commission inquiry into water resources and waste water disposal (Industry Commission ,1992):

States should introduce continuous accounting within the release sharing system. In systems where security of supply is an issue, States should consider whether capacity sharing would provide a superior form of risk management.

Version

Source version 3.0.16

Dependencies

A defining feature of Continuous Accounting is that each account is explicitly associated with a volume of water held in storage. This makes it a type of resource assessment/allocation that is applicable to regulated systems. Hence in a Source scenario with Continuous Accounting, there will usually be at least one Storage node, and one Water User node connected to a Supply Point node downstream of the Storage node in the system being modelled. Other nodes may be needed to enable the characteristics of the Continuous Accounting system to be adequately represented.

Continuous Accounting terminology

Table 1. Continuous accounting terminology

Other definitions can be found in the eWater glossary

Basic rules and assumptions

There are a number of defining features of a continuous accounting system which differentiate it from continuous sharing and annual allocation systems:

• Assessments of whether a new allocation can be made occur intermittently (based on triggers defined within the plan) with a new allocation resulting in an additional volume of water added to user’s accounts. With continuous accounting, there is no end of year forfeiture of allocation. There are, however, limits on the volume that can be held in a general security account at any one time and usage limits may also apply;
• An account is maintained for the system as a whole to meet transmission and operation losses (TOL) for delivery of regulated water. The volume required in the TOL is a function of account balances, generally defined through a simple factor. In practice the TOL factor can be decided by operators and not defined through water sharing plan rules. Where there are storages in series it includes an allowance for transfers between these. Note the high security reserve account type includes provision for delivery losses and consequently the methodology in Source includes provision for transfers of some water from the high security reserve account type to the TOL account to cover delivery losses associated with high security allocations;
• An accounting process is followed to determine whether any of the available storage volume is unallocated. The unallocated volume is that remaining after the following have been deducted from the active storage volume:
  • reserve required for storage losses;
  • reserve required for high security uses including an allowance for transmission losses to deliver these supplies. Note that high security use includes licensed and unlicensed uses such as town water supplies, stock and domestic replenishment diversions, high security irrigation entitlements, minimum storage releases, environmental flows, stock and domestic component of general security licences;
  • existing volume allocated to the generic system share/s;
  • existing volumes allocated to general security entitlements in this system; and
  • the volume required to be held in the system’s transmission and operation loss account.
• High security accounts are assigned an allocation based on a modeller defined relationship between percentage of the high security reserve met and allocation to accounts. The reserve set aside for high security uses is generally greater than the volume that is allocated to the high security accounts. Whilst the full reserve volume is set aside at each resource assessment prior to making an additional allocation, the accounts are only assigned an allocation on an annual basis.

In Source, there are some assumptions and limitations that apply to Continuous Accounting resource assessment systems:

• If there is more than one resource assessment system within the one Source scenario, it is assumed that they do not have any assigned storages in common. If they do have storages in common it is necessary to identify a master resource assessment system with the other system/s being assigned their allocation as part of the master system. The subsystems are credited with water through the ‘generic system share’ account type in the master system;
• It is only possible to have one ‘debit type’ (either ‘use debit’ or ‘order debit’) per Continuous Accounting system. Some other types of resource assessment system allow this timing of account debit to vary between account types. The reason for this limitation is that the TOL account is used as a holding account for outstanding orders made using all water user accounts, so to correctly track TOL, a consistent timing of debit is required; and
• It is assumed that if a use-debit Continuous Accounting system is being modelled, accounts for non-extractive environmental demands will also be managed through a use debit arrangement.

Account types

Every account type has a category, a priority, a TOL requirement proportion, a minimum TOL requirement proportion, a minimum requirement, and one or more accounts. 

Category

When modelling a Continuous Accounting system, Source recognises the following categories of account types:

• Storage Loss Reserve (SL);
• High Security Reserve (HS);
• Generic System Share (GSS); and
• General Security (GS).

There is also a hidden TOL account type, which cannot be accessed via the user interface.

An off-allocation account type may also be added to the system.

By default, Source creates one SL, two HS, one GSS and two GS account types for each Continuous Accounting system. Additional high security, GSS and GS account types can be used if required, and unused account types can be removed. 

Storage Loss Reserve

This account type is used to reserve water to cover storage losses. As such, it is associated with a single account to track water allocated to this purpose.

High Security Reserve

The high security reserve account types can be used to represent a number of uses including:

• stock and domestic (S&D);
• utilities (town water supply);
• high security irrigation licences;
• environmental flow requirements; and
• provision for losses incurred in delivering these requirements.

The reason for there being multiple high security reserve account types (e.g. the default HS1 and HS2) in Source is to accommodate a requirement in the Gwydir and Namoi water sharing plans (NSW Government, 2006; 2009) that utilities and S&D use should be met prior to allocating to high security irrigation licences. In this case, account type HS1 is intended to be used for modelling utilities and S&D use and HS2 is intended to be used for modelling high security irrigation licences. If multiple account types are used, the total required high security reserve for the system needs to be separated into two components which reflect the uses within each account type.

To implement the requirements above, each high security account type is associated with a reserve account, and a set of water user accounts to model high security access licences.The function manager is used to specify the reserve requirement, so Source is able to model situations in which it varies.

Importantly the water allocated to High Security accounts is a seperate accounting system maintained by the HS account type. It is not counted against the water in the system. Water borrowed from a HS account is actually borrowed from the HS account type. This prevents double counting of the water allocated to High Security.

Generic System Share

The Generic System Share (GSS) is a flexible account type that may be used for a number of purposes. The GSS can be linked to another Resource Assessment System where accounts associated with the GSS can be defined. However, the GSS itself only has one account in the Resource Assessment system it resides in. More than one GSS can be used in a given Resource Assessment System if required.

This account type has been developed with the requirements for modelling the accounting systems in the Namoi in mind. The Upper Namoi uses an Annual Accounting system while the Lower Namoi uses a Continuous Accounting system, and the two are linked. For modelling, the Upper Namoi general security entitlements could be represented as a separate Resource Assessment System that is linked to the Continuous Accounting Resource Assessment System which operates in the Lower Namoi through the GSS. The GSS approach can also be used in modelling systems with private irrigation districts.

General Security

This account type is designed to model general security access licences. It can be associated with multiple water user accounts.

Transmission and operation loss (TOL)

This hidden account type is associated with a single account, used to track TOL for all other account types except the Storage Loss Reserve (which has no TOL). The TOL account is also used as a holding account for outstanding orders. This means that in an order-debit system the TOL account is credited for the outstanding order, and debited when the ordered volume is released from storage. In use-debit systems, the storage release occurs before the water use is accounted for, so the TOL account is deducted for the release to meet the order before it is credited for the water supplied to the end-user.

Priority

An account priority is used to resolve priorities within a given category. Allocation is from lowest to highest, borrowing is from highest to lowest.

Priorities should be unique.

Different components of an account type can have differing allocation priorities as minimum requirement is prioritised over full requirement. See Model phase: Resource assessment and Water accounting for more details.

TOL requirement and TOL minimum requirement proportions

When water is allocated to an account type additional TOL may be required.

This is broken down into two requirements; the full TOL requirement (TOL requirement) and the minimum TOL requirement.

The requirement is normally specified as a proportion of the water allocated, but a linear function can be specified.

TOL minimum requirement must be no more than TOL requirement.

Note that while the proportions may be specified for all Account Types, SR and TOL do not incur TOL and so do not use the requirement.

HS accounts do have TOL, but the TOL is deducted from the HS reserve. The HS reserve itself does not have TOL, because the reserve above the account allocations is not intended to be used except later when allocated to a HS account.

For all account types, including any linked GSS accounts, the TOL is used as a holding account for orders for which releases have not yet been made. This occurs even if the percentage of entitlement volume specified is zero.

Minimum requirement

If the account type is a reserve it may specify a minimum requirement, and water will be borrowed from other accounts to meet this requirement.

Non reserves have an effective minimum requirement of zero.

Allocation to accounts

Allocation is made to each account type in order of priority (illustrated in Figure 1). Each account type’s requirement is fully met before any water is allocated to the next account type in the priority sequence. In use-debit systems, outstanding releases (to meet orders) are not included in the water available for allocation.

If it is not possible to meet the reserve requirements plus existing allocations in the GSS and General Security accounts then there is a shortfall. When this occurs, no further allocations to GSS or general security accounts will occur until the shortfall is made up. Hence, the reserve account balances must be equal to the required reserves before a GSS or general security resource allocation can occur.

An overview of the allocation calculations made for each account type are described in the sub-sections below. For a description of the variables used, please see the Variables Used table under Processes.

Reserve accounts (Storage Loss, High Security)

The required volumes for the reserve account types are defined by the modeller via function. An allocation to meet these requirements is made at each resource assessment time-step (see Timing of Resource assessment for a list of these occurrences). This allocation is limited by the water available in the system’s storages, and is done in the following order:

• Storage Loss Reserve: The Storage Loss Reserve Requirement function can be defined so that reserve volume varies with the storage volume, level or surface area - factors that impact evaporation, rainfall and seepage. The amount allocated to the reserve account is:

Allocation = Min(StorageLossReserveRequirement - Balance(SL Reserve), UnallocatedVolume)

• High Security Reserve Group 1 and Group 2: The High Security Reserve Requirement function can be defined to implement a number of rules, and allow the amount allocated to vary. The reserve has an allowance to cover transmission losses (TOL), so these are deducted from the allocation. The amount allocated to high security reserve accounts is therefore:

Allocation = Min(HighSecurityReserveRequirement - Balance(HS TOL) - Balance(HS reserve), UnallocatedVolume)

Once the reserve allocation is complete for the time-step, water is allocated to high security accounts. If there is an increase in the allocation for a high security account type, the TOL associated with this increase is also subtracted from its reserve account.

A minimum percentage of the required reserve that must be maintained can also be specified. The parameters used to specify these minimums are:

• Storage Loss Reserve: Minimum To Cover Storage Losses; and
• High Security Reserve Group 1 and Group 2: Required Reserve Below Which Borrowing Occurs.

If such minimum requirements are not met, restrictions are applied to (lower priority) GSS and General Security accounts. This is done through a borrow system. The lower priority accounts ‘lend’ their balance to meet the shortfall in the reserve accounts. The lending occurs in order of account type priority, ie. the total balance of accounts of the lowest priority account type (General Security) is lent before the allocation for the next priority account type (GSS) is used. The borrow is tracked, and paid back in subsequent time-steps when there is unallocated water left over after the system’s minimum TOL requirement is met. The payback occurs before any other water is allocated. Account types are paid back in order of priority (higher before lower).

High Security accounts

The per-unit share allocation for high security reserve account types is calculated at each resource assessment time-step between the start of the water year and the modeller specified date at which resource assessment ends. There are two methods of allocation that can be specified - Simulate or Time series:

Simulate allocation

The size of the allocation for a given high security reserve account type depends on the status of its reserve relative to its reserve requirement. If the high security reserve requirement is met then the maximum allocation is made; this is typically 1 ML per unit share, although the modeller can specify an alternative maximum allocation if required. If there is a shortfall in the reserve then the high security allocation will be less, as specified by the modeller (for example, see Table 1).

Table 3. Example Allocation Rules table for high security accounts

An initial allocation is made to high security accounts at the start of each water year:

Allocation = VolumePerShare • NoOfShares(account)

If this allocation is less than the maximum then an allocation assessment is made at each resource assessment time-step until such time as the maximum (or the end of the assessment period) is reached. Once the full allocation has been made it is not changed for the remainder of the water year.

If VolumePerShare > MaxVolumePerShare

Allocation = (VolumePerShare - MaxVolumePerShare) • NoOfShares(account)

Otherwise Allocation =0

Time series allocation

This is sometimes referred to as ‘forced allocation’. A function is used to determine the volume to be allocated per share. The full allocation occurs at every resource assessment time-step. The amount to credit each account’s balance is:

Allocation = VolumePerShare • NoOfShares(account)

Generic system share account

The GSS account allocation is performed at every resource assessment (see Timing of Resource assessment for a list of these occurrences). The volume allocated is calculated using a function defined by the modeller, and limited by the remaining active storage volume available after the requirements of higher priority account types have been fully met. The GSS account is not deducted for usage, even if it is associated with another Resource assessment system. If the GSS account is used to represent allocation to another Resource assessment system, accounts are set up in that system and credited and debited according to its rules. See the Scientific Reference Guide entry on the relevant Resource Assessment System.

General security

General security accounts receive an additional allocation at each resource assessment where there is unallocated available water after all other requirements are met (including TOL). The amount allocated to each account is limited by the account’s maximum balance. There are two methods of allocation that can be specified - Simulate or Time series:

Simulate allocation

The available water is allocated to individual water user accounts in proportion to account shares:

Allocation = UnallocatedVolume • NoOfShares(account)/TotalRemainingShares

Time series allocation

This is sometimes referred to as ‘forced allocation’. A function is used to determine the volume to be allocated per share. Any water remaining after each account is filled to its maximum balance is then distributed to other accounts in proportion to their number of shares:

ForcedAllocation= VolumePerShare • NoOfShares(account)

Allocation = Min(ForcedAllocation, MaxBalance(account) - Balance(account)

Spill = ForcedAllocation - Allocation

If Spill > 0 at the end of these calculations, the account has ‘spilled’ (reached its maximum balance). The simulated allocation method is used to distribute this water (where UnallocatedVolume = Spill) to other accounts in proportion to their number of shares. The redistribution continues until there is either no remaining resource or all accounts are full (in which case there would be a physical spill).

Transmission and operational loss (TOL) account

The modeller specifies the share of the allocation to assign to TOL for High security, Generic System Share and General security account types during model configuration. When an allocation is made to accounts of these types during resource assessment, the TOL’s share of the account balance is reassigned to the account type’s TOL account to cater for delivery losses associated with use of the allocation. The TOL share can vary depending on the volume allocated to the account type. This allows the model to replicate operator behaviour in dry periods: when allocations are low a higher TOL share is applied during resource assessment. The table lookup function for each account type’s TOL Share table uses interpolation between entries but does not extrapolate beyond the last entry.

High Security and Generic System Share Accounts

In the case of high security account allocation, the TOL requirements are included in the reserve. For this reason, the full TOL share is always added to the TOL balance when a high security account type allocation is made. It is also always allocated when assigning water to the Generic System Share account, regardless of whether there is sufficient available water to meet the TOL requirement. The amount credited to TOL during allocation to each of these account types is therefore:

Allocation(TOL) = TOLShare(account type) • Allocation(account)

General Security Accounts

The Continuous Accounting system’s total TOL requirement is determined prior to calculating the allocation to General Security accounts. In an order-debit system, the outstanding release for a time-step is added to the TOL requirement during resource assessment to set aside water for this purpose. The amount allocated to meet the TOL requirement is deducted from the water available for allocation to General Security accounts:

TOLRequirement = Sum for all account type’s accounts of TOLShare(account type) • Balance(account)

If the Continuous Accounting system is order-debit,

TOLRequirement= TOLRequirement + OutstandingReleases

Allocation = Min(UnallocatedVolume, TOLRequirement - Balance(System TOL account)

Debiting accounts

The simulated evaporation and seepage from the storage is debited from the storage loss reserve account type during the flow phase.

Water user accounts (High and General Security)

The approach to debiting water user accounts depends on whether an order debit system or a use debit system is in use. For order debit systems the account is initially debited during the order phase based on the order placed at the point of extraction. If there is a shortfall in delivering the ordered volume the difference is credited during the flow phase. For use based debiting of accounts, the account is debited after the ordered water is supplied at the ordering location in the flow phase.

Generic system share account

This account is not debited.

Transmission and operation loss (TOL) account

Transmission and operating losses incurred in delivering orders to water users via releases from storage are debited from the TOL account. The debit equals the size of the allocated release (to meet the total downstream order).

TOL Accounting

In addition to allowing for losses, the TOL account is an integral part of water accounting in the model. This works differently for an order debit system and a use debit system.

Order debit system

During order placement (in the order phase), the volume required (and for which an order will be placed) at the water user’s Supply Point node is credited to the TOL account at the same time as it is debited from the ordering water user account:

Balance(account) = Balance(account) - Required(account)

Balance(account type’s TOL) = Balance(account type’s TOL) + Required(account)

In the flow phase of the same time-step, the allocated (ordered) release is debited from the TOL account to indicate that the water reserved to cater for TOL is no longer in storage:

Balance(account type’s TOL) = Balance(account type’s TOL) - ReleasedOrder

The combined impact of these calculations is that the TOL account’s balance is reduced by the difference between the total volume of order at downstream Supply Point nodes and the release made to meet this order - ie. the volume lost in transmission/operation:

TOL Adjustment = TotalOrder - ReleasedOrder

Use debit system

As for an order-debit system, the TOL account is debited in the flow phase for the storage release to meet the downstream order:

Balance(account type’s TOL) = Balance(account type’s TOL) - ReleasedOrder

In a use-debit system, accounts are debited for regulated (ordered) flow used (extracted, or just delivered for in-stream requirements). Once the regulated flow is delivered to and used at the Supply Point node, the TOL account is recredited for the usage:

Balance(account) = Balance(account) - RegulatedUse(account)

Balance(account type’s TOL) = Balance(account type’s TOL) + RegulatedUse(account)

The calculations above transfer the order temporarily held against the TOL account back to the water user. The amounts debited and credited to the TOL account differ by the losses incurred between the storage and the water user, minus any shortfall in demand between when orders were placed and the water was required. The overall TOL adjustment is therefore:

TOL Adjustment = TotalRegulatedUse - ReleasedOrder

As the TOL account is used to cover outstanding orders as well as TOL in a use-debit system, a temporary shortfall may occur in its allocation may occur. This does not have any effective impact on the operation of the Continuous Accounting system, as it the TOL account balance is simply set to zero as a minimum (no limitations are placed on the release). It simply means that in this case the sum of account balances temporarily does not match the system’s share of the physical active storage volume. The modeller can increase the size of the TOL Share assigned to each account type to avoid this situation.

Account allocation and Usage restrictions

General security accounts in a Continuous Accounting system may be subject to maximum account balance limits. The maximum allowable account balance establishes how much water an account can accumulate at any one time. For example, in the Namoi and Gwydir systems general security accounts have a maximum allowable account balance of 2 ML and 1.5 ML per unit share respectively.

The maximum allowable account balance comes into effect during the resource assessment phase; if a new allocation causes the maximum to be exceeded the excess is shared among remaining accounts.

In addition, to allow for the management of the total use of water in a system the Continuous Accounting framework has provision for usage limits on general security accounts (caps on usage) which may limit orders regardless of a water user’s account balances. In Source, one year and multi-year cap balances, and also a moving window cap balance, can be modelled. Usage limits are specified at the account type level (i.e. one value applicable across all general security accounts in a given resource assessment system) but the limits are applied to water user accounts individually. For example, general security accounts in the Namoi and Gwydir systems are subject to the following usage limits:

• no more than 1.25 ML per unit share can be ordered in any one water year; and
• no more than 3 ML per unit share can be ordered over any three consecutive water years.

The usage limits come into effect during the order phase. If the order placed by a water user in the current time-step will result in their usage limit being exceeded then their order is reduced such that the limit is not exceeded.

In an order debit system, the usage limit is assumed to be based on orders which have been met (ie. no shortfall occurred). In a use debit system, the usage limit is assumed to be based on extractions (or ordered flow delivered for in-stream requirements). For both cases, the usage limit is updated in the flow phase. In addition, outstanding orders are accounted for when checking the remaining balance in the usage limit.

Processes

Table 4 shows the variables used for continuous accounting in Source.

Table 4. Variables used

Model phase: Resource assessment and Water accounting

Every time step, whether an allocation timestep or not, the following steps are then performed in order, with the requirement that unallocated water may never be reduced below zero.

1. Allocate unallocated water to TOL account until TOL account meets the minimum TOL requirement
2. Borrow available water from accounts to TOL account until TOL account meets the minimum TOL requirement
3. Payback accounts in priority order
4. Allocate unallocated water to TOL account to meet TOL requirement
   
   If the time step is also an allocation time step (see Timing of Resource Assessment), and the TOL account meets the minimum TOL requirement then the following additional steps are performed:
5. Allocate unallocated water to Storage Reserve
6. Allocate unallocated water to High Security Reserves in priority order
   
   If there was sufficient unallocated water to fill all reserves we then do steps 11 on, otherwise we do steps 7 through 10 and mark that there was a shortfall (and thus that next time step will also be an allocation time step)
7. Transfer water from TOL account to Storage Reserve until TOL account falls to minimum TOL requirement
8. Transfer water from TOL account to High Security Reserves in priority order until TOL account falls to minimum TOL requirement
9. Borrow available water from accounts to Storage Reserve until Storage Reserve reaches the minimum requirement
10. Borrow available water from accounts to High Security Reserve until Storage Reserve reaches the minimum requirement
11. All High Security Reserves allocate water to High Security accounts.
12. Allocate water to GenericSystemShare
13. Allocate water to General Security in priority order

While it would be helpful to think of the system as have prioritised account types, the fact that there are minimums, maximums, borrows and sub-accounts of different priority makes this difficult. Even following the algorithm presented above is difficult as there can be complicated interactions; for example water paid back in step 3 may be immediately borrowed in step 7. The most useful way to view the system is as a series of prioritised constraints (from top to bottom) as follows: