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

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

• Storage Loss Reserve (SL);
• High Security Reserve Group 1 (HS1);
• High Security Reserve Group 2 (HS2);
• Generic System Share (GSS); and
• General Security (GS).

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

By default, Source creates one of each of these account types for the Continuous Accounting system. Additional high security, GSS and GS account types can be used if required. An off-allocation account type may also be added to the system. The HS1, HS2 and GS account types can have associated accounts in the Continuous Accounting system.

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 two high security reserve account types (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 the two 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 expression editor is used to specify the reserve requirement, so Source is able to model situations in which it varies.

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.

Timing of resource assessment

Allocations to reserve Continuous Accounting system’s account types occur as follows:

• At the first time-step;
• At the start of the water year;
• At each resource assessment timestep, as defined by the modeller via the Time-steps per Assessments parameter; and
• If there was a shortfall in meeting the requirements of any of the Storage Loss or High Security reserve account types at the previous time-step.

Resource categories and allocation priority

The Continuous Accounting system’s total storage volume may be divided into a number of the allocation categories. For the default settings the categories are as illustrated in Figure 1. Note that the horizontal layering is used to indicate the allocation sequence (starting at the bottom) and does not hold any physical relevance.

The modeller can specify a percentage of entitlement volume which is to be allocated to the transmission and operation loss account (TOL). 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.

Unallocated active storage volume may occur due to storage inflow or due to deductions from accounts being greater than releases (this will occur when releases are smaller than orders, with the difference expected to be made up by forecast downstream tributary inflows).

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 expression. 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 expression 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 expression 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 Group 1 and 2 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’. An expression 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 an expression 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’. An expression 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

An overview of the continuous accounting resource assessment method is illustrated in Figure 2. Note that at each time-step, the TOL account is evaluated to ensure that it is greater than the required minimum and borrowed water is paid back when there is unallocated stored water. Depending on the assessment interval defined by the modeller, assessment of account allocations may not be required at every time-step.

This checks that there is sufficient active storage volume to meet reserve and TOL requirements, ie.:

 ActiveStorage < SL Reserve Requirement + HS Reserve Requirement + GSS TOL Requirement + GS TOL Requirement

If not, Source logs an error in the Log Reporter.

Triggers

In this step, the Continuous Accounting system’s triggers are executed. In the current version of Source, the modeller cannot specify any triggers for this type of resource assessment system. The standard trigger is therefore executed, which does the following:

• If the current time-step is the start of the water year, the TotalUsageWaterYear value is reset to zero;
  • Usage limits are checked: If the current time-step is at the start of a new usage limit period (specified by the modeller), the value is reset. Usage limit resetting is applicable to general security accounts. It occurs as follows:
  • If an annual usage limit (cap) is specified then the cap balance for each user is reset to the specified limit at the start of each water year;
  • If the cap (usage limit) is specified for n water years, then the cap balance for each user is updated at the start of the water year. The balance is reset to the usage limit for n water years minus the total actual usage for the previous n-1 water years. If an order debit system is in operation then the total actual usage is equal to the sum of the orders met over the past n-1 water years; if a use debit system is in operation then the total actual usage is equal to the total volume extracted over the past n-1 water years.
  • If the cap is specified for a moving window of n time-steps then the usage limit is updated on a rolling basis, as described in the Accounts section in the Model Phase: Flow Distribution section.

Assign minimum TOL requirement

The TOL balance is not allowed to fall below a minimum volume; defined by the modeller as a proportion of allocations (it could be zero). If it falls below the minimum requirement then, at the start of the resource assessment phase, it is increased to the minimum firstly through using unallocated available volume and then, if necessary, by borrowing from water user accounts. Borrowing starts with the lowest priority account type in the system. The amount borrowed is distributed in proportion to the users’ account balances and the borrowings are tracked as a debt against each user’s account balance for later payback (see Payback section below).

In an order debit system, the TOL balance may include outstanding releases. The TOL volume in excess of outstanding releases is compared to the minimum requirement.

This process is described in the steps below:

1. The Minimum TOL Requirement is calculated. This is the sum of the minimum TOL share specified by the modeller for each HS, GSS and GS account type in the Continuous Accounting system;
2. The Minimum TOL Requirement is compared to the Current TOL allocation:
   • If the system is order-debit,

Current TOL Allocation = Balance(TOL System) - Outstanding Releases

• • If the system is use-debit

Current TOL Allocation = Balance(TOL System)

1. If the Minimum TOL requirement > Current TOL allocation, more water is allocated to TOL: TOLRequired = Minimum TOL Requirement - Current TOL Allocation
   • If the current UnallocatedVolume > TOLRequired, the requirement can be met using unallocated water:
     • If the system is order-debit,

Balance(TOL System) = Minimum TOL Requirement + Outstanding Releases

• • • If the system is use-debit

Balance(TOL System) = Minimum TOL Requirement

UnallocatedVolume = UnallocatedVolume - TOLRequired

• • Otherwise, there is insufficient water available. All unallocated water is assigned to TOL, then water allocated to water user accounts is borrowed by (temporarily redistributed to) the TOL account:

Shortfall = Minimum TOL Requirement - Current TOL Allocation - Unallocated Volume

Balance(TOL System) = Balance(TOL System) + UnallocatedVolume

UnallocatedVolume = 0

For each water user account type, from lowest to highest priority:

• • If the TotalBalance( account type) > 0

For each water user account of the current account type:

Borrow = Min(Balance(account),
Shortfall • Balance(account)/TotalBalance(account type))

Balance(account) = Balance(account) - Borrow

OwedTo(account) = OwedTo(account) + Borrow

Balance(TOL account) = Balance(TOL account) + Borrow

• • • If the system is order-debit,

Current TOL Allocation = Balance(TOL System) - OutstandingReleases

• • • If the system is use-debit

Current TOL Allocation = Balance(TOL System)

Shortfall= Minimum TOL Requirement -Current TOL Allocation

• • • If Shortfall ≤ 0, the borrow/redistribution process finishes

Payback Borrow

During this process, TOL requirements are met, and if there is remaining unallocated water, this is used to pay back any water borrowed to satisfy the minimum TOL or SL and HS reserve requirements.

Payback to account types is made in order of highest to lowest priority (the reverse of the borrow order). Water is distributed to the individual accounts within this account type in proportion to their amount owing. If all borrowed water can be paid back for accounts in the highest priority account type, and there is unallocated storage volume remaining, then payback for accounts in the next highest allocation priority is commenced. This process continues until either all the unallocated storage volume is distributed or all debts are settled.

The payback steps are:

1. The TOL Requirement is calculated. This is the sum of the TOL share specified by the modeller for each HS, GSS and GS account type in the Continuous Accounting system;
2. Unallocated water is first assigned to meet any remaining TOL Requirement:
   • If Current TOL Allocation < TOL Requirement
     • If the system is order-debit,

Allocation = TOL Requirement - Balance(TOL System) - Outstanding Releases)

