skip to main content
Accounting Overview
Accounting
Accounting Overview
This section provides detailed information on the Accounting system and how it works including background material, definitions, solution algorithms, and description of accounting methods and slots. In particular, first we describe the requirements for water accounting. We then discuss supplies, object level accounting methods, and the controllers used to solve the accounting system. Then we present the different types of accounts, their slots, solution algorithms and properties of accounts. Next, we describe how to use the accounting user interface and some of the utility features. We describe exchanges and give some examples and finally we present the water rights allocation solver.
Topics
Motivation and Requirements for Accounting
River and reservoir basins are operated for various purposes including power production, irrigation, environmental purposes, recreation, and water quality. In many of those basins, it is necessary for water managers to track not only the volume and flow of water throughout the basin, but managers must also track the water ownership and type of the water. Operating decisions in the basin are dependent on many aspects including a user’s available water, legal restrictions, physical constraints, and any exchange mechanism. In addition, many of the basins in the United States are governed by the doctrine of Prior Appropriation which says that the right to use a water supply is based on First in time, first in right. Because of these constraints, it is necessary for water managers to have a tool to simulate the operating decisions and their effect in the basin including water type and water ownership.
The requirements for such a simulation tool are as follows:
• Must track ownership and type of water through all basin features and at all timesteps
• Flexible to model accounting in any basin with unique policies and structure
• Operating decisions must look at and set account, transfer and exchange values
• Must be able to allocate water based on the Water Right Priority date
• Must be able to visualize the accounting network
Water Accounting in RiverWare
RiverWare meets these requirements through water accounting. Simply, water accounting is a layer added to a simulation model used to track the ownership and type of the simulated water. The following box highlights how these requirements are met by the RiverWare water accounting functionality. These pieces are described in the following text as an introduction to water accounting and in more detail in this document.
 
Water accounting in RiverWare
• Physical and paper water are modeled separately.
• There is a separate network of accounts on the simulation objects.
• Accounts are linked indicating the possible transfers.
• Legal Accounts – Storage, Diversion, Instream Flow.
• Non Legal - Passthrough accounts track transfer of water between legal accounts.
• Accounts are labeled by ownership and type and can be given a priority date.
• Rules can access accounting information and also set account transfers.
• Can simulate water accounting components like accrual, exchanges, carryover, allocation, etc.
• A solver allows the user to allocate water to legal accounts based on the priority date.
In an accounting model, accounts, slots, and data are added to track why water is released, stored, or diverted. These additional components include water ownership, type, and purpose as water moves through the basin. This network is separate from the simulation network but there are methods that allocate physical water to the accounting network.
Accounts are linked to one another on both the same object and on different objects. These links indicate the possible transfers of water in the system. By defining a link, the user indicates that at some timestep, water could move between the two linked accounts. Legal accounts, including Storage, Diversion, and Instream Flow, are used to model a legal water right. Passthrough accounts are used to track the transfer of water through basin features. With both legal and non-legal accounts, the user can look at any object in the basin and determine the type and ownership of all of the water in that object.
Rules can access the account solution but can also control and set the releases from the accounts. User inputs can also drive the account solution. Using rules and other accounting utilities, the user can simulate typical accounting functionality including accrual, exchanges, carryover, and allocation. In addition, a special predefined rule function and set of methods serves as a water rights allocation solver to allocate water to legal accounts based on prioritized water rights.
Model Purpose
Water accounting can be used for a number of purposes. These include after-the-fact accounting, daily operations, and long term planning as described as follows:
After-the-fact Accounting
An after-the-fact accounting model is used on a timestep by timestep basis to track the type and ownership of water that was released the preceding timestep. For example, a water district might release water for a number of specific purposes on a given day. The following day the gaged data is imported into the model and final storages, evaporations, and losses can be calculated. The water district is able to then track how those actual releases and losses in the system should be charged to the various uses. This is considered an after-the-fact accounting model because the physical volumes, losses, and flows are known; the accounting model must calculate how those operations should be charged to the users in the basin. Often this is an exercise in book-keeping.
Short-term Operations
A short-term operations model uses information from the previous days and forecasts to determine the operations for future timesteps. If the operations depend on the amount of water available to specific users in the basin, then an accounting system is necessary to track how those releases will be made. In practice, rules set releases after looking at the balance on a certain account. For example, if a user requests a release, but that user has no available water in the accounting system, no physical release can be made.
Long-term Planning
Long term planning models are used to determine the effect operations have on a longer time scale. If the operations depend on water ownership or type in the basin, then an accounting model can be used to track those pieces. The model must look at the state of the system including water ownership and type at each timestep and determine the operations to perform.
Often, water managers may use each of the three types of accounting models in a basin for water management. An after-the-fact accounting model is used each timestep to account for the previous timestep. The results from the after-the-fact model are fed into a short-term operations model to determine upcoming operations. Finally, a long term planning model is used for impact analysis, yield determination, and other planning related purposes. The structure, i.e. the physical layout of objects and accounts in the model, are the same in each model, only the operating policy rules and data are different.
Physical Versus Paper Water
Let us develop some definitions to better discuss the accounting system. Physical Water is modeled using the simulation objects and does not have a unique classification. For example, the outflow from a reservoir is considered physical water. It may be released for a number of downstream purposes, but the total outflow is the value on the Outflow slot.
 
Physical Water
Water that is simulated by the RiverWare objects. This water represents the total Inflow, Outflow, and/or Storage not considering the use, ownership, or type of the water.
To contrast physical water, in the accounting system there is Paper Water (sometimes called colored water). This is the water that has a specific owner or type that must be tracked.
 
Paper Water
Paper water is simulated in the accounting system to track ownership or type. It is called paper water because it is often tracked on paper and may be one of many components of the physical water.
About Accounts
To track the paper water that is moving through the system, accounts are created on the simulation objects. An account is an object used to track the inflow, outflow, and storage of paper water on the simulation object. Like simulation objects, given the required knowns, the accounts can solve for certain unknowns.
 
