General concepts and background

Wherever a water source in Australia can be used by more than one entity a system for sharing this resource has been set up. In Australia, the common approach has been for the responsible state or territory to administer a system of entitlement-based sharing. The rules and methods used in each system vary between river systems and jurisdictions, but there are some common concepts and these are discussed here. Background on legal aspects of water management, access and use is provided in sources such as Tan (2002).

The term "Resource Assessment System" (RAS) as used in the context of eWater Source encompasses the process of resource assessment (also known as Available Water Determination in some jurisdictions), resource allocation and water use accounting. Given the intended applications of eWater Source for modelling water sharing in river systems, the ability to model resource assessment systems is essential.

Scale

The concept of spatial scale in the context of Resource Assessment Systems, relates 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. The status of the resource assessment system can be updated as often as at every model time-step, or less often if required.

Principal developer

This version of Resource Assessment System modelling has been developed by eWater.

Scientific provenance

Resource Assessment Systems have been modelled in predecessors to Source, such as IQQM, MSM and REALM, for many years. The concepts in these models have been updated and enhanced to suit the needs of eWater Source.

Version

eWater Source version 3.0.1.

Dependencies

The minimum requirement is that there should be at least one water user in the river system being modelled.

Assumptions

Assumptions and constraints are summarised in Table 1.

Table 1. Assumptions and constraints applying to resource assessment systems overall

#

Assumption or Constraint

1

Resource assessment systems must have defined water sources which can include:

Regulated river flow from a defined list of storages
Regulated off-allocation river flow, defined at one or more locations
Unregulated river flow
Groundwater

2

A resource assessment system can only utilise water that belongs to the resource owner, which can be:

Not defined (unassigned water)
An owner in a water ownership system
Another resource allocation system

Definitions

The following definitions supplement those in the eWater glossary:

Account

Entity to keep track of the status of a water user’s water usage. Note that a given water user can have more than one account, and these do not necessarily have to be of the same account type.

Account balance

The remaining volume/share of water available to an account holder. The sum of all of the credits to an account minus the sum of all the debits.

Annual accounting

The accounting and sharing out of water resources in either a regulated or an unregulated river system on an annual cycle. Some carryover of users accounts from one year to the next, and overdraw of users accounts within a year, may be allowed with time limits on using the carryover or paying back the overdraw in the following year. There may also be annual and multi-year use limits. In a regulated river system the operator manages the water and makes regular announcements on volume that is available for use, and the storage, transmission and operation losses are funded from a communal account.

Continuous accounting

The accounting and sharing out of water resources in either a regulated or an unregulated river system based on an annual cycle, as for annual accounting, but with broader carryover provisions than under annual accounting. This provides water users with greater flexibility in managing their own accounts than under annual accounting, although account balances may not be permitted to become negative (ie. no overdraw permitted; if a user needs more water they can enter into a temporary or permanent trade to buy the water needed). Carryover may be limited by annual and multi-year use limits. In a regulated river system the storage, transmission and operation losses are funded from a communal account.

Continuous sharing

A water use accounting system with unlimited carryover, user’s balances limited to an upper bound, storage losses funded by the water users in proportion to their current storage volumes, transmission and operation losses funded by users based on their storage factors. Variation in operation from the fixed storage factors is funded by a joint accounting reconciliation.

Entitlement

A legal right to access water. An entitlement can be specified as a share of water from a consumptive pool of water as defined in the relevant water plan, or a fixed annual volume which may be restricted according to the resource assessment. Note that the licensing system in many jurisdictions has two parts to it:

- - A water access licence (ie. the entitlement, as defined here), which is a permanent property right in the same way as land ownership title but is not associated with land title, and is tradeable. It can be expressed in terms of unit shares or some other measure, as described above. In the context of Source, each entitlement also has an account type and an account associated with it.
  - 2A water use licence, which is associated with a specific location and usage, and is not tradeable. In the context of Source these come into consideration when defining the properties of water users for modelling - location, demand characteristics, etc - but otherwise they do not need to be modelled.

Owner

Entity (eg. state) that owns a parcel of water and has the location of that water tracked as it moves through a river system. An owner is associated with a resource assessment system.

Resource allocation

The process by which the volume of water assessed as being available is shared amongst the water users in a Resource Assessment System.

Resource assessment

