skip to main content
Modeling Physical Processes
USACE‑SWD Modeling Techniques
Modeling Physical Processes
Developing the Simulation Model
Before implementing the various USACE‑SWD policies, it is necessary to build and calibrate a model of the physical river basin network. This involves selecting objects and linking them together to accurately represent the physical features of the river basin. In addition, user methods are selected to model various physical processes (i.e. spill, evaporation, seepage, routing, etc.) depending on the level of modeling detail required.
Initially, the model should be run in Simulation mode. In Simulation, RiverWare solves an exactly determined system given a set of user inputs. No rules or policy constraints are involved in the solution. Each object performs a mass balance calculation and solves any user selected methods. The purpose of the simulation model is to ensure that the physical features of the basin are correctly modeled. In this stage of model development, the modeler checks input data for accuracy, checks for proper mass balance and routing, and calibrates the model. Only after the physical model has been calibrated, should the modeler begin implementing policy through the use of rules.
Model Building Steps
Following is a very general description of the steps involved in building a simulation model. These steps should be performed in order with the exception of Step 5., and Step 6. which are interchangeable. Each step is discussed in greater detail below.
1. Set the model timestep size and the start/end dates in the Run Control dialog.
2. Set the Number of Post-Run Dispatch Timesteps.
3. Create a Unit Scheme
4. Add objects to the workspace from the palette.
5. Select the appropriate methods on each object.
6. Link the objects together.
7. Input the required data.
8. Run the model and evaluate the output.
Set Timestep and Start Date
Before adding objects to the workspace, the user should select the model timestep and specify the start and end dates of the run. This is done through the Run Control dialog.
Set Number of Post-run Dispatch Timesteps
Set the number of timestep after the run for which dispatching should be allowed. Typically you can set this equal to the forecast period. See “Post-run Dispatching” for instructions.
Define Display Units Through a Unit Scheme
The first step when setting up a model is specifying the display units for objects taken from the palette. The internal units in RiverWare are SI units but you can define the display units, scale, precision and format by setting up a Unit Scheme. In the Unit Scheme you configure these four attributes for each unit type. Then you can define exceptions to the general rule. That is, for a specific slot you may want to show the values in some other display unit. See “Unit Schemes” in User Interface for details.
Add Objects to the Workspace
Build the model network with appropriate selection of objects from the RiverWare object palette. Include control point objects at the desired locations.
Select Methods on Objects
On each object, select methods to model various physical processes (i.e. spill, evaporation, seepage, routing, etc.) depending on the level of modeling detail required. See “Reservoir Objects” for details on these methods for the basic simulation model.
Note:  These methods are strictly for the calibration model; additional methods will be selected later to implement the flood control, surcharge, and conservation pool operations.
Link Slots
Slots on objects should be linked to form the network representing the basin. For example, Reservoir Outflow should be linked to the downstream control point or reach’s Inflow slot.
Input Data
Supply the required data to the objects. There are two types of data, table or parameter data and mass balance data.
• Table/Scalar data. Specify required table/scalar data to the slots on the objects.
• Mass Balance and series data. The user should specify unregulated local inflows to control point and reservoir objects; see “Forecasting Incremental Local Inflows From Cumulative Flows”. In addition, specify enough mass balance data, typically on the reservoir objects, to run the model. This could include inflows and reservoir storage, pool elevations, or outflows; see “Reservoir Inflow and Mass Balance Data”.
Run and View
Once all objects have been configured (method selection and input data) and have been linked together, the model is ready for simulation. When the model is run, it should compute the inflow forecasts, mass balance the reservoir objects, and properly route releases downstream. The purpose of these simulations is to ensure that the modeling of the physical system has been done correctly. During this stage the model should be calibrated if necessary. Any error messages or data problems need to be resolved before moving to policy modeling. Since the inflows, uncontrolled area flows, and storage or pool elevation values have been input, each reservoir should mass balance correctly to solve for outflow. These outflows should also be routed downstream. The modeler can also input reservoir outflows and check the resulting storages and pool elevations. The resulting values computed by RiverWare should be checked against known values for accuracy. See “Modeling Unregulated Conditions” for details on viewing and analyzing results.
Reservoir Objects
When selecting a reservoir object to represent a reservoir/dam that has power production capabilities, it is best to select a power reservoir object even if the model will not be used for modeling power initially. It is easy to enable and disable power modeling on a power reservoir object but it is not as easy to change from a storage reservoir to a power reservoir after the model has already been completed.
Required Inputs
Input the relationship between pool elevation and storage in the Elevation Volume Table slot. Also, for every reservoir, an initial Pool Elevation or Storage is required.
On storage reservoirs, input the pool elevation versus release information in the Max Release slot (For level power reservoirs, similar data will be entered based on the selected power method as described in the next section).
Power Methods
For level power reservoirs, the user must select a method in the Power Calculation category regardless of whether or not the object will be used for power calculation. If the object will not initially be used to compute power, select the No Power Turbine Flow method. When this method is selected the Max Flow Through Turbines slot will be added and should be populated with the relationship between pool elevation and the maximum outflow through the turbines. However, no power calculations will take place. If the user does wish to model power, he/she should select the appropriate power calculation method. At this stage any of the methods can be used, but if releases are to be made using the HydropowerRelease function (see “Hydropower”), then the Peak Power Equation with Off Peak Spill method should be selected. See “Peak Power Equation with Off Peak Spill” in Objects and Methods for details on the required data.
Tailwater Methods
When a power method is selected, a tailwater method must also be selected. See “Tailwater” in Objects and Methods for details on the available methods.
When setting up the tailwater method, there are some important aspects to remember. The Tailwater Base Value is a series slot that is used to link to a downstream reservoir’s Pool Elevation. If the Tailwater Base Value is not linked to a downstream reservoir, it is best to leave NaNs in the Tailwater Base Value and have the Tailwater Table include all of the data necessary to calculate the correct tailwater.
This section describes how SUPER tailwater data can be input into the Tailwater Table to mimic SUPER’s functionality. In SUPER, there is a variable called the Block Loading Tailwater Elevation (BLTE). This is defined as the tailwater that results when releasing Turbine Capacity with the reservoir at the top of the power pool with no other releases. In this description, this is called the “Turbine Capacity at Top of Power Pool.”
The Tailwater Table can be input such that the look up flow will result in the correct tailwater elevation. The table will be as follows: If the flow is less than or equal to the Turbine Capacity at Top of Power Pool, then the tailwater is a constant value equal to the BLTE. If the flow is greater than the turbine capacity at top of power pool, then the value is from the right portion of the curve. See Figure 2.1. Based on sample input data, only the right portion of the curve is currently input into SUPER. This method will allow the USACE‑SWD to first input the table to mimic the SUPER methodology but in the future, the full table can be input.
Figure 2.1  Tailwater table diagram
Spill Methods and Required Data
In RiverWare, a spill is a portion of the outflow that does not go through the turbines (on a power reservoir) or through the main release works (on a storage reservoir). Spills can be controlled (Regulated Spill and Bypass) or uncontrolled (Unregulated Spill).
Spill Calculation Category
The spill calculation category is used to model various spillway structures and configurations. Select a spill method only if the model will differentiate between spillway outflow and outflow through the release gates. If a single curve is used to represent total reservoir outflow as a function of pool elevation, then no spill method is necessary. On a storage reservoir the flow vs. pool elevation data is held in the Max Release slot while on power reservoirs it is held in the power method specific slot. If uncontrolled spillways or additional controlled release structures need to be modeled, select the appropriate spill method. If a spill method is selected, enter flow vs. pool elevation data for the various release and spill structures modeled. See “Spill” in Objects and Methods for details on the spill methods.
If a spill method is selected, input the pool elevation vs. spill information on the appropriate slots. For USACE‑SWD applications, the “Drift” slots are not used and can remain empty.
Spillway and Release Modeling
Previously, the USACE‑SWD used a single relationship to define the maximum outflow as a function of pool elevation. This relationship is called the free flow rating curve. The free flow rating curve includes outflow through the turbines, regulated spillways, and unregulated spillways. Normally, the proper spill method would be selected to model each of these outflow structures separately. The data in the free flow rating curve would then need to be disaggregated for each outflow structure modeled. Originally, the USACE‑SWD decided not to model each outflow structure separately and wanted to leave the free flow rating curve intact (as opposed to disaggregating the information). Therefore, they did not select a spill method and instead input the free flow rating curve (maximum total outflow vs. pool elevation) in the Max Release slot on storage reservoirs and in the Max Flow Through Turbines slot on power reservoirs. RiverWare will solve normally when configured in this fashion. Instead of using spillways and regulated spill structures, all outflow is sent through the Release slot (on storage reservoirs) or the Turbine Release slot (on power reservoirs). While this will not affect the reservoir calculations, it is misleading because the Turbine Release and Release slots will show outflow for both the release and spill structures. This would not work if the reservoir is being used to compute power. In that case, a spill method should be selected. The sum of the turbine release capacity and spill capacities should equal the free flow rating curve.
Order of Spillway and Release Structures Used in RiverWare
If more than one spillway or release structure is being modeled on a given reservoir, RiverWare sends the reservoir outflow through these structures in a specific order. If there is an uncontrolled spillway, the spill over that structure is computed based on the average pool elevation over the timestep. Any remaining outflow is then sent through the turbines, if it is a power reservoir, or through the Release slot if it is a storage reservoir (the maximum release information is held in the Max Release slot). If there is any remaining outflow, it is sent through the Regulated Spill slot or the Bypass spill slot depending on the spill method selected. In general, RiverWare assumes that all outflow should go through the turbines (or the Release slot on storage reservoirs) and any excess is sent through the regulated spill structures.
Inflows
There are many slots on the reservoirs that can represent sources and sinks to the mass balance. This section describes the recommended structure for the inflows to the reservoir.
Reservoir Inflow and Mass Balance Data
The Inflow slot represents the inflow to the reservoir from upstream (routed flows from upstream, not uncontrolled area flows). Therefore, the Inflow slot on all reservoirs should be linked to the Outflow slot of the upstream object unless the reservoir is a headwater reservoir. If it is a headwater reservoir, a flow rate of zero should be input for all timesteps (including values through the last dispatch timestep) in the Inflow slot (the reservoir will still receive inflow from the Hydrologic Inflow Forecast slot).
Since the inflow to each reservoir will be known (either propagated from an upstream object or input to zero), one other piece of data must be input for each timestep to allow the reservoir to mass balance. An initial value for either storage or pool elevation must be input and then values must be input at each timestep for either pool elevation, storage or outflow. For testing purposes, and to ensure proper mass balancing, various combinations of inflow, outflow, storage and pool elevations can be input and evaluated.
Forecast Inflow—Uncontrolled Area Flow
The reservoir objects (and control points) are used to bring uncontrolled area flows into the system. The USACE‑SWD data for uncontrolled area flows is the cumulative, uncontrolled area flow from the upstream reservoir to the control point, adjusted for routing. As a result, it cannot be input directly into the Local Inflow slot or the flows would be multiply counted. Also, the uncontrolled flows must be forecasted to provide an estimate throughout the forecast period. Specific methods must be selected to deal with these two unique features. See “Forecasting Incremental Local Inflows From Cumulative Flows” for details.
Seepage
Seepage through the face of the dam is modeled by selecting the Input Seepage of Single Seepage Value method in the Seepage category. These methods allows the user to input a timeseries of seepage values or a constant value. The Reservoir.Seepage slot should then be linked to the downstream object’s Local Inflow slot. Figure 2.2 shows the correct linking structure.
Figure 2.2  Linking seepage
Other Possible User Methods
There are several other user method categories available on the reservoir that are not discussed in this document. Decide what additional physical processes need to be modeled (if any) and then select the appropriate methods and input the appropriate data. Possibilities include evaporation and precipitation, or bank storage. See “User Methods” in Objects and Methods for details on the methods and associated slots.
Reach Objects
The Reach object is used to route water through the network. Also, water diversions from the river must come out of the Reach object. The Inflow slot should be linked upstream and the Outflow slot should be linked downstream. See “User Methods” in Objects and Methods for details about user methods not discussed here.
Routing
The Step Response routing method is typically used by the USACE‑SWD; see “Step Response” in Objects and Methods for details. This is the same routing algorithm used in the FloodControl predefined function in RiverWare. If the user selects a different routing method, then the final releases will be routed with a different method than that used in the algorithm to determine the flood control releases.
If the Step Response method is selected, input the number of routing coefficients in the Num of Coeff slot on the reach object. The routing coefficients are input in the Lag Coeff slot. These coefficients are the INCREMENTAL routing coefficients that apply to that reach specifically (as opposed to the direct routing coefficients used on the control points for the computation of flood control releases).
Sometimes, the routing coefficients are not fixed, but are dependent on the flow in the reach, particularly during high flow events. In this situation, the Variable Step Response routing method should be used; see “Variable Step Response” in Objects and Methods for details. See “Alternative Routing Coefficients Methods” for details.
Solve Downstream Only
On any reach in the model that does not have routing (i.e. the No Routing method is selected), the user should select the No Local Inflow, Solve Outflow method in the Local Inflow and Solution Direction category; see “No Local Inflow, Solve Outflow” in Objects and Methods for details. This method forces the reach to always solve in the downstream direction. This eliminates the possibility of unintentional upstream solving as a result of complicated rule priorities.
Transit Losses
In certain basins, the USACE‑SWD simulates the loss of water released from a reservoir to meet downstream demands. In the GainLoss category, the Base Plus Fractional Loss method models loss to meet all the following criteria. See “Base Plus Fractional Loss” in Objects and Methods for details.
• Base loss
• Loss that is a fraction of flow above that base loss
• Total loss cannot exceed a maximum flow rate
In addition, the base loss and fraction above that base can be entered seasonally for future extensibility. Select this method or another method in this category to model transit losses.
Confluence Objects
The confluence object brings together flows from two objects. Select the Solve Downstream Only method in the Confluence Solution Direction category; see “Solve Downstream Only” in Objects and Methods for details. This method forces the confluence to always solve in the downstream direction. This eliminates the possibility of unintentional upstream solving as a result of complicated rule priorities.
Control Point Objects
The control point models a location on a river where certain flow requirements (maximum and minimums) must be maintained. The control points are used for flood control operations such that the flood control releases do not cause an exceedence of channel capacity at these points. They also represent the location for low-flow demands and additions of uncontrolled local flows.
Local Inflows and Uncontrolled Area Flow
Control points (and reservoirs) are used to bring uncontrolled area flows into the system. The USACE‑SWD data for uncontrolled area flows is the cumulative, uncontrolled area flow from the upstream reservoir to the control point, adjusted for routing. As a result, it cannot be input directly into the Local Inflow slot or the flows would be multiply counted. Also, the uncontrolled flows must be forecasted to provide an estimate throughout the forecast period. Specific methods must be selected to deal with these two unique aspects. See “Forecasting Incremental Local Inflows From Cumulative Flows” for details.
Control Points located at the outflow of a reservoir (or those that don’t have local inflows) should not use these methods; they should keep the None method selected in the Local Inflow category.
Water User Objects
The water user diverts water from either a reach or reservoir, uses a certain amount, and returns the rest. The USACE‑SWD uses Water User objects to simulate reservoir and reach diversions in their models. In the simulation/calibration model, the user should only configure water users to make direct from reach diversions. Any diversions from the reservoirs should be input directly on the reservoir’s Diversion slot. When the policies are implemented to determine the reservoir diversions, there are additional methods and linking structure that must be created. See “Reservoir Diversions” for details.
Typically, some water users remove water from the system but do not return any water. Other Water Users are used to divert from one reservoir or reach and pump it into other reservoirs. These Water Users return all the diverted flow to the other reservoir. On each water user, the user should select the Fraction Return Flow method in the Return Flow category. Then, in the Fraction Return Flow Input category select one of the following:
• Input Fraction. The user provides a series of Fractional Return Flows; see “Input Fraction” in Objects and Methods.
• Zero Fraction. The return flow is set to zero and all water is assumed to be depleted; see “Zero Fraction” in Objects and Methods.
• Periodic Fraction. A periodic slot will represent the fractional return flow. The USACE‑SWD can input a 1.0 to represent that all water diverted is to be returned; see “Periodic Fraction” in Objects and Methods.
Data Objects and Custom Slots
Data objects are useful for storing data that is not directly applicable to a simulation object. For example, a data object can be used to hold system data. Custom slots can be created on data objects or on simulation objects. For example. custom slots can be created on the reservoir to hold historical reservoir data for easy comparison with the RiverWare results. Also, custom expression slots and statistical table slots can be used for post processing and analysis of the data. See “Objects and Methods” in Objects and Methods for details on data objects See “Statistical Slots and Probability Plots” for details on USACE‑SWD analysis tools.
Forecasting Incremental Local Inflows From Cumulative Flows
In USACE‑SWD basins, streamflow data represents the cumulative inflow to the river up to that point. These cumulative inflows cannot be routed downstream in RiverWare since the next downstream Control Point also has cumulative inflows. However, routing inflows in RiverWare is useful so that diversions can be made from Reaches and so that the Reaches will be routing the correct flows. In order to address this problem, methods were developed to use the cumulative inflows at Control Points and Reservoirs, and calculate the Incremental Flows. The methods calculate the forecasted incremental local inflows at each control point and reservoir within a subbasin given the cumulative local inflows. These methods are described in this section and in the objects specific help.
User Implementation
Users will first need to set up a computational subbasin for each group of control points and reservoirs that contain cumulative local inflow data. The computational subbasin(s) must include all control points and reservoirs which contain the cumulative local inflow data as well as all the intervening reaches and confluences. Each control point and reach should only be included in one reservoir's subbasin. For example, in Figure 2.3, there is a subbasin that contains Clayton, Clayton_Antlers, Antlers, Antlers_Diver_Reach, Antlers_Hugo, and Hugo. The subbasin does not go upstream any further because Sardis Outflow and Tuskahoma Dam Site either have no locals or the locals are already included in Outflow.
Figure 2.3  Sample computational subbasin
For each computational subbasin, select the Compute Forecast Period Incremental Local Inflows method from the Compute Incremental Local Inflows category. This enables the Reservoir Boundary for Incrementals category. Because cumulative local inflow data is only cumulative until a reservoir is reached, select the Stop at Reservoirs method from the Reservoir Boundary for Incrementals category.
Additionally, all headwater reservoirs and those with reservoirs with no upstream objects that have cumulative inflows should be placed in a single computational subbasin. Then on the subbasin, select the Compute Forecast Period Incremental Local Inflows method from the Compute Incremental Local Inflows category. This enables the Reservoir Boundary for Incrementals category. Select the Reservoirs Only method from the Reservoir Boundary for Incrementals category; see “Reservoirs Only” in Objects and Methods for details. This method allows the user to input local inflow data into the Cumulative Hydrologic Inflow slot on the reservoirs but the reservoirs do not have any upstream objects for which there are cumulative local inflows. This usually happens on headwater reservoirs but can also occur when a reservoir is directly downstream of another reservoir and inflows do not accumulate between the two reservoirs. This method allows users to input cumulative inflows consistently throughout the model in the Cumulative Hydrologic Inflow slot.
Note:  Make sure to enter values after the run so that post-run dispatching can occur. That is, you only need to input Cumulative Hydrologic/Local Inflows through the run end plus the Period of Perfect Knowledge on each inflow location. See “Post-run Dispatching” for details.
For each control point and reservoir in each computational subbasin several new methods must be selected. Method selection on multiple objects can be accomplished efficiently through the Multiple Object Method Selector. The Multiple Object Method Selector is enabled by selecting Workspace, then Objects, then Select Methods on Objects.
In RiverWare, local inflows are called Local Inflows on Control Points and Hydrologic Inflows on Reservoirs. In this discussion, we will use the terminology Local Inflows exclusively; please substitute Hydrologic Inflows anywhere a reservoir is referenced.
For each control point and reservoir in an incremental calculation subbasin, users should specify the following criteria. The listed methods are described in the object-specific documentation.
• Select Forecast Local Inflows method (in the Local Inflow category) to specify that forecasting should be performed.
• Specify how the forecasting should be performed. Typically, for the USACE‑SWD, the Geometric Recession method should be selected in the Generate Forecast Inflows category.
• Select the Compute Forecast Period Incremental Local Inflows method from the Compute Incremental Local Inflows on Subbasin category (Compute Incremental Hydrologic Inflows on Subbasin category on reservoirs).
• On the control points, the Locals Included In Outflow method should be selected from the Include Locals in Outflow category.
With this setup, the user then inputs the cumulative flows into the Cumulative Local Inflow slot (on control points) or the Cumulative Hydrologic Inflow slot on the reservoirs.
Methods
 