Account
An account is an object used to track the balance of paper water with a given type and/or ownership on a simulation object.
Account Types
Accounts can be defined as either legal accounts or passthrough accounts. The types of allowable accounts depend on the type of simulation object on which the account resides.
Legal accounts
The types of legal accounts are as follows:
• Storage account. These accounts have a legal right to store water. See “Storage Account” for details.
• Diversion account. These accounts have a legal right to divert or consume water. See “Diversion Account” for details.
• Instream flow account. These accounts have a legal right to a certain flow rate of water in the river. See “Instream Flow Account” for details.
Passthrough accounts
Passthrough accounts do not have a legal right to water. They are used to connect legal accounts and to show how much paper water is on an object at a given timestep. See “Passthrough Account” for details.
Account Level Methods
Accounts have user-selectable methods that control how the accounts behave. For example, the user can select a carryover method where all of the storage in the account carries over from one water year to the next. Alternatively, the user can configure the account such that the storage in the account is reset at the beginning of the water year. Provided for each account in “Account Reference” is a description of each category and the methods in that category including the method-specific slots.
Account Solution Equations
Accounts solve when they have the required information. Unlike simulation, accounts typically solve in the downstream direction. Storage accounts usually solve for Storage and passthrough accounts usually solve for Outflow, but never for Inflow. Each type of account is described in more detail in the “Account Reference” including the solution equations for each type of account. See “How the Accounting System Solves” for additional information on how the accounting system solves.
Account Properties
In addition to the slots that reside on each account, there are variables that can be used to describe the account including Water Type and Water Owner. These properties are used to keep accounts clearly identified and, as we will see later, used by predefined functions to access the correct account.
Water Type
Water Type is a property of an account that can be used to describe that account. Typically, Water Type is used to classify where the water originated or where it is going. For example, in a model with a trans-basin diversion, the user could define two water types, Type A and Type B, one for each basin. When water is diverted trans-basin, the Water Type can be used to track water from basin A when it is in basin B. The default Water Type is NONE.
Water Owner
Water Owner is another property of accounts used to classify or describe an account. Typically, the Water Owner is used when a volume of water is owned by a specific user who wishes to track that water through a basin. For example, a city might own a set volume of water in an upstream reservoir. The default Water Owner is NONE.
By defining both Water Type and Water Owner, the user can track the classification of a wide range of water. If we combine the two examples above, the city might own some of the trans-basin water but cannot use it until it is diverted from Basin A to Basin B and flows downstream to the city. By defining both Water Type and Water Owner, the city can track that the water released for the city (which is located in Basin B) is from Basin A and owned by the city.
The Water Owner and Water Type are defined in the Accounting System Configuration and apply to a specific model. When configuring an individual account, the default Water Owner and Water Type is NONE but can be changed by the user.
Priority Date
Legal accounts (Storage, Diversion, Instream Flow) can have a priority date associated with the account. Specified in the account’s configuration dialog, the priority date is a fully specified date and time. If the Water Rights method is selected on the Account, then a Priority Date must be specified and vice versa. The Priority Date is used by the water rights allocation solver to allocate flow to the account. See “Water Rights Allocation” for details.
About Supplies
Accounts, defined on the simulation objects, track water as it moves through the network. Accounts are connected to other accounts by an entity called a Supply.
 
Supply
A supply links two slots on two accounts. Specifically, a supply to an account means that paper water is transferred into that account from another (often upstream) account.
The term supply comes from the relationship between the two accounts. The account on the upstream end of the link supplies the downstream account with water. Similarly, the downstream account has a demand on the upstream account. When looking at a given account, there may be supplies coming into the account and demands leaving the account. We can also say that there are supplies to the accounts and that the account has demands. The demand to one account is also considered a supply to the downstream account. As a result, we refer to all of the links in the accounting system as Supplies.
Supplies are workspace objects, like a Storage Reservoir or Reach simulation objects. Because they are workspace objects, supplies are referenced by RPL using a different syntax than simulation slots. This syntax used to reference a supply is “SupplyName.Supply”. This is described in more detail in later chapters.
Typically, there are multiple supplies both entering and leaving an account. Supplies can connect two slots on the accounts on the same simulation object or on other simulation objects as long as there is a physical simulation link between the two objects. In addition, there may be multiple supplies connecting the same two accounts.
Supply Names
By default, the supply name indicates the from object, the from account, the text “to”, the to object, and to account. For Diversion/Return Flow and Transfer supplies (see next section), the string “Div” and “Tran” are appended, respectively.
The format for supply names can be controlled by the user in the Supply Name Format dialog. (See “Supply Name Format” for details.) The format specified in this dialog is applied to new supplies and can be applied to existing supplies from the Supply Manager. The user can also individually set supply names from the Open Account dialog Supplies tab. See “Configuring Accounts Through the Open Account Dialog” for additional information.
Types of Supplies
When a supply is created, the user must select how the supply is going to be used. In the supply creation menu, the user can select one of the following supplies classifications. The selected type determines which slots will be linked.
Note:  A link in the physical or simulation system must exist to create a supply between two accounts.
Inflow/Outflow
A supply connecting an inflow on an account on one object and an Outflow on an account on another object. These are used to represent the water that is moving from one object to another as an outflow to an inflow. The supply is created from the downstream account to the upstream account.
In Figure 1.1, an Inflow/Outflow supply connects the following:
Reservoir^Fish.Outflow to Reach^Trout.Inflow and Reservoir^Fish.Outflow to Reach^Minnows.Inflow
Figure 1.1  Inflow/Outflow example
Diversion/Return Flow
A supply connecting a Diversion (or Return Flow) on an account on one object to a Diversion (or Return Flow) on an account on another object. These supplies are used to represent water that is diverted from one object to another. They are also used to represent return flows from one object to another. A supply connecting Diversion slots is created starting at the receiving object, typically a water user. A supply connecting Return Flow slots is also created by starting at the receiving object, in this case, it is usually the reach or reservoir object.
In Figure 1.2, a Diversion/Return Flow supply connects the following:
Reservoir^Project.Diversion to Farms^AppleOrchard.Diversion and Farms^AppleOrchard.ReturnFlow to Reservoir^Project.ReturnFlow
Figure 1.2  Diversion/Return Flow example
Transfer
A supply connecting a Transfer In on an account to a Transfer Out on another account on the same object. These supplies are used to represent water that is transferred from one account to another on the same object. The supply is always created starting at the receiving account, the one that is receiving the Transfer In.
In Figure 1.3, a Transfer type supply connects the following:
Reservoir^Project.Transfers Out to Reservoisr^Fish.Transfers In
Figure 1.3  Transfer type supply example
Supply Properties
Accounts have optional Water Type and Water Owner properties that can be used to classify and label the accounts. Similarly, Supplies have properties that can be used to label the purpose and/or classify the account. These optional properties are called Release Type and Destination Type and are described as follows:
Release Type
Supplies can be labeled according to their release type. For example, a release may be made for environmental flow purposes.
Destination Type
In addition, supplies can be labeled according to their Destination Type. For example, a release may be made from a reservoir to be used at a downstream water user.
Thus, using the Release Type and Destination Type properties, the user can specify both the reason for releases and where the water is ultimately headed. For example, a release might be made for flood control purposes but can also be diverted downstream for use in a groundwater recharge structure.
The Release Type and Destination Type are defined in the Accounting System Configuration and apply to a specific model. When configuring an individual supply, the default Release Type and Destination Type is NONE but can be changed by the user.
Setting Values With a DMI
If a DMI is used to bring in values to account inflows, outflows or transfers, it should set supplies in the accounting system rather than accounting slots. This is similar to the concept of setting supplies with rules; see “Setting Slots Versus Setting Supplies” for details.
Object Level Accounting Methods (OLAMs)
In simulation, local inflows and gains/losses are typically input by the user, set by rules, or calculated by methods on the objects. For example, local inflows to a reservoir may be input on the Hydrologic Inflow slot and daily Evaporation may be calculated from a monthly table. These components represent a change in the physical amount of water in the object and must also be represented by the accounting system.
Object Level Accounting Methods (OLAMs) are used to allocate physical gains and/or losses to the accounting system. They can also be used to reconcile the physical and accounting systems. They are called object level because they allocate water from a given simulation object to one or more accounts on that object.
 
Object Level Accounting Methods (OLAMs)
Object Level Accounting Methods are used to allocate physical gains, losses, and local inflows on an object to accounting slots on that object. In addition, they can be used to reconcile the physical and accounting system.
There are two types of OLAMs, Compiled and User-defined. See the following sections for details:
Compiled Accounting Methods
 