The process by which the volume of water that can be shared amongst a group of water users is calculated.

Resource assessment system

Describes the resource assessment, resource allocation, water use accounting and water users that make up a water sharing arrangement.

Water user

Modelled entity in Source that can order and/or use water.

Water year

A continuous twelve-month period starting from a specified month for water accounting purposes. The water year varies between systems. Two common water year periods are 1 July to 30 June, and 1 October to 30 September.

Structure and processes

In eWater Source, Resource Assessment Systems are used to model the management of shared water resources. Separate systems are used for regulated and unregulated water.

A Resource Assessment System is a group of water users and sources of water that are managed together in a common sharing scheme. The sources of water could be an aquifer, one or more reservoirs, one or more capacity shares in one or more reservoirs, and the balance in an account granted to the Resource Assessment System from another system higher in a series of nested resource assessment systems. The relationships between resource assessment systems, account types, accounts and water users are explained further in the sections below.

In practice, the types of Resource Assessment Systems in use in Australia include:

Continuous sharing (eg. Macintyre Brook)
Continuous accounting (eg. Namoi)
Upper Namoi annual accounting
Victorian water system accounting
New South Wales and Queensland annual accounting (various)
Murray accounting
Forecasting requirement for Lachlan, Murray, and Murrumbidgee resource assessment.
Murray system planning

The options available in eWater Source for modelling Resource Assessment Systems are identified by the name of the water use accounting system each one uses; these are Annual Accounting, Continuous Accounting, Continuous Sharing and Off-Allocation. These are further explained in the appropriate sections of this Scientific Reference Guide.

Categories of water managed

There are three main categories of water that can be used by, and shared, between individual ‘water users’ such as town water suppliers, irrigators, industry and the environment:

Regulated water - ordered: Water ordered from storages (reservoirs) in a regulated river section.
Regulated water - off-allocation: Water in regulated river sections that is additional to the volume ordered and above a defined off-allocation threshold.
Unregulated water: This includes the flow in unregulated river sections, flow in a regulated river section above a defined threshold, and groundwater.

The management of each of these categories of water may be modelled in eWater Source by a RAS, or its component account types and accounts (see following sections).

Accounts

Volumes of water available to water users in a RAS are tracked using water use accounts. For a given water user, their accounts are used to keep track of usage relative to their account balance and allowable usage, and this defines how much more water they are allowed to use.

RAS may also have ‘system’ accounts. These are used to track water the RAS puts aside for purposes such as transmission and operational loss (TOL), reserves, or other linked or nested RAS (see the section on RAS structure).

Water users and accounts

A water user may have accounts in more than one RAS. This enables them to use water from more than one system, where these could all be regulated or unregulated, or a combination of the two.

Account types and allocation priority

Accounts within a RAS may be grouped together for the purposes of allocation when they are governed by the same set of rules (such as usage limits), or have the same priority of access to water. This grouping is referred to in eWater Source as an ‘account type’. Examples of such groupings are licence types, such as high security, or general security. High security users will usually be allocated their full allowance before general security irrigators start to be allocated any water.

Separate account types are used for ordered and off-allocation water within a regulated RAS. Further details on account types are provided in the respective Scientific Reference Guide sections on Annual Accounting, Continuous Accounting, Continuous Sharing and Off-Allocation.

Triggers (events)

In water resource management, there are a range of events that require actions to take place. A standard example is the start of a water year - this ‘triggers’ the resource assessment and allocation process. Other examples may include:

When storages fall below a given volume, water restrictions are invoked
When storages are spilling, flood operations commence

In eWater Source, such event driven processes are modelled using triggers. Triggers for RAS and account types may be specified by the modeller in Annual Accounting systems. There is a default trigger to invoke resource assessment in all system types, this may be modified or deleted in Annual Accounting systems, but is hidden and cannot be changed in other system types.

Usage limits (Caps)

Accounts and account types may have limitations placed on their usage that are independent of their allocation (or account balance). This dichotomy may occur because the allocation relates to a water year, and the usage limitation relates to multiple years, or moving time period. The way such account or account type limitations are implemented in eWater Source is described below:

In Annual Accounting systems, any number of usage limits may be defined for account types and accounts.
Continuous Accounting system General Security accounts may have up to two usage limits. Usage limits cannot be defined for other account types in this system.
Continuous Sharing system accounts have a single usage limit that applies to a water year, this is implemented via the Annual Cap attribute.

