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

Term	Definition
active capacity	The volume of water in storage minus the dead storage volume when the storage is at the full supply level.
active volume	The volume of water in storage above dead storage or the minimum operating level, but not exceeding the full supply level.
airspace	The remaining storage capacity in an account or reservoir.
High Security (HS) Reserve	The HS Reserve is a type of account used to set aside water to ensure adequate supply for both licensed and unlicensed essential use. In the Namoi, this includes the following: Town water supplies, Stock and domestic replenishment diversions, High security licence entitlements, Minimum storage releases, Stock and domestic component of general security licences, and An allowance for transmission losses to deliver these supplies. The HS account type can have zero to many accounts
Generic System Share (GSS)	A generic account type which is used to credit water to a linked resource assessment system (RAS). The GSS account type has one account (which is used as an allocated storage for a linked RAS - noting that the linked RAS may have several accounts in it)
Storage Loss Reserve	A Storage Loss Reserve Account Type is a volume of water set aside for predicted losses from the storage due to net evaporation and seepage. The Storage Loss Reserve Account type only has one account.
Transmission and Operation loss (TOL)	The TOL Account Type is used to represent the losses incurred in the process of delivering water to a user (transmission loss) and a factor of safety built into the system to avoid shortages in the system (operation loss). The TOL Account type only has one account.
Unit share	A licence holder is issued with a number of shares in the system’s available water. A single share is referred to as a unit share.
Usage limit	The amount of water that a user is allowed to take/order at the specified location over a specified period of time.

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.

Priority outside category

Example: 5 account types that all want 20 ML, with different minimums and priorities

A is a Storage Reserve account type with priority 5, minimum requirement of 10 and full requirement of 20.

B is a High Security account type with priority 3, minimum requirement of 0 and full requirement of 20.

C is a High Security account type with priority 2, minimum requirement of 0 and full requirement of 20.

D is a High Security account type with priority 4, minimum requirement of 20 and full requirement of 20.

E is a General Security account type with priorty 1 and a full requirement of 20.

Rule
SR account = SR minimum requirement	A (p=5) is allocated 10
HSR account = HSR minimum requirement	C (p=2) is allocated 0 B (p=3) is allocated 0 D (p=4) is allocated 20
SR account = SR full requirement	A (p=5) is allocated 10 (to 20)
HSR account = HSR full requirement	C (p=2) is allocated 20 (to 20) B (p=3) is allocated 20 (to 20) D (p=4) is allocated 0 (to 20)
GS account = GS full requirement	E (p=1) is allocated 20

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. See "TOL Accounting" for more details.

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.

Accounts

The purpose of a resource assessment system is to maintain a list of accounts and the water assigned to those accounts.

Each account type has one or more accounts. If the account type is a reserve (HS, SR, TOL) it will have a hidden system 'reserve' account. If it is GSS it will have one account representing another accounting system. if it has users (GS. HS) it will have accounts representing users of water.

Note that while HS has both a system account and user accounts, from the perspective of the continous accounting system it only has a reserve acccount, and the HS account type allocates water to user accounts as if it were a child resource assessment system.

An account type can have no accounts (eg a GS account with no users) but in that case will be ignored.

Accounts can have usage limits or other limits on how much water they can be assigned at any one time. No account should ever have more water than this.

Mechanisms for changing water in an account

Conceptually the volume of water assigned to a particular account can be changed using several mechanisms. For the purpose of this document those are:

Allocate: a quantity of water is added to an account and an appropriate amount of water is also added to the TOL account equal to the TOL requirement of the account type. This does not remove water from another account or reserve, but will reduce the available resource available to the allocating system (usually the continuous accounting system, but is the parent high security reserve for high security accounts).

Borrow: water is deducted from one or more lender accounts, TOL is reduced by an appropriate amount, and the sum of the water is added to the borrowing account or reserve. The amount borrowed is tracked over time. See Borrowing section for details.

Payback: water is added to an account that has previously lent water to repay the water borrowed. This requires water also be added to the TOL account equal to the minimum TOL requirement of the account type. The account's borrow account is reduced by the amount repaid (not including TOL).