Compiled accounting methods
Compiled accounting methods are hard-coded Object Level Accounting Methods. These methods were created by CADSWES and are available in a library. They represent either commonly used functionality or methods that are too complex to represent as user-defined methods.
Examples of compiled accounting methods include commonly used methods like the Zero Slot Inflow method in the Reservoir Account Slot Inflow category which assigns zero to each account’s Slot Inflow. In addition, there are complex methods that were too difficult to implement in RPL. For example, there is the Heron Inflow Calculation; a method specific to basins that have Rio Grande water types. Table 1.1 briefly describes each of the compiled methods. The default method for each category is shown in italic; the general methods are also described in more detail after the table.
 
Table 1.1  Compiled accounting methods summary
Object / Category
Method
Description
Agg Diversion Account Reconciliation
No Method
No action - never executed
Bifurcation Account Slot Inflow
No Method
No action - never executed
Zero Slot Inflows
Sets all Slot Inflows to 0.0. See “Zero Slot Inflows” for details.
Confluence Account Slot Inflow
No Method
No action - never executed
Zero Slot Inflows
Sets all Slot Inflows to 0.0
Rio Grande Inflow 2
Confluence^RioGrande.Slot Inflow is set equal to the Inflow 2. All other accounts’ Slot Inflow set to 0.0
Sidewater Inflow 2
Distribute Confluence.Inflow 2 to the Floriston Rate and Undes account Slot Inflow.
Control Point Account Slot Inflow
No Method
No action - never executed
Zero Slot Inflows
Sets all Slot Inflows to 0.0
Copy Slot to Slot Inflows
On the specified account, set the Slot Inflow equal to the Local Inflow. Set all other Slot Inflows to 0.0. See “Copy Slot to Slot Inflows” for details.
Distribution Canal Account Slot Inflow
No Method
No action - never executed
Zero Slot Inflows
Sets all Slot Inflows to 0.0
Diversion Object Account Slot Inflow
No Method
No action - never executed
Zero Slot Inflows
Sets all Slot Inflows to 0.0
Inline Pump Account Slot Inflow
No Method
No action - never executed
Zero Slot Inflows
Sets all Slot Inflows to 0.0
Pipe Junction Account Slot Inflow
No Method
No action - never executed
Zero Slot Inflows
Sets all Slot Inflows to 0.0
Pipeline Account Slot Inflow
No Method
No action - never executed
Zero Slot Inflows
Sets all Slot Inflows to 0.0
Reach Account Slot Inflow
No Method
No action - never executed
Zero Slot Inflows
Sets all Slot Inflows to 0.0.
Reconcile Rio Grande Outflow
Rio Grande Local Inflow
Reach^RioGrande.Slot Inflow is set equal to the Reach.Local Inflow. All other accounts’ Slot Inflows are set to 0.0. See “Rio Grande Local Inflow” for details.
Provo River Local Inflow
Reach^ProvoRiver.Slot Inflow is set equal to the Local Inflow.
NIC Local Inflow
Reach^NIC.Slot Inflow is set equal to the Local Inflow.
Copy Slot to Slot Inflows
On the specified account, set the Slot Inflow equal to the Local Inflow. Set all other Slot Inflows to 0.0. See “Copy Slot to Slot Inflows” for details.
Reach Account Gain Loss
No Method
No action - never executed
San Juan Gain Loss
Sets Gain Loss on accounts with water types Rio Grande and San Juan. Many accounting slots are registered as dependencies.
Reservoir Account Slot Inflow
Reservoirs:
Storage
Level Power
Sloped Power
Pumped Storage
No Method
No action - never executed
Zero Slot Inflows
Sets all Slot Inflows to 0.0
Heron Inflow
Sets Slot Inflow on accounts with water types Rio Grande and San Juan. Many accounting slots are registered as dependencies. See “Heron Inflow” for details.
Pooled Account Slot Inflow
Pooled.SlotInflow is set equal to the object’s Hydrologic Inflow Net
Donner Inflow
Basin-specific
Prosser Uncomm
Basin-specific
Copy Slot to Slot Inflows
On the specified account, set the Slot Inflow equal to the Hydrologic Inflow. Set all other Slot Inflows to 0.0. See “Copy Slot to Slot Inflows” for details.
Reservoir Account Gain Loss
Reservoirs:
Storage
Level Power
Sloped Power
Pumped Storage
No Method
No action - never executed
Heron Gain Loss Calculation
Sets Gain Loss on accounts with water types Rio Grande and San Juan. Many accounting slots are registered as dependencies. See “Reservoir Account Gain Loss Category” for details.
El Vado Loss Calculation
Nambe Falls Loss Calculation
Elephant Butte Loss Calculation
Elephant Butte Loss with RG Compact
Sets Gain Loss on accounts with water types Rio Grande and San Juan Includes logic for the RG Compact. Many accounting slots are registered as dependencies. See “Elephant Butte and El Vado Gain Loss” for details.
Abiquiu Loss Calculation
Sets Gain Loss on accounts with water types Rio Grande and San Juan. Many accounting slots are registered as dependencies. See “Abiquiu, Cochiti and Jemez Gain Loss” for details.
Jemez Loss Calculation
Cochiti Loss Calculation
Reservoir Account Reconciliation
No Method
No action - never executed
Water User Account Reconciliation
No Method
No action
Stream Gage Account Slot Inflow
No Method
No action - never executed
Zero Slot Inflows
Sets all Slot Inflows to 0.0
Reconcile Rio Grande Outflow
All Rio Grande
Sets Slot Inflow on accounts with water types Rio Grande
All San Juan Chama
Sets Slot Inflow on accounts with water types San Juan
General and Commonly Used Compiled Methods
Following are descriptions of general and commonly used compiled methods. Each method is executed according to its selected execution time; the default execution time is listed in the method description. See “Reconciling the Accounting and Physical Systems” for additional details.
* No Method
The default No Method is a no-action method and does nothing. In fact, the method has a static execution time of “Never”, meaning it will never execute.
* Zero Slot Inflows
The Zero Slot Inflows method on many of the object’s account slot inflow category sets the Slot Inflow to 0.0 for each account. By default, it is executed once at the beginning of the run, but the user can change this if desired.
* Copy Slot to Slot Inflows
The Copy Slot to Slot Inflows method copies the object’s local inflow to the target account’s Slot Inflow and sets the other accounts’ Slot Inflow to zero. See “Copy Slot to Slot Inflows”.
Slots Specific to This Method
Selecting the Copy Slot to Slot Inflows method instantiates the following slot.
Target Account
Type: List Slot
Units: No Units
Description: This slot contains one account on the object. This account’s Slot Inflow will be set equal to the local inflow.
Only one account is allowed in this list and the account must be on the same object as this slot. Also, the account must be a storage or passthrough account. This slot can be set (by account name, water type, or water owner) for many objects at once using the Multiple Object Method Selector. See “Multiple Object Method Selector” in User Interface for details.
I/O: Required Input
Method Details
The method is available only in the <Object> Account Slot Inflow category on the following objects with one of the specified local inflow methods selected.
 
