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

There are two types of OLAMs: compiled and user-defined. See the following sections for details:

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.

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.

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.

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 you can change this, if desired.

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. This method is available only in the <Object> Account Slot Inflow category, on the objects listed in Table 1.2 and with one of the possible local inflow methods selected.

User-defined accounting methods are created by the user in the RiverWare Policy Language (RPL).

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.

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

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.

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.

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.

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.

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

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.