Table 2.1  Storage and Level Power Reservoirs
Category
Method
Storage Reservoir Section in Objects
Level Power Reservoir Section in Objects
Hydrologic Inflow
Forecast Hydrologic Inflows
Generate Forecast Hydrology
Geometric Recession
Compute Incremental Hydrologic Inflows on Subbasin
Forecast Period
 
Table 2.2  Control Point
Category
Method
Control Point Section in Objects
Local Inflow
Forecast Local Inflows
Generate Local Inflows
Geometric Recession
Compute Incremental Local Inflows on Subbasin
Compute Forecast Period Incremental Local Inflows
 
Table 2.3  Computational Subbasin
Category
Method
Computational Subbasin Section in Objects
Calculated Incremental Local Inflows
Compute Forecast Period Incremental Inflows
Reservoir Boundary for Incrementals
Any method
Initialization for Routing Methods
In routing reaches, the user must input enough data before the start of the run (presimulation) to allow the reaches to solve for the Outflow at the first (and possibly subsequent) timestep. The necessary slots and number of presimulation values required to ensure solution of the entire system at the start timestep depends on the number, type, linkages, method selection and parameterization of objects in the system.
In most circumstances, the modeler identifies the presimulation data requirements through knowledge of the system or trial and error. These data are then specified (manually or via input DMIs) to provide the model with required and reasonable data. This section describes an approach to automatically initializing flow slots at presimulation timesteps so routing can simulate successfully at the first computational timestep.
Slots Requiring Presimulation Values
The following section describes the slots used in USACE‑SWD models requiring presimulation data.
1. Outflow from each reservoir to initialize inflows to downstream routing reaches.
Note:  Reservoirs never dispatch before the start of the simulation and as a result, reservoirs need neither Inflow nor Hydrologic Inflows, before the start of the run. Of course, reservoirs still require 1 initial value for pool elevation or storage. Also, certain methods require a single value for the initial timestep. For example, the tailwater methods require an initial Tailwater Elevation. These single initial values will still need to be input by the user.
2. Seepage from each reservoir, when in use and linked. Typically, the reservoir Seepage slot is linked to the outflow Control Point’s Local Inflow slot. When non-zero, Seepage is typically a small value. But the Seepage needs to be initialized to provide reasonable flows downstream on the first timestep.
3. Flow into the upstream-most non-reservoir object of each tributary, typically a control point inflow or possibly a reach inflow. In the case of many models, these are all control point objects (often called Dam sites).
In the USACE‑SWD models, secondary flow paths have been created to allow Low-flow Releases to be diverted around the routing reaches as shown in Figure 2.4. Because this modeling approach requires a No Routing reach and a water user, additional presimulation values are required to solve these two reaches at the first timestep. See “Low-flow Releases” for details.
4. Diversion on reaches diverting to water users. In addition, any direct-from-reach diversions will also need the Diversion slot initialized.
5. Return Flow on reaches when linked to water users.
Note:  Although Diversion and Return Flow are not typically required to solve a reach, if these two slots are linked but unknown, the reach will dispatch but not solve.
In the above screenshot, the two reaches are linked to the water user (Reach.Diversion to Water User.Diversion, Reach.Return Flow to Water User.Return Flow). As a result, it is only necessary to set one side of the link and it makes no difference which side is set. Therefore, it would be identical to initialize the Water User’s Diversion and Return Flow slots.
6. Local Inflow on reaches, when instantiated.
Figure 2.4  Linking structure for secondary flow paths
Presimulation Values
Currently in USACE‑SWD models, all presimulation values are set to zero. On the Local Inflow, Diversion, and Return Flow slots, this value may be reasonable. But zero reservoir outflow does not seem reasonable as this value will propagate downstream. Therefore, the above slots can be initialized using one of the following methods:
1. Assign zero to all presimulation timesteps.
2. Assign the user-input value at the initial timestep to all presimulation timesteps on that slot.
Required Number of Presimulation Timesteps
For each object, the method determines the number of required presimulation values by visiting each downstream reach object and looking at the routing characteristics. The search is stopped when a reservoir or other object that does not dispatch before the first timestep is met or the downstream-most point in the basin is found. Objects that do not dispatch before the timestep are: Reservoir (all types), Pipeline, Inline Pump and Bifurcation. The upstream to downstream search will stop at any of these points.
Note:  Even though the Gage does not dispatch before the start of the timestep, its inflow and outflow are linked, allowing any upstream values to propagate downstream.
Reservoirs of all types, Pipelines, Inline Pumps and Bifurcations will not calculate a mass balance for timesteps before the begin of the run, so reaches downstream of these points must be initialized as if they were at the top of their basins. For example, flows above a reservoir will not affect the outflows specified for the reservoir because the reservoir cannot solve prior to the start timestep.
To ensure that this algorithm produces the same results for model files without the initialization method, every object is checked to see that it is a member in a subbasin with an initialization method. If the object is not a member, the number of lags calculated will be zero, and the results of the first dispatch timestep will be the same as without these methods selected.
The number of required presimulation values will be determined as follows:
• Visit each reach in the flow path and sum the number of lag coefficients. For each object, the required number of presimulation timesteps is calculated using Equation 2.1.
(2.1)    
Note:  This approach assumes you can determine the maximum number of coefficients a priori. Therefore, it only works for the No Routing, Step Response, Variable Step Response, Impulse Response, Time Lag, or Variable Time Lag methods.
• When diagnostics are turned on, Reaches and Aggregate reaches report the total number of downstream timesteps required in order to solve the most downstream object at the first timestep. Aggregate Reaches, like other objects, report the total number of timesteps required, but because they contain reaches, the contained reaches also report the number of timesteps required.
Methods
Using Initialization Methods
To apply the initialization functionality to an existing USACE‑SWD model, the following steps are required.
1. Create a subbasin.
2. Define initial values as necessary.
3. Disable existing initialization rules.
This section will identify and walk through these steps.
Create an Initialization Subbasin
The Initialization methods reside on a Computational Subbasin. While several computational subbasins exist in USACE‑SWD models, it is recommended that a new subbasin be created to ensure that all simulation objects be considered for initialization; not just those listed in an existing subbasin.
• Open the Workspace, then Edit Subbasins dialog.
• Select the Subbasin, then Append Typed Subbasin, then Computational Subbasin.
• Select the new subbasin to rename it, then select Subbasin, then Invoke Member Selector.
• Use the Selector to select all simulation objects (excluding data objects) as members of the subbasin.
• Close the Subbasin Manager dialog and return to the workspace, select Workspace, then Open Computational Subbasin, then <Name of the New Subbasin>. Shift to the Methods tab and select the desired initialization method from the Initialize Flow Slots for Routing category. For simplest initialization, select Backcast Zeros. Otherwise, select Backcast Initial Value.
If further flexibility is required, the user may create separate subbasins to initialize objects differently. For example, choose to specify all reservoirs as part of a Computational Subbasin that Backcasts the Initial Value. All the other objects should be part of a Computational Subbasin that would Backcast Zeros. This approach is possible because all of the objects in the model should be in a subbasin to find the correct downstream lag, they don’t necessarily have to be in the same subbasin.
Define Initial Values as Necessary
In past USACE‑SWD models, slots requiring initialization values were set with rules and/or were set manually. If desired, these user-input values may now be removed, resulting in the model relying more fully on the Initialization methods. Remember that these user input values or any extra values do not interfere with proper execution of the Initialization methods, but may be unnecessary. While there are several means to accomplish removing the initial values, during development and testing CADSWES staff found the following method to be relatively efficient.
1. Create a new SCT and add all existing slots to it.
2. Under Config, then General, extend the display period by setting the Pre-Run Timesteps value to a high number.
3. Scan through the slots focusing at or near the Initial Timestep for those shaded as User Input (gray). When a slot is found with user input, remove those values as appropriate. If you have selected Backcast Initial Values, make sure to leave one input value on the initial timestep.
Remember that certain slots require user input at the Initial Timestep, such as Reservoir Storage or Pool Elevation.
Deactivate or Remove Initialization Rules
If previous initialization efforts included usage of rules to initialize diversions, return flows or local inflows, these rules should be removed or deactivated. If the chosen method is Backcast Zeros, the model should run.
Other Suggested Changes
Change no-lag reaches to use the No Local Inflow, Solve Outflow method to avoid requiring the Local Inflow to have a initial value. See “No Local Inflow, Solve Outflow” in Objects and Methods for details.
Diagnostics are available for the initialization methods under the Dispatch Management, SimObj category. Make sure to select the computational subbasin in the object filtering section.
Alternative Routing Coefficients Methods
In the USACE‑SWD flood control routing methods, releases are routed using the Step Response routing method. During extreme large events with overbank flow, the channel routing coefficients are insufficiently accurate to model the routing of water down the reach, i.e., large flows that occupy the overbanks have different travel times. This section outlines the required simulation functionality and proposes a design to add the capability to RiverWare to provide for alternative routing coefficients during high flows, both in the reach simulation and in the flood control release algorithm.
The USACE‑SWD typically uses the Step Response Routing method to route water in RiverWare simulations. There are two separate sets of routing coefficients used, one set for each control point and one set for each reach. The control point routing coefficients are used in the flood control algorithm’s release determination while the reach routing coefficients are used in the simulation to route water. These two routing methods are described below.
One set of routing coefficients for each upstream reservoir resides on the control point Routing Coefficients slot. These coefficients are used only in the flood control algorithm to estimate the effect reservoir releases would have on downstream flooding. In the flood control algorithm water is routed from each upstream reservoir directly to the control point (i.e. reservoir outflow routed to control point) using Equation 2.2.
(2.2)    
The estimated flow at the control point is the sum of the contribution from each upstream reservoir. This equation is only used in the routing in the flood control calculation (i.e. rule function evaluation) and does not actually route water to the control point. These calculations are used by the rule to set reservoir outflows.
The reach is used to route water in the simulation after reservoir outflows have been set. On the reach, the following equation is used to incrementally route water in the reach (i.e. route Inflow plus Local Inflows to Outflow) during the simulation. Step Response routing uses Equation 2.3.
(2.3)    
This equation is used to calculate the current and future outflows (from t = current to t = number of coeffs). All of the C values are calculated outside of the model and for each set of coefficients, the C values sum to 1.0.
To simulate large flows accurately, it is necessary to use alternative routing coefficients only at high flows for both the flood control calculation and the reach simulation. These routing coefficients come into effect when flows are above thresholds. These coefficients are used when the flow is above a threshold in both the flood control algorithm and the reach routing.
Note:  It is not necessary to use Step Response Routing on the reaches for simulation/dispatching. You can use any routing method you want. Of course the routing will not match the linear routing used in the flood control algorithm. If you do use a different routing method on the reaches, you will need to still specify routing coefficients on the Control Points. If you wish to use flow based routing coefficients, you will need to select the Variable Step Coefficients method in the Alternative Routing on Subbasin category. This is described below.
User Implementation
To implement the above approach, various methods must be selected.
In the simulation/calibration model, you have the following choices:
• Select the Variable Step Response routing method on the reach. This method adds the alternative coefficients table slot.
• If you wish to not use the Variable Step Response method for simulation/dispatching, select a different routing method, like Modified Puls. But, you must then select Variable Step Coefficients in the Alternative Routing on Subbasin category.
Then, populate the Variable Lag Coefficients table slot with data.
When Flood Control is implemented, a computational subbasin must have the correct method selections. Generally, the same subbasin used for Flood Control should be used for this purpose; see “Flood Control” for details. This subbasin will contain most, if not all objects in the basin. On this subbasin, select the Compute Aggregate Coefficients method in the Control Point Variable Routing Coefficients category.
Additionally, on each control point downstream of a reach with alternative coefficients, the user must select the Compute Aggregate Coefficients method or Compute Aggregate Coeffs every Timestep method in the Variable Routing Coefficients category. No additional data entry is required on the control point for this method (although the standard Routing Coefficients table are typically input on the control point for the normal flow conditions).
Methods
To enable this approach, the user must select methods on the objects summarized in Table 2.4.
 