Transfer: water is moved from one account to another without being tracked.

Reduce: an account is reduced by an amount

Debit: a reduction in an account that is not caused by the Resource Assessment system. e.g. evaporation in the storage is debited from the Storage Reserves

Note that this ignores Resource Assessment Triggers (not allowed in Continuous Accounting except for limiting allocation) and usage (which is covered under ordering).

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

% of reserve requirement met	High security allocation (ML/unit share)
0%	0
20%	0.4
50%	1.0
80%	1.0
100%	1.0

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.

Note: the allocation will NOT decrease in a 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

Storage loss reserve

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

Note: This may lead to a situation where the reserve is empty but the water users’ accounts have existing allocation. This situation is rectified at the next resource assessment (see the Reserve accounts sub-heading under Allocation).

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

Symbol	Purpose/Description	Units	Phase Used In
Account	Index of an account in a RAS	n/a	All
ActiveStorageVolume	Volume of water in excess of dead storage in the Continuous Accounting system’s storages at the current time-step.	volume	Resource assessment and allocation
Allocation	Amount allocated in the current allocation round	volume	Resource assessment and allocation
AvailableWater	Water available for allocation to GS accounts	volume	Resource assessment and allocation
Balance(account)	The balance (unused allocation) of the account in the Continuous Accounting system.	volume	Resource assessment and allocation, Ordering, Flow distribution
CapBalance(account, limit)	The amount of a usage cap/limit limit that has not been used by account yet.	volume	Ordering
Current TOL allocation	Current volume of water in the Continuous Accounting system that is allocated to cover transmission and operational losses (TOL), excluding OutstandingReleases if the system is order-debit.	Volume	Resource assessment and allocation
DeliveryShortfall(account)	The difference between the account’s order due for delivery in the current time-step and its share of the flow arriving at its supply point.	Volume	Flow distribution
ForcedAllocation	Volume of water to be allocated to a general security account via time series (forced) allocation	Volume	Resource assessment and allocation
ft	Timestep index - between the current one and the maximum order time	n/a	Ordering
HS 1	High security group 1 account type	n/a	Resource assessment and allocation
HS 2	High security group 2 account type	n/a	Resource assessment and allocation
HS account type	High security account type (e.g. HS1, HS2)	n/a	Resource assessment and allocation
HS reserve	Reserve account for the high security account type being processed.	n/a	Resource assessment and allocation
Infiltration(storage)	The groundwater infiltration loss volume in storage node storage over the current time-step.	Volume	Flow distribution
MaxVolumePerShare(account)	Maximum volume per share allocated to the account in previous time-steps	Volume	Resource assessment and allocation
Minimum TOL Requirement	The sum of the minimum TOL share specified by the modeller for each HS, GSS and GS account type in the Continuous Accounting system	volume	Resource assessment and allocation
MinRequirement( account type)	Account type’s allocation level below which borrowing occurs from lower priority account types. Applies to SL, HS1 and HS2 account types.	volume	Resource assessment and allocation
NewAvailableWater	New estimate of water available for allocation to GS accounts - used in iterative calculation.	volume	Resource assessment and allocation
NewTOLShare(account type)	New TOLShare value - Estimate used in iterative process or allocation to GS accounts when TOL is specified as a linear function.	%	Resource assessment and allocation
NetEvaporation(storage)	The sum of rainfall and evaporation volume (positive value is a loss) in storage node storage over the current time-step.	Volume	Flow distribution
NoOfShares(account)	Number of shares held by account in the Continuous Accounting system	n/a	Configuration, Resource assessment and allocation
OrderSupplied(account)	Volume of flow that has already been assigned at the current Supply Point to meet ReducedOrder(account) for the current time-step.	Volume	Flow distribution
OriginalBalance(account)	Balance of account before a debit takes place.	Volume	Ordering, Flow distribution
OutstandingOrders	Total volume of order placed in timesteps up to and including the current one, that has not been delivered yet.	Volume	Ordering, Flow distribution
OutstandingReleases	Volume of releases to be made in the current time-step to fulfil orders.	Volume	Resource assesment and allocation
OwedTo(account)	Volume that has been borrowed from an account and needs to be paid back when water becomes available.	Volume	Resource assessment and allocation
Payback	Volume of water available to pay back accounts that have been borrowed from.	Volume	Resource assessment and allocation
PercentageMet	Percentage of a high security account type’s reserve requirement that has been met (allocated)	%	Resource assessment and allocation
RegulatedFlow	Volume of flow at the current Supply Point that was pre-ordered.	Volume	Flow-distribution
RegulatedFlowToUse	Volume of RegulatedFlow that is required to meet the remaining order at the current Supply Point once all overbank and off-allocation flow has been used	Volume	Flow-distribution
ReducedOrder(account)	Order assigned to account to be met in the current time-step by flow at the current supply point.	Volume	Flow distribution
ReleasedOrder(outlet path)	Volume of order released on storage outlet path in the current time-step to meet downstream orders.	Volume	Flow distribution
RegulatedUse(account)	Account’s assigned share of the flow volume arriving at its Supply Point node that was ordered and due to arrive in the current time-step.	Volume	Flow distribution
ReleasedOrder	Volume of order released from storage in the current time-step to meet orders placed using accounts in the Continuous Accounting system.	Volume	Flow distribution
Reserve type	Type of reserve. Can be Storage Loss, High Security Group 1 or High Security Group 2.	n/a	Resource assessment and allocation
Required(account)	Water user’s requirement that is to be met using the resources allocated to account	volume	Ordering
Required(account, SupplyPoint, ft)	Water user’s requirement that is to be met using the resources allocated to account, and to be supplied at SupplyPoint node in time-step ft	volume	Ordering
Requirement(account type)	Volume required by accounts of account type. Applies to SL, HS1 and HS2 account types.	volume	Resource assessment and allocation
Spill	Leftover allocation after an account has reached its maximum balance - this is redistributed to other accounts. (Only applies to general security accounts).	volume	Resource assessment and allocation
SL Reserve	Storage loss reserve account type or account (This account type has a single account).	n/a	Resource assessment and allocation
System%(storage)	Percentage of volume in storage node storage assigned to the Continuous Accounting system	n/a	Flow distribution
SystemStorageLoss	Volume of storage losses incurred over the current time-step assigned to the Continuous Accounting system	n/a	Flow distribution
TOL	TOL assigned to the account currently being processed	volume	Resource assessment and allocation
TOL GS	A general security account type’s TOL account	n/a	Resource assessment and allocation
TOL GSS	A generic system share account type’s TOL account	n/a	Resource assessment and allocation
TOL HS	A high security account type’s TOL account	n/a	Resource assessment and allocation
TOL System	The Continuous Accounting system’s TOL account.	n/a	Resource assessment and allocation
TOLRequirement	The Continuous Accounting system’s total TOL requirement in the current time-step	volume	Resource assessment and allocation
TOLShare(account type)	The modeller specified TOL share for the account type.	%	Configuration, Resource assessment and allocation
TOLVolume	Current system allocation to TOL, used in iterative calculation for GS allocation when TOL share is defined as a linear function.	volume	Resource assessment and allocation
TotalBalance(account type)	The total of account balances (unused allocation) for all accounts of account type	volume	Resource assessment and allocation
TotalDeliveryShortfall	The total shortfall in delivery to all order-debit water user accounts in the Continuous Accounting system for the current time-step.	Volume	Flow distribution
TotalOrder	Total volume ordered at Supply Point nodes using water user accounts in the Continuous Accounting system in the current time-step.	volume	Ordering
RegulatedUse(account)	Account’s assigned share of the flow volume arriving at its Supply Point node that was ordered and due to arrive in the current time-step.	Volume	Flow distribution
TotalRegulatedUse	The Continuous Accounting system’s share of the flow volume ‘used’ at its Supply Point nodes that was ordered (using system accounts) and due to arrive in the current time-step.	Volume	Flow distribution
TotalRemainingShares	The sum of shares for general security accounts with a balance less than the account’s maximum	n/a	Resource assessment and allocation
UnallocatedVolume	Volume of water stored in the Continuous Accounting system that is not allocated yet	volume	Resource assessment and allocation
VolumePerShare	Volume returned by the time series allocation function specified by the modeller	volume	Configuration, Resource assessment and allocation

