Many regulated river systems support several resource assessment schemes to share the available resource (water) amongst users. In Source, a resource assessment system:

• is associated with only one scenario in a project, whereas a scenario may be associated with one or more resource assessment systems;
• can only have one owner, but any given owner or water user may be affected by more than one system; and
• supports multiple account types.

Note that resource assessment only operates correctly in a regulated system.

Figure 104 shows the various contextual menus available for each level in the resource assessment hierarchy. Note that similar types of accounts or systems have the same contextual menu. For example, all off-allocation systems have the same contextual menu, and all account types follow a similar trend.

Image Removed

In practice there are a number of resource assessment methodologies used, which can be implemented in Source using a generic resource assessment tool, referred to as Simple Water Accounting. The next section provides details on configuring two types of resource assessment in Source - general and continuous sharing.

General Resource Assessment

For detailed information about resource assessment, refer to the Source Scientific Reference Guide. To enable General Resource Assessment:

• Choose Edit > Resource Assessment... from the Source main menu;
• Click + to the left of the project name (Figure 104) to reveal the project’s active scenarios; and
• Right-click the scenario for which you wish to enable resource assessment and choose Add Simple System from the contextual menu (Figure 104).

You can edit the system name by right clicking on the name and choosing Rename from the contextual menu. Type in the field and press the carriage-return.

Once a system has been added (Figure 105), provide the following details:

Image Removed

• Set the system Owner. There can only be one owner per system; and
• Set the Water Year Start date. The system will run for 365 days from the date set.

You can also configure an off-allocation system and an account type by right-clicking the system name and choosing from the contextual menu.

Adding an account type

A system may contain several account types, each consisting of many accounts that have common properties. With resource assessment, you can group accounts according to different levels of water security, or any other common criteria appropriate to a set of accounts.

To add a new account type, right-click the system name and choose Add Account Type (Figure 105). If desired, you can edit the account type name to be more meaningful.

When an account type is selected, the right hand panel displays two tabs - Details and Allocation. The former (shown in Figure 106) is a summary of operating information for each account type, whereas the latter (shown in Figure 107) calculates account allocations using either a time series, expression or results from another scenario.

Image Removed

Note that allocation data is interpreted as a cumulative volume allocated per unit share. This means that accounts are only credited if there is an increase in allocation volume since the previous timestep. An account is credited by calculating the increased volume multiplied by the number of shares that the account has in the resource assessment system.

The Originating Allocation System item in the Details tab is a feature relating to tagged trading. In the current version of Source, this functionality is not available.

Adding an account

In the Resource Assessment Explorer window (shown in Figure 107), right-click on the Account Type in the left hand panel and choose Add Account from the contextual menu.

Image Removed

You can configure the properties of an account using the panel displayed in Figure 108. Note that:

Image Removed

• Each account can have only one water user associated with it;
• You must enter the number of shares that the account has in the resource assessment system; and
• You can specify an opening account balance.

Usage limits

You can limit water usage for all accounts by absolute volume or a per-unit-share, which can cover a water year or movable time window (shown in Figure 109). You can define any number of usage limits.

Image Removed

• To add a usage limit, right click on Account Type and choose Add Usage Limit;
• To delete a usage limit, right click on it, and choose Delete; and
• You can also rename it using the contextual menu.

Note The usage limit, regardless of its position in the hierarchy, requires the same parameters to be configured. Figure 109 is therefore the same for all invocations of usage limit.

Account type triggers

A trigger initiates or cancels certain actions for an account type and can be configured using the properties panel shown in Figure 110. To set up a trigger, right-click the account type on the left hand panel and choose Add trigger.

Image Removed

Triggers can be set to activate on a particular date, a year start or end or the passing (either raising or falling) through a specified storage water level. When a trigger is activated it will initiate a pre-defined action, which is defined in the panel on the right hand side of the Triggers window. Possible actions include:

• Transferring a percentage of water to another account;
• Levelling accounts;
• Writing off accounts; and
• Truncating or assigning accounts.

An account type can have several triggers, each designed to initiate a particular action. Triggers can be prioritised by moving them up or down under Trigger Precedence.

Continuous Sharing Resource Assessment

A Continuous Sharing Resource Assessment System is one in which the behaviour of a water user has as little effect as possible on other water users within that system. For detailed information about continuous sharing resource assessment, refer to the Source Scientific Reference Guide. To enable it in Source:

• Choose Edit > Resource Assessment...;
• Click + to the left of the project name (Figure 104) to reveal the project’s active scenarios; and
• Right-click the scenario for which you wish to enable resource assessment and choose Add Continuous Sharing from the contextual menu (Figure 104).

You can rename the system using the same method for simple resource assessment systems. Refer to General Resource Assessment.