Water ownership and RAS

Each RAS can be associated with a ‘resource owner’, ie. a water owner in an ownership system. In rivers such as the Murray, multiple state ‘owners’ (eg. NSW, Victoria, South Australia) share ownership of the water. Each of these states or owners can have its resource assessment systems to share water between individual users. The concept of an ‘ownership system’ is used in eWater Source to delineate the boundaries of river sections where different owners share the water resource. Each owner in the ownership system is assigned a share of the water in that system. The owner’s resource assessment systems can only allocate the owner’s share of water resources (where the ‘ownership system’ determines what this share is at any given time).

Simpler river management systems can be modelled without consideration of water ownership. eWater Source therefore allows ownership to be turned ‘off’. When this is done, all water sharing is carried out by resource assessment systems.

The Murray Darling Basin Agreement allows state water owners to exchange water to make the best use of the available resource. In eWater Source, these exchanges are referred to as ‘borrow and payback’, and occur within the boundary of the ‘ownership system’. The modeller may choose to implement payback via RAS. This is done by adjusting the allocation function of the top-level RAS for each owner. The owner’s borrow account balance should be subtracted from the RAS’s allocation. For example, if there were two owners A and B, and A owes B 200 GL, and at assessment both A and B have 1000 GL each in storage:

A available resource = 1000 - 200 = 800 GL
B available resource = 1000 + 200 = 1200 GL

During resource allocation, Owner A’s RAS would allocate 800 GL to its accounts and Owner B’s RAS would allocate1200 GL. Later in the season after the water users in Owner B’s RAS have used 1000 GL, Owner B would have no more water in storage. However, Owner B’s RAS accounts would still have a total balance of 200GL, and so its water users would keep placing orders. To meet such orders, Owner B would start to borrow water from Owner A (who has 200 GL in storage that its RAS can’t allocate). In this way the borrow accounts for owners A and B would start heading back toward zero.

Nested and linked RAS

Accounts and Account Types can be used as a mechanism for a ‘parent’ RAS to allocate water to ‘nested’ or linked systems. In these cases the modeller specifies an allocation function in one RAS that refers to recorded variables such as ‘account balance’ in the other RAS.

Nested system example - Border rivers

One example of this would be in modelling the Border Rivers system (so-called because it straddles the border between NSW and Queensland). Two owners operate within this river system - NSW and Queensland. The RAS in use by NSW has two sub-systems - Glenlyon and Pindari, as shown in Figure 1. In eWater Source, three RASs would be used to represent this scenario: the Border Rivers (NSW), Glenlyon and Pindari. The ‘resource owner’ for all the RASs would be the state owner - NSW. The Border Rivers (NSW) RAS would use direct sources for its allocation, ie. storages and off-allocation flow shares. It would have a set of accounts, each of which would be assigned a balance representing a share of the total allocation. The nested Glenlyon and Pindari systems would each use the total balance for a corresponding system account/account type in the parent Border Rivers (NSW) RAS as their allocation, instead of a direct share of storage or off-allocation volume. These nested systems would each also have their own set of water user accounts.

Figure 1. Example of nested Resource Assessment Systems - Border Rivers

RAS Interdependency Example

An example of the resource allocation system structure within ownership systems is illustrated in Figure 2.

Figure 2. Example Resource Allocation structure in eWater Source

RAS Entity-Relationship Diagram

The relationships between ownership systems, owners, resource assessment systems, account types, accounts and water users are illustrated in Figure 3.

Figure 3. Resource Assessment & Allocation Entities & Relationships

Resource Assessment And Allocation

The methodology required is determined by the resource assessment system type. However, each method implements the same basic process shown in Figure 4. It is applied at each modelling time-step, at the beginning or the end, depending on the type of system.

Figure 4. Resource Assessment & Allocation Flowchart

Each resource assessment system is processed separately. The resource assessment process uses information regarding current storage and link volumes, future forecasts of inflow and loss, and current usage (as recorded in water user accounts) to determine the resource available. It only occurs at time-steps that mark resource assessment/allocation events or conditions - such as the start of a water year. The resource is allocated according to the methodology that applies for the particular system type. Water user accounts are then updated for their allocation.