Model phase: Resource assessment and Water accounting

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 below is difficult as there can be complicated interactions; for example water paid back under "Payback accounts in priority order" may be immediately borrowed again under "Borrow available water from accounts to Storage Reserve". The most useful way to view the system is as a series of prioritised constraints (from top to bottom) as follows:

Constraint	Rule	Explantion
1 (most)	Available Water >= 0	The system cannot be overallocated
2	Dead Storage = Dead Storage requirement	Dead storage must be exactly equal to the dead storage requirement
3	TOL account >= TOL minimum requirement	The TOL minimum requirement must be met, but can be exceeded (Priority 7 imposes a maximum)
4	Storage Reserve account > = Storage Reserve minimum requirement	The Storage Reserve minimum requirement must be met, but can be exceeded (Priority 8 imposes a maximum)
5	In priority order p: High Security Reserve p account >=High Security Reserve p Minimum	Each minimum High Security Reserve requirements must be met, but can be exceeded (Priority 9 imposes a maximum) where there is more than one High Security Reserve treat this priority as multiple priorities based on the account type priority Note this has the side effect of water being assigned to individual high security accounts
6	In priority order p: Account p Borrow = 0	All borrowed water should be paid back where more than one account with a debt exists, pay back the water in account type priority order If mupltiple accounts exist share the amount paid back based on the account's share of the debt
7	TOL account = TOL requirement	The TOL account should exactly meet the TOL requirement
8	Storage Reserve account = Storage Reserve requirement	The Storage Reserve account should exactly meet the Storage Reserve requirement
9	In priority order p: High Security Reserve p account = High Security Reserve p requirement	Each High Security Reserve account should exactly meet its High Security Reserve requirement Where there is more than one High Security Reserve treat this priority as multiple priorities based on the account type priority Note this has the side effect of water being assigned to individual high security accounts Note also that the sub-requirement that no High Security Reserve account exceeds the maximum is hardwired in the system
10	Generic System Share = Generic System Share requirement	The Generic System Share account should exactly meet the Generic System Share requirement
11 (least)	In priority order p: General Security p = General Security p requirement	Each General Security account should exactly meet its General Security requirement Where there is more than one General Security treat this priority as multiple priorities based on the account type priority