System Configuration

To configure a continuous sharing system, start by selecting the owner whose share is described by this system from the Owner pop-up menu (Figure 111) and define the start of the owner’s water year. The owner may be any one of the defined owners in the physical system being modelled. The other owners are assumed to use separate allocation systems, with all calculations occurring independently.

Image Removed

The sharing of various system losses is based on long term averages. Over time, discrepancies will emerge which must be reconciled. You can control the frequency with which reconciliations occur using the Timesteps per Reconciliation field. The default is one time-step. Shortfalls identified during a reconciliation are treated as storage losses, gains as inflows. Losses and gains are shared based on account share sizes, but ignore account priorities.

The reconciliation process also resolves situations such as when multiple resource assessment systems draw upon the same water (whether such a configuration is accidental or deliberate).

The second step is to specify the percentage shares that the owner has in each storage known to the system. You use the Owner Shares tab in the relevant Storage feature editors to accomplish this.

Next, select each storage that should participate in the continuous sharing system in the Unassigned Storages list and move it into the Assigned Storages list by clicking the button with the right arrow. Note that a storage can be removed from the Assigned Storages list by selecting the storage and clicking the button with the left arrow.

As each storage is added to the Assigned Storages list, the owner’s share in that storage is added to the Total Conceptual Storage field, which is the sum of the active capacity for this owner of all of the assigned storages in the resource allocation system. You can not edit this value directly.

By default, 100% of all allocations are considered to be high priority but you can designate a lesser proportion by adjusting the High Priority Allocation field. The related fields of High Priority Storage, Medium Priority Allocation and Medium Priority Storage adjust dynamically in response.

You can adjust the Medium Priority Threshold field to determine how inflows are assigned to accounts. The field behaves as follows:

• When storage is below the stipulated threshold, inflows are only assigned to high priority accounts; and
• When storage is at or above the stipulated level, inflows are assigned to both high priority and medium priority accounts according to the percentages entered in the respective priority allocation fields.

The default Medium Priority Threshold is zero which means that inflows will be assigned to both high priority and medium priority accounts.

The System Cap Balance Carryover specifies the maximum proportion of the owner’s annual resource cap that the system can carry over into the next water year.

Finally, you can define the loss characteristics of each storage in millimetres per day between one or more start- and end-date pairs within the water year. You can also import loss characteristics from a .CSV file formatted as shown in Table 100.

Adding Accounts

To add accounts to a continuous sharing resource assessment system, switch to the Accounts tab (Figure 112) and click Add Accounts to open the Add Accounts window (Figure 113). The nodes which appear in the list on the left hand side of Figure 113 are Water User nodes, otherwise known collectively as demand nodes. Select one of the nodes in this list and click OK.

To add accounts for more than one demand node to a resource assessment system, repeat the process of clicking Add Accounts, selecting the relevant demand node, and clicking OK.

By default, an account of each type (ie a high priority and medium priority allocation account) is added for each water user, although only one account is required to have a maximum account balance greater than zero. Note that, where the High Priority Allocation is 100% (Figure 111), the medium priority account will remain unused.

You can delete an account-pair by selecting either of its members and clicking Delete Accounts. Image Removed

Account configuration

You can configure individual accounts by manipulating the controls shown in Figure 112. Fields that are grey can not be adjusted. They fall into three categories:

• Values that are inherited from previous steps and which are included for reference. Examples include the Name, Type and Priority fields;
• Values that are set by reference to other values. The Maximum Balance column is an example; or
• Fields that must first be enabled explicitly. For example, you must enable the relevant Spec Cap checkbox before you can specify an Annual Cap.

You can allocate shares water by shares or volume. You can specify a maximum cap for an account by enabling the Spec Cap check-box and entering a volumetric limit (ML) in the ‘Annual Cap’ field. This cap will limit the annual volume diverted by the associated water user.

The share factor (Share Fact) defines the relationship between orders and the amount that must be released in response to those orders, having regard to losses and gains during transmission:

• A share factor in the range 0.0 < Share Fact < 1.0 indicates that a loss is expected to occur between the storage and supply point. The closer to zero, the greater the loss;
• A share factor of 1.0 indicates perfect transmission between the storage and supply point;
• A share factor greater than 1.0 indicates gains are expected to occur during transmission, such as inflows from a tributary;
• To account for the transmission losses and gains, the volume of water released from a storage to meet a water user’s order is calculated as the Order divided by the Share Fact; and
• Accounts with a lower share factor are allocated a larger share of the storage to account for the transmission losses they incur.

All share factors at a given priority level within a continuous sharing system are interrelated as follows:

Image Removed

Continuous Accounting

