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:

We will also define accounting rules/assignments as follows:

Both simulation rules; that is, rules that set outflows and storages, and accounting rules; that is, 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.

Following is a description of the possible ways an accounting model can interact with the physical simulation.

The physical simulation is run completely without any rule effects; that is, 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.

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.

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.

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.

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.

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 wants to specify the Depletion using a rule, then the left hand side of the rule would have the following format: WaterUser^DiversionAccount.Depletion[].

For accounting assignments, the left-hand side of the assignment statement will consist of a Supply name with the following syntax:

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.

Rules can be used to ensure that the physical system is reconciled with the accounting system; that is, 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.