Note: This is documentation for version 5.0 of Source. For a different version of Source, select the relevant space by using the Spaces menu in the toolbar above

Continuous Accounting - SRG

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:

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

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

    • If the system is use-debit

Current TOL Allocation = Balance(TOL System)

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

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

      • If the system is use-debit

Balance(TOL System) = Minimum TOL Requirement

UnallocatedVolume = UnallocatedVolume - TOLRequired

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

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

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

UnallocatedVolume = 0


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

    • If the TotalBalance( account type) > 0

For each water user account of the current account type:

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

Balance(account) = Balance(account) - Borrow

OwedTo(account) = OwedTo(account) + Borrow

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

      • If the system is order-debit,

Current TOL Allocation = Balance(TOL System) - OutstandingReleases

      • If the system is use-debit

Current TOL Allocation = Balance(TOL System)

Shortfall= Minimum TOL Requirement -Current TOL Allocation

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

Payback Borrow

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

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

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

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

      • If the system is use-debit

Allocation = TOL Requirement - Balance(TOL System)

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

UnallocatedVolume = UnallocatedVolume - Allocation

  1. The total amount owing Total Owed System is determined by accumulating for all accounts in the Continuous Accounting system OwedTo(account).
  • While Unallocated Volume > 0, and the value of Total Owed System is changing:

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

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

Payback = Min(OwedTo(account), (Unallocated Volume • OwedTo(account)/TotalOwedTo(Account Type))/(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