Table 2.4   
Object
Category
Method
Section in Objects
Reach
Routing Method
Variable Step Response
Reach
Alternative Routing on Subbasin
Variable Step Coefficients
Control Point
Variable Routing Coefficients
Compute Aggregate Coefficients
Control Point
Variable Routing Coefficients
Compute Aggregate Coeffs every Timestep
Computational Subbasin
Control Point Variable Routing Coefficients
Compute Aggregate Coefficients
Alternative Routing and Flood Control
The flood control algorithm accesses the correct set of routing coefficients based on the method selection. On a given control point,
• If the Compute Aggregate Coefficients method is selected, the calculated Computed Routing Coefficients will be used. These represent the coefficients determined by the subbasin at the beginning of the timestep. If they were not recalculated (flows did not go above the first threshold), they will contain the same values as the Routing Coefficients slot.
• If the Compute Aggregate Coeffs every Timestep method is selected, the calculated Computed Routing Coefficients will be used. These represent the coefficients determined by the subbasin at the beginning of every timestep.
• If the None method is selected on the control point, the existing Routing Coefficients slot will be used.
Once the set of coefficients are determined, the flood control algorithm proceeds as usual. The algorithm will use the coefficients throughout flood control execution and throughout the forecast period.
Post-run Dispatching
Forecasting and basin lag times result in situations where the last timesteps of the run may not solve correctly if the objects have not solved past the end of the run. To allow objects to solve past the end of the run, you must configure post-run dispatching. Figure 2.5 shows a timeline diagram when post-run dispatching will occur.
Figure 2.5   
To configure post-run dispatching, set the number of post-run dispatch timesteps equal to the forecast period; see “Number of Post-Run Dispatch Timesteps” in User Interface for details. For dispatching to occur after the end of the run, certain data must be specified. Following is a description of the required data for post run dispatching
Local Inflow Forecasting Algorithms
The forecasting and disaggregation of cumulative local inflows is done at the beginning of each timestep. The forecasting will be executed at Begin Timestep on the last timestep, but will not occur after that. That is, even though the objects dispatch past the end of the run, no additional forecasting is required. But, local inflow data is required after the end of the run through the Period of Perfect Knowledge. That is, the user only needs to input Cumulative Local Inflows through the run end plus the Period of Perfect Knowledge on each inflow location.
Data Filled for Each Object
Following is data that will be automatically filled in at beginning of run and there is not a valid value. No user interaction is required.
• Reservoir.Diversion
• Reservoir.ReturnFlow
• Reservoir.Precipitation Rate
Data That Must be Input
Following is data that is typically input by the user (input or using a DMI). These will need to be input for post-run timesteps as well. DMIs or rules (RBS or Init) can be configured to quickly set this data.
• Headwater inflows. Gage.Inflow, Control Point.Inflow, Confluence.Inflow 1 or 2 or Reservoir.Inflow, Reach.Inflow. These are typically set to zero.
• Reservoir.Evaporation Rate or Evaporation (defaults to zero if not input)
• Reservoir.Cumulative Hydrologic Inflow and Control Point.Cumulative Local Inflow (or Deterministic Incremental Hydrologic or Local Inflow) See section above for data requirements.
Data Currently Input but Can be Set by Alternative Method Selections
Following is data that is may be input, but with different method selections, the data can be automatically set for all timesteps, including post-run.
• WaterUser.Fractional Return Flow. Select Periodic Fraction method and input a value. Make sure there are no other input values on these slots.
• Reservoir.Seepage. Select Single Value Seepage. Otherwise, seepage defaults to zero if not input.
 
Revised: 06/03/2019