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; 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.
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; 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.
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.
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 wants 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.
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; 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.
Revised: 11/11/2019