This document describes functionality developed to replicate algorithms used by the U.S. Army Corp of Engineers Southwest Division (USACE‑SWD). These algorithms, consisting of object methods, RPL predefined functions, and other utilities were developed as a replacement tool for the USACE‑SWD FORTRAN SUPER program. Although the algorithms were implemented for the USACE‑SWD, they are general in nature and available to all RiverWare users.

The purpose of this document is to consolidate all of the documentation specifically developed and delivered to the USACE‑SWD to describe the algorithms. This document contains documentation and implementation Help specific to the USACE‑SWD model setup and approach. But it contains links to the rest of the RiverWare Help to describe the general methods and functions. The document first presents an overview of the approach used. Then it describes the steps necessary to set up a basic simulation model and run it as a calibration. Next, there is a description of the process used to define operating policy using a RPL ruleset. Each USACE‑SWD policy is then described including the necessary method selections, how to define the policy in RPL, and detailed description of the algorithm. Finally, sections are provided to describe how to set up a yield study, use the Data Management Interface, use output and analysis tools, and how to improve performance of the modeling runs.

This document is intended to guide a user from a blank workspace through adding objects, implementing policy, and finally implementing a yield study.

The integration of USACE‑SWD algorithms in RiverWare brings together the RiverWare object-oriented modeling features, the power and flexibility of the priority rulebased simulation, and the Computational Subbasin, that allows the execution of multi-object computations from a rule function. The algorithms are thus implemented in modular, object-specific contexts for ease of maintenance and extension, as well as flexibility of use through user selectable methods. Following is a brief overview of the modeling steps and components.

Figure 1.1 shows the typical modeling steps to implement the functionality described in this document. An overview of each step is described in the following sections and the remainder of this document describes these items in detail.

The first step is to develop a simulation model of the system by pulling objects off the palette, selecting the appropriate methods, linking objects together and specifying required data. Next, timeseries data is specified. The data management interface (DMI) can be used to import data as desired. With enough data, the model will run. At any point, the output utilities can be used to analyze and view results. The model should be calibrated to make sure that the inputs are producing the desired outputs. For example, you may input inflows to the system and reservoir outflows. You would then make sure that reservoir pool elevation or storage are correct and that downstream flows are routed correctly.

See “Developing the Simulation Model” for details.

The model can then be converted to a predictive mode by removing some of the inputs (E.g. Storage, Pool Elevation, and Outflows) to under-determine it. Then, rules can be implemented to compute the reservoir outflows based on the state of the system and the operating policies.

Described in this document are the following policies: surcharge, regulation discharge, flood control, low-flow releases, reservoir diversions, hydropower releases, and fish releases. Each policy may have additional methods to be selected and data to be input. Then, rules can be written in the RiverWare Policy Language (RPL). Many of the rules use specific predefined functions that execute methods on objects.

See “Implementing Operating Policies Using Rulebased Simulation” for details.

Sometimes, it is desired to run the model and compute the flows that would have occurred without one or more reservoirs in place. To do so, use scripts to change the model to use unregulated conditions. Use a script to make a run and generate snapshots of desired slots.

See “Modeling Unregulated Conditions” for details on defining and running an unregulated system.

Given the model and the ruleset, a run is made. There are numerous tools and utilities that can be used to view and analyze results including the following:

See “Analysis and Output Tools” for details on viewing and Analyzing results.

A yield study is used to determine the largest constant diversion that can be made from a single reservoir such that the reservoir pool elevation will not drop down below the bottom of conservation pool at any time during the run period. Other operating policies like Surcharge, Regulation Discharge, Flood Control, Low-flow Release, and Hydropower are included in this analysis.

The Yield study uses the iterative Multiple Run Management configuration. In this configuration, the model is run multiple times with a different trial value for the diversion from a reservoir. After each run, logic is used to determine if the yield has been met and if not, a new trial value is calculated and a new run is made. Multiple reservoir can be included; each reservoir’s yield is computed separately, starting at the top of the system. Once the first reservoir’s yield is found, the next downstream reservoir’s yield is found. Thus, the model is run multiple times to find the yield from one reservoir, then that reservoir’s yield is locked in and the analysis is repeated on the next reservoir.

An existing model is converted to a yield study by importing data and an MRM RPL set. Then, the user sets up an MRM configuration and specifies the search algorithm (Bisection or a heuristic approach). The user can also specify the convergence criteria including the initial trial values and the maximum iterations. Finally, the run is made. The SCT can then be used to view the results of the multiple runs. Included in the results (for each reservoir) is the yield, the critical draw down date, the critical draw down period and the critical period duration.

The conversion to a yield study is a separate modeling step that may or may not be required for a given basin or portion of a basin. See “Computing Reservoir Yield” for complete details.

Implementation of the USACE‑SWD functionality makes use of many of the RiverWare modeling features. Following is a description of the various pieces.