Examples

Storage has up to 100ML, with a Dead Storage of 10ML.

There is only one General Security account, and a TOL account.

The TOL requirement is 20%, the min TOL requirement is 10%.

Example 1:

There is 49 ML in the storage, and GS has 20ML, and TOL has 0ML.

Available Water = 19 ML.

TOL is taken to 4 ML

TOL and GS are then increased in lockstep until GS = 32.5 ML and TOL is 6.5 ML

Example 2:

There is 21 ML in the storage, and GS has 30ML, and TOL has 6ML.

There is a Resource of 21 ML, and commitments of 10 ML (Dead Storage) + 30 (GS) +6 (TOL).

The available water is -25 ML.

The system has "crashed" and become invalid. GS and TOL will be reduced until available resource is 0.

First TOL is reduced to 3 ML (min TOL).

Next GS and TOL are reduced in lockstep until GS is 20ML and TOL is 2 ML.

Note this is TOL minimum, because minimising borrow (constraint 6) is prioritised over meeting TOL requirement (constraint 7) but under meeting TOL min requirement (constraint 3)

Every time step the amount of available water in the storages attached to the continuous accounting system is calculated, and commitments (primarily account type balances, but also containing external functions such as dead storage) are removed. This gives an amount of unallocated water. In rare situations overallocation (negative unallocation) may occur, though this usually indicates the system is not configured correctly. If this happens the system will Reduce the TOL account by the overallocation even if this would reduce TOL below zero.

Alt text

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.