Ordering

When ‘account sharing’ water users place water orders in a regulated river system, the size of the order is limited by the balance of their accounts. See the Water user node SRG entry for more information.

Accounting for usage

Each account’s usage is calculated at every time-step. The time-step phase in which this is done (order or flow) is dependent on the RAS rules as specified by the modeller. These rules can be specified at the RAS, account type or account level, depending on the type of RAS.

Under ‘order-debit’ rules, a water use account is debited for the amount of water actually released to meet the water user’s order placed using the account. This is done in the timestep order phase.

Under ‘use-debit’ rules, a water user account is debited for the amount of water ‘used’ (in the time-step flow phase). Usage may be to meet extractive or in-stream requirements. For more information as to how usage is calculated, see the Water user node SRG and the Supply point node - SRG entries.

Input data

Input data varies depending on the type of system being used. Parameters common to many resource assessment systems, their account types and accounts are listed from Table 2 through Table 4. Triggers and usage limits may also be defined for most types of system. The input data for these are listed in Table 5 and Table 6. Further information on data requirements are provided in the SRG sections on the individual resource assessment systems available in eWater Source, and also in the Source User Guide.

Table 2. Common resource assessment system parameters

Attribute	Description	Units	Range
RAS Name	Name of RAS	N/A	Alphanumeric
RAS Type	Type of RAS, eg. Continuous Sharing.	N/A	‘Annual Accounting’, ‘Continuous Accounting’, ‘Continuous Sharing’, ‘Off-Allocation System’
Ownership System	Name of any ownership system the resource assessment system operates within.	N/A	‘None’ or any existing ownership system
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
Water year start	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}
Assigned Storages	List of storage nodes that supply water to the resource assessment system.	N/A	Storage nodes in the scenario river network
*Debit-type	Determines time at which water is deducted from the account.	N/A	‘Use’ or ‘Order’
⁺ Timesteps per assessment	Number of timesteps between each resource assessment and allocation.	N/A	Integer > 0

* The debit-type attribute is hidden in Continuous Sharing systems (value ‘Order’) and Off-Allocation systems (value ‘Use). It is overridden by a corresponding parameter at Account Type level in Annual Accounting systems.

⁺ Timesteps per assessment are not used in Off-Allocation systems. Off-allocation occurs when modeller specified conditions are met.

Table 3. Common Account Type Parameters

Attribute	Description	Units	Range
Account Type	Name of the account type.	N/A	Alphanumeric
Allocation Priority	Determines order in which the account type will be credited during a resource allocation.	N/A	Integer > 0
*Debit-type	Determines time at which water is deducted from the account.	N/A	‘Use’ or ‘Order’
+Maximum Balance Type	Type of maximum account balance	N/A	‘Unrestricted’, ‘Absolute volume’, ‘Per unit share’
+Maximum Balance	Maximum volume that can be allocated to each account of this account type.	Depends on Maximum balance type	Real number ≥ Minimum Balance
+Minimum Balance Type	Type of minimum account balance	N/A	‘Unrestricted’, ‘Absolute volume’, ‘Per unit share’
+Minimum Balance	Balance level below which water cannot be debited for accounts of this account type.	Depends on Minimum balance type	Real number between 0 and Maximum Balance

* The debit-type attribute is hidden in account types for Continuous Accounting and Continuous Sharing systems. It is determined by the corresponding attribute at system level (in the case of Continuous Sharing, the debit-type value is always ‘Order’).
+ These attributes are implemented differently for Continuous Accounting’s Storage Loss Reserve and High Security Group 1 and 2 account types. There is a minimum reserve requirement for these account types that act as a minimum balance for reserve accounts.

Table 4. Common Account Parameters

Attribute	Description	Units	Range
Number of Shares	Dictates the share of available water the user is allocated.	N/A	Real number > 0
Initial Balance	Account balance at the start of the scenario run.	Volume	Real number ≥ 0
⁺Previous Usage	Indicates the ‘usage’ by the account at the start of the scenario run.	Volume	Real number ≥ 0

⁺ In Continuous Sharing systems, previous usage is expressed as an ‘Initial cap balance’. This is the account’s usage limit (or cap) minus the previous usage.

Table 5. Common Resource Assessment System Parameters

