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.

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.

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

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.

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.

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.

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.

Direct from reach diversions are not included in the rule set because they are designed to take whatever water is available in the reach.

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.

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.

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.

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,

This assignment statement says that the Surcharge flag should be set on the Reservoir.Outflow slot at the current timestep.

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.

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.

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.

The surcharge policy determines the mandatory release that must be made to protect the reservoir.

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.

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

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.

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.

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.

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.

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.

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.

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:

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.

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

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.

On each reservoir, select the following:

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:

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.

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:

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.

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.

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.

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.

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:

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:

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.

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.

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.

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.

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:

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.

See “Operating Level Balancing” in Objects and Methods for a detailed description of the logic for this function.

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.

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.

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:

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.

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.

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.

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.

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:

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.

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.

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.

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:

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.

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”

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.

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:

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.

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.

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.

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.

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.

On the water user, the user must select a method from the categories summarized in Table 3.2

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

See “HydropowerRelease” in RiverWare Policy Language (RPL) for the general logic of the HydropowerRelease function.

The HydropowerRelease function executes the following process.

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

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.

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.

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.

When this rule executes, the following steps are performed.

Water is diverted directly out of the river to meet demands. This operation does not require additional rules but does require additional 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.

On the diversion reach, select the methods summarized in Table 3.4.

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.