skip to main content
Modeling Operations
USACE‑SWD Modeling Techniques
Modeling Operations
Implementing Operating Policies Using Rulebased Simulation
Once the basic model structure has been developed and calibrated using the Simulation controller, the operating policies can then be implemented using rules. The rules will compute the reservoir outflows and diversions to water users based on the state of the system and the operating policies. Described in this section is an overview of configuring the rulebased simulation model followed by a description of each USACE‑SWD policy: surcharge, regulation discharge, flood control, low-flow releases, reservoir diversions, hydropower releases, and fish releases. Described for each policy are the additional method selections and data needs. Then the implementation in RPL is described along with algorithm itself.
Overview of Use of Rulebased Simulation
The USACE‑SWD models includes policy implemented as rules. Therefore, the model must use the Rulebased Simulation controller. The Rulebased Simulation controller is selected in the Run Control dialog.
A Rulebased Simulation model is an under determined model in terms of user input values. A set of prioritized rules, which implement basin policy, is used to look at the state of the system, execute policy logic, and set slot values to provide enough information for the model to solve.
In the calibration model discussed above, storage values may have been input for each timestep on every reservoir. The user may have chosen to input outflows or pool elevations instead. Regardless, in the rulebased model, this data must be removed because rules will be used to determine the reservoir outflows. However, this data will be useful for testing the various flood control algorithms so it should be stored on a data object. So for each reservoir object, copy input storage values into a custom slot and then clear those values from the reservoir object (every reservoir still needs an initial storage or pool elevation value so don’t remove those). Once these storages are removed, the model is under determined and will not solve. The flood control rules, whose implementation is discussed below, will be used to provide the necessary data for the model to solve.
Ruleset Overview
Rules are used to implement policy and invoke the flood control algorithms taken from the SUPER logic. Rules execute in the order specified by the user and are numbered according to priority. Rule #1 is the highest priority rule while the rule with the highest number (depends on the number of rules in the ruleset) is the lowest priority rule. In general, the lowest priority rules should execute first and represent the ideal operating conditions while the highest priority rules should execute last and represent special conditions or constraints that must be upheld. The idea behind rulesets meant to reproduce the SUPER logic is a bit different. Rulesets that implement SUPER flood control logic are designed to make mandatory releases first, then the releases may be increased as space allows. Therefore, the surcharge release rules execute first, then the rules to compute the regulation discharge and empty space, and finally the rules to compute the flood control releases. After the flood control model is working properly, additional higher priority rules could be added to account for other types of releases (for fish flows, power generation, irrigation demands, etc.).
Creating a New Ruleset
A new ruleset is created by selecting Policy, then Ruleset, then New in the main RiverWare menu. See “Creating, Editing, and Viewing RPL Sets” in RiverWare Policy Language (RPL) for details on the ruleset editor.
Agenda Order
To follow the guidelines presented in this document, the ruleset should execute the rules in order of lowest priority rules first and the highest priority rules last, that is rule n first, rule 1 last. This is the default structure but the following steps can be used to verify this.
1. Select View, then Show Advanced Properties menu in the RPL set editor.
2. In the Agenda Order field, select the toggle button for 3,2,1.
Order of Policies
In a rulebased simulation run, the run controller alternates between rule execution and object simulation. For a given controller timestep, all rules start out on the agenda. Rules are executed in reverse priority order until a rule succeeds and sets a slot in the model. Then control shifts to simulation and objects dispatch given the new information from the successful rule. When simulation is finished and there are no objects left to solve, control shifts back to the rule agenda and rules continue to execute until one is successful. Then control shifts back to simulation to simulate the affects of the rule. This process continues until there are no rules left on the agenda and no objects to solve. Then the controller moves to the next timestep and the process begins again.
Note:  After a rule executes and is taken off the agenda it can go back on the agenda if one of its dependencies changes.
Note:  Objects can solve at timesteps other than the current controller timestep if they have enough information to do so.
Table 3.1 shows the priority and execution order to be used by most USACE‑SWD models. The rules will execute from lowest priority to highest (8 to 1) as shown by the execution order. Descriptions of the rationale follow, sorted by execution order.
 