A Continuous Accounting (CA) resource assessment system can be created in Source to replicate the Resource assessment system used in the Gwydir and Namoi in NSW. There are a number of defining features of a CA 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. An accounting process is followed to determine whether any of the available storage volume is unallocated. The unallocated volume remains 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;
• 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 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.

The enhancements to continuous accounting in Source over IQQM are:

• Ability to simulate more than one type of resource allocation and accounting method in the one scenario and to link one system to another;
• Ability to specify data to calculate the initial balance of the usage limit;
• Better simulation of management during dry periods including the ability to:
• Restrict allocations to high security accounts during dry periods where the required reserve cannot be met;
• Define the TOL factor as a variable depending on account balances. This allows a higher factor to be defined when balances are low, as a higher proportion of the allocations will be required to cover transmission losses; and
• Represent the rules which may reduce the required high security reserve.

Adding a continuous accounting system

A CA system can be added to a particular scenario in a project using the Resource Assessment Explorer (Edit > Resource Assessment...). Right click on the scenario and choose Add Continuous Accounting from the contextual menu (Figure 114). The parameters to configure are described in Table 101. The Resource Allocation Table defines the allocation priority when there is more than one account type. It also defines the TOL allocations for each eligible system account type.

When you add a CA system, the following account types are automatically loaded:

• Storage Loss Reserve - define the reserve required for evaporation and seepage losses from storage;
• High Security Group 1 - define the reserve required for high security users. Also allows you to define accounts which relate to this reserve and the method for allocating water to these accounts;
• High Security Group 2 - same as for High Security Group 1 but relates to a separate, lower priority group of high security users;
• Generic System Share 1 - used to allocate water to another Resource assessment system; and
• General Security 1 - allows you to define accounting rules and shares for general security accounts.

Note IQQM includes a number of inbuilt triggers which are not replicated in Source. For this reason, the Timesteps per assessment parameter may need to be set to 1. Additionally, to replicate IQQM, the TOL Share parameter on the high security account type should be zero.

Accounts

The Accounts tab (Figure 115) provides a summary of accounts which have been added to the High Security and General Security account types. Additional Water User Account information is also displayed for each General and High Security Account type. A description of the parameters in this tab are provided in Table 102.

Image Removed

Note In IQQM, No. of shares is named Licence Volume. Additionally, the Initial balance and Previous Usage parameters are not available.

Storage Loss Reserve

The storage loss reserve (Figure 117) is a volume which is required to account for expected evaporation and seepage losses from the storage. The reserve is debited from the available resource prior to making any other allocations. It may be made a function of the current storage volume or area, which can be specified using an expression. A minimum percentage of the required reserve that must be maintained can also be specified; restrictions are applied to general security accounts (or lowest priority account type) to achieve the required minimum reserve.

Image Removed

The following parameters must also be specified:

• Minimum to cover storage losses - Defines the percentage of required reserve below which borrowing occurs. This parameter is not available in IQQM, so it must be set to zero; and
• Storage Loss Reserve Requirement - the reserve required to cover storage evaporation and seepage losses. Note that in IQQM, this requirement is defined through the number of months that evaporation is take into account. In some cases the storage loss is combined into the carryover reserve.

High Security Groups

High Security Groups (Figure 118) define the reserve which is required for high security users (may also be referred to as essential supplies). The high security reserve requirement may be defined using two groups - a higher and lower priority group. In the case where only one group is required, you can delete the other by right clicking on the item and choosing Delete. Additional groups may also be added (right click on the CA system and choose the desired system to be added). This can be specified as a fixed value or as an expression. The latter can be used where there are rules that vary the high security reserve requirement.

Image Removed

High Security accounts are treated as annual accounts with no carryover. In other words, at the start of a water year (as defined at the system level page) all accounts have the existing balance deleted and a new allocation is made. Allocation to high security accounts can be defined using a time series file or simulated based on whether or not the reserve requirement has been met. The Allocation Rules table allows you to define restrictions on allocations to high security accounts if the reserve requirement has not been completely met. The high security shares held by each water user is defined in Accounts. For example, if 1ML is the total reserve, and only 20% of the required high security reserve has been met, then high security accounts will only be given 0.3ML per entitlement share. Table 103 describes the parameters that must be specified.

Generic System Share

The generic system share (GSS) is used to allocate water to another resource assessment system. Water user accounts cannot be added directly to the GSS account from within the Resource Assessment Explorer. The accounts associated with the GSS are configured as part of the linked system. The GSS is credited as part of the continuous accounting allocation method and is debited when accounts in the linked Resource assessment system are debited. If an allocation is made to the GSS, this volume is distributed to users as part of the resource assessment phase of the linked system. The configuration dialog is shown in Figure 119.

Image Removed

The following parameters must be specified for a GSS:

• Time Series Allocation - Enables the entry of a time series file for allocating to the GSS;
• Simulate Allocation - Define an expression to allocate to GSS. The value of the expression is treated as a volume to be added to the GSS account subject to available water limitations; and
• Total Volume Initial Balance - Initial balance in the GSS account.

GSS is generally used with resource assessment system linking to an annual accounting system where a portion of the resource assessment system is determined by the output of another system.

In the Resource Assessment Explorer, the Expression Editor dialog allows you to link two resource assessment systems using the Time of Evaluation tab. Normally, fields in the expression editor are lagged by a time-step (that is, they get their value from the last time-step to use in the current time-step). Enabling the During Resource Assessment checkbox results in the resource assessment system linked parameters being executed within the current time-step. As long as the resource assessment system appears above another resource assessment system in the hierarchical list, the values will be update-to-date in the time-step. Conversely, if one resource assessment system appears below a linked resource assessment system, its values will be lagged by a time-step.

General Security

This item (Figure 120) allows you to define accounting rules for accounts. The general security shares held by each water user is defined using the Accounts tab. The parameters that must be specified are described in Table 104.

Image Removed

In the example below, allocations have been defined to general security account should be simulated using the in-built continuous accounting functionality. There is a maximum balance of 2ML per entitlement share. This means that if a water user has an entitlement of 200 shares, their maximum account balance is 400ML. Two usage limits have been defined. The first says that no more than 1.25 ML can be used per entitlement share in any water year. The second says that no more than 3ML can be used per entitlement share in any 3 consecutive water years. These rules replicate the conditions for the Namoi river system.

Ownership and resource assessment

Resource assessment systems are generally used with ownership when one owner has borrowed from a second owner, and payback is required. One method of paying back water can be accomplished through a resource assessment system. Refer to Borrow and payback with resource assessment for further details on configuring this arragement in Source.

Where: flux is the loss in millimetres per day for the recurrent period defined by start through end
start is the first day of each year represented as dd-mmm (eg "01-Jan") on which flux begins
end is the last day of each year represented as dd-mmm (eg "01-Jan") when flux ends.

Item Name

Description

Time series Allocation

Allows you to define a time series file of volume to be allocated per unit share at that time-step. This volume is added to user’s accounts based on their number of shares.

Simulate Allocation

Determines the allocations to general security accounts which assess water availability.

Maximum Balance

Defines the maximum volume of water which can be held in an account. If an allocation results in this limit being exceeded, then the excess amount is redistributed to other accounts.
Choose Per Unit Share to define the maximum balance as a volume per share.
In IQQM, it is referred to as maximum proportion of entitlement that can be in storage

Minimum Balance

If a minimum balance is defined, then order or extractions will not be allowed if it will cause the balance to drop below the minimum specified. This is not included in IQQM.

Usage Limits

Period

Time period that the limit applies to - Moving Water Year or Moving Window.
If a usage limits relates to a single water year, choose Moving Water Year and Years set to 1.
Where a "rolling years" usage limit has been defined in IQQM for general security accounts, these should be defined as Moving Water Year limits in Source.

Quantity

Specify if the limit is Per Unit Share or an Absolute quantity. To replicate IQQM, set this parameter to Per Unit Share.

Years / Window

For a moving water year, enter the number of years the usage limit applies to. For a moving window, define the number of days that the usage limit applies to.

Quantity setting

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.

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.

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

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.

eWater Source version 3.0.1.

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

Assumptions and constraints are summarised in Table 88.

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.

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 a generic accounting system. These are further explained in the appropriate sections of this Scientific Reference Guide.

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

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

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.

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 the generic Simple system.

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 and Simple systems. There is a default trigger to invoke resource assessment in all system types other than Simple, this may be modified or deleted in Annual Accounting systems, but is hidden and cannot be changed in other system types.

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 Simple and 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 2 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.

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’ (e.g. 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 expression 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.

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 expression in one RAS that refers to recorded variables such as ‘account balance’ in the other RAS.

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

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

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

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

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.

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 entry on the Water User Node in this Scientific Reference Guide for more information.

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 entry in this Scientific Reference Guide on the Water User node and Supply Point node.

Input data vary depending on the type of system being used. Parameters common to many resource assessment systems, their account types and accounts are listed from Table 89 through Table 91. Triggers and usage limits may also be defined for most types of system. The input data for these are listed in Table 92 and Table 93. 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.

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.

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

* 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 and Simple systems.

+ Timesteps per assessment is not used in Simple systems and Off-Allocation systems. Standard trigger types are used to define the frequency of assessment for Simple systems. Off-allocation occurs when modeller specified conditions are met.

* 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. The Generic System Share account does not have such limitations defined, as it is assumed that they will be implemented in the nested or linked system that the account type represents.

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