Table 1.2   
Object
Local Inflow Category
Possible methods
local inflow slot
Control Point
Local Inflow
Input Local Inflow
Local Inflow
Reach
Local Inflow and Solution Direction
Specify Local Inflow, Solve Inflow or Outflow
Specify Local Inflow, Solve Outflow
Solve Inflow, Outflow or Local Inflow
Contingent Local Inflow or Solve Outflow
Local Inflow
Reservoirs: Storage, Level Power
hydrologicInflow
CalculationCategory
solveHydrologicInflow
inputHydrologicInflow
Hydrologic Inflow and Loss
Hydrologic Inflow
Reservoirs: Sloped Power, Pumped Storage
hydrologicInflow
CalculationCategory
inputHydrologicInflow
Hydrologic Inflow
The Copy Slot to Slot Inflows method will first assign zero to the current timestep value of the Slot Inflow slot of all accounts on the object. It will then copy the current timestep value in the object’s local inflow slot (as shown in Table 1.2) to the specified Target Account’s Slot Inflow slot. By default this method will be given an execution time of Beg of Timestep Once meaning it will be executed once at each timestep before simulation starts. This execution time can be changed by the user. See “Copy Slot to Slot Inflows” for details.
User-defined Accounting Methods
User-defined Accounting Methods are created by the user in the RiverWare Policy Language (RPL).
 
User-defined Accounting Methods
User-defined Accounting Methods are Object Level Accounting Methods created by the user in the RiverWare Policy Language.
For example, User-defined Accounting Methods can be used to specify how Hydrologic Inflow on a reservoir is allocated to the accounts on that reservoir or how the seepage in a reach is charged to the passthrough accounts on the reach. Often the methods depend on policy decision and are not physically based. For example, seepage in a reach may be charged only to the allocatable flow for that reach, not to any of the other water released from upstream reservoirs for downstream diversions. As a result, the methods are basin-specific and must be created for each basin.
Because the methods are basin-specific, the user must define and configure these methods for each basin. On storage and passthrough accounts, there are slots called Slot Inflow and Gain Loss. These are the slots in the accounting system that are set by the User-defined Accounting Methods to allocate local inflows and apportion gains and losses, respectively. This is done in the RiverWare Policy Language (RPL) using the Accounting Method Set Editor. In this editor, there are preconfigured policy groups for the allowed Objects/Accounts and the intended actions. For example, there is a policy group for the Reservoir Account Slot Inflow and Reservoir Account Gain Loss. These policy groups correspond to categories on the appropriate object.
 
In DeepLake, the Hydrologic Inflow is shared equally amongst three accounts in a Deep Lake: A, B, and C. The Storage Account Slot Inflow method would be the following:
• DeepLake ^ “A.Slot Inflow”[] = DeepLake.“Hydrologic Inflow”[] / 3
• DeepLake ^ “B.Slot Inflow”[] = DeepLake.“Hydrologic Inflow”[] / 3
• DeepLake ^ “C.Slot Inflow”[] = DeepLake.“Hydrologic Inflow”[] / 3
When the user creates a new Method in one of these policy groups, the new method appears as a method in the appropriate category on the object’s Accounting Methods tab and can be selected by the user. By selecting this method on the object, the user is telling the object that the selected User-defined Accounting Method should apply to the accounts on that object. As a result, the method created for each object applies to all of the accounts on the object. Multiple assignment statements may be necessary to set all necessary slots.
Table 1.3 lists the policy groups / categories in the Accounting Method Set Editor and the associated objects and the accounts to which they apply
 
Table 1.3  Accounting Method Set Editor policy groups, associated objects, and applicable accounts
Policy Group / Category
Object
Account(s)
Agg Diversion Account Reconciliation
Aggregate Diversion
Diversion
Bifurcation Account Slot Inflow
Bifurcation
Passthrough
Confluence Account Slot Inflow
Confluence
Passthrough
Control Point Account Slot Inflow
Control Point
Passthrough
Distribution Canal Account Slot Inflow
Distribution Canal
Passthrough
Diversion Object Account Slot Inflow
Diversion Object
Passthrough
Inline Pump Account Slot Inflow
Inline Pump
Passthrough
Pipe Junction Account Slot Inflow
Pipe Junction
Passthrough
Pipeline Account Slot Inflow
Pipeline
Passthrough
Reach Account Gain Loss
Reach
Passthrough
Reach Account Slot Inflow
Reach
Passthrough
Reservoir Account Gain Loss
Storage Reservoir
Level Power Reservoir
Pumped Storage Reservoir
Sloped Power Reservoir
Storage and/or Passthrough
Reservoir Account Reconciliation
Storage Reservoir
Level Power Reservoir
Pumped Storage Reservoir
Sloped Power Reservoir
Storage and/or Passthrough
Reservoir Account Slot Inflow
Storage Reservoir
Level Power Reservoir
Pumped Storage Reservoir
Sloped Power Reservoir
Storage and/or Passthrough
Stream Gage Account Slot Inflow
Gage
Passthrough
Water User Account Reconciliation
Water User
Diversion
User-defined Accounting Methods, although written in RPL, do not behave the same as rules. Although the methods are prioritized in the method set editor, the priority is not used. Instead, there can only be one method selected for each object. The methods execute according to their specified execution time. See “Reconciling the Accounting and Physical Systems” for additional information.
Figure 1.4  Object Level Accounting Method Set Editor
Although the methods are specific to a basin, there are a few features that can be used to generalize the methods. The keyword ThisObject (there is no space) can be used in place of a specific object name. When called, it will replace this with the name of the object from which the method is called.
 
Example 1.1   
Following is a reach Pass Through Gain Loss method that makes use of the “ThisObject” syntax. It would be useful on this basin because each reach has two accounts, Fish and Farmers. The Fish account gets charged with all loss, Farmers get none. Each reach in the model could then use this method.
ThisObject ^ “Fish.Gain Loss”[] = ThisObject. “Total GainLoss”[]
ThisObject ^ “Farmers.Gain Loss”[] = 0 [“acre-feet”]
Note:  Gain Loss in the accounting system is a volume.
 