• • • If the system is use-debit

Allocation = TOL Requirement - Balance(TOL System)

Balance(TOL System) = Balance(TOL System) + Allocation

UnallocatedVolume = UnallocatedVolume - Allocation

1. The total amount owing Total Owed System is determined by accumulating for all accounts in the Continuous Accounting system OwedTo(account).

• While Unallocated Volume > 0, and the value of Total Owed System is changing:

For each HS, GSS and GSS account type, from the highest to the lowest priority:

• • The total amount owing to all accounts of the account type is accumulated - TotalOwedTo(Account Type)
  • For each account of the current account type, the payback is made:

Payback = Min(OwedTo(account), Unallocated Volume • OwedTo(account)/TotalOwedTo(Account Type)

Balance(account) = Balance(account) + Payback

OwedTo(account) = OwedTo(account) - Payback

UnallocatedVolume = UnallocatedVolume - Payback

Total Owed System is recalculated (as per step 3).

Allocation time-step

See Timing of Resource Assessment for a description of time-steps in which this occurs.

Resource allocation

If the time-step is a resource allocation time-step, and there is water remaining after TOL and Payback requirements are met, this water is then allocated as outlined in Figure 3:

The principles of how allocations to the storage loss (SL) and high security (HS) reserve accounts are modelled are described in the section on Allocation to Accounts. The specific steps are:

• The specified share of TOL is allocated to each High Security account type:

Balance(TOL HS) = TOLShare(HS account type) • TotalBalance(HS account type)

• The Storage Loss Reserve account’s allocation is increased to meet the modeller specified requirement:

Requirement(SL Reserve) = result of the specified Storage Loss Reserve Requirement
expression

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

Balance(SL Reserve) = Balance(SL Reserve) + Allocation

UnallocatedVolume = UnallocatedVolume - Allocation

• The allocation to each High Security account type’s reserve account is increased to meet the modeller specified requirement. The account type’s TOL is excluded from this allocation:

For each High Security account type:

Requirement(HS account type) = result of the specified High Security Reserve Requirement expression

Allocation = Min(UnallocatedVolume, Requirement(HS account type) - Balance(TOL HS) - Balance( HS Reserve))

Balance( HS Reserve ) = Balance( HS Reserve ) + Allocation

UnallocatedVolume = UnallocatedVolume - Allocation

• All the reserve account balances are compared to their modeller specified minimum requirement to determine whether there is a shortfall.
• The minimum requirement for the storage loss reserve account is:

MinRequirement(SL Reserve) = Minimum To Cover Storage Losses % • Requirement(Storage loss)

The minimum reserve requirement for each high security account type is:

MinRequirement(HS reserve) = Required Reserve Below Which Borrowing Occurs % x Requirement(HS account type)

If there is a shortfall in any of the reserve accounts, a flag is set to indicate that a resource assessment is required in the next time-step.

• The shortfall for each of the reserve accounts (SL, HS1 and HS2) is calculated as:

Shortfall(reserve account) = Max(0, MinRequirement(Reserve type) - Balance(reserve account))

• Water is ‘borrowed’ from water user accounts to meet any reserve account shortfalls:

For each reserve account type, in order of descending priority (SL, HS1, HS2):

For each water user account type in order of ascending priority,

For each water user account of the current water user account type:

Borrow= Min(Balance(account), Shortfall(reserve account) • Balance(account)/TotalBalance(account type))

Balance(account) = Balance(account) - Borrow

OwedTo(account) = OwedTo(account) + Borrow

Shortfall(reserve account) = Shortfall(reserve account) - Borrow

Balance(reserve account) = Balance(reserve account) + Borrow

High security allocation

This section applies to all high security account types; allocations to accounts in the highest priority high security account type (HS1) are made first, followed by allocations to accounts in the lesser priority high security account types as necessary. The method used depends on whether the modeller specified Time Series or Simulated allocation:

Time series allocation

Steps for each account type are as follows:

• The account type’s per-share allocation is determined:

VolumePerShare = result of modeller specified Allocation to accounts expression

• For each account of the account type:
  • The full allocation is calculated and added to the account balance:

Balance(HS account) = Balance(HS account) + (VolumePerShare • NoOfShares(HS account))

• • The account’s TOL share is added to the account type’s TOL, and subtracted from its reserve:

TOL = TOLShare(HS account type) • Balance(HS account)

Balance(TOL HS) = Balance(TOL HS) + TOL

Simulated allocation

Steps for each account type are as follows:

At the start of each water year:

• The account type’s percentage of the reserve requirement that has been met is determined - if this is less than 100%, a warning is logged

PercentageMet = Balance(HS reserve) / MinRequirement(HS reserve)

• The account type’s per-share allocation is determined:

VolumePerShare = Interpolated HS Allocation value from the account type’s Allocation Rules table. The values interpolated are those for the two rows where PercentageMet falls between HS Reserve% values

• For each account of the account type:
  • The full allocation is calculated and added to the account balance:

Balance(HS account) = Balance(HS account) + (VolumePerShare • NoOfShares(HS account))

• • The account’s TOL share is added to the account type’s TOL, and subtracted from its reserve:

TOL = TOLShare(HS account type) • Balance(HS account)

Balance(TOL HS) = Balance(TOL HS) + TOL

Balance(HS Reserve) = Balance(HS Reserve) - TOL

• The account’s maximum allocation for the year is set to the current per share allocation:

MaxVolumePerShare(account) = VolumePerShare

For all other time-steps

• The account type’s percentage of the reserve requirement that has been met, and the per-share allocation is determined in the same way as for the start of the water year.
• For each account of the account type where VolumePerShare > MaxVolumePerShare(account), an incremental allocation is made:
  • The incremental allocation is calculated and added to the account balance:

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

Balance(HS account) = Balance(HS account) + Allocation

• • The associated increment in TOL is added to the account type’s TOL and subtracted from its reserve:

TOL = TOLShare(HS account type) • Allocation

Balance(TOL HS) = Balance(TOL HS) + TOL

Balance(HS Reserve) = Balance(HS Reserve) - TOL

• • The account’s maximum allocation for the year is set to the current per share allocation:

MaxVolumePerShare(account) = VolumePerShare

Generic system share allocation

The generic system share (GSS) allocation is updated only if the SL and HS reserve requirements have been met. The method used depends on whether the modeller specified Time Series or Simulated allocation:

Time series allocation

In this method, a full allocation to meet the specified requirement is always made (forced). Steps for each account type are as follows:

• The allocation is calculated and added to the GSS account balance:

Allocation = result of modeller specified expression

Balance(GSS account) = Balance(GSS account) + Allocation

• The GSS TOL balance is updated

Balance(TOL GSS) = Balance(TOL GSS) + TOLShare(GSS account type) • Allocation

Simulated allocation

Updating is based on using remaining unallocated storage volume available, if any, to meet the specified requirement. The steps are:

• The remaining unallocated volume is determined:

UnallocatedVolume = Max(0, ActiveStorageVolume - (Balance(TOL system) + Balance(SLReserve) + ∑Balance(HS Reserve) + ∑TotalBalance(GSS account type) + ∑TotalBalance(GSaccount type))

If the system is use-debit,

UnallocatedVolume = Max(0, UnallocatedVolume - OutstandingRelease)

• The allocation is calculated and added to the GSS account balance:

Allocation= Min(UnallocatedVolume, result of modeller specified Generic System Share expression)

Balance(GSS account) = Balance(GSS account) + Allocation

• The GSS TOL balance is updated in the same way as for Time Series Allocation.

Generic security allocation

At the interval specified by the modeller, unallocated water remaining after allocation to higher priority account types is allocated to general security accounts. The method used depends on whether the modeller specified Time Series or Simulated allocation:

Time series allocation

In this method, a full allocation to meet the specified requirement is forced - but as GS accounts can have a maximum balance, this may place a limitation on the allocation. Where this occurs, the ‘spill’ is redistributed to other accounts that can take it, in proportion to their number of shares. Steps for each account type are as follows:

For each GS account of the current account type:

• The allocation is calculated, and the account balance updated

ForcedAllocation= VolumePerShare • NoOfShares(GS account)

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

Balance(GS account) = Balance(GS account) + Allocation

Spill = ForcedAllocation - Allocation

• The GS TOL balance is updated for the allocation:

Balance(TOL GS) = Balance(TOL GS) + TOLShare(GS account type) • Allocation

• Any ‘Spill’ is redistributed to accounts with room (see the steps under the next heading).

Re-distribution of ‘spill’

• The AvailableWater is set to equal Spill
• While account(s) remains unfilled, and AvailableWater > 0, this is redistributed to the account(s) with room:

TotalRemainingShares = ∑ NoOfShares for accounts with Balance(account) < MaxBalance(account)

For each GS account of the current account type:

Allocation = Min(MaxBalance(account) - Balance(account), Spill • NoOfShares(account)/TotalRemainingShares)

Balance(account) = Balance(account) + Allocation

TotalRedristributed = TotalRedistributed + Allocation

AvailableWater = AvailableWater - TotalRedistributed

Simulated allocation

Updating is based on using remaining unallocated storage volume available, if any, to meet the specified requirement. The steps are:

• The remaining UnallocatedVolume is determined in the same way as it is for GSS account type’s Simulated Allocation method (see step 1).
• If UnallocatedVolume > 0, the system’s TOL requirement is determined:

TOLRequirement = Sum for all accounts in the system, TOLShare(account type) • Balance(account)

If the Continuous Accounting system is order-debit,

TOLRequirement= TOLRequirement + OutstandingReleases

• The system TOL requirement is compared to the system TOL balance:
  • If Balance(TOL System) < TOLRequirement , some or all of the unallocated volume is used to meet the requirement:

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

Balance(TOL System) = Balance(TOL System) + Allocation

UnallocatedVolume = UnallocatedVolume - Allocation

• • If Balance(TOL System) > TOLRequirement, the extra TOL allocation is made available to general security accounts:

Difference = Balance(TOL System) - TOLRequirement

Balance(TOL System) = Balance(TOL System) - Difference

UnallocatedVolume = UnallocatedVolume + Difference

• The water available for allocation to the general security account type is determined:

AvailableWater = UnallocatedVolume/(1+TOLShare(GS account type)

• If the account type’s TOL share is not static (ie. is a modeller specified linear function), iteration is used to converge on the right split between the account’s share of the allocation and the TOL share:

TOLVolume = Balance(TOL GS) + AvailableWater • TOLShare

NewTOLShare = result of specified TOLShare function for this value of TOLVolume

NewAvailableWater = UnallocatedVolume/(1+NewTOLShare)

If NewAvailableWater - AvailableWater > tolerance

This step is repeated with AvailableWater = NewAvailableWater, TOLShare = NewTOLShare

Once this process is complete, AvailableWater = NewAvailableWater

• The GS account type’s TOL balance is updated:

Balance(TOL GS) = Balance(TOL GS) + TOLShare(GS account type) • AvailableWater

• Any ‘spilled’ water (unused account allocation) is redistributed to other accounts. See the previous heading for a description of this method. At the end, the remaining AvailableWater can be used for the next GS account type (if there is one).

Model phase: Ordering/Demand management

During the ordering phase each ‘account sharing’ Water User needs to know how much water is available in their accounts. An ‘account sharing Water User’ in this context is a model component in Source that can order and/or use water, and track this usage via a set of accounts. A ‘Supply Point’ refers to the model component that represents the location of the water use in the scenario network. Currently only the Supply Point node performs this function.

If the Water User has more than one account (eg. a high security account and a general security account) the account, the way in which the requirement is assigned to accounts depends on modeller specified settings at the Water User.

The amount of a Water User’s time-step requirement that can be assigned to each account is limited by the account balance and cap balance (in the case of general security accounts). Cap balance refers to the difference between the usage limit and the usage that has occurred, for general security accounts. Where multiple usage limits have been defined, the minimum cap balance of the two is used.

In an order debit system, an account is debited when a part of a Water User’s requirement is ‘committed’ (assigned) to the account and a particular Supply Point node in the Ordering Phase of each time-step. The account is debited by this committed volume, NOT the order placed at the Supply Point (which may be associated with multiple accounts and include an over order factor).

The steps in this phase are therefore:

• The Continuous Accounting system’s account balances at the start of the ordering phase are recorded;
• The scenario’s network is processed from the downstream end to the upstream end, with orders generated at ordering nodes. The Supply Point generates orders as requested by the Water User, which interacts with the RAS in which it holds accounts. The basic steps in this interaction are outlined below:
  • The Supply Point requests a list of its requirements from its connected water user node;
  • If the Water User has not created a list of requirements this time-step, it does the following for each time-step ft from the current one to the maximum order time (order time is described in this Scientific Reference Guide’s entry on the Rules Based Ordering System):
    • The Water User’s total requirement for the time-step ft is determined, which includes any opportunistic requirement to fill an on-farm storage (if there is one);
    • Time-step ft requirements are distributed to accounts in priority order. Each account is assigned a proportion of the remaining requirement based on its share of the total shares held at the Water User by all accounts. The amount assigned to each account is also limited by the account’s available balance, which is calculated as:

AvailableBalance(account) = Min(Balance(account), CapBalance(account, *smallest usage limit)) - OutstandingOrders(account)

• • • Each account’s time-step ft requirement is distributed to Supply Points associated with the account that have a minimum order time < ft (ie. that can deliver the water in time).

The Supply Point’s requirement Required(account, SupplyPoint, ft) is its share of the account’s requirement that can be met using its estimated capacity in the time-step.

If the account is order-debit, its requirement that is due in the assigned Supply Point’s minimum order time is debited from the account’s balances. For a Continuous Accounting system account, see the section on Account Debit Process (that follows the flow distribution phase description). In this case the usage to debit, Usage(account), equals Required(account, SupplyPoint, ft).

• • • The Supply Point creates a new order due in its maximum order time that is for the total of all requirements assigned to it.

Order(SupplyPoint, maxOrderTime) = ∑Required(account, SupplyPoint, maxOrderTime)

• The total volume to be released to meet orders at all the Continuous Accounting system’s storages is added to its outstanding release volume - OutstandingReleases.

Model phase: Flow distribution

The following steps are performed by Continuous Accounting systems in each time-step’s flow distribution phase:

• The system’s storage losses are estimated and deducted from the storage loss reserve account:

SystemStorageLoss = Sum for all the Continuous Accounting System’s storages of:

System%(storage) • (NetEvaporation(storage) + Infiltration(storage)

Balance(SL Reserve) = Max(0, Balance(SL Reserve) - SystemStorageLoss)

• The volume of the release this time-step allocated to meet orders placed using the system’s accounts are deducted from TOL, and the outstanding releases total is updated:

ReleasedOrder = Sum for all the Continuous Accounting System’s storages of:

System%(storage) • ∑ReleasedOrder(outlet path)

Balance(TOL system) = Balance(TOL system) - ReleasedOrder

OutstandingReleases = OutstandingReleases - ReleasedOrder

• Order-debit accounts are re-credited for the difference between their order due and their share of delivered flow (ie. the account’s shortfall). This allocation is returned from the TOL account:

For each water user account in the Continuous Accounting system:

Balance(account) = Min( Balance(account) + Shortfall(account), MaxBalance(account))

TotalDeliveryShortfall = TotalDeliveryShortfall + DeliveryShortfall(account)

Balance(TOL system) = Balance(TOL system) - TotalDeliveryShortfall

During this phase, the scenario network is processed from upstream to downstream. Each of the Supply Points interact with their connected Water User. If the Water User is ‘account sharing’, account updates are made according to the amount of flow delivered. The processes are described in detail in this Scientific Reference Guide’s entries for the Supply Point Node and Water User Node. The basic steps performed for each Supply Point are described below, with details given for interactions with Continuous Accounting systems:

• The current order due at the Supply Point is determined for the time-step. This order may be smaller than the original order placed for this time-step - this is known as the order shortfall. There may also be ‘opportunistic’ water available in excess of opportunistic demand. The order shortfall and excess opportunistic water is used to reduce the order assigned to accounts - represented here as the ReducedOrder(account) volume.
• The Supply Point’s volume of flow arriving over the time-step is categorised into overbank, off-allocation, regulated and unregulated. This impacts the way it is accounted for.
• Overbank and off-allocation water is assigned first to meet orders. The volume of the order that has been supplied from this water is assigned to accounts and recorded in OrderSupplied(account).
• Regulated flow is assigned next. The use of this type of flow is accounted for. The distribution of this RegulatedFlow between each owner’s accounts is described below:
  • The amount of regulated flow required to meet the part of the reduced order that hasn’t been supplied yet is calculated:

RegulatedFlowToUse = Min(RegulatedFlow, ∑(ReducedOrder(owner account) - OrderSupplied(owner account))

• • Each of the owner’s accounts that require more supply to meet their reduced order (OrderSupplied(account) < ReducedOrder(account)) are assigned a share of the regulated flow in proportion to their share of the reduced order:

RegulatedUse(account) = (ReducedOrder(account) / ∑ReducedOrder(owner account)) • RegulatedFlowToUse

OrderSupplied(account) = OrderSupplied(account) + RegulatedUse(account)

RegulatedFlow = RegulatedFlow - RegulatedUse(account)

• The Water User debits its use-debit accounts for their regulated use. It first tries to debit its off-allocation account (if it has one). If there is any of this usage remaining to be accounted for after the off-allocation account balance is used up, it is debited from the regulated account. The way a Continuous Accounting system account is debited is described in the next section. In this case the usage to debit, Usage(account), equals RegulatedUse(account).

Account debit process

In Continuous Accounting systems, accounts are debited for usage as follows:

• The original balance is saved:

OriginalBalance(account) = Balance(account)

• The account balance is debited for the usage - not allowing the balance to be reduced below the minimum (default 0).

Balance(account) = Max(MinBalance(account), Balance(account) - Usage(account))

• The balance of any usage limits associated with the account are debited for the change in account balance:

CapBalance(account, limit) = CapBalance(account, limit) - (OriginalBalance(account) - Balance(account))

• If the account is of a high security account type, this account type’s reserve account is debited:

Balance(HS Reserve) = Balance(HS Reserve) - Usage(account)

• The requirement is added to the system’s TOL account balance and to the outstanding orders:

Balance(TOL System) = Balance(TOL System) + Usage(account)

OutstandingOrders = OutstandingOrders + Usage(account)

Input data

Details on data are provided in the Source User Guide. Requirements are summarised in the sections following.

Table 5. Continuous accounting system parameters

Parameters or settings

Key parameters and examples of values, where relevant, are described in the Theory and Structure and Processes sections above. When modelling an existing continuous accounting system, the values of parameters adopted will be dictated by rules governing the operation of the system in place. When modelling new systems or modifications to existing systems, it will be a matter of professional judgement and consultation with stakeholders as to reasonable values to explore, combined with "trial and error" solutions, to arrive at acceptable parameter values.

Output data

Output data for Resource Assessment Systems is available under the Miscellaneous menu in the Project Hierarchy. The recording manager output type is Resource Assessment and can be found near the top of the recording manager outputs.

The output data includes time series results for account types as well as individual accounts. The available outputs are defined in Tables 11 through 14.

Table 11. Recorded variables: Account types

Table 12. Recorded variables: Water user accounts

Industry Commission (1992) Water Resources and Waste Water Disposal. Report No. 26. Australian Government, Canberra. 17 July. ISBN 0 644 25500 5. Available at: www.pc.gov.au/ic/inquiry/26water

NSW Government (2006) Water Sharing Plan for the Gwydir Regulated River Water Source 2002. Current version for 1 January 2006 to date (accessed 6 October 2011 at 15:31). Available via: www.water.nsw.gov.au/Water-management/Water-sharing-plans/Plans-commenced/Water-source/Gwydir-Regulated-River/default.aspx

NSW Government (2009) Water Sharing Plan for the Upper Namoi and Lower Namoi Regulated River Water Sources 2003. Current version for 12 June 2009 to date (accessed 6 October 2011 at 15:16). Available via: www.water.nsw.gov.au/Water-management/Water-sharing-plans/Plans-commenced/Water-source/Upper-Namoi-and-Lower-Namoi-Regulated-River/default.aspx