The ruleset implements the policy that is used to make reservoir releases and diversions from the system. The following policies apply to one or more USACE‑SWD applications. Presented is a conceptual overview. Each piece is described in detail in the document.

The surcharge release calculations are executed by the reservoir object when the surcharge release flag is set on the outflow slot by a rule. Each rule sets the surcharge release flag on the outflow slot of a single reservoir object. The rules must start at the upstream end of the basin. When the surcharge release flag is set, the reservoir will dispatch during post-rule simulation if the Inflow to the reservoir is also known. During dispatching, the reservoir will compute the surcharge release forecast and set the Outflow slot for the current timestep and all other timesteps in the forecast period. These outflow values propagate via links to downstream objects and are routed using the selected routing method on any Reach objects that are encountered. When the flow values reach a downstream reservoir, that reservoir will have Inflow slot values for the forecast period. A subsequent rule will set the surcharge release flag on that reservoir resulting in dispatching. In this way, each subsequent downstream reservoir calculates the surcharge releases for the forecast period considering the routed surcharge releases from upstream reservoirs.

Using rule logic, Flood Control Minimum Release values can be set after the surcharge operation. It is up to the user to define the rule logic for these releases. These releases are considered minimums because they are made regardless of what the flood control logic computes. Once set, the releases are allowed to propagate downstream and occupy channel space.

After the above rules have executed and the releases have been routed downstream, a single rule sets the regulation discharge flag on the Reg Discharge Calculation slot for all Control Point objects. This triggers each control point to dispatch and execute the selected regulation discharge methods. Because the uncontrolled area inflow forecasts have already been computed and the surcharge releases have been routed downstream, each control point contains the total discharge at its location for each timestep in the forecast period. This information is used to appropriately compute the regulation discharge and empty space hydrographs.

After the regulation discharge rule has executed, the rule to calculate the flood control releases can be executed. This rule calls the predefined FloodControl function which executes the selected Flood Control method on the Computational Subbasin. The FloodControl function returns a list of flood control releases that should be made for each reservoir at the current timestep. Also included is the outflow from each reservoir at the current timestep. The outflow is computed as the flood control release plus the surcharge release plus the flood control minimum release. The flood control rule sets the Outflow slot and Flood Control Release slot on each reservoir, at the current timestep, given the values returned by the FloodControl function. When these slots are set, it triggers each reservoir to redispatch using the new Outflow value. The reservoir objects solve, compute new storage and pool elevation values (as well as execute any user selectable methods), and the new Outflow values are routed downstream.

Low-flow demands are specified at control points and each control point has a list of reservoirs that are used to meet a given demand. Also, each reservoir has a specified maximum delivery rate for meeting a low-flow requirement.

Once flood control is complete, then the Low-flow rule executes and calls the MeetLowFlowRequirements predefined function. This function determines the low-flow release for each reservoir serving a low-flow demand (i.e. a control point) as follows: If there is a low-flow shortage, the serving reservoirs are sorted by level in descending order. Each reservoir (beginning with the most full reservoir) makes a release until the requirement is met, the maximum low-flow release on the reservoir is met, or the reservoir reaches the bottom of the conservation pool (whichever value is lowest).

When the reservoir Outflows are set, the system resolves to route the flows downstream. The low-flow shortages 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.

Once low-flow releases have been made for all reservoirs, direct from reservoir diversions are calculated by calling the predefined function ComputeReservoirDiversions. Reservoir 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.

The diversions from the reservoir are modeled using diversion objects while the actual demands are modeled with water user objects that compute their Diversion Request (water supply requirement). Even if the demand point is another reservoir, the demand is modeled with a Water User object (configured to have a 100% return flow which could then be sent to the demand reservoir).

When called, the ComputeReservoirDiversions function computes the diversion to each water user by visiting each reservoir (in order of highest level first) and trying to meet the diversion request but limited by maximum delivery amounts, not drawing below the conservation pool. Also, if the demand is a based on reservoir level, no diversions are made if the demand reservoir and has a higher level than the supply reservoir, or the demand reservoir is in the flood pool.

The rule sets the Supply From Reservoirs and the Incoming Available Water slots causing the water user object to solve. It then propagates values to the diversion object and the reservoir which also dispatch and solve.

After surcharge releases, flood control, low-flow releases, and reservoir diversions have been made, a reservoir may release additional water from its power pool to meet a specified power commitment, i.e., the Load specified for that reservoir. The hydropower rule executes the HydropowerRelease predefined function. This function tries to meet the specified or computed load but is limited to prevent the following conditions:

The rule sets the additional hydropower release and increases the reservoir Outflow. This causes the reservoir to redispatch and propagates the water downstream.

On a power reservoir, during the hours of the day when power is not generated, water may be released to meet minimum fish flows. These are called Fish Releases or QFish releases. 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 demand. 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 the following 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.

To summarize, the following are the steps that are taken for each timestep in the model.