Example 1.2   
Following is an example setting all of the account’s Slot Inflow to zero using a ForEach loop (note, this is just a sample method, this functionality can be accomplished much more easily using the compiled Zero Slot Inflows method, as follows. See “Zero Slot Inflows”.
FOREACH (STRING account IN AccountNamesByAccountType(ThisObject, “ALL”))
ThisObject^(account CONCAT “.Slot Inflow”)[] = 0 [“cfs”]
ENDFOREACH
Note:  See “Creating, Editing, and Viewing RPL Sets” in RiverWare Policy Language (RPL) for additional information on RPL and its uses.
Execution of OLAMs
Object Level Accounting Methods provide flexibility in when they can be executed, what they set, and the data required. This section describes the execution times and some additional information on errors you may encounter during execution.
Execution Time
You are able to control when each Object Level Accounting Method is executed. Because Object Level Accounting Methods set the Slot Inflow and Gain Loss values on the accounts and these are required knowns for the account solution, this execution time allows you to control when the accounts solve. Depending on the application, you should execute the method as soon as possible once the information is known. For example, if you input Local Inflow, then you can configure your Slot Inflow method to execute at the Beginning of the run. Table 1.4 shows possible execution times.
 
Table 1.4  Possible execution times
Execution Time
Description
Dependencies
Never
The method is never executed. This is only available for the default no-action method for each category.
None
Beg. of Run
At the beginning of the run, the method is executed once per timestep.
None
Beg. of Timestep Once
The method is executed once before each timestep's simulation.
None
Beg. of Timestep
The method is executed before each timestep's simulation and if dependent slots change. For this execution time, the method registers both simulation and accounting slots as dependencies. That is, if a value in a dependent slot changes, the method is put on the accounting queue to resolve.
Note: This could have performance implications if slot dependencies cause methods to re-fire.
Accounting and Simulation Slots
After Simulation
The method is executed after each timestep's simulation is complete and as accounting dependencies change.
Note:  This is the default for compiled methods and the only execution time in releases prior to RiverWare 5.1.
Technically, the method is executed as part of the accounting beginning of timestep which occurs after all rules have executed and all dispatching is complete. Each method registers accounting slot dependencies when executed. Therefore, if a value in a dependent accounting slot changes, then the method will re-execute.
Accounting Slots only
Note:  See “How the Accounting System Solves” for details about the run sequence, including OLAM execution.
Data Requirements and Error Conditions
The Object Level Accounting Methods can only access information that exists at the time they are called or the method will terminate early. For example, the Object Level Accounting Methods set to execute After Simulation can only access accounting values at the previous timestep as accounts may not have solved yet. Usually, these methods can access physical values at the current timestep as the simulation has likely solved when After Simulation Object Level Accounting Methods are called. Input values can be accessed by any OLAM.
Additionally, if an OLAM attempts to set a slot’s timestep that has an Input value (I flag), the run will abort with an error: “Attempting to set an input value”. If you wish to input Slot Inflow / Gain Loss, then you will need to input Slot Inflow / Gain Loss on all accounts OR create a user-defined method that does not attempt to assign to an input.
Selecting OLAMs and Execution Time
OLAMs and their Execution Time are selected from the object’s Accounting Methods tab.
The Accounting Methods tab works similar to the Methods tab. You select a category, then choose a method from the Selected Method menu at the top of the tab. An adjacent combo box labeled Execution Time allows you to choose the Execution Time. The category / method list on this tab also contains the Execution Time column showing the currently chosen execution time for each selected method.
Additionally, you can select methods on multiple objects using the Multiple Object Method Selector; see “Multiple Object Method Selector” in User Interface for details. See “Selecting Object Level Accounting Methods (OLAMs)” in User Interface for details about OLAMs.
Reconciling the Accounting and Physical Systems
User-defined accounting methods (and rules discussed later) can be used to ensure that the accounting system is reconciled with the physical system; that is, the sum of the accounting releases is the same as the physical release and the sum of account storages is the same as the total object’s storage. RiverWare has no automatic checks to ensure that physical and paper water are reconciled. Each basin is unique and operates differently. As a result, it is the responsibility of the modeler to reconcile the two systems according to the legislation and operations of the basin. There are river basin that have legally decided that the accounting system can vary from the physical system on a daily basis and the total reconciliation happens on a monthly (or longer) timescale.
There are reconciliation categories on the aggregate diversion, reservoir, and water user objects. These categories can hold methods that set the Gain Loss slot, Slot Inflow slot, and/or accounting supplies. Reconciliation can also be accomplished using rules in a rulebased model. See “Accounting With Rules” for additional information on rules and accounting.
How the Accounting System Solves
The accounting system does not dispatch in the same way that the physical water network simulation is dispatched, but there are some similarities. Account solution is triggered by the assignment of a value to a slot on the account. Assignment to account slots occurs in one of six ways: by user input, by a rule, by propagation through a supply, account solution, account level method, and by an object level accounting method on the object that references physical water quantities to introduce water into the accounting system (paper water). Table 1.1 provides details on each type of assignment.
Accounts solve whenever sufficient known slot values are present to run a solution method. This is analogous to dispatching in the simulation network; however, in the case of the accounting system, this means that accounts may solve when a user edits the account values through the user interface, a rule sets a value, or a method sets a value. Therefore, a run is not required to make a single account solve.
Each time an account slot is given a value (during resetting of user input, execution of object level methods, rule execution, or during account solution), the account holding the slot is notified, and performs its own checks for over- and under-determination, and possibly solves at one or more timesteps. Some accounts solve into the future under some circumstances, even though the controller might be at a different timestep.
Outside of a run, accounts solve for as many timesteps as there is the required known data. This means that the account solution behaves similarly to a spreadsheet solution. If the user inputs an Outflow for each timestep in the accounting period for a storage object and all of the inflows, slot inflow and Gain Loss are known, then the account will solve for Storage at each timestep. This action is performed when the user hits the enter button. If the user then changes an Outflow value at the start of the accounting period, then the storage for the entire period will change because the solution equation for the storage account depends on the previous timestep’s Storage. By changing one Outflow, the Storage for the whole period is affected.
In a run, the solution is similar, but accounts will only solve into the future one timestep, even if enough information is given for the accounting system to solve for the entire run. For example, if Gain Loss and Slot Inflow of a storage account are known for an entire month starting on the 1st of the month, the storage will be solved for the entire month during that first timestep. During the course of the run, a transfer on the 10th of the month will reset the storage on the 10th of the month, and the 11th of the month, but won’t reset storage on the 12th or any subsequent date.
There are three controllers that allow accounting: Post-simulation Accounting, Inline Simulation and Accounting, and Inline Rulebased Simulation and Accounting. These three controllers and their solution steps during a run are described in the following subsections.
Post-simulation Accounting
The simulation must be run under the Simulation controller, then the post-simulation accounting process can be run under the Post-simulation Accounting controller. The user must manually switch between controllers for each run. Accounts solve when they have the required knowns and resolve when a value in the solution equation changes.
Simulation Steps
See “Simulation Controller” in Solution Approaches for a description of the process followed by the Simulation controller.
Accounting Steps
The Post-simulation Accounting controller follows the procedure outlined below in the process of a run:
1. Initialize Accounting Run
– Clear Iteration count
– Clear Account States, i.e. Output values and Output flags
– Set Accounting User Inputs
2. Accounting Beginning of Run
– Execute Beginning of Run Account Level Methods for all objects.
– Execute the Object Level Accounting Methods that are set to execute at Beg. of Run.
3. For each timestep,
– Execute the Object Level Accounting Methods that are set to execute at Beg. of Timestep and Beg. of Timestep Once.
– Execute the Object Level Accounting Methods that are set to execute After Simulation.
– If dependent accounting slot have changed, re-execute as necessary Object Level Accounting Methods that are set to execute at Beg. of Timestep or After Simulation.
Inline Simulation and Accounting
For each timestep, the physical simulation and accounting method execution are intermixed. Accounts solve when they have the required knowns and resolve when a value in the solution equation changes.
Simulation Steps
The simulation controller follows the procedure outlined below in the course of a run:
1. Initialization Simulation Run
– Clear all output and values from previous runs for all timesteps in all series slots.
– Set user inputs.
– Propagate user inputs across links.
– Determine first dispatch timestep. See “Initialization” in Solution Approaches for additional information.
2. Initialize Accounting Run
– Clear Iteration count
– Clear Account States, i.e. Outputs and Output flags
– Set Accounting User Inputs
3. Execute rules in the Initialization Rules RPL set. See “Initialization Rules Set” in RiverWare Policy Language (RPL) for additional information.
4. Simulation Beginning of Run
– Execute Beginning of Run methods for all objects.
– Evaluate Beginning of Run expression slots for all timesteps.
5. Accounting Beginning of Run
– Execute Beginning of Run Account Level Methods for all objects.
– Execute the Object Level Accounting Methods that are set to execute at Beg. of Run.
6. For each timestep:
– Set the controller clock to the timestep time.
– Execute the Object Level Accounting Methods that are set to execute at Beg. of Timestep and Beg. of Timestep Once.
– Execute Beginning of Timestep methods for all objects.
– Evaluate Beginning of timestep, current timestep only expression slots
– Dispatch objects until the queue is empty, simulating the effects of the user inputs and default values.
– Execute End of Timestep methods on all objects.
– Execute the Object Level Accounting Methods that are set to execute After Simulation.
– For OLAMs set to execute After Simulation or Beg. of Timestep, re-execute if dependent slots have changed.
– Evaluate end of timestep, current timestep only Expression slots
7. Execute End of Run Simulation methods on all objects.
8. Evaluate End of Run expression slots.
Inline Rulebased Simulation and Accounting
For each timestep, the rulebased simulation is run where slots are set by rules, the simulation objects dispatch, and user defined accounting methods execute. Remember that accounts solve when they have the required knowns and re-solve when a value in the solution equation changes. This can happen at any time throughout the course of the run or even outside of the run.
This section describes the inline rulebased simulation and accounting steps in more detail. First, the run steps are presented in paragraph format, then they are presented in bullet format. See “Rulebased Simulation” in Solution Approaches for details about rulebased simulation.
Note:  Execution of rules and dispatching (simulation) of objects are intermixed and may be mutually dependent.
Rulebased Simulation Process Overview
At each timestep, the controller cycles the following process.
Processing the object dispatch queue. Objects check their dispatch conditions and may try to dispatch (or re-dispatch) after a dispatch slot on the object changes value. An object maintains a list of its dispatch slots and dispatching only occurs if it has sufficient known values.
Processing the accounting queue. Object Level Accounting Methods with the execution time of Beg. of Timestep can have simulation slot dependencies so that when the dependent simulation slot changes, the method is placed onto the accounting queue for processing. The accounting queue is processed in a first in, first out order.
Executing rules from the agenda one at a time. When a rule is successful, all its slot assignments are made. If it is not successful, none of its assignments are made, i.e. never are some, but not all of the assignments made. When the rule succeeds, the slot cell whose value was changed is given the priority of the rule and the “R” flag. These values show up in the rules analysis dialogs. Each rule maintains a list of the slots on which the outcome of the rule is dependent, namely those slots that were read during the rule execution. A rule will re-execute after one or more of its dependency slots changes value. Thus, objects that are dispatching can cause rules to re-execute by changing the values of slots upon which the rules depend, while rules that change dispatch slot values can cause simulation objects to dispatch. In the accounting system, a rule can change an account slot's value, which may cause the account to solve and may propagate changes throughout the accounting system. This can happen during a rule execution, but not during an object dispatch. A change in a simulation slot can also cause an Object Level Accounting Method to go onto the accounting queue if the slot is a dependent simulation slot of the method,. This can occur during rule execution or during an object dispatch,
At the start of the timestep (after beginning of timestep behavior has occurred where object level accounting methods may be executed), the dispatch queue (Step ) is fully processed until empty. This simulates the effects of user inputs. In this processing of the dispatch queue, objects may dispatch one or more times or may not dispatch at all depending on the dispatch slots that are set or changed throughout the course of the dispatching. Then the accounting queue (Step ) is processed to execute any Object Level Accounting Methods that have come onto the queue.
Once this queue is empty, the rules controller moves to Step  and starts with the full set of enabled rules on its agenda in priority order. This ensures that each enabled rule gets at least one chance to execute. The controller tries to execute the first rule on the agenda, in user specified order, at which time the controller removes the rule from its agenda. A successful rule may put objects on the simulation dispatch queue or Object Level Accounting Methods on the accounting queue. After a rule succeeds and sets a value, the controller returns to Step  and dispatches all objects on the dispatch queue, and then proceeds to Step , where it executes all Object Level Accounting Methods on the accounting queue.
When the dispatch and accounting queues are again empty, the controller returns to Step  and executes the next rule on its agenda. Once a rule succeeds, it returns to Step  and processes the dispatch queue and then the accounting queue. It continues cycling until the dispatch and accounting queues and the rules agenda are empty.
When all simulation dispatching is complete and the rules agenda is empty, Object Level Accounting Methods may execute under the accounting controller and then the simulation moves to the next timestep.
Rulebased Simulation Steps
The rulebased simulation controller follows the procedure outlined below:
1. Initialization Rulebased Simulation Beginning of Run
– Clear all output and values set by rules from previous runs for all timesteps in all series slots.
– Set the controller priority to 0.
– Set user inputs.
– Propagate user inputs across links.
– Determine first dispatch timestep. See “Initialization” in Solution Approaches for details.
2. Initialize Accounting Run
– Clear Iteration count
– Clear Account States, i.e. Outputs and Output flags
– Set Accounting User Inputs
3. Execute rules in the Initialization Rules RPL set. See “Initialization Rules Set” in RiverWare Policy Language (RPL) for details.
4. Rulebased Simulation Beginning of Run
– Execute Beginning of Run methods for all objects.
– Evaluate Beginning of Run expression slots for all timesteps.
5. Accounting Beginning of Run
– Execute Beginning of Run Account Level Methods for all objects.
– Execute the Object Level Accounting Methods that are set to execute at Beg. of Run.
6. For each timestep:
a. Set the controller clock to the timestep time.
b. Execute the Object Level Accounting Methods that are set to execute at Beg. of Timestep and Beg. of Timestep Once.
c. Set controller priority to 0.
d. Execute Beginning of Timestep methods for all objects.
e. Evaluate expression slots that have evaluate-at-beginning-of-timestep selected
f. Put all rules on the agenda (in priority order - whether 3,2,1 or 1,2,3 is user-selectable)
g. Do the following processes until the dispatch queue, the accounting queue, and the rules agenda are empty.
• Process 1 - Process the Dispatch Queue. Dispatch objects (as in basic Simulation) until the queue is empty, simulating the effects of any user inputs and default values and any recent changes to slots by rules. For each slot changed by this dispatch:
1. Put all rules that depend on the changed slot on the agenda, if it's not already there.
2. If the slot is a dispatch slot, check dispatch conditions and if necessary put the object containing the slot on the simulation dispatch queue.
3. Put all Object Accounting Methods with execution time of Beg. of Timestep that depend on the slot on the accounting queue.
4. If the slot is an accounting slot, notify the account that it may need to solve.
5. Once the Dispatch Queue is empty, move on to process 2.
• Process 2 - Process the Accounting Queue. Execute any Object Level Accounting Methods that have come onto the accounting queue. For each slot changed as a result of method execution:
1. If the slot is an accounting slot, notify the account that it may need to solve.
2. If the slot is an accounting slot, put all Object Level Accounting Methods that have a dependency of this accounting slot onto the accounting queue for execution if the method’s execution time is also Beg. of Timestep.
3. Once the Accounting Queue is empty, move on to process 3.
• Process 3 - Execute a Rule on the agenda. Set the controller priority to the priority of the next rule on the agenda (either in order 3,2,1 or 1,2,3 based on user-selection), and fire this rule. If not successful, continue firing one rule at a time until a rule is successful and at least one slot is set in the model. Each rule is removed from the agenda after it fires. Once a rule is successful:
1. Apply the slot changes, giving the changed slot cell the priority of the controller (i.e. the last rule that fired)
2. Add to this rule’s dependency’s list each slot that was read by this rule.
3. For each slot set by this rule, put all rules that depend on the changed slot on the agenda if the rule is not already there.
4. For each slot changed by this rule, if the slot is a dispatch slot, check dispatch conditions and if necessary, place the object containing the slot on the simulation dispatch queue.
5. For each slot changed by this rule, if the slot is an accounting slot, notify the account that it may need to solve.
6. For each slot changed by this rule, if the slot is a dependent simulation slot for an Object Level Accounting Method with an execution time of Beg. of Timestep, add the method to the accounting queue.
h. Return to Process 1 and repeat until the Agenda and the Queues are empty.
i. Set controller priority to zero, and execute End of Timestep methods on all objects.
j. Execute the Object Level Accounting Methods that are set to execute After Simulation.
k. If dependent accounting slot have changed, re-execute as necessary Object Level Accounting Methods that are set to execute at Beg. of Timestep or After Simulation.
l. Evaluate end of timestep, current timestep only Expression slots
7. If the number of run cycles performed is less than the number of run cycles specified, return to Step 6. and loop through each timestep again. See “Run Cycles” in Solution Approaches for additional information.
8. Execute End of Run Simulation methods on all objects.
9. Evaluate End of run expression slots.
Accounting With Rules
In an Inline Rulebased Simulation and Accounting run, rules can be used for two purposes: setting slots on the physical system and setting supplies in the accounting system. In the accounting system, rules are used to move water between two accounts by setting Supplies. To clarify the two types of assignments, we will define simulation rules/assignments as follows:
 
Simulation or Physical Rules/assignments
Rules and/or assignments that set values in the physical simulation system. For example, these rules set reservoir Outflow, Storage, or Pool Elevation.
We will also define accounting rules/assignments as follows:
 
Accounting Rules/assignments
Rules and/or assignments that set slots or supplies in the accounting system
Both simulation rules, i.e. rules that set outflows and storages, and accounting rules, i.e. rules that set supplies, can be part of the same ruleset and even assignments within the same rule. Accounting rules may be interspersed with physical rules that set simulation slots. Or, all of the Simulation rules can execute, then all of the accounting rules can execute. The structure of the ruleset depends on the application. In addition, accounting assignments and simulation assignments can be within the same rule. For example, when a physical release is made, the release can be allocated to the appropriate supplies in the same rule.
Accounting Model Interaction With Physical Simulation
Following is a description of the possible ways an accounting model can interact with the physical simulation.
After-the-Fact Accounting
The physical simulation is run completely without any rule effects, i.e. all objects dispatch because of input data. Rules are used to determine how the water already released in the physical simulation should be classified in the accounting system. This type of application has only Accounting Rules, all of the physical simulation is the result of input data. Typically this type of system is used in an operations mode to determine how yesterday’s final releases should be classified. For example, if Reservoir.Outflow = 100cfs yesterday. In the accounting system, 20cfs of that was for fish minimums and 80cfs was for downstream demands.
Physical and Accounting (Concurrent on Each Timestep)
For each simulation assignment/rule, there is an accounting assignment/rule. In this application, for example, each physical release corresponds to a release in the accounting system. The physical operations often depend on the results of the accounting operation. This is usually the most intuitive to describe but is often difficult to implement. Each time a release is increased or decreased, the accounting system must also be increased or decreased by the same amount. If there are physical constraints that limit the amount of water that can be released, it quickly becomes confusing as to what supply needs to be set. For example, Rule 2 sets Reservoir.Outflow = 80 cfs and in the accounting system sets that 80cfs was for downstream demands. Rule 1 then sets Reservoir.Outflow = 100cfs and in the accounting system sets that the additional 20cfs was for minimum flows.
Physical Then Accounting (Consecutive Per Timestep)
For each timestep, first all of the simulation rules execute and set releases. Then, accounting rules execute and determine how those releases should be classified. This is similar to after-the-fact accounting but rules are used to determine the physical releases as well. This type of system is convenient because the physical rules have access to account values at the previous timestep and release constraints can be more easily incorporated. The accounting rules look at the total release and use logic to determine the accounting releases. For example, Rule 3 sets Reservoir.Outflow equal to 80cfs, Rule 2 sets Reservoir.Outflow equal to 100cfs. Then in the accounting system, Rule 1 sets that of the 100cfs released from the Reservoir, 20 cfs was for minimum flows and 80 cfs was for downstream demands.
Water Rights
Accounting rules allocate flow to the accounts, then physical rules look at the results to drive the simulation. See “Water Rights Allocation” for complete details.
Following are considerations that should be followed when using rules with accounting.
Setting Slots Versus Setting Supplies
In the physical system, rules are used to set values on slots such as Reservoir.Outflow or WaterUser.Diversion Requested. When making RPL assignments in the accounting system, the user has to be careful to about which values to set. Rules can be used to either set an accounting slot or a supply in the accounting system. Setting of slots can only be accomplished if there is no supply connecting the slot to another slot. If there is one or more supplies connecting the slot, then the rule must set the supply. Lets consider Example 1.3.
 
Example 1.3   
A storage account on a reservoir has the typical slots including inflow, outflow and storage. If there is no supply (actually a demand) leading out of the account, then a rule can be used to directly set the outflow: “Reservoir^Account.Outflow”. If there is one or more supply leading out of the account, then it is not possible to directly set the outflow. Instead one of the supplies should be set by the rule such as “Reservoir Acct to Reach Acct.Supply []”. Setting of supplies is described in the following section.
Typically, the user should use rules to set supplies, not accounting slots. There are a few cases where the user must set the slot directly. For example, on a diversion account, if the user wishes to specify the Depletion using a rule, then the left hand side of the rule would have the following format: WaterUser^DiversionAccount.Depletion[].
Setting Supplies
For accounting assignments, the left-hand side of the assignment statement will consist of a Supply name with the following syntax:
“SupplyName.Supply”[] =
For this syntax, the “SupplyName.Supply” is a String. The “.Supply” portion of the string is necessary to tell RiverWare that this is a supply in the Accounting system and not a slot in the physical system. The SupplyName.Supply either can be typed by the user or selected from the palette using the supply option in the selector dialog.
Because accounts will not solve until the User Defined Accounting Methods have executed and set the Gain Loss and Slot Inflow, the accounting rules can typically reference current timestep information on the simulation objects but can only reference previous timestep information on the accounting system. Within this limitation, simulation rules can also reference values in the accounting system.
 
Example 1.4   
A water district and a power company share ownership of the water in a reservoir. On any given day, the water district makes calls to release their water to meet downstream demands. The power company releases water to meet power demands. A simple rule for this reservoir may look like:
Reservoir.Outflow[] = FarmerDemand() + PowerDemands()
WaterDistrictAccount.Supply[] = Farmer Demand()
PowerAccount.Supply[] = Power Demands()
In this rule we have set both the Outflow to the reservoir in the physical system and then classified that release in the accounting system. The functions FarmerDemand() and Power Demands() can reference the available storage in each account at the previous timestep and reference the current demand:
FarmerDemand() -> Min (FarmersData.DiversionSchedule[],
PreviousAccoutStorage(“WaterDistrict”))
PowerDemand() -> Min (PowerData.Demand[],
PreviousAccoutStorage(“Power”))
PreviousAccountStorage(STRING Account) -> VolumeToFlow (Reservoir ^ Account.Storage[@”Previous Timestep”], @”Current Timestep”)
Using this approach, the amount of water that either user could release is limited by the volume of water stored in their account at the previous timestep.
Reconciliation With Rules
Rules can be used to ensure that the physical system is reconciled with the accounting system, i.e. the total physical release is the same as the total accounting release. RiverWare has no automatic checks to ensure that physical and paper water are reconciled. Each basin is unique and operates differently. As a result, it is the responsibility of the modeler to reconcile the two systems according to the legislation and operations of the basin. There are river basin that have legally decided that the accounting system can vary from the physical system on a daily basis and the total reconciliation happens on a monthly (or longer) timescale.
Predefined RPL Functions for Accounting
There are predefined RPL functions that deal specifically with accounts, supplies, and exchanges in the accounting system. This section lists some accounting-specific predefined functions. See “RPL Predefined Functions” in RiverWare Policy Language (RPL) for additional information.
AccountNamesByAccountType
This function returns a list of names of Accounts on a specified Object having the indicated Account type, sorted in ascending Account priority date order. Accounts which don’t have a priority date are at the end of the list, sorted in ascending name order. See “AccountNamesByAccountType” in RiverWare Policy Language (RPL) for additional information.
AccountNamesByWaterOwner
This function returns a list of names of Accounts on a specified Object having the indicated WaterOwner, sorted in ascending Account priority date order. Accounts which don’t have a priority date are at the end of the list, sorted in ascending name order. See “AccountNamesByWaterOwner” in RiverWare Policy Language (RPL) for additional information.
AccountNamesByWaterType
This function returns a list of names of Accounts on a specified Object having the indicated WaterType, sorted in ascending Account priority date order. Accounts which don’t have a priority date are at the end of the list, sorted in ascending name order. See “AccountNamesByWaterType” in RiverWare Policy Language (RPL) for additional information.
AccountNameFromPriorityDate
This function evaluates to the name of the Account having the specified priority date. See “AccountNameFromPriorityDate” in RiverWare Policy Language (RPL) for additional information.
AccountNamesFromObjReleaseDestination
This function returns a list of names of Accounts on a specified Object where the attributes of the outflow Supplies of the Accounts match the given ReleaseType and Destination. The list is sorted in ascending Account priority date order; Accounts which don’t have a priority date are at the end of the list, sorted in ascending name order. See “AccountNamesFromObjReleaseDestination and AccountNamesFromObjReleaseDestinationIntra” in RiverWare Policy Language (RPL) for additional information.
AccountPriorityDate
This function evaluates to the priority date of the Account, on the specified Object, having the specified name. See “AccountPriorityDate” in RiverWare Policy Language (RPL) for additional information.
Destinations
This function evaluates to a list of user-defined Destinations. See “Destinations” in RiverWare Policy Language (RPL) for additional information.
DestinationsFromObjectReleaseType
This function returns a list of unique names of Destinations of Supplies which represent outflows from a specified Object, and which have the indicated Release Type. See “DestinationsFromObjectReleaseType” in RiverWare Policy Language (RPL) for additional information.
GetAccountFromSlot
Given a Slot, the function return its parent account name as a String. It is an error if the slot is not on an account. See “GetAccountFromSlot” in RiverWare Policy Language (RPL) for additional information.
GetObjectDebt
This function evaluates to the sum of the debts to all accounting exchanges which may be paid by supplies on the given object. If there are no exchange paybacks on the given object, the debt is zero. See “GetObjectDebt” in RiverWare Policy Language (RPL) for additional information.
GetPaybackDebt
This function evaluates to the value of the debt slot of the given exchange payback source at the given timestep. See “GetPaybackDebt” in RiverWare Policy Language (RPL) for additional information.
ObjAcctSupplyByWaterTypeRelTypeDestType
This function returns a list of objects, accounts and supplies that match the given arguments. It returns a list of triplets{OBJECT object, STRING account, STRING supply}, where the object^account is served by the supply, and the object is in the given subbasin, the supply has the given release type and destination type, and the supplying account (upstream end of the supply in the returned triplet) has the given water type. See “ObjAcctSupplyByWaterTypeRelTypeDestType” in RiverWare Policy Language (RPL) for additional information.
ObjectsFromAccountName
This function returns a list of the objects that contain an account with the given name and account type. See “ObjectsFromAccountName” in RiverWare Policy Language (RPL) for additional information.
ObjectsFromWaterType
This function returns a list of the objects that have an account with given water type and account type. See “ObjectsFromWaterType” in RiverWare Policy Language (RPL) for additional information.
ReleaseTypes
This function returns a list of the names of all user-defined ReleaseTypes in the Water Accounting System Configuration. See “ReleaseTypes” in RiverWare Policy Language (RPL) for additional information.
ReleaseTypesFromObject
This function returns a list of unique names of ReleaseTypes of Supplies which represent outflows from a specified Object. See “ReleaseTypesFromObject” in RiverWare Policy Language (RPL) for additional information.
SolveWaterRights and SolveWaterRightsWithLags
This water accounting function invokes the Water Rights Allocation method on a computational subbasin; see “Water Rights Allocation” and “SolveWaterRights and SolveWaterRightsWithLags” in RiverWare Policy Language (RPL) for details.
SumAccountSlotsByWaterType
This function sums the values of all accounting slots of a given name on accounts of a given water type. See “SumAccountSlotsByWaterType” in RiverWare Policy Language (RPL) for additional information.
SupplyNamesFrom, SupplyNamesFrom1to1
This function returns a list of names of Supplies which represent outflows from given Accounts and have the indicated ReleaseType and Destination. See “SupplyNamesFrom, SupplyNamesFrom1to1” in RiverWare Policy Language (RPL) for additional information.
SupplySlotsFrom, SupplySlotsFrom1to1
This function returns a list of Supply slots of Supplies which represent outflows from given Accounts and which have the indicated ReleaseType and Destination. See “SupplySlotsFrom, SupplySlotsFrom1to1” in RiverWare Policy Language (RPL) for additional information.
SupplyNamesFromIntra, SupplyNamesFromIntra1to1
This function returns a list of names of Supplies which represent internal flows from given Accounts and which have the indicated ReleaseType and Destination. See “SupplyNamesFromIntra, SupplyNamesFromIntra1to1” in RiverWare Policy Language (RPL) for additional information.
SupplySlotsFromIntra, SupplySlotsFromIntra1to1
This function returns a list of Supply slots of Supplies which represent internal flows from given Accounts and which have the indicated ReleaseType and Destination.
SupplyNamesTo, SupplyNamesTo1to1
This function returns a list of names of Supplies which represent inflows to given Accounts and which have the indicated ReleaseType and Destination. See “SupplyNamesTo, SupplyNamesTo1to1” in RiverWare Policy Language (RPL) for additional information.
SupplySlotsTo, SupplySlotsTo1to1
This function returns a list of Supply slots of Supplies which represent inflows to given Accounts and which have the indicated ReleaseType and Destination. See “SupplySlotsTo, SupplySlotsTo1to1” in RiverWare Policy Language (RPL) for additional information.
SupplyNamesToIntra, SupplyNamesToIntra1to1
This function returns a list of names of Supplies which represent internal flows to given Accounts and which have the indicated ReleaseType and Destination. See “SupplyNamesToIntra, SupplyNamesToIntra1to1” in RiverWare Policy Language (RPL) for additional information.
SupplySlotsToIntra, SupplySlotsToIntra1to1
This function returns a list of Supply slots of Supplies which represent internal flows to given Accounts and which have the indicated ReleaseType and Destination. See “SupplySlotsToIntra, SupplySlotsToIntra1to1” in RiverWare Policy Language (RPL) for additional information.
WaterOwners
This function returns a list of the names of all WaterOwners defined in the Water Accounting System Configuration. See “WaterOwners” in RiverWare Policy Language (RPL) for additional information.
WaterTypes
This function returns a list of the names of all WaterTypes defined in the Water Accounting System Configuration. See “WaterTypes” in RiverWare Policy Language (RPL) for additional information.
Revised: 06/03/2019