Overview
Description and rationale
All ownership systems must have at least a global borrow and payback system, and can also include local borrow and payback systems as well. These allow for one owner to borrow water from another owner, with the requirement that there is payback of the borrowed water at a later time. Borrow and payback is necessary to allow the ownership system to function and it enables better and more flexible use of available water. When an exchange occurs, unallocated water owned by one owner is utilised by another owner. The water used by the other owner is termed a borrow and is reconciled against the borrowing owner’s water share. The borrow must be accounted for to determine how much water the borrowing owner should later pay back.
The actual rules that govern borrow and payback are likely to be highly specific to any given water management plan. Currently there is only one river system in Australia where borrow and payback is allowed, namely the River Murray (authorised via the Murray-Darling Basin Agreement). The implementation of borrow and payback in Source is principally designed to model the arrangements authorised in the Murray-Darling Basin Agreement, as followed in practice. However, the implementation is intended to provide sufficient flexibility that would enable it to be used for other ownership systems.
How a borrow is shared between owners using a distribution system, accounted and reconciled, in Source, is described here. For more information on how a borrow is generated, in the first instance see the Scientific Reference Guide entry for Ownership at nodes and links - SRG.
Scale
On a spatial scale, ownership applies to a river system or defined section of a river system. Source utilises the concept of an ownership system, which covers the section of a river system where the same set of owners share water in the river. It is possible for one modelling scenario to include multiple ownership systems. Ownership of water at each modelled location can be tracked at every model time-step.
Principal developer
This version of Borrow and Payback has been developed as part of the development of Ownership modelling by eWater CRC for Source.
Scientific Provenance
Borrow and Payback has been modelled in predecessors to Source, such as IQQM and MSM, for many years. The concepts in these models have been updated and enhanced to suit the needs of Source.
Version
Source version number 2.19.1.
Dependencies
The model configuration in Source must include at least one Ownership System with at least two Owners for borrow and payback to be modelled.
Availability
Automatically included with the full version of Source.
Structure & processes
Theory
Introduction
The Murray Darling Basin Agreement enables the operators in the River Murray to exchange the ownership of volumes of water between the states of New South Wales (NSW) and Victoria when the lending state has water surplus to its requirements. An example of this is when state owned tributary inflows are greater than expected. These excess tributary flows result in a state’s share of water in the river being surplus to that required to meet to meet its ordered requirements. Where possible, this excess water is utilised by the other state (owner) and the amount of water that needs to be released from storage is reduced. The water used by the other state (owner) is termed a borrow and is reconciled against the state’s water share. In the case of the River Murray, payback and account balances are reconciled at Lake Victoria.
The Agreement also allows for NSW and Victoria to borrow water from one another that is held in storage. As an example, NSW may borrow Victorian owned water held in Hume Reservoir if NSW has insufficient volume in Hume Reservoir to meet downstream demand (noting that NSW must have the capacity to payback the borrow). The Agreement requires that a separate account of borrow is maintained at some storages as:
- Different storages have different probabilities of spilling and filling. Thus water in some storages is more valuable.
- Water in Menindee Lakes and Lake Victoria can only be used to supply a very small amount of diversions.
Hence accounting is required for:
- System borrows – where unallocated water in the river is used to meet another owner’s order/requirement.
- Local storage borrow – where one owner has insufficient water in storage to meet downstream requirements and borrows from other owners’ shares in the storage.
To model borrow and payback arrangements similar to those described in the Murray-Darling Basin Agreement, Source supports a global borrow accounting system that applies throughout an ownership system, and also local borrow accounting systems for individual storages. The Agreement refers to an exchange of water, which indicates that when a state/owner borrows water, it needs to pay back to the owner it borrowed the water from. In a global system, payback can occur anywhere in the river network covered by the system of ownership. In a local system, payback must occur at the same storage. Payback can only occur when the borrowing owner has water within the relevant system (the ownership system or a storage) to transfer to the lending owner.
Modelling of borrow and payback is performed for every model element where there is a loss from or a gain to the river. These include:
- Inflow and confluence nodes
- Wetland hydraulic connectors
- Loss nodes
- Supply point nodes
- Controlled splitter nodes
- Storage nodes
- Links
Borrow and Payback accounting occurs mainly during the flow distribution phase, although some aspects of Borrow and Payback are also considered in the order phase.
Assumptions and constraints
Table 1. Assumptions and constraints
| No | Assumption/constraint |
|---|---|
| 1 | An ownership system must have a global borrow and payback system. |
| 2 | An ownership system’s global borrow and payback distribution hierarchy applies in all storages where there is no local borrow and payback system. |
| 3 | Borrow and payback systems only operate when ownership is enabled. |
| 4 | A borrow can occur anywhere in an ownership system when one or more owners has insufficient water to meet requirements. |
| 5 | When a global borrow and payback system is reconciled/paid back at a storage, the payback storage must maintain a local borrow and payback system. |
| 6 | For payback at a storage, owners are checked to see if they have to forfeit lending credit if they do not have enough airspace available. This is to ensure that the owner has enough capacity to be repaid. |
| 7 | When a global borrow and payback system is reconciled/paid back at a storage, all owners in the system must payback water at the same storage. |
| 8 | Borrow and payback accounting will occur prior to resource assessment. Resource assessment and accounting must consider the total sum of all borrows in the model, and thus includes:
|
| 9 | The borrow network for the global borrow and payback system must be complete. That is, there must be a connection between each owner and every other owner (the connection can be made at any priority level). |
| 10 | The borrow network for sharing a system constraint must be complete. An operator is not going to refuse service to an owner if there is surplus capacity available to use to serve them. |
Definitions
| Airspace | Difference between the volume in a storage (reservoir) and its full supply level. |
| Borrow | In systems with multiple owners, losses and gains are shared by defined ratios. In such cases it is possible for different owners to have surpluses and deficits in the use of these losses and gains. For efficient river operations these surpluses can be shared to owners with deficits. The borrow records the trading of these fluxes from owners with surpluses to owners with deficit. |
| Payback | This is the reverse of borrow; i.e. when the water that was lent to a particular owner is paid back by the borrower. |
| Borrow Network or Distribution System | System that prioritises the sharing of each owner’s surplus water to other owners with a deficit/insufficient water to meet their requirements. |
| Unallocated water | In the flow distribution phase, all water is either allocated (previously ordered) or unallocated. Unallocated water is not associated with a demand node or a non-consumptive requirement. Water that was ordered but not extracted on passing the node that generated the order, becomes unallocated water. |
Other definitions can be found in the eWater glossary.
Structure of Borrow and Payback Systems
Overview
When modelling borrow and payback, an ownership system for a scenario will have:
- A single global borrow and payback system that contains one or more member storages. Reconciliation and payback of borrow can occur in a specified storage, or on an ownership system wide basis. If payback is to occur at a storage, this storage must also be one that maintains a separate accounting system to that used for the global borrow and payback system.
- Zero or more local borrow and payback systems, each associated with a single member storage. The local system storage cannot be a member of any other local borrow and payback system. A local system’s storage may be used for reconciliation of the global system.
The structure of borrow and payback systems is illustrated in Figures 1 and 2, below.
Figure 1. Entity relationship diagram: Borrow and payback
Figure 2: Example of storage allocation to a scenario's borrow and payback systems
Figure 2 illustrates how each storage that falls within a scenario’s ownership system can only be a member of one borrow and payback system, except that where there is reconciliation/payback at a storage for the global system, this storage must also be in a local system.
Rules of the Borrow and Payback System (Summary)
Rules defining the borrow and payback system are listed below:
- Borrow is permitted to occur anywhere in the system. This applies to local systems as well as global systems. Note that where borrow in a storage is concerned, this is required only when one owner has run out of storage share.
- A borrow network/distribution system defines how any owner’s surplus water is shared amongst other owners. See Distribution of Surpluses for more information on how this is done. In a global system, every owner must be able to share to every other owner.
- In scenarios where ownership is configured, all storages must be members of a borrow and payback system. By default they are members of the global system.
- Individual storages can be configured to either:
- Account for borrows at a local level, which means that payback can only occur by ‘recolouring’ storage volumes. For example, any borrow in Hume Reservoir on the River Murray, must be paid back by reassigning water stored in Hume Reservoir.
- Account for borrows as part of a global borrow and payback balance. Note that borrows recorded under local borrow and payback systems are not included in the global set of accounts.
- For local borrow and payback systems and for global borrow and payback systems that are reconciled at a storage, the amount of borrow from other owners is limited by how much surplus the other owners have.
- A record of the net borrow between each of the water owners in an ownership system is maintained for:
- The global borrow and payback system (exclusive of storages configured to maintain local accounts)
- Each storage configured to maintain a local account of borrows. A storage configured to account for borrows locally does not participate in the global borrow account (i.e. borrows are not accounted in two places).
- Global borrow is either:
- Paid back in a storage: A user defined input parameter identifies the storage where balances are reconciled. This payback storage must have a separate, local borrow-payback system configured.
- Not explicitly paid back. Borrow balances adjust, in due course, as a result of the action of resource assessment systems (RAS). See Interaction with Resource Assessment Systems for a description of how this occurs.
- For local systems, or for global systems where a payback storage is nominated: Payback is attempted each time step at the storage. See Repayment of Borrow for more information on how this is done.
Distribution of Surpluses
The Murray Darling Basin Agreement only requires that borrow and payback occur between two state owners, so no specific rules have been required to determine how an owner shares out their surplus water when there is more than one other owner which could require it – i.e. those with a deficit. To allow the flexibility to meet future requirements, Source allows the modeller to configure for each borrow and payback system a ‘distribution system’ (otherwise referred to as a borrow network, see Assumptions and Constraints 9 and 10).
The distribution system specifies the list of owners that share at each priority level. Distribution of surpluses is performed in order of priority level, from ‘highest’ to ‘lowest’. Surpluses must fully meet requirements (deficits) at a ‘higher’ priority level before the next priority level is considered. Distribution within a priority level is proportional, i.e.:
- Owners with a surplus share their surplus in proportion to their share of the total surplus.
- Owners with a deficit receive surpluses in proportion to their share of the total deficit.
At an ownership system level, it must be possible for every owner to lend to every other owner, to ensure that water not required by one owner is available to any other owner that might need it. Hence for a global borrow and payback system, sharing must be enabled for every owner-other owner combination.
Repayment of Borrow
Payback of borrow occurs in the flow phase each time step. In a local borrow and payback system, the reconciliation and payback always occurs at the specified storage for the system. For the global borrow and payback system, the modeller must specify system’s reconciliation type to determine the ‘location’ at which payback occurs. Two reconciliation types are allowed for:
- System: When this is selected, there is no explicit payback process. Borrow balances are adjusted over time via the action of resource assessment systems.
- Storage: In this case, payback occurs at a selected storage that has a separate local accounting system. The modeller selects the storage from a list of those within the ownership system that have a local borrow and payback system.
The payback process occurs once the volume of water owned by each owner is determined. The amount each owner with debt can pay back creditor owners is limited by the volume of water they have in storage. The amount of payback a creditor can receive is limited by their airspace in the payback storage.
As with borrow, payback occurs in priority order. An owner’s debts at the highest priority level must be paid back before the next priority level is considered. Payback within a priority level is proportional, i.e. owners with a debt pay back the debt to each other owner in proportion to the other owner’s share of the owner’s total debt at the priority level.
Once each payback volume is determined, its ownership is simply transferred from the debtor owner to the creditor, and the borrow account is adjusted for the volume transferred. If full payback is not possible at a time step, the remaining debt is preserved, so it may be paid back in future time steps.
Interaction with Resource Assessment Systems
Resource assessment systems (RAS) take into account the borrow between owners when determining the volume of water available for allocation. In a global borrow and payback system without a payback storage nominated, payback is effected by adjusting the water availability in the resource assessment process and then letting the day-to-day borrows in the flow phase deal with moving the water back to the creditor.
For example, if there are two owners A and B, and A owes B 200 GL, and at resource 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
Owner A allocates 800 GL to its users and B 1200 GL. Later in the season after the users of owner B have used 1000 GL, B runs out of water and by borrowing starts to take back water from A (which has 200 GL in storage it can't allocate).
Methodology
Variables and Entities Used
Variables and entities used are listed in Tables 2-5, that follow. Rows highlighted in grey refer to entities. Each entity may have its own set of variables and/or methods, which are described in a separate table.
Table 2. Variables and entities: general
| Symbol | Purpose/Description | Units |
|---|---|---|
| Allocation(RAS) | Allocation for resource assessment system RAS | volume |
BPSystem BPSystem(RAS) BPSystem(ownersys) | Borrow and payback system. See Table 3 for variables and methods specific to this entity. BPSystem(RAS) is used to manage the same water resources as resource assessment system RAS BPSystem(ownersys) belongs to ownership system ownersys. | n/a |
| nBPSystem(RAS) | Number of borrow and payback systems that are used to manage the same water as resource assessment system RAS | n/a |
| nBPSystem(ownersys) | Number of borrow and payback systems that belong to ownership system ownersys. | n/a |
| component | Model component index. | n/a |
| nowner | Number of owners in the ownership system the borrow-payback system belongs to. | n/a |
| nowner(pl) | Number of owners that have a borrow & payback sharing relationship at priority level pl. | n/a |
| n_other_owner | Number of owners, other than the ‘current’ one, a total is being calculated for. | n/a |
| n_other_owner(pl) | Number of owners, other than the ‘current’ one, a total is being calculated for that have a borrow & payback sharing relationship at priority level pl. | n/a |
| ownersys | An ownership system | n/a |
| owner | Current owner in system | n/a |
| owner(pl) | Owner that has a borrow & payback sharing relationship at priority level pl. | n/a |
| other_owner | Owner that is not owner | n/a |
| other_owner(pl) | Owner that is not but has a borrow and payback sharing relationship with at priority level pl. | n/a |
| RAS | Resource assessment system | n/a |
| pl | Priority level for sharing | n/a |
| t | Time-step index | n/a |
The following variables relate to a Borrow and Payback system:
Table 3. Borrow and Payback System Variables
| Variable or method | Purpose/description | Units |
|---|---|---|
| *BorrowBalance(t, owner) | Owner’s cumulative borrow balance at time step – equals the sum for all other owners: NetBorrow(t, owner, other_owner) | volume |
| *ComponentBorrowBalance(t, component, owner) | Owner’s time step t borrow balance for borrowing done at component. | volume |
| *ComponentNetBorrow(t, component, owner, other_owner) | Net borrow between owner and other_owner for time step t, performed at model component - +ve value indicates owner does the borrowing, -ve value indicates owner does the lending | volume |
| *NetBorrow(t, owner, other_owner) | Cumulative net borrow between owner and other_owner at time step | volume |
| Share(pl, owner) | Flag (Yes or No) specified by modeller indicating whether an owner, owner, shares with other owners at priority level pl. For any two owners, owner and other_owner, they can share at priority level pl if Share(pl, owner) = Yes and Share(pl, other_owner) = Yes. | n/a |
| Connected(owner, other_owner) | Flag (Yes or No) indicating whether two owners, owner and other_owner, are able to share using the configured distribution hierarchy, and is derived from Share(pl, owner). These flags are set up and used for validating the distribution hierarchy used in a global borrow and payback system. | n/a |
*Recorded values
The following variables are used by the Borrow method in the order and/or flow phases:
Table 4. Variables & entities: Borrow Method
| Variable or method | Purpose/description | Units |
|---|---|---|
| Airspace(owner) | Owner’s share of the airspace in the payback storage for BPSystem in the current time step (input parameter). Airspace is the difference between the volume in storage and the full supply volume – each owner has a configured fixed percentage of this. | volume |
| Borrow(owner, other_owner) | Amount owner borrows from other_owner in this instance of sharing (calculated). This may be limited by airspace if it is within a storage. | n/a |
| component | Model component accessing the borrow method (input parameter). | n/a |
| BPSystem | Borrow system to use for the current round of sharing (input parameter). | n/a |
| Deficit(owner) | Deficit volume/capacity/flux per owner in the current time step (input parameter). | n/a |
| OwnerBorrowed(owner) | Total each owner borrowed from all other owners in this instance of sharing (output parameter). | n/a |
| OwnerLent(owner) | Total each owner lent to all other owners in this instance of sharing (output parameter). | n/a |
| Surplus(owner) | Surplus order/flux/capacity for owner in the current time step (input parameter). | n/a |
| TotalDeficit(pl) | Total of owner deficits at priority level pl (calculated). | n/a |
| TotalSurplus(pl) | Total of all owner surpluses remaining to be shared to other owners with a deficit at priority level pl (calculated). | n/a |
| UpdateAccounts | Input parameter that indicates whether borrow and payback system accounts should be updated. | n/a |
The following variables are used by the Payback method at a Storage Node in the flow phase:
Table 5. Variables & entities: Payback Method
| Variable or method | Purpose/description | Units |
|---|---|---|
| Airspace(owner) | Owner’s share of the airspace in the current time step (input and output parameter). Airspace is the difference between the volume in storage and the full supply volume – each owner has a configured fixed percentage of this. | volume |
| BPSystem | System to perform paybacks for (input parameter). This must be associated with the current storage. | n/a |
| CanPayback(owner, pl) | Maximum volume of debt owner can pay back to lending owners that share at priority level pl in BPSystem. This is limited by the owner’s storage share. (Calculated) | volume |
| CanReceive(owner, pl) | Maximum volume owner can receive this time step as payback for loans to other owners that share at priority level pl in BPSystem. This is limited by the owner’s airspace. (Calculated) | volume |
| component | Model component accessing the payback method (input parameter). | n/a |
| PaidBack(owner, pl) | Volume of debt owner paid back to all lending owners that share at priority level pl in BPSystem. (Calculated) | volume |
| Received(owner, pl) | Volume owner received as payback for loans to other owners that share at priority level pl in BPSystem. (Calculated) | volume |
| TotalCanPayback(pl) | Total volume all debtor owners that share at priority level pl in BPSystem can pay back lending owners using their storage share. (Calculated) | volume |
| TotalCanReceive(pl) | Total volume all lending owners that share at priority level pl in BPSystem can receive as payback from debtor owners into their airspace. (Calculated) | volume |
| Payback(owner, other_owner, pl) | The volume an owner paid back to the other_owner for sharing at priority level pl (Calculated). | volume |
| Storage(owner) | Owner’s share of the storage volume in the current time step (input and output parameter). | volume |
Model Configuration Phase
When an ownership system is created (e.g. when ownership is turned on), a default global borrow and payback system is also created that contains all storages within the ownership system’s boundaries.
The modeller then configures:
- Details of the global borrow and payback system.
- A local borrow and payback system for each storage for which one is required. Once a local borrow-payback system is configured, the storage is removed from the global system (e.g. see Figure 2).
The following must be configured for each borrow and payback system:
- Distribution hierarchy.
- Payback details
- Initial borrow balance between owners
Distribution Hierarchy
The list of owners that can share surpluses is specified for each priority level in each borrow and payback system. Source ensures that for a global system, each owner is represented, and can share with every other owner. In a local system, owners may opt out of sharing, or only share to some owners. In the methodology, this distribution hierarchy is described as BPSystemShare(pl, owner).
Example global system distribution hierarchy (where every owner can share with every other, but not necessarily at all priority levels):
| Owners | |||
| Priority | A | B | C |
| 1 | Yes | Yes | No |
| 2 | No | Yes | Yes |
| 3 | Yes | No | Yes |
In this example, with owners A, B and C, the connections required are AB, AC, BC. AB applies at priority level 1, AC at priority level 3, and BC at priority level 2.
Payback Details
The modeller must specify the global borrow and payback system’s reconciliation type to determine the ‘location’ at which payback occurs and, if required, the storage where this is to occur, as discussed in the section Repayment of Borrow, above.
Initial Balance
An initial net borrow value is configured for each owner / other_owner combination in each borrow and payback system: BPSystemBorrow(0, owner, other_owner). A negative value indicates that an owner owes other_owner, a positive value indicates that the other_owner owes the owner. During the configuration phase, Source calculates each owner’s initial borrow balance, and ensures the total of all these balances adds up to zero, i.e.:
Model Initialisation Phase
During model initialisation, Source associates all nodes and links with the global borrow and payback system except storage nodes that have local borrow and payback systems which are not the global system payback location.
Start of Time Step
Borrow and payback accounts are cumulative, so it is necessary to carry over borrow and payback totals from the previous time step to the next one. This is done for each borrow and payback system being modelled:
The accounts for each individual model component that falls within a given borrow and payback system boundary are NOT cumulative, so these start at zero every time step:
Each model component uses the methods described in the following sections to update the relevant borrow and payback system’s accounts in the flow phase for any borrow/lending that occurs at the model component.
During Time Step: Order and Flow Phases
Borrow
Borrow needs to be considered in both the order and flow phases. However, borrow and payback accounting occurs in the flow phase, as it is only at this stage that the flow borrowed/paid back is known.
- Order phase - There is a potential to reduce upstream orders through borrowing of tributary inflow. See Ownership at Inflow and Confluence Nodes - SRG for details.
- Flow phase - An owner can have a delivery shortfall as a result of higher than expected losses, lower than expected tributary inflows, or the use of its water by another owner that was planned in the order phase. If there is surplus water in the river at the point where the shortfall occurs, the owner with the shortfall can borrow from other owners.
Input parameters required
BPSystem - The borrow and payback system to use in determining distribution rules and, where relevant, updating accounts. Borrow and payback system(s) are associated with each model node and link during model initialisation.
component - Model component using this borrow method, needed for updating accounts.
Surplus(owner), Deficit(owner) - The current ‘surplus’ and ‘deficit’ volume/capacity for each owner. At a storage node, surplus water is any water that is not required to meet downstream requirements in the current time step. This definition may vary between model components, and between the model phases (order or flow). Refer to the SRG entry for the appropriate model component for more information.
Airspace - Each owner’s share of airspace in the borrow and payback system’s payback storage (when there is one). This is needed to limit lending.
UpdateAccounts - Borrow accounting only needs to occur in some circumstances, as described above. This parameter is set or reset according to whether or not borrow accounts are to be updated.
Output parameters
The borrow method returns the volume each owner borrowed and lent for the time step (OwnerBorrowed(t, owner), OwnerLent(t, owner), OwnerBorrowed(t, owner, other_owner), OwnerLent(t, owner, other_owner)) to the relevant component so that the payback requirement can be adjusted (see examples at the end of this SRG entry). Borrowed volumes are subtracted from, and loaned volumes added to, the requirement.
Steps
The following steps describe how surpluses are distributed within the given borrow and payback system BPSystem. Note that an owner can participate in sharing at a priority level (is in the owner(pl) and other_owner(pl) lists) when BPSystem.Share(pl, owner) = Yes.
- Start with zero borrow between all owners:
If the borrow and payback system BPSystem is a local system and this method is used in the flow phase to lend water (UpdateAccounts = Yes), limit the surplus amount each owner can lend to their airspace (to ensure payback is possible).
(This should not be done for global systems, as it is possible for ownership to get out of synchronisation at different points in the system, so temporary incompatibility between airspace and balances must be allowed to occur)Share surpluses to owner’s with a deficit. Surpluses are shared to owners that participate in sharing at the same priority level and have a deficit in proportion to their deficit. Where surpluses exceed deficits, the volume of the owner’s surplus distributed to other owners is in proportion to their share of the total surplus:
For each priority level pl represented in the configured distribution table – PSystem.Share(pl, owner), do the following:Calculate the total surplus and deficit remaining to be shared at the priority level (this is the sum for all owners sharing at the priority level):
If there is no surplus and/or deficit (TotalSurplus(pl) = 0 or TotalDeficit(pl)=0), sharing at the priority level is finished, so skip to the next priority level.
For each owner and other owner that share at this priority level pl (Share(pl, owner) = yes and Share(pl, other owner) = yes), calculate the volume owner can borrow from the other owner at the priority level:
Update the surpluses & deficits left over for sharing at the next priority level:
- Find the owner’s borrow and lending totals to return to the relevant model component:
If the UpdateAccounts flag is set,
Update the reported borrow accounts for the current component and the borrow and payback system as a whole:
Payback at a Storage (Flow Phase only)
The payback process at a ‘payback’ storage node is performed at the end of the flow phase, when storage releases have been made (so requirements have been met as far as possible).
A payback storage either has a local borrow and payback system, or is the specified payback storage for a global borrow and payback system. When a storage is the payback storage for a global borrow and payback system, Source runs the payback process twice, first to reconcile its global accounts, then to reconcile its local accounts.
A running account of net borrow between all owners is maintained for each borrow and payback system – BPSystem.NetBorrow(t, owner, other owner). This amount is positive when the owner has a debt to the other owner, and negative when the owner has lent to the other owner. Debt is paid back by reassigning ownership of water in the storage.
Debtors pay back creditors with their share of storage, until no more is owed or the creditor runs out of airspace. Debts between owners that share at higher priority levels are fully paid before any debts at lower priority levels are processed. At the same priority level, where owners have insufficient storage to repay debts, they pay creditors pack in proportion to how much is owed.
For more details on payback at a storage see Ownership in Storages - SRG.
Time step: Resource Assessment – Water Accounting Phase
In this phase, allocation of each owner’s resource assessment systems (RAS) must be adjusted for the net borrow between owners recorded in borrow and payback system accounts. Each RAS will belong to an ownership system, that has a global borrow and payback system. A RAS may also be associated with one or more local borrow and payback systems (if it is used to manage storages). The allocation of each RAS should be adjusted as follows:
More details regarding the way resource assessment systems are configured and allocate water are given in Resource Assessment - SRG and its sub-pages.
Data
Input data
Details on data are provided in the Source User Guide.
Parameters or settings
Parameters are listed in Tables 6-8, which follow.