Allocate unallocated water to TOL account until TOL account meets the minimum TOL requirement
Borrow available water from accounts to TOL account until TOL account meets the minimum TOL requirement
Payback accounts in priority order
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:
Allocate unallocated water to Storage Reserve
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)
Transfer water from TOL account to Storage Reserve until TOL account falls to minimum TOL requirement
Transfer water from TOL account to High Security Reserves in priority order until TOL account falls to minimum TOL requirement
Borrow available water from accounts to Storage Reserve until Storage Reserve reaches the minimum requirement
Borrow available water from accounts to High Security Reserve until Storage Reserve reaches the minimum requirement
All High Security Reserves allocate water to High Security accounts.
Allocate water to GenericSystemShare
Allocate water to General Security in priority order

Check Initial Balances

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.

Allocate unallocated water to TOL account to meet TOL min requirement

Water will be allocated to the TOL account until there is no more unallocated water, or the TOL minimum requirement is met.

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 through using unallocated available volume, then by borrowing (see next).

Note: TOL can be altered by delivery of water - see "TOL Accounting" for details.

Borrow water from accounts to TOL account to meet TOL min requirement

Water will be borrowed from accounts so the TOL balance meets the TOL minimum requirement. Note that borrowing from these accounts may also reduce the TOL minimum requirement, which must be taken into account.

Water will be borrowed until the TOL minimum requirement is met, or there is no more water available to borrow (which means there is no more water left in the system).

This borrowing occurs in the following order;

GS and GSS accounts; in reverse account type priority (least important first) order. Accounts of the same account type share the borrowing according to (account balance/account type balance).
Reserve accounts; reduced equally regardless of priority according to ((reserve balance - allocated accounts)/account type balance).
This means that a HS reserve will not be reduced below the point where water allocated to a HS account will be borrowed.
This is based on operator behaviour in the Namoi during extreme droughts.
The logic is that this should be a temporary state and it is better to lower all reserves (essentially reducing in the reserve horizon) rather than have one reserve at 100% and one at 50%
HS accounts: at this point water will be borrowed from HS accounts (this is actually borrowing the last water left in their HS reserve). This borrows from all accounts equally according to (account balance/all account balances)

Borrowing reduces the available balance in an account, and may not reduce the available balance of any account below zero. Debt accumulates between time steps until paid back by the system.

If this step passes the TOL balance cannot be reduced below the TOL minimum requirement for any reason during the rest of allocation.

Payback accounts in priority order

If there is still unallocated water then the system will attempt to payback water to any account with a 'Borrow' debt from the system.

Water will be paid back until there is no more unallocated water, or there is no more debt to repay.

Payback will be done in priority order. Accounts of the same account type share the payback according to (account debt/account type debt).

Allocate unallocated water to TOL account to meet TOL requirement

Water will be allocated to the TOL account until there is no more unallocated water, or the TOL requirement is met.

The TOL requirement (also known as TOL full requirement to differentiate it from TOL min requirement) will be at least equal to the TOL minimum requirement.

The TOL balance can be reduced from this level later if water is needed to meet minimum reserves.

Is this an Allocation time step?

A time step is an Allocation time step if at least one of the following conditions is true:

This is the first time-step of the run;
This time step is the start of the water year;
This is a resource assessment timestep, as defined by the modeller via the Time-steps per Assessments parameter; and
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.
Note that if the system borrowed water to raise a reserve it will still count as a shortfall.

Allocate unallocated water to Storage Reserve

Water will be allocated to the hidden Storage Reserve system account until there is no more unallocated water, or the Storage Reserve requirement is met.

Allocate unallocated water to High Security reserves in priority order

Water will be allocated to each High Security reserve system account until there is no more unallocated water, or all High Security reserve requirements are met.

Where this insufficient water to meet all High Security reserve requirements, the system will allocate water by starting with the highest priority High Security reserve and proceeding by descending priority order.

Do any Reserves still need water?

Also known as 'Shortfall'.

If any reserve has not had its (full) requirement met by this stage the system is considered to have a shortfall.

If there is a shortfall the next time step will be an allocation time step.

