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

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

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

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

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

Storage Loss Reserve

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

High Security Reserve

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

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

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

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

Generic System Share

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

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

General Security

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

Transmission and operation loss (TOL)

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

Timing of resource assessment

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

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

Resource categories and allocation priority

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

Figure 1. Allocation sequence of account types (starting at the bottom)

Table 2. Allocation of current active storage volume to determine additional volume for allocation to general security and transmission and operation loss (TOL) accounts

1. Existing allocations and required reserves:

Storage loss reserve: required reserve for current storage volume
HS 1 and 2: high security allocation reserves
Existing balance in the GSS
Existing General Security account balances
Transmission and operation loss account

2. Unallocated volume can be used to create new allocations to GSS and TOL accounts if required

3. Remaining volume is distributed to general security accounts and system TOL account.

The modeller can specify a percentage of entitlement volume which is to be allocated to the transmission and operation loss account (TOL). For all account types, including any linked GSS accounts, the TOL is used as a holding account for orders for which releases have not yet been made. This occurs even if the percentage of entitlement volume specified is zero.

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

Allocation to accounts

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

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

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

Reserve accounts (Storage Loss, High Security)

The required volumes for the reserve account types are defined by the modeller via 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 Group 1 and 2 accounts

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

Simulate allocation

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

Table 3. Example Allocation Rules table for high security accounts

% 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

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

Figure 2. Timestep Resource Assessment And Allocation Phase Flowchart

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.

Assign minimum TOL requirement

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

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

This process is described in the steps below:

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

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

- If the system is use-debit

Current TOL Allocation = Balance(TOL System)

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

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

- - If the system is use-debit

Balance(TOL System) = Minimum TOL Requirement

UnallocatedVolume = UnallocatedVolume - TOLRequired

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

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

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

UnallocatedVolume = 0

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

- If the TotalBalance( account type) > 0

For each water user account of the current account type:

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

Balance(account) = Balance(account) - Borrow

OwedTo(account) = OwedTo(account) + Borrow

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

- - If the system is order-debit,

Current TOL Allocation = Balance(TOL System) - OutstandingReleases

- - If the system is use-debit

Current TOL Allocation = Balance(TOL System)

Shortfall= Minimum TOL Requirement -Current TOL Allocation

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

Payback Borrow

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

Payback to account types is made in order of highest to lowest priority (the reverse of the borrow order). Water is distributed to the individual accounts within this account type in proportion to their amount owing, 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