Attribute	Description	Units	Range
Name	Name of the trigger	n/a	Alphanumeric
Trigger Type	Type of condition that causes the trigger to operate	n/a	Specified date, Start of Water Year, End of Water Year, Storage level, Season, Per timestep, Monthly Trigger
Execution	The part/phase of the timestep in which to perform the action.	n/a	‘Timestep beginning’,‘Timestep end’
Specified Date	The date at which the trigger action is performed.	n/a	Valid dates in a year
Storage	Name of the storage that the ‘Storage Level’ trigger applies to	n/a	Storage in the scenario network
Level change type	Type of level change that causes the ‘Storage Level’ trigger action to occur.	n/a	‘Rising’, ‘Falling’
Level	The ‘Storage Level’ trigger action will occur when Storage has the Level change type (rises/falls) to reach the Level.	Depth	Real number
Timesteps	Number of time-steps between a trigger action (if 1, then every time-step).	n/a	Integer > 0
Season start date	Date at which the season starts (the season in which the trigger action occurs)	n/a	Day and month within year, format dd-mmm
Season end date	Date at which the season ends (the season in which the trigger action occurs)	n/a	Valid dates in a year
Offset from	Defines whether the action date is offset from the start or end of the month.	n/a	‘Start of the month’, ‘End of the month’
Days offset	Number of days the action date is from the start/end of the month.	n/a	Integer ≥ 0
Function	Function that dictates when the trigger action will occur (trigger executes when ‘true’).	n/a	True or false value
Action Type	Type of action to perform when the triggered condition is true.	n/a	Transfer, Truncate accounts, Write-off accounts, Per-unit share allocation, Assign allocation, Reassessment, Carryover
Account type	Account type action applies to for the following action types: truncate, write-off, per-unit share allocation, assign allocation, carryover.	n/a	Account type in the current RAS
Amount	The volume to change/limit account balances to/by for the following action types: truncate, per-unit share allocation, assign allocation.	Volume	Integer ≥ 0
Carryover%	The percentage of the balances of accounts of the specified type to carryover when action type is ‘Carryover’.	n/a	Integer ≥ 0
Reassessment time-steps	The number of time-steps between each standard resource allocation when Action Type =’Re-assessment’	n/a	Integer > 0
From account type	Account type to transfer allocation from when Action Type = ‘Transfer’	n/a	Account type in the current RAS
To account type	Account type to transfer allocation to when Action Type = ‘Transfer’	n/a	Account type in the current RAS
Transfer%	Percentage of allocation to transfer between accounts of specified type when Action Type = ‘Transfer’	n/a	Integer ≥ 0

Table 6. Usage limit parameters

Attribute	Description	Units	Range
Period	Type of period over which the usage limit applies.	N/A	‘Moving Window’, ‘Moving Water Year’
Years	Number of years the usage limit applies to (after this period, the usage is reset to zero).	Years	Integer > 0
Quantity type	Indicates whether the limit quantity is specified as a volume, or volume per unit shares.	N/A	‘Absolute volume’, ‘Per unit share’
Quantity	The usage limit. If the Quantity type is ‘Per unit share’, this value is multiplied by the account or account type’s shares to determine the volume limitation. Otherwise, it is the actual volume limitation.	N/A	Real number ≥ 0

Output data

Statistics on a range of specific variables can be recorded and displayed for each time-step and for each Resource Assessment System (RAS) specified in a modelling scenario. For all RAS types, the following entities can have attribute totals reported if specified by the modeller:

Account
Water User (for each water user’s accounts in a RAS)
Account Type (in a RAS)
RAS.

Each attribute’s value is viewable in both table and graph form, with an entry/plot point shown for each model time-step where a value is recorded. In most cases a value is recorded every time-step.

Details of the outputs vary depending on the type of resource assessment system. These are discussed further in the SRG sections on the individual resource assessment systems available in eWater Source and in the User Guide.

Reference list

Tan P-L (2002) Legal Issues Relating to Water Use. Issues Paper No 1. Murray-Darling Basin Commission Project MP2004: Agriculture and Natural Resource Management in the Murray-Darling Basin: A Policy History and Analysis. April. Available at http://thelivingmurray2.mdbc.gov.au/__data/page/1482/Poh-ling_Tan_final_report1.pdf

Browser not supported