Note that the system will still attempt to meet the reserve requirements after this step, so a shortfall can occur even if the (post allocation) reserves are all at full requirement,

From this stage the system can go down two paths; performing allocation to the GSS and GS account types, or forcing the reserves to meet minimum requirements.

Reserves between minimum and full

In a situation where all reserve balances are greater than their minimum reserve balance and less than their (full) reserve balance the system can refuse to allocate to GS and GSS but choose not to borrow water to increase the reserves. This can result in multiple consecutive 'shortfall' states.

Transfer water from TOL account to Storage Reserve

Water is transferred from the TOL account to the hidden Storage reserve system until the Storage Reserve minimum requirement is met, or until the TOL account is reduced to the TOL minimum requirement.

Note this a Transfer and not a Borrow as this water will not be repaid (but should be allocated back later as required)

Transfer water from TOL account to High Security reserve in priority order

Water is transferred from the TOL account to the High Security reserves until all High Security reserve minimum requirements are met, or until the TOL account is reduced to the TOL minimum requirement.

Where this insufficient water to meet all High Security minimum reserve requirements, the system will allocate water by starting with the highest priority High Security reserve and proceeding by descending priority order.

Note this a Transfer and not a Borrow as this water will not be repaid (but should be allocated back later as required)

Borrow water from accounts to Storage Reserve

Water is borrowed from eligible accounts until the Storage Reserve minimun requirement is met, or until no available water remains in eligible accounts.

Note: unlike "Borrow water from accounts to TOL account to meet TOL min requirement" we do not borrow water from other reserves (which includes high security accounts) or other system types.

This borrowing occurs from GS and GSS accounts in reverse account type priority (least important first) order. Accounts of the same account type share the borrowing according to (account balance/account type balance).

Borrow water from accounts to High Security reserves

Water is borrowed from eligible accounts until all High Security reserve minimun requirements are met, or until no available water remains in eligible accounts.

Note: unlike "Borrow water from accounts to TOL account to meet TOL min requirement" we do not borrow water from other reserves (which includes high security accounts) or other system types.

This borrowing occurs from GS and GSS accounts in reverse account type priority (least important first) order. Accounts of the same account type share the borrowing according to (account balance/account type balance).

Where this insufficient water to meet all High Security minimum reserve requirements, the system will allocate water by starting with the highest priority High Security reserve and proceeding by descending priority order.

All High Security reserves allocate water to High Security accounts

Each High Security reserve allocates water to its accounts based on its per-unit share allocation strategy.

Note that this does not reduce the water in the High Security reserve by the amount allocated to the account, but does transfer water from the High Security reserve to the TOL account based on the account's TOL proportion multiplied by the change in allocation. i.e. at this point the High Security reserve 'pays for' the account's TOL.

This will usually result in the High Security reserve being 'topped up' on the allocation next time step.

Allocate water to Generic System Share

Water will be allocated to each Generic System Share account until there is no more unallocated water, or all Generic System Share requirements are met.

Where this insufficient water to meet all Generic System Share requirements, the system will allocate water by starting with the highest priority Generic System Share and proceeding by descending priority order.

This may result in a change in TOL minimum requirement or TOL requirement, and if so appropriate water must also be allocated to TOL in order to allocate to an account (see "TOL Allocation")

Allocate water to General Security in priority order

Water will be allocated to each General Security account until there is no more unallocated water, or all General Security requirements are met.

Where this insufficient water to meet all General Security requirements, the system will allocate water by starting with the highest priority General Security account type and proceeding by descending priority order. If there is insufficient water to meet all the requirements of a given account type water will be allocated based on (account entitlement / account type entitlement)

This may result in a change in TOL minimum requirement or TOL requirement, and if so appropriate water must also be allocated to TOL in order to allocate to an account (see "TOL Allocation")

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, taking into account the increased TOL requirements due to the payback. 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:

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

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))/(1 + TOLShare(Account Type))

Balance(account) = Balance(account) + Payback

OwedTo(account) = OwedTo(account) - Payback

UnallocatedVolume = UnallocatedVolume - Payback*(1+TOLShare(Account Type))

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:

Figure 3. Resource Allocation Flowchart

Reserve Allocation

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
function

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 function

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 function

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 function

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

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

Note: Because the allocation to the TOL occurs before allocation to accounts, this will result in a larger than required TOL in cases where accounts are spilling.

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)

Note: In Continuous Accounting systems, General Security accounts can have up to two usage limits. The smallest limit is used to limit the available balance.

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

Attribute	Description	Units	Range
Owner	Owner of the resources managed by the Resource Assessment System.	N/A	Depends on Ownership System: None: ‘Not specified’ - Otherwise an owner in the selected Ownership System
Debit Type	Determines how water is deducted from all accounts associated with this continuous accounting system.	N/A	‘Use’ or ‘Order’
Start of Water Year	Day and month the water year starts	dd-mmm	1 ≤ dd ≤ (days in month) mmm = { Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec}
No further resource assessments from this date	Day-month after which no further resource assessments should be conducted	dd-mmm	1 ≤ dd ≤ (days in month) mmm = { Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec}
Time-steps per Assessments	Defines time-steps between assessments	N/A	Integer > 0
Assigned Storages	List of storage nodes that supply water to the resource assessment system.	N/A	Storage nodes in the scenario river network
Account Type	Lists the account types available in a Continuous Accounting system	N/A	Account types defined for the Continuous Accounting system
Allocation Priority	Determines order in which the account type will be credited during a resource allocation.	N/A	Integer > 0
TOL Share	Proportion of allocations which are to be held in reserve for transmission and operation loss (TOL) account	%	Real number > 0
TOL Minshare	Used to calculate the minimum required TOL volume(borrowing used if required to achieve minimum)	%	Real number >=0

Table 6. Storage loss reserve account type parameters

Attribute	Description	Units	Range
Storage Loss Reserve Requirement	Defines the reserve required to cover storage losses (eg. evaporation)	Volume	Real number > 0
Minimum to cover storage losses	Defines the % of required reserve below which borrowing occurs	%	Real number > 0

Table 7. High Security Group 1 and 2 Account Type Parameters

Attribute	Description	Units	Range
High Security Reserve Requirement	Defines the reserve required to cover delivery of High Security Entitlements	Volume	Real number > 0
Required Reserve Below Which Borrowing Occurs	Defines the % of required reserve below which borrowing occurs	%	Real number > 0
Account allocation method	Allows the user to select whether the allocation to the account type’s use accounts should be determined via a time series (via an function) or simulated.	n/a	‘Time Series’, ‘Simulated’
Allocation to accounts	A field to enter a function for when the time series account allocation has been selected.	Volume	Real number > 0
Using account rules	Determines whether the allocation rules table is treated as a set of thresholds or whether interpolation applies	n/a	Interpolation, Thresholds
HS reserve met	Defines the HS1 account balance as a percentage of the requirement	%	Real number > 0
HS Allocation	Defines the allocation for High Security Group 1 accounts	Volume	Real number > 0

Table 8. Generic System Share Account Type Parameters

Attribute	Description	Units	Range
Allocation method	Allows the user to select whether the allocation to this account type should be determined via a time series (via a function) or simulated.	n/a	‘Time Series’, ‘Simulated’
Total Volume Initial Balance	Initial balance for the GSS account	n/a	Real number > 0
Function	Function entry field used to define the time series allocation	Volume	Real number > 0
Generic System Share Allocation	Defines the simulated allocation to the Generic System Share Account (via a function)	Volume	Real number > 0

Table 9. General Security Account Type Parameters

Attribute	Description	Units	Range
Allocation method	Allows the user to select whether the allocation to this account type should be determined via a time series (via a function) or simulated.	n/a	‘Time Series’, ‘Simulated’
Allocation to GS	When time series allocations is selected, this field is used to enter the Function	Volume	Real number > 0
Maximum Balance	Account balance level above which water cannot be allocated; if no balance defined the no restriction is imposed.	Volume	Real number > 0
Minimum Balance	Account balance level below which water cannot be debited; if no balance defined the no restriction is imposed.	Volume	Real number > 0
Minimum Volume	Allows the user to define a minimum volume level for the account if required	Volume	Real number > 0
Maximum volume	Allows the user to define a maximum volume level for the account if required	Volume	Real number > 0
Usage limit 1 and 2	Parameters to define usage limits - See the overview of Resource Assessment in this Scientific Reference Guide entry for usage limit parameters