Table 3.1   
RPL Priority Order
Execution Order
Policy
1
8
Fish Releases (QFish)
2
7
Hydropower Release
3
6
Reservoir Diversions
4
5
Low-flow Releases
5
4
Flood Control
6
3
Regulation Discharge
7
2
Minimum Flood Control Releases (Optional)
8
1
Surcharge Release
0. The forecast of incremental inflows from cumulative methods executes for each control point and reservoir object at the start of each timestep; see “Forecasting Incremental Local Inflows From Cumulative Flows” for details. This results in a new inflow forecast for each object. The computed inflow forecast sits on the Hydrologic Inflow Forecast slot on reservoir objects and on the Local Inflow slot on the control point objects. This is listed as step zero because it happens at the beginning of the timestep (and at priority 0) before any rules execute. Also at beginning of the run, the selected method in the Conditional Operating Level category will be executed; see “Conditional Operating Levels” in Objects and Methods for details. This could alter which operating level table will be used.
1. The lowest priority surcharge release rule is executed and it sets the surcharge release flag on the outflow slot of a reservoir object. That reservoir object then dispatch with the solveMB_givenInflowOutflow dispatch method. While dispatching, the reservoir computes a surcharge release forecast. These values will be set on the Surcharge Release slot and on the Outflow slot. The reservoir object will then solve for storage and pool elevation over the forecast period using the new outflow values. When the reservoir is finished dispatching, the forecast outflows will be routed downstream to the next reservoir object. This is done by dispatching the reach and control point objects as they receive inflow values from upstream (their inflow values are the routed releases from the upstream reservoir). When all objects are finished dispatching, the next highest priority rule executes and sets the surcharge release flag on another reservoir object. That reservoir then dispatches and computes its surcharge release forecast. The forecasted outflow values are then routed downstream to the next reservoir. This process repeats until all surcharge release rules have executed, all reservoirs have computed a surcharge release forecast, and the surcharge releases have been routed downstream.
Note:  The surcharge policy initializes the reservoir Outflow to zero if no surcharge release is necessary.
2. Optionally, minimum flood control releases can be made after the surcharge operation. These releases are considered minimums because they are made regardless of what the flood control logic computes. Also, the releases occupy downstream channel space so they should be made before the Regulation Discharge. It is up to the user to write the rule logic for when these should be made, but the rule should set the following:
– Reservoir.Flood Control Minimum Release
– Reservoir.Outflow
– Reservoir.Bypass or Regulated Spill (if this water should not go through the turbines or release structure)
3. The regulation discharge rule executes and sets the regulation discharge flag on the Reg Discharge Calculation slot on each control point object. This triggers each control point to dispatch. The control points compute the regulation discharge and empty space hydrographs over the forecast period. Because each control point has already computed its inflow forecast and the surcharge releases have already been routed from upstream reservoirs, the control point knows how much water is already occupying the channel at its location and can compute the empty space accordingly.
4. The flood control rule executes and calls the FloodControl predefined function. For all reservoirs in the computational subbasin and for all timesteps in the forecast period, the flood control releases are computed. The FloodControl function returns the final flood control releases and the final outflows (flood control release plus surcharge release) for the current timestep. The flood control rule sets the Outflow and Flood Control Release slots. This triggers each reservoir object to redispatch with the solveMB_givenInflowOutflow method. The reservoirs compute their final storage and pool elevation values and the outflows are routed downstream.
5. The Low-flow Release rules execute next, releasing additional flows to meet downstream requirements. Flood control and low-flow releases are normally thought of as mutually exclusive for a particular reservoir in that when a flood control release is necessary, minimum flows downstream are satisfied and additional low-flow releases are not necessary. However, it is possible for some reservoirs to be in flood control while others are required to make low-flow releases. Also, in SUPER (hence in the RiverWare model), demands for diversions out of the rivers are satisfied by specifying low-flow requirements at control points upstream of the diversion points. Because these low flows are not restricted to environmental low flows, but also include diversion demands, it is possible that flood control releases are not adequate to satisfy these demands and additional releases are needed from the conservation pool. Hence the Low-flow Release rules execute regardless of whether flood control releases have been executed.
6. The Reservoir Diversion rules execute next, diverting water out of reservoirs directly to water users or to other reservoirs. This happens after the Low-flow rule executes, guaranteeing that the low flows will be satisfied at the possible expense of direct reservoir diversions. This is the expected behavior if the low flows are strictly environmental. However, the fact that the environmental and out-of-river diversions are grouped together means that the out-of-river diversions have priority over the out-of-reservoir diversions. If this relative priority is not desirable, the rules could be reversed and/or the out-of-river demands can be separated from low-flow demands that are strictly environmental.
7. The Hydropower rule executes last. All other releases automatically go through the turbines and generate power to the maximum extent possible, so when this rule fires, it compares the hydropower already being generated at each reservoir with the specified load. If the load is not met, the rule makes an additional release to generate additional power. These releases are constrained only by power pool drawdown limits and limitations on increasing flooding downstream.
8. The Fish Release rules (where defined) execute and determine the additional outflow to meet the Fish Release demand. The rule sets the reservoir Outflow and reservoir Off Peak Spill slots. This again causes the system to redispatch and solve. The rule also performs accounting actions to calculate and set the inflows and outflows to the fish account on the reservoir.
Direct from reach diversions are not included in the rule set because they are designed to take whatever water is available in the reach.
Execution Constraints to Execute Rule Once per Timestep
In general, each rule executes only once per timestep. This is guaranteed by including an execution constraint for each rule that calls the HasRuleFiredSuccessfully predefined function. For Example, as shown in Figure 3.1, the execution constraint for the Flood Control Rule says that it will only execute when NOT(HasRuleFiredSuccessfully(“Current Rule”)). The keyword “Current Rule” is used to reference the given rule. This prevents the user from having to change this argument if the name of the rule changes. The name of the rule, as a string, is also valid.
Figure 3.1  Execution constraint to limit firing
Types of Rules
In rulebased simulation, rules set slots equal to the value determined by the logic on the right side of the assignment statement. For the USACE‑SWD functionality, there are two variations to this: rules loop through a list of lists and set values from those two lists. Also, for Surcharge and regulation discharge, the rules set flags on slots. These two approaches are described in this section to familiarize the user with this structure.
Assigning Values Using Lists of Lists
The four specific USACE‑SWD predefined functions (FloodControl, HydropowerRelease, ComputeReservoirDiversions, MeetLowFlowRequirements) that are accessed by the rules all return a list of lists. The outer list contains an inner list that consists of a triplet of {slot, value, and object}. Example 3.1 illustrates.
Example 3.1   
{ {“Res1.Outflow”, 6344.32 [“cfs”], “Res1”},
{“Res1.Flood Control Release”, 6344.32 [“cfs”], “res1”},
{“Res1.Target Balance Level”, 8.32, “res1”} ,
{“Res2.Outflow”, 3243.02 [“cfs”], “Res2”},
{“Res2.Flood Control Release”, 2312.20 [“cfs”], “Res2”},
{“Res2.Target Balance Level”, 8.32, “Res2”} }
Generally, the rule loops over this list and sets the slot at index 0 (the first one, the slot) to the value at index 1 (the second one, the value). The body of the rule would look as follows:
FOR (LIST triplet IN FloodControl( “Flood Basin” )) DO
( triplet < 0 > )[] = triplet < 1 >
END FOR
The third item, the object) is typically only used in debugging.
Setting Flags
The second unique syntax used by the USACE‑SWD is to set a flag on a slot. This applies to the Surcharge and Regulation discharge rules. In general, the slot is assigned the flag. The flags are all found on the palette. For example,
Reservoir.Outflow[ ] = SURCHARGE_RELEASE_FLAG
This assignment statement says that the Surcharge flag should be set on the Reservoir.Outflow slot at the current timestep.
Use of Computational Subbasin
A computational subbasin is a user configured subbasin that is used to specify a group of objects and the computations that should be performed on those objects.
Create a Computational Subbasin
The Subbasin Manager dialog is invoked by selecting Workspace, then Edit Subbasins from the main RiverWare menu. The Subbasin Manager dialog has three tabs: User Defined, Automatic, and Object Membership. Computational subbasins are added in the User-Defined Subbasins tab. Then, in the Subbasin Manager dialog, select Subbasin, then Append Typed Subbasin, then Computational. A new subbasin will appear in the dialog box and the user can rename the subbasin if desired. The subbasin will contain any objects that were selected on the workspace. The following section describes how to add objects to the subbasin.
Adding Objects to Subbasin
All objects which will be used in the specific calculations must be included in the computational subbasin. Furthermore, all objects in the subbasin must be continuous (i.e. there can be no disconnected objects with the exception of data objects). The easiest way to add objects to the subbasin is to select the objects on the RiverWare workspace by drawing a large box around all the relevant objects. This can be done by starting at a corner of the model then clicking and dragging until all the objects are highlighted. Once the objects are highlighted on the workspace, highlight the new subbasin then select Subbasin, then Append Members from Workspace in the Subbasin Manager dialog. The new subbasin should then show all of the objects associated with it when the subbasin view is expanded (by selecting the small icon to the left of the subbasin name). Even though data objects are not part of the flood control calculations, for ease of selecting and appending objects to a subbasin their inclusion in the flood control subbasin is allowed.
Surcharge
The surcharge policy determines the mandatory release that must be made to protect the reservoir.
Model Setup
On each reservoir, select the desired surcharge method from the Surcharge Release Category. The multi-object method selector can be used to make this selection on all reservoir objects at once.
Typically in USACE‑SWD models the Flat Top Surcharge method is used and will be used as an example here. Once this method is made active, several slots will be added that require user input. The Rating Curves table contains the induced surcharge and free flow rating curves. The Operating Level Table contains the pool elevation vs. operating level information for each operating level. The body of this periodic slot contains the pool elevations and the column headers represent the balance levels. So there must be a column for each operating level and the pool elevations within that column may vary with time. Input a value in the Top of Flood Pool and Top of Conservation Pool slots. These values represents the operating level (not elevation) associated with the top of flood pool and top of conservation pool, respectively. They must be the same on all reservoir objects. The user can set these values on all objects at once using the computational subbasin (the computational subbasin is discussed below).
See “Flat Top Surcharge” in Objects and Methods for details on the Flat Top Surcharge method. See “Surcharge Release” in Objects and Methods for details on other Surcharge Release category methods.
If using the Flat Top Surcharge method, consider also selecting the Constant Additional Surcharge Release method in the Elevation Max Duration Constraints category; see “Constant Additional Surcharge Release” in Objects and Methods for details. This method compute the constant additional surcharge release to meet one or more maximum elevation duration constraints.
RPL Implementation
Since the surcharge release rules must execute first, they should be the lowest priority rules. Furthermore, the surcharge release rules must execute in an upstream to downstream order. Therefore the surcharge release rules for the most upstream reservoirs must be the lowest priority rules. Its important to remember that the lowest priority rules are the rules with the highest numbers. Conversely, rule 1 is the highest priority rule and will execute last when the agenda order is ...,3,2,1.
The surcharge release rules should be contained in their own policy group for easy organizing. Add a policy group by selecting Ruleset, then Add Policy Group in the main Ruleset Editor dialog and then name the policy group accordingly. Rules can be added to this policy group by selecting Ruleset, then Add Rule with the policy group highlighted. Add a rule for each reservoir in the basin. The rules are edited by expanding the policy group view and then double-clicking the red “R” icon next to one of the rules. This invokes the Rule Editor dialog. Each rule should be renamed accordingly. In the Rule Editor dialog, add an assignment by selecting Rule, then Add Assignment. Then, use the palette to build the rule.
Each rule should set the outflow slot of the reservoir to the surcharge release flag. This will trigger the reservoir to solve for its surcharge release forecast and set its outflows (for each timestep in the forecast period) equal to the computed surcharge releases. Since the downstream reservoirs need to know the surcharge release forecasts from the upstream reservoirs before they can solve for their surcharge releases, the rules must be ordered to execute in an upstream to downstream direction. If a reservoir receives releases from more than one upstream river branch, then each upstream branch must solve first. An example rule for one reservoir is shown in Figure 3.2. The end result will be a series of rules that set the outflow slot on each reservoir to the surcharge release flag. The rules will execute from lowest priority to highest priority (from the upstream reservoirs to the downstream reservoirs).
Figure 3.2  Sample surcharge rule
Description of Logic
See “Flat Top Surcharge” in Objects and Methods for a complete description of the logic used in the Flat Top Surcharge computations.
The interaction between the rule and object dispatching is as follows.
1. When the surcharge rule executes, it sets the surcharge release flag on the reservoir outflow slot.
2. This triggers the object to dispatch at the current timestep (solveMB_givenInflowOutflow) and solve for its surcharge release forecast.
3. Within this dispatch, it sets the Surcharge Release slot and also sets the surcharge release flag (and physical constraint flag) on the outflow slot at each subsequent timestep in the forecast period. This causes the object to be put on the queue at each of those timesteps.
4. When the reservoir dispatches at each timestep in the forecast period (t), it recognizes that the controller timestep and the object timestep are not the same, and it does not recompute the forecast of surcharge values. Instead it sets the Outflow (@t) equal to the Surcharge Release (@t) that was previously computed.
5. Once the outflow slot is set, the value is then routed downstream to the next reservoir.
6. Then the next rule will execute, triggering another reservoir to solve for its surcharge releases and route downstream.
7. This continues until all rules have executed and all reservoirs have computed their surcharge release forecasts
Flood Control Minimum Release
In certain basins, water is released from a reservoir regardless of the downstream constraints or balancing. These minimum releases are not surcharge releases but are considered minimum flood control releases. They can be modeled by setting the Flood Control Minimum Release slot and the reservoir Outflow slot with a rule; see “Operating Level Balancing” in Objects and Methods for details. It is up to the user to write the rule logic of when these slots should be set and their corresponding values. These rules should execute after surcharge, but before regulation discharge; see “Order of Policies” for details. Then, the minimum releases will be routed downstream and the Regulation Discharge rules will include them in their empty space determination.
RPL Implementation
It is up to you to write the rule logic to set the reservoir Outflow and Flood Control Minimum Release. Figure 3.3 shows a sample rule.
In this sample rule, the current Outflow and Flood Control Minimum Release is set to the Firm Power Release when the current Outflow is less than the Firm Power Release and the Operating Level is above the Top of Conservation Pool.
Note:  Only the current timestep values are set by this rule. Setting future timesteps in the forecast period is possible but not easy due to the priorities of the rules.
Optionally, if you wish the Minimum Flood Control Release not to go through the release or turbines, you can also set the Regulated Spill or Bypass slot in the rule. You may need to select a regulated spill or bypass method on the reservoir to add these slots to the reservoir.
Figure 3.3   
Regulation Discharge
The regulation discharge operation calculates the regulation discharge, meaning the maximum flow that is allowed in the channel at the control point, for each timestep in the specified forecast period. It also computes the empty space at the control point. Calculation of these values are fundamental to the Operating Level Balancing procedure for determining flood control releases. Thus, in effect, the regulation discharge operations are looking at the state of they system after the surcharge release to determine the available space at each control point for the flood control operation.
Model Setup—Control Point Methods
A regulation discharge method must be selected on each Control Point that will be involved in the Flood Control. See “Regulation Discharge” in Objects and Methods for method descriptions. Each method describes the slots that are instantiated and the logic that it uses to compute the Regulation Discharge and Empty Space.
Note:  The desired Flood Control method must be selected before the Regulation Discharge category becomes available.
Depending on the Regulation Discharge method selected, additional categories may be available. Each category has methods that modify how the Regulation Discharge is performed. The possible categories are as follows:
• Percent Full Determination; see “Percent Full Determination” in Objects and Methods.
• Stage Control Over Forecast; see “Stage Control Over Forecast” in Objects and Methods.
• Regulation Recession; see “Regulation Recession” in Objects and Methods.
RPL Implementation
The regulation discharge calculations are performed on the control point objects after the surcharge release forecasts have been computed and routed downstream. In order to ensure that the surcharge release calculations have finished, the rule to trigger the regulation discharge calculations must execute after all the surcharge release rules. This means it must be a higher priority rule. Add a policy group for regulation discharge in the main Ruleset Editor dialog and add a single rule to this policy group. Make sure that this policy group sits above the surcharge release policy group thereby making the regulation discharge rule a higher priority rule.
A single rule can be used to trigger the regulation discharge calculations on all control point objects. The rule should consist of a FOR loop that will loop through every control point in the flood control subbasin and set the regulation discharge flag on the Reg Discharge Calculation slot. When this flag is set it will trigger the control point to solve for regulation discharge and empty space. Figure 3.4 shows a sample rule.
This rule consists of a single FOR statement. The ControlPt variable is a temporary loop variable whose expression data type is OBJECT. The FOR statement will loop through every object in the list on the right hand side of the IN expression and the ControlPt variable will become each object in that list. The right hand side of the IN statement is a predefined function named ListSubbasin that takes a subbasin as an argument and returns a LIST that contains each object in the subbasin.
In this example, the subbasin used in the ListSubbasin function is called “CP” and is a user-defined subbasin. The rule could have used the “ControlPoint” automatic subbasin. This subbasin can be viewed in the Automatic Subbasins view of the Subbasin Manager dialog. If every control point in your model is used in flood control, then your rule can look just like the example rule. If however the user is only using a subset of control points for the flood control calculations, a new subbasin must be created that contains the subset of control points. The rule should then refer to the new subbasin in the ListSubbasin predefined function. In summary, the example rule will loop through every control point in the specified subbasin and set the Reg Discharge Calculation slot on each object (at the current timestep) with the regulation discharge flag. This will trigger each control point to perform its regulation discharge calculations and compute the empty space for the forecast period. Then the model is ready to compute the flood control releases.
Figure 3.4  Sample regulation discharge rule
Flood Control
The Flood Control methods calculate a flood control release for the current simulation day. The flood control methods use forecast data (storage, inflows, empty space at 0 through Forecast Period timesteps after the current simulation timestep). They propose release schedules for each reservoir for each timestep in the forecast period to account for routing effects. They return the values for the first timestep of the proposed schedule (for the current simulation timestep).
Model Setup
There are two flood control methods, Operating Level Balancing and Phase Balancing. See “Operating Level Balancing” in Objects and Methods for details on Phase Balancing. Because most of the Southwest Division uses the Operating Level Balancing method, it is the only one discussed in this document.
To use the Operating Level Balancing method, the user must select methods on each reservoir and control point. Also a computational subbasin must be created that contains the desired objects (typically all of the objects in the model). The user must also select a number of methods on this computational subbasin. Following is an overview of the methods that should be considered on each object type.
Reservoir Methods
On each reservoir, select the following:
• Operating Level Balancing method in the Flood Control Release category; see “Operating Level Balancing” in Objects and Methods.
• Conservation and Flood Pools in the Operating Levels category; see “Conservation and Flood Pools” in Objects and Methods.
The multi-object method selector can be used to make this selection on all reservoir objects at once. The flood control method does not perform calculations on the object, but provides the following slots that will be added that require user input:
• Allowable Rising Release Change
• Allowable Falling Release Change
• Maximum Release Variation
• Balance Period
• Forecast Period
• Top of Flood Pool
• Top of Conservation Pool
• Bottom of Conservation Pool
• Operating Level Table
The value entered in the Balance Period and Forecast Period slot must be the same on all reservoir objects used in flood control. The user can set these values on all objects at once through the computational subbasin. See “Computational Subbasin Methods” for details.
Optionally, you can select a method in the Conditional Operating Level category to add an alternative operating level table, which will be used when hydrologic conditions indicate. See “Conditional Operating Levels” in Objects and Methods for details.
Control Point Methods
On each control point, select the Operating Level Balancing method in the Flood Control category; see “Operating Level Balancing” in Objects and Methods for details. The multi-object method selector can be used to make this selection on all reservoir objects at once.
Once Operating Level Balancing method has been selected, several other method categories become active. These include, but are not limited to the following:
• Key Control Point Balancing; see“Key Control Point Balancing” in Objects and Methods.
The user must decide if any of these categories apply to the control point in question (a selection is not necessary if these calculation do not apply). Several slots may be added as a result of these method selections.
If the control point is a key control point, select a method in the Key Control Point Balancing category. If a method is selected, the control point will be displayed as a key control point on the workspace with a key icon in the center of the object. Control point objects designated as key control points will be included in the reservoir balancing calculations performed during the computation of flood control releases.
Required Input Data
Configure the Upstream Reservoirs and Routing Coefficients slots on each control point. The Upstream Reservoirs slot is a list of all upstream reservoirs whose releases are routed through the control point in question. The Routing Coefficients slot will have a column for each reservoir listed in the Upstream Reservoirs slot. In each column, enter the direct routing coefficients from the reservoir in the column header to the control point object. These coefficients will be used to route releases in the algorithm that computes the flood control releases. The actual routing of the final releases is done incrementally via the reach objects. Therefore, in order to have consistent routing between the flood control algorithm and the reach objects, these direct routing coefficients should be computed from the incremental routing coefficients used on the reach objects (or vise versa) using a sufficient number of significant figures.
Note:  Flow-based routing coefficients are allowed. See “Alternative Routing Coefficients Methods” for details on these methods.
Key Control Point Balancing
If the control point is a key control point, select the Operating Level Balancing method in the Key Control Point Balancing category (the Control Point icon will then display a key symbol). Several slots are added when this method is selected. Enter a list, in the Key Control Point Reservoirs slot, of the upstream reservoirs that are balanced by the control point. This list should either be the same as, or a subset of, the list of reservoirs in the Upstream Reservoirs slot. Input a value for Balance Period. This value must be the same value on all key control points and reservoir objects. The computational subbasin can be used to set the value on all objects simultaneously. Also, input values for the Balance Tolerance and Balance Iterations slots. See “Operating Level Balancing” in Objects and Methods for details on the effects these slots have on the balance calculations.
Computational Subbasin Methods
Create a Computational Subbasin for flood control using the Subbasin Manager dialog and specify the objects included in the subbasin. The subbasin consists of all the objects, linked to form a continuous network, that are considered in the simultaneous flood control release calculations.
Configure Subbasin for Flood Control
Once the computational object has been created it can be configured for flood control. The computational subbasin object can be opened in the following ways:
• Double-click the subbasin in the Subbasin Manager dialog.
• Select Workspace, then Open Computational Subbasin from the main RiverWare menu.
The open subbasin dialog has two tabs: Slots and Methods. The slots view will be empty until a method has been selected. In the Methods view, select the Operating Level Balancing method in the Flood Control category. Several new slots and method categories will be added as a result of this selection. Input values in the following slots:
• Forecast Period
• Balance Period
• Top of Conservation Pool
• Highest Operating Level
• Lowest Operating Level
• Top of Flood Pool.
The remaining slots with the word “Tolerance” in the name will default to the tolerance values used in SUPER. See “Operating Level Balancing” in Objects and Methods for details on these slots.
Also, when the Operating Level Balancing method is selected, a number of categories become available. All of these dependent method categories on the computational subbasin default to the method selection that corresponds to SUPER behavior. See “Balance Level Determination” in Objects and Methods for details on these methods.
Propagate Values
The values entered in the Forecast Period, Balance Period, Top of Flood Pool and Top of Conservation Pool slots must be the same on all objects that have these slots. The user can enter these values on the computational subbasin and then propagate the values to all other objects using the Subbasin, then Propagate Values feature in the open subbasin dialog.
Verifying and Enabling Subbasin
Once the subbasin has been configured, it can be verified and enabled. Subbasin verification is performed by selecting Subbasin, then Verify Subbasin in the open subbasin object. This is an internal check to ensure that the subbasin is continuous and that all the required data has been input. Once the subbasin is ready for use in a model run, it can be enabled by selecting Subbasin, then Enable Subbasin in the open subbasin object. When a subbasin is enabled, the verification checks are performed at the beginning of the run and the subbasin can be used by the Flood Control function. If the subbasin is not being used in a model run and will not pass verification, it can simply be disabled and will not hinder the model run.
RPL Implementation
Once the surcharge release forecasts have been computed and routed downstream, and the empty space forecasts have been computed, the model is ready to solve for the flood control releases. The flood control logic is called from the FloodControl predefined function. This function will perform the flood control calculations for all objects in the specified computational subbasin. After execution, the FloodControl function will return the flood control value and the outflow value, for the current timestep, for each reservoir in the computational subbasin. The flood control rule will set these values on each reservoir object. The resulting reservoir outflow is then routed downstream.
The flood control rule must execute after the regulation discharge calculations and therefore must be higher priority. Add a new policy group above the regulation discharge policy group and add a single rule to this policy group. Figure 3.5 shows a sample rule that executes the FloodControl predefined function and sets the resulting outflow and flood control release (and possibly Target Balance Level) on each reservoir in the Flood Basin subbasin.
Figure 3.5  Sample flood control rule
The FloodControl predefined function executes the flood control algorithm. While it computes the flood control releases over the forecast period (using the inflow, surcharge release, flood control minimum release and empty space forecasts computed previously), only the final flood control release for the current timestep is set in the model. Therefore, the FloodControl function returns the flood control release and outflow values for the current timestep only. The FloodControl function returns a LIST that contains three items for each reservoir. Each list contains a slot, the value that should be set on that slot, and the object. So for each reservoir, the following slots are typically set using a FOR statement:
• Outflow = Surcharge Release + Flood Control Release + Flood Control Minimum Release
• Flood Control Release
• Target Balance Level
The sample rule in Figure 3.5 consists of a FOR statement that calls the FloodControl function and sets the resulting values on the proper reservoir slots. The FloodControl function performs the flood control calculations for all objects in the Flood Basin subbasin over the forecast period. In this example, Flood Basin is the name of the computational subbasin created for flood control (this may be named differently in your model). The FloodControl function returns the lists described above and the FOR expression loops through each list and sets the returned slot, at the current timestep, to the corresponding value.
In summary, the flood control rule calls the FloodControl function which computes the flood control releases for every reservoir in the computational subbasin. Then, for each reservoir, at the current timestep, it sets the Flood Control Release slot to the computed value, the Outflow slot to the computed value, and the Target Balance Level to the computed value. After the rule is finished executing, the new outflow values are routed downstream and all objects in the model solve given the outflow values.
See “FloodControl” in RiverWare Policy Language (RPL) for details on the function itself.
FloodControl Function—Detailed Description of Logic
See “Operating Level Balancing” in Objects and Methods for a detailed description of the logic for this function.
Low-flow Releases
The Low-flow Release policy computes the reservoir outflows to meet a low-flow demand at a downstream control point. If a control point’s demand can be met by multiple reservoirs, the fullest reservoir is considered first and releases as much as possible, then the next reservoir is considered. To set up this operation, the user must select methods and implement rules that call the predefined MeetLowFlowRequirements function.
Model Setup
The user must select methods on each control point and reservoir involved in the low-flow operation. Also, a computational subbasin must be created and methods must be selected on that subbasin.
Control Point Methods
For a control point with a low-flow requirement, the user should select a method in the Low-flow Requirement category to specify how the demand is represented. The valid options are as follows:
• Low Flow Periodic Lookup. The demand is specified in a periodic slot; see “Low Flow Periodic Lookup” in Objects and Methods for details.
• Reservoir Level Lookup. The demand is specified in a periodic slot that relates a reservoir level to the demand; see “Reservoir Level Lookup” in Objects and Methods for details. If the specified reservoir is disabled and is set to Pass Inflows, no low-flow requirement can be computed; see “Low-flow Requirements Based on Disabled Reservoirs” for details.
Both of these methods add the slot Low-flow Reservoirs, which is used to specify the upstream reservoirs that can serve the low-flow demand.
Reservoir Methods
On each reservoir that can possibly serve a Low-flow demand on a control point, the user should select the Enable Low-flow Releases method in the Low-flow Releases category; see “Enable Low Flow Releases” in Objects and Methods for details. This method adds the Low-flow Release slot to hold the result of the policy and the Maximum Low-flow Delivery Rate which is the maximum flow that can be released from the reservoir to meet low-flow demands.
Computational Subbasin Methods
A computational subbasin should be created that contains the objects involved in the low-flow release. Typically, the same subbasin used for the Flood Control rule can be used. On this subbasin, the user should select the Operating Level-Based method in the Low-flow Releases category; see “Operating Level-Based” in Objects and Methods for details.
RPL Implementation
A rule will need to be created for each control point that has a low-flow requirement. In the rule, a predefined RPL function, MeetLowFlowRequirement, is used to compute the required low-flow releases for each reservoir. The function will take a computational subbasin and a control point as an argument. See “MeetLowFlowRequirement” in RiverWare Policy Language (RPL) for details.
Figure 3.6 shows a sample rule that meets the Eagletown low-flow requirement using the computational subbasin name FloodBasin. The execution constraint forces the rule to execute only once.
Figure 3.6  Sample low-flow release rule
MeetLowFlowRequirements Function
See “MeetLowFlowRequirement” in RiverWare Policy Language (RPL) for details on this predefined function.
The function iterates through each of the Low-flow Reservoirs specified on the control point. For each control point (i.e. each time the RPL function is called), the following steps will take place:
1. The Low-flow Deficiency slot is checked to see if there is a low-flow shortage. If not, the Low-flow Release is zero for each reservoir. The Outflow Should not be reset if the Low-flow Release is zero.
2. If there is a deficiency, the following steps are taken:
a. The reservoirs in the Low-flow Reservoirs slot are sorted by level in descending order. Reservoirs below the bottom of the conservation pool are excluded.
b. Each reservoir (beginning with the most full reservoir) makes a release until the requirement (in the Computed Low-flow Requirement slot) is met, the Maximum Low-flow Delivery Rate (on the reservoir) is met, or the reservoir reaches the bottom of the conservation pool (whichever value is lowest). Routing coefficients (travel times) are not considered.
c. The RPL function returns a list of paired items, the Low-flow Release slot and the value to be set on the slot (for each reservoir). The rule makes the assignment to the Low-flow Release slot. The new Outflow and Outflow slot is also returned by the rule function. A ForEach statement is used to make the assignments.
When the reservoir Outflows are set, the system will solve to route the flows downstream. The Low-flow Deficiencies will be recomputed to reflect the low-flow releases. The reservoir Operating Levels will be recomputed to reflect the new releases. Then the next rule will execute to determine the low-flow releases for the next control point.
Setup to Avoid Routing Low-flow Releases
In the MeetLowFlowRequirement function, routing is not considered, but in the subsequent simulation of the releases, routing is considered. As a result, the released flow often does not meet the demand. This section describes the issues with the approach, then presents a structure to avoid routing of the low-flow releases.
Releases are made from reservoirs to meet minimum flow criteria specified at downstream Control Points. In SUPER, routing is considered in the low-flow release calculation as follows: Today's low-flow release fills deficiencies noted in yesterday's final results. Yesterday's final results are adjusted by today's low-flow release. In the RiverWare MeetLowFlowRequirement function, the current timestep’s low-flow release deficiency is used as the low-flow demand and water is released from the reservoir to meet this demand, but routing is ignored. Example 3.2 illustrates.
Example 3.2   
Assume a control point that is 1 day travel time downstream of the reservoir with a 1000 cfs low-flow requirement every day. Assume there are no other releases, no surcharge or flood control, and hydropower is inactive. On the current day, let's say there is 500 cfs at the control point from uncontrolled area flows. The reservoir would make a 500 cfs low-flow release to make up for that deficiency. However, that release would not get there until the next day. On the next day, there are no other releases or inflows. So the low-flow deficiency is still 500 cfs (the requirement is 1000 cfs and there are 500 cfs at the control point from the previous day). The reservoir would again make a 500 cfs release to cover the deficiency. However, that wouldn't get there until the next day. On the next day there is still a 500 cfs deficiency (let's keep assuming there are no other releases and no uncontrolled area inflows). So the reservoir would again make a 500 cfs release.
This example illustrates the problem with the existing RiverWare approach: the minimum flows may never be satisfied. RiverWare tries to make up the current timestep’s deficit, which often does not arrive at the control point until future timesteps. This leads to less water being released. In general, the releases for this purpose are smaller in RiverWare than in SUPER.
The model can be modified to address low-flow issues in a manner consistent with SUPER low-flow handling. That is, reservoir releases made specifically for low-flow requirements at a downstream control point are passed through secondary flow paths avoiding routing between the reservoir and control point. Below is the approach.
Creation of Secondary Flow Paths
To avoid routing the effects of low-flow releases, designated low flows were passed around routing reaches by creating a secondary flow path between a control point and its associated upstream reservoirs as follows:
1. a non-routing reach was created for use in diverting the designated low flows from the primary (existing) flow path.
2. a water user was created to the side of the primary flow path, facilitating diversion of water from the non-routing reach and returning flows to the routing reach’s Return Flow slot.
Figure 3.7 shows this setup. The secondary flow path was created by linking these two objects. The non-routing reach Available For Diversion slot was linked to the water user Incoming Available Water slot. The non-routing reach Diversion slot was linked to the water user Diversion slot. The water user Return Flow slot was then linked to the routing reach’s Return Flow slot which flows into the routing reach after the main channel flow has been routed.
Figure 3.7  Sample setup to avoid routing low-flow releases
The non-routing reach was then inserted into the existing flow path, with existing links being restructured to provide inflow / outflow connectivity. The outflow / inflow link connecting the routing reach object and its upstream object(s) was deleted. Outflow from the upstream object(s) instead was linked to the inflow of the new non-routing reach. Outflow from the new non-routing reach was linked to the inflow of the routing reach.
In the case where a reservoir provides low-flow releases to two (or more) downstream control points, this structure must be created around each routing reach between the reservoir and the lowest control point. Flows destined for low-flow demand at the lowest control point should pass through secondary flow paths created for flows destined for control points higher up in the river system. It is not necessary to create more than one secondary flow path around a single routing reach, the rules will determine the quantity of water to divert through the secondary path. For this setup (in the initial implementation), each reservoir should have a companion data object. On the data object, you should add slots to hold the low-flow releases for each downstream control point: Reservoir Data.LowFlow for CP. For example, there may be a slot “John Redmond Data.Low-flow Release For Iola”
Method Selection on Objects
On each of the new water user objects, the Return Flow category was set to Fraction Return Flow, and then the Fraction Return Flow Input category was set to Periodic Fraction. A value of 1.0 was entered into the Periodic Fraction periodic table. This sets up zero consumption in the water user; all diversion becomes return flow.
On each new non-routing reach object (named with *NoLag Div in the sample model), the Routing method was set to No Routing. Also, on each of the new water users (named with *NoLag in the sample model) the Periodic Diversion Request method was selected from the Diversion and Depletion Request category. A value of 0.0 was input into the only cell in the Periodic Diversion Request slot. This method executes at the beginning of the run and on each timestep looks up a value in the Periodic Diversion Request slot. The computed value is set in the Diversion Requested and Depletion Requested slots. This serves to initialize the water users so their diversion request is zero at the beginning of the run.
Local Inflow and Solution Direction was set to No Local Inflow, Solve Outflow on each of the new non-routing reaches. This was discovered as necessary due to rule execution and convergence errors during simulation resulting from an unintended solution direction caused by the lagging reaches.
Rules to Divert to No Lag Secondary Flow Paths
When using this setup, a slightly different structure should be used for performance and readability. For each control point where the flows should not be routed, there should be two rules:
• A lower priority rule computes the necessary low-flow release for the specified control point, but sets the value on the Reservoir's data object slot. No dispatching happens after this rule. Figure 3.8 shows an example.
Figure 3.8  Sample rule to compute low flows needed and set it on a data object
• The higher priority rule that applies it to the reservoir by increasing the Outflow and Low-flow Release slot. It also increases the NoLag.Diversion Requested slot. The system will dispatch and solve after this rule finishes. Figure 3.9 shows an example.
Figure 3.9   
This two rule structure is necessary for performance and readability. Computing the values in the first rule but setting th-m on the reservoir in the next rule improves performance by only dispatching the system once. These rules should be set to execute only once through execution constraints.
Note:  Take care if there are multiple low-flow demands. The low-flow diversion rule must divert the correct amount.
Figure 3.10  Sample ruleset that avoids routing low-flow releases
Reservoir Diversions
Diversions are made directly out of a reservoir to meet a demand. Demands can be a water user or another reservoir. Each demand can draw from multiple reservoirs and each reservoir can act as a source for multiple water users or demand points.
Model Setup
A diversion consists of a Reservoir, Diversion object, and Water User. In the simplest case, there is one of each as shown in Figure 3.11. A specific linking structure must be employed between the reservoir, diversion object, and water user objects. This can only be set up after the appropriate methods have been selected. Thus, the method selections are described first, then the linking structure is revisited. Each of these objects must have methods selected as described in the following sections.
Figure 3.11  Sample diversion from reservoir setup
Note:  If the reservoir is disabled and is set to Pass Inflows, no diversions are made. See “Diversions Based on Disabled Reservoirs” for details.
Reservoir Methods
There are no required method selections on the reservoir objects as the Diversion slot exists on all reservoirs. In previous versions, it was necessary to select the Available Flow Based Diversion from the Diversion from Reservoir category. This is no longer necessary nor encouraged as the RPL function ComputeReservoirDiversions calculates the available flow, which is different than the Available for Diversion slot used in this method.
Diversion Object Methods
On the Diversion object, the Solve Given Outflow should be selected from the Diversion Object Solution Direction category. This tells the object that the outflow will be set and cause the object to dispatch. See “Solve Given Outflow” in Objects and Methods for details on this method.
Also, the Available Flow Diversion method should be selected from the Available Flow category. This category adds the Max Diversion and Min Diversion slots which must be user input.
Water User Methods
On the water user, the user must select a method from the categories summarized in Table 3.2
 
Table 3.2   
Category
Method
Section in Objects
Return Flow
Fractional Return Flow
Fraction Return Flow Input
Input Fraction, Zero Fraction, or Periodic Fraction
Diversion and Depletion Request
Use either Input Request, Periodic Diversion Requests, or Reservoir Level Lookup.The last one allows the Diversion Request to be based on the operating level of a reservoir.
Multiple Supply Sources
Multiple Supply Reservoirs. Even if there is only one source, this adds the Supply From Reservoirs slot which will be used in the linking step below. It also adds the Maximum Delivery Rates which specifies the maximum flow that this water user can take.
Computational Subbasin Methods
A computation subbasin must be defined that contains all of the reservoir, diversion object and water users that are part of the system. Typically, this can be the same subbasin used for flood control. On this subbasin, the user should select the Operating Level-Based method from the Diversions from Reservoirs category; see “Operating Level-based” in Objects and Methods for details.
Linking Setup
Figure 3.12 shows the linking setup that must be used. The Diversion slot on each reservoir is linked to the Diversion slot on the Diversion Object.
Note:  Do not link Reservoir.Available For Diversion to DiversionObject.Available For Diversion as this unnecessary and can lead to excessive dispatching.
The demands are represented by the Water User objects. Thus, the Supply From Reservoirs slot on each Water User is linked to the Multi Outflow slot on each Diversion Object that can act as a supply for that demand.
Figure 3.12  Schematic diagram for ComputeReservoirDiversions function
RPL Implementation
A rule will need to be created for each subbasin that has reservoirs that divert. Typically, the same basin used for flood control can be used. In the rule, a predefined RPL function, ComputeReservoirDiversions, is used to compute the diversion from each reservoir and the supply to each water user. The function takes a computational subbasin as an argument. See “ComputeReservoirDiversions” in RiverWare Policy Language (RPL) for details.
Figure 3.13 shows a sample rule that meets the Reservoir Diversion demands using the computational subbasin name FloodBasin. The execution constraint forces the rule to execute only once.
Figure 3.13  Sample reservoir diversion rule
ComputeReservoirDiversions Function—Detailed Description of Logic
When the rule executes the ComputeReservoirDiversions predefined function, the following process occurs. See “ComputeReservoirDiversions” in RiverWare Policy Language (RPL) for details on the function.
Each Water User in the subbasin is visited (the order does not matter since these objects are diversions and have no upstream/downstream orientation). For each Water User, the following steps are taken.
1. A list of supplying reservoirs is generated based on the links to the Supply From Reservoirs slot. The links are followed to the diversion object then to the reservoir.
2. The reservoirs are ranked by Operating Level (highest level first). Reservoirs below the bottom of the conservation pool are ignored.
3. Loop through each reservoir. If the Limit by Reservoir Level method is selected (on the Water User object), and the Demand Reservoir has a higher level than the supply reservoir, move on to the next Water User object. If the Demand Reservoir is in the flood pool, skip ahead to the next Water User object.
4. The appropriate subslot (corresponding to the link to the current reservoir in the list) is computed as the minimum of the following:
– Diversion Requested
– Maximum Delivery Rate corresponding to that subslot (in the Maximum Delivery Rates table slot on the Water User)
– The amount of water that would draw the reservoir down to the bottom of the conservation pool
5. Each reservoir is visited until the Diversion Requested is met or there are no more reservoirs.
6. Move on to the next Water User object.
The reservoir levels are updated when moving to each water user object because multiple Water Users can divert from the same reservoir. Also, Remember, this computation is all done within the predefined function, no values on the workspace have been set.
The RPL function returns a list of slot, value pairs - the subslot and the value to be set on the subslot and also the Incoming Available Water slot and the total of all the subslots.
The rule sets the subslots on the Supply From Reservoirs slot and the Incoming Available Water slot. The Water User object can then dispatch solveStandAlone_givenDivDep (given Diversion Requested and Incoming Available Water).
The Supply From Reservoir slot propagates to the Multi Outflow slots on the connected Diversion Objects. The Diversion objects solve for their Diversion slot solveMB_givenOutflow. The Diversion values are passed to the Diversion slot on the Reservoir object and the water is removed from the Reservoir.
Hydropower
A power reservoir may release additional water from its power pool to meet a specified power commitment, i.e., the load specified for that reservoir.
Model Setup
The user must select methods on each power reservoir involved in the hydropower operation. Also, a flood control computational subbasin must be used. Optionally, methods can be selected on the control point to limit the effect the control point has on the hydropower operation.
Power Reservoir Methods
On each Level Power Reservoir, the user should select the methods summarized in Table 3.3.
Each method has its own data requirements as described in the appropriate section. Special consideration should be given to the Load Calculation as there are methods to specify the Load as an input, monthly value, annual value, periodic table, or seasonal weekday or weekend load or load time.
 
Table 3.3   
Category
Method
Section in Objects
Power
Peak Power Equation with Off Peak Spill
Power Release
Peak Power Equation with Off Peak Spill Release
Tailwater
Any method but None
Additional Hydropower Release
Meet Hydropower Load
Load Calculation
Any method but No Method
Control Point Methods
On control points, consider selecting the Flooding does not constrain hydropower release in the Hydropower Flooding Exception category. This method, sometimes used on outflow control points, indicates that additional flooding at the control point does not limit hydropower releases.
Note:  This is not typically used except in special circumstances.
Computational Subbasin Methods
Because the hydropower release operation prevents releasing hydropower water that causes additional flooding downstream, it relies on verification and data that is implemented during the Operating Level Balancing flood control initialization. As a result, the basin must execute Operating Level Balancing flood control and the same subbasin must be used for both operations. Because the hydropower operation is dependent on having flood control, no additional method selections are required on the subbasin.
RPL Implementation
A rule will need to be created for each flood basin that has hydropower reservoirs that make additional hydropower releases. The same basin used for flood control must be used. In the rule, a predefined RPL function, HydropowerRelease, is used to compute the additional release from each reservoir; see “HydropowerRelease” in RiverWare Policy Language (RPL) for details.
Figure 3.14 shows a sample rule that meets the HydropowerRelease using the “Flood Basin” computational subbasin. The execution constraint forces the rule to execute only once.
Figure 3.14  Sample hydropower release rule
HydropowerRelease Function—Detailed Description of Logic
See “HydropowerRelease” in RiverWare Policy Language (RPL) for the general logic of the HydropowerRelease function.
Note:  If the level power reservoir is disabled and just passing inflows as described “Pass Inflows” in Objects and Methods, no load is calculated nor are any releases made for hydropower purposes. Essentially, the disabled reservoir is skipped in all calculations described below. Also, see “Hydropower Releases Downstream Search” for details about disabled downstream reservoirs limiting upstream hydropower releases.
The HydropowerRelease function executes the following process.
1. Prioritizes the power reservoirs in the basin according to the relative Load shortage. This is calculated using Equation 3.1. This is a value less than one. The reservoirs with the highest values are first, the lowest reservoirs last.
(3.1)    
2. In order of priority, hypothetically calculates the additional release to meet the shortage as the minimum of the following:
– The Outflow calculated to meet the given Load. The method uses the user selected methods on the reservoir, i.e. it calls the Peak Power Equation with Off Peak Spill Release method and the selected tailwater method.
– The Outflow calculated such that the Pool Elevation would exactly equal the Minimum Power Pool Elevation.
– The Outflow calculated such that the Pool Elevation would exactly equal the Minimum Elevation for Power Operations.
– The Outflow calculated such that the Pool Elevation exactly equals the previous Pool Elevation minus the Maximum Power Pool Drawdown slot.
– The Outflow that generate the maximum possible Energy. This Energy is produced by running the turbines at max release (generator capacity) for the full timestep.
The method sets the Proposed Additional Hydropower Release slot and also returns the additional flow to the calling rule function.
3. The function then hypothetically makes the release and visits downstream control points until it reaches a tandem reservoir or the end of the subbasin, whichever comes first1. If the release causes (additional) flooding at a control point, it reduces the release until flooding is not caused or the release becomes zero.
4. A control point’s available space hydrograph (in units of flow projected into the future based on the routing coefficients on the control point) is calculated using Equation 3.2.
(3.2)    
For the purpose of Equation 3.2, Inflow includes the value of the Inflow slot (at the time of the last dispatch) and the additional inflow resulting from the hypothetical additional releases from upstream reservoirs 2. It also contains the proposed flood control release hydrograph from the last pass of the flood control method.
Once all power reservoirs have been visited (in priority order), the HydropowerRelease() function returns to the calling rule. The result is a list of {slot,value,object} triplets,. The triplets take the form {powerReservoir.slot, value for this slot, powerReservoir}. The slots include the Additional Power Release, the reservoir Outflow (if non-zero), and depending on method selection, the Load (if using the Seasonal Load Time method; see “Seasonal Load Time” in Objects and Methods for details.
Where values for additional power releases are zero, the triplet {reservoir.Additional Power Release, 0.0, reservoir} will be returned, but no triplet for the reservoir’s Outflow slot will be returned, because the value of the Outflow slot will not change as a direct result of this rule. (It may change as an indirect result, if an upstream reservoir makes an additional power release.) This avoids unnecessary dispatching when no additional power releases are made on a tributary.
The rule then sets these slots, if different, and the reservoir and all downstream objects dispatch.
Fish Release
During the hours of the day when power is not generated, water may be released to meet minimum fish flows called Fish Release or QFish. Minimum fish flows below the reservoir are specified on a monthly basis (12 values per year) and stored on a data object in a periodic slot. The release of water to meet a downstream demand is determined based on the available fish water in the reservoir, the other off peak releases that are occurring and the monthly minimum fish flow. The fish storage in the reservoir is accounted for each timestep. Fish water is either released or is lost due to evaporation. It is replenished through three methods: all inflow is shared, the accumulated local inflow is shared, or no inflow is shared. Also, anytime the pool exceeds the top of conservation pool, the fish storage is replenished.
Power releases are always made at full turbine capacity for as many hours of the day necessary to meet the load. The Fish Release is defined as the release of water that occurs when power releases are not being made. The Fish Release is considered a spill. To model this in RiverWare, a rule must be developed that calculates the additional water that must be released to meet the fish flow. Because this release is a minimum release, it is assumed that there will be no downstream flooding. Therefore, no additional functionality needs to be developed; the existing rule language is sufficient to simulate this release.
Accounting Setup on Reservoir and Control Point Objects
This model will use a simplified accounting network where each Reservoir has a storage account. Water will accumulate in the account and be released from the account according to user defined logic. The released accounting water will not propagate downstream. Following is a description of the modeling changes necessary by the user.
1. Enable accounting by selecting Enable Accounting on the Accounting menu.
2. Switch the controller from Rulebased Simulation to Inline Rulebased Simulation and Accounting.
3. Create a new Fish storage account on each desired reservoir.
4. Create a new Fish pass-through account on the object below the reservoir. Create a supply link between the two objects. This is necessary so that the user can set the outflow from the Fish account using a rule. Figure 3.15 shows a sample setup.
Figure 3.15  Sample Accounting
5. Develop User Defined Accounting Methods that describe the logic used to bring water into the account through the Slot Inflow according to one of the following methods:
– All inflow is shared and the fish account is fully replenished when the pool exceeds the top of conservation pool.
– The accumulated local inflow is shared and the fish account is fully replenished when the pool exceeds the top of conservation pool.
– No inflow is shared but the fish account is fully replenished when the pool exceeds the top of conservation pool. Figure 3.16 shows a sample method that does this.
Figure 3.16  Sample Accounting setup
6. Develop User Defined Accounting Methods that describe the logic used to account for Evaporation losses. Evaporation losses on any day is calculated as the current fish storage divided by the current total conservation storage times the current day total evaporation loss.
RPL Implementation
The rule should calculate the additional fish release necessary, set the Outflow slot and Bypass or Regulated Spill slot, by looking at the Off Peak Spill on the reservoir. This value is the water spilled (through regulated spill structures) during the non-peak (non-generating) hours of the day. If the Off Peak Spill does not meet the fish requirement, then the Reservoir outflow and bypass or regulated spill will be increased. To calculate the Fish Release, it is necessary to keep track of the volume of Fish water that is stored in the reservoir. This is best accomplished using the Accounting functionality in RiverWare. The accounting system in RiverWare provides a robust system of accounts and methods to keep track of different types of water in a system.The release rule should look at the previous Storage on the Fish account and available Fish Inflows to make sure that there is available water. When the reservoir dispatches again, the Turbine Release, Peak Release and Peak time should remain the same, only the Off Peak Spill, will change. A separate assignment will set the outflow supply from the Fish account equal to the additional water released from the reservoir. This assignment must set the outflow from the account and increase the outflow from the reservoir. Both of these outflows must be averages over the entire timestep but will actually be over the Off Peak period. Therefore, when writing the rules, it is important to calculate the correct value (off-peak) and then convert it to an average over the timestep. Figure 3.17 shows a sample rule.
Figure 3.17  Sample fish release rule
When this rule executes, the following steps are performed.
1. A Fish rule fires and checks to see if the off-peak spill is enough to meet the fish requirement. If not met, the outflow is increased to meet the requirement limited by available fish water. Another assignment will set the outflow supply from the Fish account and the bypass or regulated spill slot.
2. If the outflow was reset, the reservoir will dispatch given inflow and outflow. The dispatch method will call the Peak Power Equation with Off Peak Spill method which calculates the tailwater elevation, Peak Release and peak time. Storage, Pool Elevation and the spill slots are set using the mass balance equations.
3. The reservoir’s accounting system will solve for Fish slot inflow and gain loss according to user defined methods. The storage account will then solve for Fish account storage.
Direct from Reach Diversions
Water is diverted directly out of the river to meet demands. This operation does not require additional rules but does require additional model setup.
Model Setup
A reach object must be added for each demand point. The reach will be set up to have a diversion and will have a Min Diversion Bypass method selected. The minimum base flow requirement will be input on the Minimum Diversion Bypass slot. The reach will be linked to a water user with the appropriate methods selected. The water user object will always divert the computed Diversion Request as long as there is sufficient water available. If not, it will take the available water. The available water is computed as the total flow in the reach (Inflow) minus the Minimum Diversion Bypass.
Make sure to also add these reach objects to the subbasins created for other operations.
Reach Methods
On the diversion reach, select the methods summarized in Table 3.4.
 
Table 3.4   
Category
Method
Section in Objects
Routing
No Routing
Local Inflow and Solution Direction
No Local Inflow, Solve Outflow
Diversion from Reach
Available Flow Based Diversion
Min Diversion Bypass
Periodic Min Bypass
Water User and/or Diversion Object Methods
Either a water user or a diversion object can be used, but typically a water user is recommended. On the water user, the method selections summarized in Table 3.5 are recommended.
 
Table 3.5   
Category
Method
Section in Objects
Return Flow
Fractional Return Flow
Fraction Return Flow Input
Input Fraction, Zero Fraction, or Periodic Fraction
Diversion and Depletion Request
Use either Input Request, Periodic Diversion Requests or Reservoir Level Lookup.The latter method allows the Diversion Request to be based on the operating level of a reservoir.
Note:  If diversion requests are based on a reservoir level, but the reservoir level is disabled because it is set to Pass Inflows, requests are set to zero. See “Diversions Based on Disabled Reservoirs” for details.
 

1 Hydropower releases from upstream reservoirs will accumulate in the first downstream tandem reservoir, if one exists. No consideration is given to control points downstream of a tandem reservoir. The search continues through a disabled reservoirs; see “Hydropower Releases Downstream Search” for details.

2 The notion of hypothetical releases is significant here because a rule function cannot have side-effects (i.e., change the state of a simulation object). This means that none of the computations made by the HydropowerRelease function are visible until/unless the Hydropower rule succeeds in setting all the slots returned from the HydropowerRelease function.

Revised: 06/03/2019