Table 10. Water User Account Parameters

Attribute	Description	Units	Range
Name	Name of the water user node.	N/A	Alphanumeric
Type	Eg. Time Series Demand.	N/A	Water user node types
No. of Shares	Dictates the share of available water an account is allocated.	N/A	Real number > 0
Account Volume	Entitlement volume.	volume	Real number > 0
Initial balance	Initial account balance	volume	Real number > 0
Previous Usage	Function to define previous usage of the account at the start of the simulation.	N/A	Real number > 0

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

Attribute	Description	Units	Range
Account balance	Total volume in all accounts for that account type at the end of the time-step	Volume	Real number ≥ 0
Account Balance pre orders	Account balance at the start of the timestep (i.e. prior to crediting orders).	Volume	Real number ≥ 0
Change in allocation	Total volume added to accounts of that type at the current time-step. Only reports on new allocations; credits from payback and adjustment due to shortfall are not included.	Volume	Real number ≥ 0
Order / use debit	Total volume debited from accounts of that type at the current time-step. For order debit systems, debit refers to total orders. For use debit systems, debit refers to total extractions. Debits due to borrowing are not included.	Volume	Real number ≥ 0
Reserve balance	Balance of the reserve account for this account type (used in Storage Loss Reserve, High Security Group 1 and High Security Group 2 only)	Volume	Real number ≥ 0

Table 12. Recorded variables: Water user accounts

Attribute	Description	Units	Range
Account balance	Total volume in all accounts for that account type at the end of the time-step	Volume	Real number ≥ 0
Account Balance pre orders	Account balance at the start of the time-step (ie. prior to crediting orders).	Volume	Real number ≥ 0
Change in allocation	Total volume added to accounts of that type at the current time-step. Only reports on new allocations; credits from payback and adjustment due to shortfall are not included.	Volume	Real number ≥ 0
Order / use debit	Total volume debited from accounts of that type at the current time-step. For order debit systems, debit refers to total orders. For use debit systems, debit refers to total extractions. Debits due to borrowing are not included.	Volume	Real number ≥ 0
Max Balance Limit	The maximum volume that can be held in the account (General security accounts only)	Volume	Real number ≥ Min Balance ≥ 0

Table 13. Recorded variables: Water user account usage limits (General security accounts only)

Attribute	Description	Units	Range
Usage Limit - Accumulated Usage	The account's total usage during the defined usage limit period. Note that there are 2 separate usage limit results reported as the modeller can define 2 separate usage limits.	Volume	Real number ≥ 0
Usage Limit - Limit	The maximum usage allowed during the defined usage limit period. If the remaining usage limit balance is required this can be calculated by debiting the accumulated usage from the limit value.	Volume	Real number ≥ 0

Table 14. Recorded variables: System reserves

Attribute	Description	Units	Range
Debt to account	Total borrowed from accounts, either for TOL or reserves, that has not been paid back yet.	Volume	Real number ≥ 0
High Security Reserve Balance	Total volume in high security reserves. [A separate balance for each reserve is not available at this stage].	Volume	Real number ≥ 0
Storage Loss Reserve Balance	Total volume in the storage loss reserve account.	Volume	Real number ≥ 0
Storage Loss Reserve requirement	Result of the storage loss reserve requirement Function. Does not account for the reduced requirement due to some balance having been transferred to TOL.	Volume	Real number ≥ 0
TOL Balance	Total volume in the transmission and operation loss account.	Volume	Real number ≥ 0
TOL balance pre order	Total volume in the TOL at the start of the time-step (ie. prior to crediting for orders or debiting from storage releases).	Volume	Real number ≥ 0

Reference list

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

Browser not supported