skip to main content
Computational Subbasin
Objects and Methods
Computational Subbasin
The Computational Subbasin supports computations that involve more than one object, so-called global solutions, although they need not encompass the entire network. A Computational Subbasin is created through the same dialogs as other subbasin types, but it, like simulation objects, contains slots and other attributes that you can inspect and change by “opening” the subbasin. See “Subbasin Manager” in User Interface for details on creating, deleting, and viewing computational subbasins. Computational subbasins contain no general slots; all slots are dependent on user-selectable methods.
Selected slot values may be propagated from a computational subbasin to all member simulation objects. When you choose to propagate a slot named “S”, the value of the slot is copied to the slot named “S” on all objects in the subbasin. Propagation has no effect on member objects that do not contain a slot named “S”.
The subbasin may also be “verified”. The meaning of this depends on the selected methods. During verification, RiverWare performs checks that can be made prior to a run and that might discover errors before a run is begun, so that such errors can be identified and corrected early.
The subbasin is either “enabled” or “disabled”. When enabled, it will be verified at the beginning of a run, and if its verification fails, the run will abort. If disabled, it will not be verified at the beginning of a run. This allows subbasin verification not to interfere with model runs while the model or subbasin is under development.
General Slots
• None
User Methods
Diversions from Reservoirs
* None
There are no slots or calculations associated with this method. This method cannot be selected (that is, the user must select a method other than “None”) if the ComputeReservoirDiversions RPL function is being used; see “CompletePartialDate” in RiverWare Policy Language (RPL).
* Operating Level-based
This method is used in conjunction with the ComputeReservoirDiversions RPL function. See “ComputeReservoirDiversions” in RiverWare Policy Language (RPL) for details on the ComputeReservoirDiversions function,
This method is used to meet multiple Water User demands via reservoir diversions. Each reservoir can supply one or more Water Users and each Water User may divert from one or more reservoirs. The ComputeReservoirDiversions function computes, for each Water User object, the portion of water supplied by each connected reservoir. This information is set on the Supply From Reservoirs slot on the Water User object. The data can then propagate from the Water User to the reservoir Diversion slot via Diversion Objects (see Figure 8.1). The details of the calculations are included in the help file for the ComputeReservoirDiversions RPL function.
See “Reservoir Diversions” in USACE‑SWD Modeling Techniques for details on using this method for USACE-SWD.
Slots Specific to This Method
Bottom of Conservation Pool
Type: Scalar Slot
Units: none
Description: The Operating Level that represents the bottom of the conservation pool
Information: The operations/calculations associated with this method only apply to the conservation pool. If a reservoir is below the bottom of the conservation pool, it is not considered for diversions.
I/O: Required input
The use of this method and the ComputeReservoirDiversions RPL function requires a specific configuration of objects and method selections. Figure 8.1 illustrates the required object and link configuration.
Figure 8.1  Required object and link configuration for Operating Level-based method
In Figure 8.1, 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. 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. The rule sets the values on the Supply From Reservoirs slots. These propagate to the Multi Outflow slots on connected Diversion Objects. The Diversion objects solve for their Diversion slot. The Diversion values are passed to the Diversion slot on the Reservoir object and the water is removed from the Reservoir. On each reservoir, the Conservation and Flood Pools method in the Operating Levels category should be selected to instantiate the Bottom of Conservation Pool slot.
Low Flow Releases
* None
There are no slots or calculations associated with this method. This method cannot be selected (that is, the user must select a method other than “None”) if the MeetLowFlowRequirement RPL function is being used; see “MeetLowFlowRequirement” in RiverWare Policy Language (RPL).
* Operating Level-Based
This method is used in conjunction with the MeetLowFlowRequirement RPL function. See “MeetLowFlowRequirement” in RiverWare Policy Language (RPL) for details on this function.
This method is used to meet Control Point low flow requirements with releases from reservoir. Each reservoir can supply some water to the Control Point. The MeetLowFlowRequirement function computes a release from each reservoir in a Control Point’s list. See the MeetLowFlow Requirement help file for details on the calculations. See “Low-flow Releases” in USACE‑SWD Modeling Techniques for details on using this method for USACE-SWD.
Slots Specific to This Method
Bottom of Conservation Pool
Type: Scalar Slot
Units: none
Description: The Operating Level that represents the bottom of the conservation pool
Information: The operations/calculations associated with this method only apply to the conservation pool. If a reservoir is below the bottom of the conservation pool, it is not considered for low flow releases.
I/O: Required input
Flood Control
The Flood Control methods calculate a flood control release for the current simulation day. The two flood control methods, Operating Level Balancing and Phase Balancing, are invoked from a predefined rules function, and their results are returned to the calling rule.
See “Flood Control” in USACE‑SWD Modeling Techniques for details on this approach for USACE-SWD methods. The flood control methods (other than None) 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. They do this to account for routing effects. They return the values for the first timestep of the proposed schedule (for the current simulation timestep).
A sample rule for using flood control with a computational subbasin named “Flood Basin” is as follows.
FOREACH (LIST triplet IN "FloodControl“(“Flood Basin”)) DO
( triplet <0>) [] = triplet <1>
ENDFOREACH;
This rule invokes the predefined FloodControl RPL function, which returns a list of {slot, value, object} triplet; see “FloodControl” in RiverWare Policy Language (RPL). The rule iterates over the list, assigning the value (index 1 from triplet) to the slot (index 0 from triplet). The rules function returns three {slot, value, object} triplets for each reservoir:
{res.Flood Control Release, value, object}, {res.Outflow, value, object}, and for Operating Level Balancing method {res.Target Balance Level, value, object}
Thus, three slots may be set for each reservoir in the subbasin. The value for the Outflow slot is the sum of the Surcharge Release, Flood Control Release and the Flood Control Minimum Release. The Outflow slot is a dispatch slot, so setting this slot will cause the reservoir to dispatch and the outflows to be propagated downstream. If no flood operations are required, the values returned for Flood Control Release and Outflow will be zero, and each reservoir in the subbasin will dispatch no outflow. The Target Balance Level is the value as assigned by one or more key control point.
If a flood control method determines that flood operations are needed when the end of the run is within Forecast Period timesteps, the method will issue a warning suggesting that the user extend the post-run dispatching past the time when flood operations are needed. The method will then return zeroes for the values in the {slot, value} pairs. See “Rulebased Simulation Run Parameters” in User Interface for details on post-run dispatching. Typically, you can set the Number of Post-Run Dispatch Timesteps equal to the Forecast Period.
In the event that flood operations are needed and forecast data are missing, but the end of the dispatching is not within Forecast Period timesteps, the method will issue an error message and the run will abort.
The flood control methods are computationally intensive and make assumptions about the model configuration. Each method makes different assumptions, which are described below, in the context of the method. Checks are performed at the beginning of the run to catch errors that would cause the flood control to fail. These checks (also performed through the GUI “verify” button on the computational subbasin’s Open Object dialog) allow a user to correct errors early.
At the time these checks are made, the subbasin creates topological indices, that is, maps that cache the downstream and upstream relationships that are used frequently during the computationally-intensive flood control algorithms. These indices persist throughout the run, so any changes to the topology during a run will cause undefined, possibly disastrous results. These indices contain only the objects of interest to the flood control methods, which are reservoirs and control points. Reaches, stream gages, water users, and other such objects are ignored. The relationships among the reservoirs and control points are determined by following the “main channel outflow” slot links; see Table 8.1.
 
Table 8.1  Main Channel Slots
Object Type
Main Channel Outflow Slot
AggDistributionCanal
Total Outflow
Agg Diversion Site
Total Return Flow
Bifurcation
Outflow1
DiversionObject
(none)
StreamGage
Gage Outflow
WaterUser
(none)
all others
Outflow
By performing the checks and building the indices only at the beginning of the run, the computational cost of running the flood control method is reduced.
Warning:  Because these checks are not in the critical path of the flood control algorithm, the user must not modify the model during a run. The only GUI operations that are permissible during a flood-control run are read-only operations, such as plotting and viewing data. RiverWare’s behavior is undefined (may crash) if a model is modified during a flood control run.
Flood control uses linear routing coefficients as a computationally-cheap way to approximate the routing that occurs during simulation. Proper choice of routing coefficients is essential to producing high-quality results with the flood control methods.
Note:  Flood control optimizes the control points’ channel space using the linear routing coefficients on the control point; however, the Reaches may use a non-linear routing method in the simulation. The closer the linear routing coefficients approximate the routing methods on the Reaches, the better the flood control algorithm will work. If the linear routing coefficients are bad approximation of the routing methods used on the Reaches, the flows routed in the simulation may be vastly different than the flows approximated by the flood control algorithm used to be release decisions. As a result, the simulated flows may not optimize channel capacity and oscillations in the flood control releases may result.
Note:  Flood control assumes that flood control releases will be routed to future time steps. Therefore, the Impulse Response routing method should not be used with this flood control method.
General Beginning-of-Run Checks
The subbasin must be contiguous and must contain no loops.
* None
None is the default for the category. An error results if None is selected and a run calls the rules FloodControl method on the subbasin. (Disabling the subbasin does not disable the rule -- it simply disables the verification process at the beginning of the run.)
Slots Specific to This Method
None
* Phase Balancing
Beginning-of-run Checks Specific to this Method
The slots Forecast Phases and Forecast Period must be valid (have defined values).
All reservoirs in the Upstream Reservoirs slot of a key control point must have the Phase Balancing method selected in the Flood Control Release category.
All propagable slots, when also instantiated on members, must match those of the subbasin.
Behavior of this Method
The method calculates flood control release values at the current timestep for each reservoir in the subbasin by the following steps.
1. Set the proposed flood control release slot of each reservoir in the subbasin for each timestep in the forecast period to the reservoir’s maximum allowable release. The reservoir’s maximum allowable releases for each timestep in the forecast period is calculated using the reservoir’s objective release pattern, which is then constrained by the reservoir’s permissible outflow change tables and the maximum limit of the outlet works. The objective release pattern attempts to evacuate the flood control storage (including forecasted inflows) in the number of timestep specified by the pattern from the first unconstrained release. If the volume of water is constrained by the reservoir’s constraints or by downstream control points within the objective pattern threshold the release pattern should be maintained. If the objective patter threshold is surpassed the objective release pattern is reapplied starting with the current timestep. This value is based on the reservoir’s objective release pattern, the reservoir’s max release slot and the reservoir’s permissible outflow constraints slots. This release value is the target release, which will likely be constrained by control points downstream.
2. For each phase (phase III down to phase I) and for each timestep calculate the phase space allocations at each control point.
1. Calculate the reservoir’s phase space allocation at the current control point. The phase space allocation at each control point is calculated by determining which reservoir releases contribute to the water in the control point. The contributing reservoir releases are determined from the control point’s reservoir list and the linear routing coefficients. Available space in the control point is calculated by taking the phase space hydrograph and subtracting out local inflows, all contributions of known reservoir releases, and minimum release contributions from reservoirs whose release is unknown. Known reservoir releases are considered releases that occurred before t - lag time from the reservoir to the control point. These are releases that have already been constrained by the current control point. Unknown reservoir releases are all reservoir releases occurring at or after t - lag time from the reservoir to the control point. These are releases that have not yet been constrained by the current control point. The available space is then divided up to all unknown reservoir releases which will contribute the control point at the current timestep. The space is divided among reservoirs using the reservoirs’ linear routing coefficients and reservoirs’ lake character weight at the timestep t-1-lag time from the reservoir to the control point.
Figure 8.2   
The lake character value is calculated by the reservoir as follows: The Lake Character is a weighting factor that will be determined for certain types of Reservoir Objects (Storage and Level Power Reservoirs) to be used as a means to balance all reservoirs in the same Operating Level. Once the Lake Character is known, it can be used in conjunction with other reservoirs of the same Operating Level to divvy up the available empty space at downstream control points. A reservoir’s Lake Character for each timestep is calculated by:
The coefficient is either the value in the Lake Character Coefficient scalar slot or the value in the Variable Lake Character Coefficient series slot if input for that timestep. RiverWare will check at each timestep if a value has been input in the Variable Lake Character slot. If valid, the Coefficient is the input value for some timestep from Variable Lake Character Coefficient. When NaN, the Coefficient is the value in the Lake Character Coefficient ScalarSlot.
The percentage of the flood pool that is currently occupied is calculated as
This storage value takes into account the Surcharge Release determined for the current timestep. The Top of Flood Control Pool Level and Top of Conservation Pool Level are required input. The storage corresponding to these level will be determined from an interpolation of the Elevation-Volume TableSlot.
2. The proposed flood control release slot for each reservoir is then set to the minimum of the current value of the proposed flood control release or the phase space allocation at the control point divided by the linear coefficient. Dividing the allocation by the linear coefficient results in a release value that will wholly fill the allocated space. Recall the minimum release contribution was subtracted out of the available phase space, ensuring that space would be available for all minimum releases.
3. If the control point lists a reservoir directly upstream (that is, there is no time lag from the reservoir to the control point) and the reservoir has upstream tandem reservoirs, the control point may constrain upstream tandem reservoirs to their minimum release. Two reservoirs which are located so that a release from one becomes the inflow of the other are in tandem. The upstream reservoir releases will be set to the reservoir’s minimum release if the two reservoirs are out of tandem balance. A tandem balancing curve is constructed for each pair of tandem reservoirs by interpolating straight lines between the following points calculated from the tandem operating levels table slot and the tandem operating aberrations slot:
• top of flood pool
• the top of Phase II
• the top of Phase I
• the top of the conservation pool
If more water is stored in the downstream tandem reservoir than indicated by the tandem balance curve then the temporary release from the upstream reservoir will be set the minimum release. Given a reservoir D and its tandem upstream reservoir U. The tandem upstream reservoir is constrained to its minimum release if the point (DPoolElevation(t-1), UPoolElevation(t-1-lagTime)) lies within the shaded area. If the point lies in the unshaded area, the flood control release is the same as the parallel case.
Figure 8.3   
4. If not all of the control point’s available phase space was taken by its reservoirs’ releases (one or more of the reservoirs may have been constrained upstream) the phase space allocation is repeated with all reservoirs which are not constrained upstream, considering all releases constrained upstream as known releases. This process is repeated until the entire phase space is allocated for the current timestep or until all of the current control point’s reservoirs are found to be constrained upstream.
Note:  See the notes regarding the flood control methods in general, above.
Slots Specific to This Method
Forecast Period
Type: Scalar Slot
Units: NONE
Description: Timesteps in the period for which forecast data are available.
Information: Minimum value of 1.
I/O: Required Input.
Top of Conservation Pool
Type: Scalar Slot
Units: NONE
Description: Operating level associated with the top of the conservation pool of every reservoir in the subbasin.
Information: Also known as “target operating pool level, since this is the preferred, or target, level for all reservoirs. This level is also the bottom of the flood pool.
I/O: Required Input.
Top of Flood Pool
Type: Scalar Slot
Units: NONE
Description: Operating level associated with the top of the flood pool.
Information: Must be above the top of the conservation pool.
I/O: Required Input.
Number Of Phases
Type: Scalar Slot
Units: NONE
Description: The number of phases associated with the all the reservoirs in the subbasin.
I/O: Required Input.
* Operating Level Balancing
This method uses a series of passes over successively lower operating levels (called “balance levels” in this context), in which it attempts to reduce all the reservoirs in the subbasin to the operating level of the pass. It attempts to release as much water as feasible as soon as possible. A set of criteria is applied, reducing the potential release from each full reservoir so that
• flooding does not occur downstream at the control points to which this reservoir routes1,
• water is not released from the reservoir’s conservation pool, and the release schedule does not rely on any water being released from the conservation pool in its projections,
• priority is given to reservoirs based on their operating levels (“fullness”),
• the reservoirs subject to a key control point are left as balanced2 as possible, given the above,
• flood pools are drained as soon as possible and within the forecast period, given the above, and
• reservoirs have a release schedule that is as smooth as possible, given the above.
A more detailed description of the operation of this method follows the list of slots below.
When this method is selected, dependent method categories Balance Level Determination, Pass Behavior, Key Control Point Max Release, Key Control Point Space Use, Operating Level Mapping, Tandem Balancing, Modify Inputs to Two-Reservoir Midpoint, Tandem Storage Management, Tandem Storage Considered, Priority Determination, Reservoir Set, Smoothing Releases, Last Pass Timesteps May Increase apply, and Control Point Variable Routing Coefficients. They are described below.
Note:  The Operating Level Balancing method was developed under the aegis of the U.S. Army Corps of Engineers - Southwest Division, with the expressed purpose of approximating algorithms and results of portions of the Corps’ SUPER suite of programs. Some of the methods described below (among those dependent on Operating Level Balancing) exist solely for the testing and acceptance phase of this project. Some of these methods and the slots associated with them may not persist in RiverWare, and are so indicated below. Other methods exist for the purpose of experimentation, to enable interested persons to study the effects and interactions of various algorithmic details. The defaults were chosen to match the SUPER behavior. See “Flood Control” in USACE‑SWD Modeling Techniques for details on using this method for USACE-SWD.
Note:  Undocumented temporary slots may appear (with “Temp” or “Temporary” in their names) in various releases of RiverWare, and may disappear later, for the reasons stated in the previous note. Such temporary slots are not stored with a model, and are not deemed available to users for use in rules, user-defined accounting methods, or for any other purpose. In RiverWare 6.1, many of the Temp slots were converted to regular slots but then made invisible. These invisible slots but can be viewed in the Special Results details on the Model Run Analysis tool; see “Model Run Analysis—Special Results Details Dialog” in USACE‑SWD Modeling Techniques.
Slots Specific to This Method
Forecast Period
Type: Scalar Slot
Units: NONE
Description: Timesteps in the period for which forecast data are available.
Information: Minimum value of 1. May be propagated from the subbasin to its members. All subbasin members with this slot must have the same value in the slot.
I/O: Required Input.
Balance Period
Type: Scalar Slot
Units: NONE
Description: Timestep in the future (origin 1, i.e., 1 means the current simulation timestep) at which the forecast storage in the flood pool determines the amount of water to be released over the forecast period by the flood control algorithm.
Information: Minimum value of 1. Less than or equal to the value of the Forecast Period. Values must match on all objects in the subbasin that have this slot. May be propagated from the subbasin to its members.
I/O: Required Input.
Top of Conservation Pool
Type: Scalar Slot
Units: NONE
Description: Operating level associated with the top of the conservation pool of every reservoir in the subbasin (all reservoirs in the subbasin must have the same value for this slot).
Information: Also known as “target operating pool level”, since this is the preferred, or target, level for all reservoirs. This level is also the bottom of the flood pool. May be propagated to every subbasin member that has this slot.
I/O: Required Input.
Top of Flood Pool
Type: Scalar Slot
Units: NONE
Description: Operating level associated with the top of the flood pool of every reservoir in the subbasin (all reservoirs in the subbasin must have the same value for this slot).
Information: Must be greater than the Top of Conservation Pool. Used to compute surcharge releases. May be propagated to every subbasin member that has this slot.
Highest Operating Level
Type: Scalar Slot
Units: NONE
Description: The highest operating level that is valid for every reservoir in the subbasin. The Operating Level Balancing method will not consider operating levels higher than this when it attempts to balance reservoirs.
Information: Used in the Two-Reservoir Midopoint method of the Tandem Balancing category (dependent on the Operating Level Balancing method selection). Every reservoir in the subbasin must have an Operating Level Table whose domain covers this operating level because the Two-Reservoir Midpoint method looks up storages associated with levels up to and including this.
I/O: Required Input.
Lowest Operating Level
Type: Scalar Slot
Units: NONE
Description: The lowest operating level that is valid for every reservoir in the subbasin. The Operating Level Balancing method will not consider operating levels lower than this in its attempts to balance reservoirs.
Information: Used in the Two-Reservoir Midopoint method of the Tandem Balancing category (dependent on the Operating Level Balancing method selection). Every reservoir in the subbasin must have an Operating Level Table whose domain covers this operating level. The Two-Reservoir Midpoint method looks up storages associated with this balance level on each reservoir in the subbasin.
I/O: Required Input.
Routed Flow Tolerance
Type: Scalar Slot
Units: FLOW
Description: Performance tuning knob. Flow, due to a routed flood control release, below which it is not worth the computational expense to continue processing.
Information: When, during the computation of a prospective additional flood control release, the resulting routed flow at a control point is below this value, the method considers it to be zero, at (and downstream of) this control point.
I/O: Required input. Default value 0.000001 cms.
Incremental Release Tolerance
Type: Scalar Slot
Units: FLOW
Description: Performance tuning knob. Magnitude of additional release (for a pass of the flood control algorithm) below which it is not worth the computational cost to consider.
Information: When, during the computation of a prospective additional flood control release, the additional release becomes limited to a magnitude below this, the additional release is taken to be 0.0.
I/O: Required Input. Default value 0.000001 cms.
Beginning-of-run Checks Specific to this Method
Prior to the start of a run, the subbasin is analyzed and verified, at which time the following checks are made.
1. On the subbasin:
– The following slot values must be positive: Forecast Period, Balance Period, Highest Operating Level.
– The following slot values must be non-negative: Routed Flow Tolerance, Lowest Operating Level.
– The Balance Period must be less than or equal to the Forecast Period.
– The Highest Operating Level must be greater than the Lowest Operating Level.
2. On member reservoirs:
– The following slot values must be positive: Allowable Rising Release Change, Allowable Falling Release Change, Maximum Release Variation.
– The following slot values must be non-negative: all elevations in the Operating Level Table.
– For each date in the Operating Level Table, the elevations must monotonically increase with the operating level, and the Operating Level Table must cover the range Lowest Operating Level through Highest Operating Level (from the subbasin slots).
– Each reservoir must have the Operating Level Balancing method selected for the Flood Control Release category.
– (This is not a check, but an action taken:) A slot, Operating Level Storage Table, is created at this time. It is a direct mapping between operating levels and volumes, created from the Elevation-Volume Table and the Operating Level Table. For performance purposes, this table is used by the flood control and related methods in lieu of two table interpolations for mapping storage volumes to operating levels and back. Also, see the Conditional Operating Level category in “Conditional Operating Levels” for details on when this slot could be recomputed.
3. On member control points:
– The following slot values must be positive: Excepted Releases, if the control point has a flooding exception.
– The following slot values must be non-negative: elements of Routing Coefficients.
– If the control point is key, its Key Control Point Balancing method must be Operating Level Balancing.
– The sum of the elements of the Routing Coefficients vector for each Upstream Reservoir must be within Routed Flow Tolerance of 1.0.
– The Empty Space slot must be valid, which means that a method other than None for Regulation Discharge must be selected. This slot determines how much water may flow at a control point without causing flooding. Flooding is defined as flow exceeding the regulation discharge.
– Each control point must have the Operating Level Balancing method selected for the Flood Control Release category.
4. Relationships among slot values of objects in the subbasin:
– The following slots, when instantiated on members, must match those of the subbasin: Balance Period, Forecast Period, Top of Conservation Pool, Top of Flood Pool.
5. Relationships among objects in the subbasin:
– Each reservoir has a member control point “immediately” (considering only reservoirs and control points) downstream, which is called its “output gage control point”. The Routing Coefficients vector from the reservoir to its output gage control point is exactly { 1.0 }.
– All subject reservoir of a key control point (those named in the control point’s Key Control Point Reservoirs slot) must be members of the subbasin and upstream of the control point.
– When the selected method for Key Control Point Space Use is Key Control Point Balancing Share, there may not be non-subject reservoirs interposed between a key control point and any of its subject reservoirs. This is because the non-subject tandem may take on storage of water released from a subject reservoir upstream, but be unable to release it. When the selected method is First-Come First-Served, it doesn’t matter, as all reservoirs have equal access to the key control point’s empty space.
– Every reservoir in a control point’s Upstream Reservoirs slot must be a subbasin member and must be upstream of the control point.
Note:  There is no beginning-of-run check that the Key Control Point Reservoirs are among the Upstream Reservoirs, but the Key Control Point Balancing method Operating Level Balancing will issue a fatal error if they are not.
Note:  If a given control point has the Compute Aggregate Coefficients method selected in the Variable Routing Coefficients category, the temp Routing Coefficients slot will be used in place of the Routing Coefficients slot in all calculations. This slot is populated at the beginning of the timestep based on the flows in the system. See the Compute Aggregate Coefficients method documentation in the Control Point Variable Routing Coefficients category below.
Example Subbasin
For illustrating the behavior of this method with examples, we refer to the following simplified subbasin (with only reservoirs and control points extracted; Reaches and other objects are not of interest to the flood control algorithm and so are not considered in any discussion of the flood control algorithm). This example subbasin, illustrated below, contains three reservoirs, RA, RB and RC. Each reservoir has an “output gage control point”, CPA, CPB, CPC, respectively. Two more control points, CPX and CPY are in the subbasin. In the subbasin from which this is extracted, there would be Reaches between CPB and CPX, and between CPC and CPY. There would also be a confluence above RC, possibly with Reaches between it and CPA and between it and CPX. During simulation, the dispatching of reaches would affect the routing. which is incremental (one reach at a time), but during execution of the flood control rule, the linear routing coefficients on the control points are used to approximate the composite (cumulative) routing between reservoirs and control points.
For the purpose of illustration, we assume that this subbasin has
• a 1 Day timestep,
• a forecast period of 5days,
• a balance period of 3 days,
• the top of the conservation pool at operating level 5.0,
• hypothetical units, in which 1 unit of volume == 1 unit of flow (for simplicity)
• (hidden) reaches with routing coefficients, as shown in Figure 8.4.
Figure 8.4   
Behavior of this Method
The Operating Level Balancing method first determines if flood control is needed. If no reservoirs in the subbasin are forecast to be in the flood pool on the current simulation timestep, it returns with no flood control releases for any of the reservoirs in the subbasin.
Note:  If a reservoir in the computational basin is disabled and is set to Pass Inflows (see “Pass Inflows”), the reservoir is not considered in the computations below. The reservoir will pass the flows through including any upstream releases that could possibly have been held as tandem storage.
If flood control is needed, the method initializes the flood control release schedule3 for each reservoir to zero: no flood control release on any timestep of the forecast period. It then invokes the selected Key Control Point Balancing method on each of the key control points in the subbasin. After this, the method selects a set of balance levels to use to drive the algorithm. This set is determined by the selected method in the Balance Level Determination category (q.v., below). The set is sorted in descending order (duplicate values are removed) and preserved so it can be returned to the calling rule/function to set on the Target Balance Level slot.
The flood control method then runs one or more “passes” over the reservoirs in the subbasin. There is one pass for each balance level in the above-mentioned set, and an additional “final” pass associated with the operating level that is the Top of Conservation Pool. The goal of each pass is to determine the maximum release that each reservoir can make on each timestep of the forecast period, to bring its forecast operating level to the balance level of the pass as soon as possible4. No attempt is made to reduce a reservoir below the level of the pass.
At the beginning of each pass, the method determines the set of “full” reservoirs, namely those whose forecast operating levels (at the end of the balance period) exceed the balance level of the pass 5. The set of full reservoirs is sorted by fullness (fullest one first).
The full reservoirs are considered in order, and for each full reservoir there are two steps to compute a release schedule. Remember that all the actions described here are on intermediate (temporary or invisible) slots; the simulation state of objects is not changed by the flood control method. (Empty space and storage slots are not changed.)
1. Undo the proposed releases from the prior pass (if any), freeing space at control points and removing tandem storage at tandem reservoirs. This step is not necessary if accumulating additional releases on each pass (Pass Behavior method selected is Compute Additional Release).
2. Loop over the timesteps in the forecast period, computing a tentative release for each timestep. In this loop are two steps:
• Compute a tentative release for the full reservoir for the forecast timestep in question, based on empty space at the downstream control points, on our ability to store water in a downstream tandem reservoir, and on constraints of the full reservoir; and
• “Apply” that tentative release, updating the empty space at downstream control points and storages at downstream reservoirs.
RA is forecast to be at level 10.2, RB at 8.9, RC at 9.5. The key control point, CPY, assigned balance level 9.0 to reservoirs RA, RB and RC, and so its balance level for the current timestep is 9.0. The balance level set is { 9.0, 5.0 }. There are three passes, one at 9.0, one at 5.0 and a “final” pass at 5.0, in which certain constraints, described below, are removed. On the first pass, the algorithm proposes release schedules for RA and RC that will bring them down as close to operating level 9 as possible in 5 days, given empty space constraints at control points. It considers RA before RC because RA is forecast to be “fuller” (at a higher operating level). On the second pass, the algorithm proposes releases for RA, RC, and RB, to bring them down to operating level 5.0 while still respecting all the constraints of the first pass. On the final pass, all reservoirs are considered, with the goal of bringing them to level 5.0, with slightly different constraints, as described below.
Downstream Objects that Constrain a Full Reservoir’s Release
The objects that constrain a reservoir’s release are those reachable by water routed within the forecast period. For the purpose of the flood control method, water travels only as far as
• there are control points with routing coefficients from that full reservoir, and
• it can travel within the forecast period, and
• it will result in at least Routed Release Tolerance cms on the timestep in question.
Note:  This is internal units.
If there were no routing coefficients at CPC for routing from RA to CPC, the flood control algorithm would stop checking constraints at CPA, even if control points downstream of CPC had routing coefficients for releases from RA. If the routing coefficients for RA to CPC were { 0,0,0,.5,.5 }, no releases after the 2nd day would be considered from CPC on downstream, because no water from such releases would reach CPC or beyond within the forecast period. Finally, if the Routed Release Tolerance were 0.000001 cms, and a release were to route to a control point but the arriving flow were to be less than 0.000001 cms, the flood control algorithm would stop at said control point. Thus, the Routed Release Tolerance can be used to tune the algorithm - to make it run faster, but with less precision.
The flood control algorithm does not check for consistency of the linear routing coefficients with the simulation routing. If the linear routing coefficients used by the flood control do not approximate the routing used in simulation, results may be of low quality. Similarly, if the routing coefficients at two control points are inconsistent, RiverWare will not notice.
Routing coefficients from RA to CPC could be {.5,.5} and from RA to CPY could be {.8,.2}, and RiverWare would not notice. It is entirely up to the modeler to see that the coefficients are consistent with each other and with the simulation routing methods.
The routing coefficients on the Reach between CPA and RC might be {.1,.2,.3,.4}, and all else as described in the reference subbasin. RiverWare would use the routing coefficients on the reach during simulation, and the routing coefficients on the control points for flood control. The fact that they don’t match would not be discovered by RiverWare. The Reaches might not use linear routing at all. RiverWare would have no way to tell if the linear routing used in flood control is an “acceptable” approximation of the (possibly non-linear) routing selected on the Reaches and used during simulation.
Empty Space Restrictions at Control Points
Limited channel (empty) space at downstream control points may reduce the proposed release. The available empty space on a pass is determined as follows.
• On all passes, all empty space at non-key control points is available on a first-come, first-served basis.
• Space at key control points is reserved for use by subject full reservoirs on passes prior to the final pass. This allocation of space is respected on these passes, unless overridden by the selected method in the Key Control Point Space Use category (q.v., below). See below for a discussion of the allocation of water stored in downstream tandem reservoirs.
• On the final pass, all empty space at all control points that has not been used heretofore is available on a first-come, first-served basis.
The key control point balancing method on CPY apportioned its empty space as follows: 60% to RA and 40% to RB. With three passes, at operating levels 9.0, 5.0 and 5.0, on the first two passes (9.0 and 5.0), RA releases can consume at most 60% of the empty space at CPY on any day of the forecast period, while RB can consume at most 40%. On the final pass, any unused space at CPY is available to both RA and RB. Empty space at CPC is available to RA and RB on all passes because CPC is not key.
“Trim” (Max Release Variation) and Empty Space
When considering empty space at a control point, the method computes an upper bound on the flood control release for each timestep in the forecast period. The upper bound is the maximum amount that can be used as the first ordinate in a stepped-down release hydrograph from the timestep under consideration through the end of the forecast period, with the full reservoir’s Maximum Release Variation (so-called “Trim” value) defining the magnitude of the reduction in this hydrograph between timesteps, and when this hydrograph is routed to the control point, all the resulting flow for the rest of the forecast period will fit in the empty space available at the control point. This stepped-down hydrograph is computed without regard to the goal release volume; it merely results in an upper bound on the release at each timestep. (This is a heuristic method of smoothing the release schedules. There is no guarantee that the second and succeeding timesteps of the stepped-down hydrograph will approximate the release hydrograph ultimately resulting from the flood control operations.)
We are proposing a release from RB. For the purpose of this example, let us assume that below CPX, no other constraints reduce a release, that is, this example considers only the effects of CPB and CPX. RB has volume of 150 units to release to bring it down to the goal balance level for the pass. RB has a Max Release Variation of 10 flow units per timestep. Empty space at CPB for the forecast period is { 50, 50, 50, 50, 50 }. For the first forecast day, the empty space at RB would permit a stepped-down release hydrograph of {50, 40, 30, 20, 10}, so it proposes a release of 50 units. For the second day, the remaining empty space at CPB would then be { 0, 50, 50, 50, 50 }, so it proposes a release of 50 units again. Now the proposed release schedule is { 50,50, 0, 0, 0 } and the proposed empty space at CPB is {0,0,50,50,50}. Thus, CPB will impose the same upper bound on each day’s release from RB.
Continuing the above example, we now consider the empty space at CPX, which is { 50, 60, 40, 50, 50 }. For the first day, the stepped-down hydrograph would be 55, 45, 35, 25, 15}, which, routed, yields {27.5,50,40,30,20}, limited by day 3. Since the release is already constrained to 50 units on each day, CPX does not impose any constraints on the RB release schedule for the first day. Assuming the release from RB for the first day is indeed 50 units (after considering all control points and all other constraints), arriving at CPX as {25,25,0,0,0), on the second day the resulting free space at CPX would be {25, 35, 40, 50, 50}. This empty space dictates a stepped-down hydrograph for day 2 of { 0, 45,35,25,15}, resulting in an arrival hydrograph of { 0, 22.5, 40, 30, 20 }, restricted by day 3. Thus, the upper bound of 45 is imposed on the release for day 2. Assuming that holds, we route it to CPX, and it arrives as {0,22.5,22.5,0,0}. This leaves empty space for day 3 at { 25,12.5,17.5,50,50}. This empty space dictates a stepped-down hydrograph for day 3 of {0,0,35,25,15}, which, routed to CPX gives an arrival hydrograph of {0,0,17.5,30,20}, being restricted by day 3. Thus, the upper bound of 35 is imposed on day 3, which we assume remains the release for day 3. Routed to CPX, it arrives as {0,0,17.5,17.5,0), which reduces the empty space to {25,12.5,0,32.5,50}. The day 4 hydrograph is then { 0,0,0,55,45}, routed to CPX arriving as 0,0,0,27.5,50}, being restricted by day 5. Thus, the day 4 upper bound is 55, and if it ends up being released, it routes to CPX as {0,0,0,,27.5,27.5}, leaving empty space of {25,12.5,0,5,22.5}. This empty space dictates a day 5 hydrograph of {0,0,0,0,45}, which gives the upper bound of 45 for day 5. Thus control point CPX imposes limits of {55, 45,35,55,45}, and the release schedule is {50,45,35,55,45}.
While the above consideration of empty space guarantees that no release will cause flooding downstream, given the routing information and the forecast period limitations at hand, the following circumstances could cause flooding downstream at simulation time:
• the routing coefficients used by the flood control algorithm do not closely approximate the routing used during simulation, or
• the forecast period is considerably shorter than the effect of the routed releases at simulation time, or
• the model does not contain routing coefficients for control points reached within the forecast period by releases from reservoirs above, or
• there is a Flooding Exception relationship between a control point and a reservoir (see the Flooding Exception category on a control point for details).
Constraints of the Full Reservoir
The proposed release at any timestep in the forecast period will not exceed the release at the prior timestep plus the full reservoir’s Allowable Rising Release Change. When computing this constraint on the release, surcharge and flood control minimum releases are considered.
RA’s Allowable Rising Release Change (ARRC) is 20. Computing RA’s optimal release for the first day yields a release of 100. The total release (surcharge release plus flood control release) made on the prior simulation timestep was 75, so RA will not release more than 95 today (surcharge and flood control releases combined). After applying all other constraints, we end up with a release for today of 55. That means that the second forecast day’s release will not exceed 75, and so on throughout the forecast period.
The algorithm tries to assure, but does not guarantee, that the proposed releases in the forecast period do not drop by more than the full reservoir’s Allowable Falling Release Change. This constraint is applied by computing a stepped-down hydrograph that releases the goal volume for the timestep (based on the difference in storage between the forecast operating level at the end of the balance period and the balance level of the pass) over the remaining timesteps in the forecast period, with a reduction at each timestep of exactly the Allowable Falling Release Change within the forecast period (the last ordinate may exceed the Allowable Falling Release Change). The first ordinate in such a hydrograph is used as an upper bound on the release for the timestep under consideration. Of course, a release at some timestep may be forced to zero by sudden inflows at a downstream control point, and this can cause the Allowable Falling Release Change constraint to be untenable for that timestep. The upper bound computed on the first timestep (which uses the goal volume that is the entire flood pool’s contents above the balance level of the pass) is applied to every timestep of the forecast period. Thus, the first timestep of the forecast period has one such upper bound applied, while the rest of the timesteps have two such upper bounds applied (one for the whole volume to release, and one for the remaining volume to release at that timestep).
RA’s Allowable Falling Release Change (AFRC) value is 10 flow units per timestep. RA is forecast to have150 units of flood pool volume at the end of the balance period, so 150 units is the release goal on a pass at balance level 5.0. The stepped-down hydrograph computed for 150 units volume for the first timestep is {50, 40, 30, 20, 10}, which releases all the volume in the forecast period. Thus, 50 is an upper bound on the first day’s release. Having ultimately released 40 on the first day, due to space restrictions downstream, we compute a new hydrograph for the second day, to release 110 units in the 4 remaining days. This hydrograph is {42.5, 32.5, 22.5, 12.5}.
Note:  The last day’s ordinate may exceed AFRC, because our goal is first to release all the water within the forecast period, knowing that forecasts far out in the forecast period are dubious in any case.
The second hydrograph imposes an upper bound of 42.5, in addition to the upper bound of 50 on the release for the second day. Assuming we could ultimately release 41 units on day 2, we have for the third day 110-41=69 units to release. We compute a hydrograph for the third day: {33, 23, 13}. Thus the third day’s release is subjected to the upper bound of 50 and the upper bound of 33. If a downstream control point imposes a limit of 0 on the third and fourth day releases, we will still have 69 units to release on day 5. This will give us a stepped-down hydrograph of {69}, and the upper bounds of 69 and 50 will apply to day 5. Thus, the upper bounds for each of the days for this constraint will be: {50,42.5,33,39.5,50}.
The proposed release at the simulation timestep may not exceed the spillway capacity, as determined by the reservoir’s utility method getMaxOutGivenIn(). (This constraint is not applied to forecast timesteps after the first, that is, after the current simulation timestep.) If part of an upstream reservoir’s proposed release is to flow through a downstream tandem reservoir (results in a so-called “through release”), the downstream tandem’s spillway constraint is applied to the amount of the through release arriving on the simulation day plus other inflows so-far computed, along with other releases so-far computed for the tandem. Thus, the spillway constraint on the tandem may restrict flood control releases from upstream reservoirs.
RA can release 100 units, and RC cannot store any water (having stored plenty from RB). Routing 100 units from RA to RC, we get {50,50}, and we then apply the spillway constraint at RC, considering the 50 arriving as being in addition to any other inflows at RC, and considering any other proposed releases from RC. If the release from RA, upon flowing through RC, could exceed the spillway capacity of RC, RA’s release will be reduced accordingly.
The proposed release at a timestep may not dip into the full reservoir’s conservation pool on that forecast timestep. This constraint may be applied to every timestep in the forecast period, or only to the first timestep, based on the method selection in the Tandem Storage Management category (q.v.).
If the Key Control Point Max Release category selection is Max Release Applies, the maximum flood control release constraint applies: on all passes but the last, a reservoir’s proposed release may not exceed the reservoir’s Max Flood Control Release on any timestep. This value is computed by the Key Control Point Balancing method. If a reservoir is not subject to a key control point, this constraint has no effect.
Key control point CPY assigns to RA a maximum release of 40 units, and to RB a maximum release of 30 units. If we have three passes, at levels 9.0, 5.0 and 5.0, on the first two passes, RA will release no more than 40 units on any day of the forecast period. RB will not release more than 30 units on any day of the forecast period. Thus even though RA may be forecast to be significantly higher than RB, it may not be able use all the downstream channel space otherwise available to it. Only on the final pass will these limits be lifted, and RA will be free to consume all remaining channel space, subject to its other constraints. Assuming that the key control point allocates these maxima in proportion to the fullness of the reservoirs, using the maxima may have the effect of allowing each reservoir to release something each timestep, rather than allocating all channel space to RA today, leaving RB “fuller” tomorrow, allocating all channel space to RB tomorrow, leaving RA “fuller” the next day, and so on (causing undesirable oscillating behavior). Of course, the effect depends on the key control point balancing method selected.
On the last pass, the release schedule at timesteps after the first are subjected to another upper bound, which is the larger of
• the value proposed on the prior pass for the timestep, and
• the value proposed on this pass for the prior timestep minus the trim value (Maximum Release Variation slot).
This constraint may be overridden by selecting the Entire Forecast Period method of the Last Pass Timesteps May Increase category.
RB is forecast to be at level 10.0 and RC is forecast to be at level 5.0 at the end of the balance period. The key control point balancing method assigns level 7.0 to all three reservoirs. On the first pass, at balance level 7.0, RC takes on 100 units from RB, released as { 40, 30, 20, 10}. Since the forecast period is 5 days long, the arrival hydrograph for this release schedule from RB is {4, 19, 30, 25, 15}, but because we consider only that water that arrives within the balance period, we account for only the 53 units arriving on days 1-3, leaving 47 units that arrive after the end of the balance period. Thus, in future calculations based on the forecast storage in RC, 53 units of volume will be added to RC’s forecast storage. RC will be free to release on day 1 an additional 4 units of volume, and on day 2 an additional 19 units of volume, and so on through the forecast period. If the Two-Reservoir Midpoint method is selected, the starting volume for RC will henceforth include 53 units of volume above its forecast volume at the end of the balance period.
Storing Water in Downstream Tandem Reservoirs
All or part of a proposed release may be stored in downstream tandem reservoirs if the downstream reservoir is not Surcharging (Surcharge Release equals zero or is not valid) at the current controller timestep. Such tandem storage is determined as follows.
• A downstream reservoir will store water to increase its forecast operating level to the smaller of the pass’s balance level and the tandem reservoir’s Target Balance Level (assigned by a controlling key control point). If a reservoir is not subject to any key control point and thus not given a balance level, the Top of Conservation Pool value will be used for the assigned balance level and an error will be issued. This error will abort the run.
• A downstream reservoir may store additional water if the Two-Reservoir Midpoint method is selected in the Tandem Balancing category; see “Tandem Balancing”.
There are four passes at balance levels 9.0, 8.7, 5.0 and 5.0. RC, subject to more than one key control point (not shown in the example subbasin), has been assigned a balance level of 8.7. On the first pass (9.0), RA may store water in RC to bring RC up to the larger of 9.0 (balance level of the pass) and 8.7 (balance level assigned RC). On the second pass, RC will accept water to bring it no higher than 8.7 again. On the last two passes, it will accept no water, unless it is forecast to be in the conservation pool at the end of the balance period, in which case, it will accept water to fill the conservation pool. If the Two-Reservoir Midpoint method is selected, RC will, in addition, agree to accept more water. Let us assume, as in a prior example, that RA is forecast to be at 10.2, RB at 8.9, and RC at 9.5. RC will accept, from RA, that volume of water that, if instantaneously moved from RA to RC, would put RC and RA a the same operating level. That level will be somewhere between 10.2 and 9.5. RC will not initially accept any water from RB because RB is forecast to be lower than RC. If, on the first pass, RC is able to release enough water to bring it below the ending operating level of RA at the conclusion of the pass, RC will accept water from RB.
When the Key Control Point Space Use method is Key Control Point Balancing Share, and water is moved from a full reservoir to a tandem, ownership of key control point shares of the empty space are transferred from the full reservoir to the tandem in amounts equal to the resulting inflow at the tandem for each timestep of the forecast period. This allows the tandem to release the water through the key control point later, all else permitting. Transfer of such ownership applies only to water to be stored in the flood pool (not to water to be stored in the conservation pool, as it will not be drained by the flood control algorithm). This transfer of ownership is not necessary and is not computed when the Pass Behavior selection is Undo and Recompute Max Release.
This example applies only when Pass Behavior is Compute Compute Additional Release. On the first pass, RA releases 100 units of volume to be stored in RC, as follows: {50,30,20,0,0}. The key control point, CPY, has allocated to RA {30, 30, 30, 30, 30}, to RB {10, 10, 10, 10, 10} and to RC {20, 20, 20,2 0,20}. Having stored 100 units of RA’s water in RC, on a later pass we might be able to release some or all of that 100 units from RC, but because that water originated at RA, we transfer its ownership to RC. Routing the release hydrograph to CPY, we get {12,5, 32.5, 32.5, 17.5, 5}, so we transfer such units of water in CPY’s accounts. Now CPY has allocated to RA: {17.5, 0, 0, 12.5, 25}, and to RC: {32.5, 50, 50, 37.5, 25}.
The quantity of water scheduled for tandem storage and accounted for in the tandem reservoirs depends on the method selection in the Tandem Storage Management category. For details of the accounting, see the method descriptions, below.
Note:  See the notes regarding the flood control methods in general, above.
Balance Level Determination
This category appears only if the Operating Level Balancing method is selected in the Flood Control category. Its purpose is to determine the set of balance levels that will drive the Operating Level Balancing flood control method.
* Key Control Point Balance Levels (default)
The default way to drive the Operating Level Balancing method is to collect the key control points’ balance levels (Balance Level) computed by the Operating Level Balancing method of the Key Control Point Balancing category, and to use this set of balance levels to determine the number of passes to run and the operating levels to use on each pass.
Slots Specific to This Method
Balance Levels Used
Type: Agg Series Slot
Units: NONE
Description: The set of balance levels taken from the key control points for driving the algorithm.
Information: This slot is not visible on the open object dialog, it is only visible in the Special Results USACE methods tab of the Model Run Analysis (on the subbasin). It is for observing the operation of the algorithm during or after a run.
I/O: Output.
* Iteration Balance Levels
The user may drive the algorithm by defining a set of balance levels that will be used for the passes of the flood control algorithm. The more levels given, the more passes will be run, at a computational cost. The fewer levels given, the coarser will be the balancing. This selection may make sense if the allowable rising or falling release change represents the release of enough water to change reservoir’s storage by an amount that is a significant portion of an operating level.
Slots Specific to This Method
Iteration Balance Levels Slot
Type: Table Slot Nx1
Units: NONE
Description: The set of balance levels to drive the algorithm, independent of the activity of the key control points.
I/O: Required Input.
* Reservoir Operating Levels
This method collects the reservoirs’ forecast operating levels (at the end of the balance period). The highest reservoir operating level is excluded, and added to the set are the key control point balance levels (Balance Level) computed by the Operating Level Balancing method of the Key Control Point Balancing category (this is the set of balance levels used with the default selection). This option is useful when there are no key control points. It attempts to bring the highest reservoirs down to the levels of lower reservoirs before it processes the lower reservoirs.
Slots Specific to This Method
Balance Levels Used
Type: Agg Series Slot
Units: NONE
Description: The set of balance levels taken from the key control points for driving the algorithm.
Information: This slot is not visible on the open object dialog, it is only visible in the Special Results USACE methods tab of the Model Run Analysis (on the subbasin) It is for observing the operation of the algorithm during or after a run.
I/O: Output.
Pass Behavior
This category appears only if the Operating Level Balancing method is selected in the Flood Control category.
The flood control method operates in one of two ways: on each pass it computes an additional release for each reservoir for the pass’s balance level, or it undoes any prior pass’s release schedule and recomputes from scratch, given the new balance level.
* Undo and Recompute Max Release (default)
For a given full reservoir FR, on a pass at balance level BL, pretend FR’s release schedule for the prior balance level did not happen. Thus, at each downstream control point, add back in the empty space consumed by FR’s prior release schedule, and at each tandem reservoir, subtract out the tandem storage scheduled on the prior pass. Then recompute the best release schedule for the full reservoir, as before, but this computation respects a new set of space reservations and tandem storages from other reservoirs, as computed on this and prior passes.
Slots Specific to This Method
None
* Compute Additional Release
Whatever could be release from a full reservoir FR on any pass can still be released on the next pass, with the exception of the final pass, which is recomputed so that additional empty space will be used as early as possible in the release schedule.
This method can give different results than recomputing the release, due to interactions with other method selections and the function of the “trim” (Max Release Variation slot) value in the empty space computations at control points. See ““Trim” (Max Release Variation) and Empty Space”.
The main benefit of this method is to reduce complexity and thus runs may be faster. No performance comparisons have been made as of this writing.
Slots Specific to This Method
None
Key Control Point Max Release
This category appears only if the Operating Level Balancing method is selected in the Flood Control category. This method category and its methods exist for convenience of algorithm development, and may not be available in the future.
Each reservoir that is subject to a key control point may be assigned a Max Flood Control Release value by the key control point balancing method. This method determines whether the flood control uses that value in its computations. (If the value is not a valid, it is ignored, in any case.)
The Max Flood Control Release is a value determined by the Key Control Point Balancing method. It is applied on all but the final pass of the algorithm. See the discussion and example in the subsection “Constraints of the Full Reservoir”.
* Max Release Applies (default)
The Max Flood Control Release is applied as an upper bound on each timestep of the forecast period, on all passes but the last.
The effect of applying this maximum is mixed. On one hand, it tends to allow each subject reservoir to release something, even if at the expense of a higher-priority reservoir. This may help to smooth the release schedules for reservoirs, to avoid oscillating behavior, in which on one day, RA releases but RB does not, and on the following day RB releases, while RA does not, then RA releases, then RB releases, and so on. On the other hand, it may subvert the principle of giving priority to the fuller reservoirs.
When a reservoir’s maximum is zero, the flood control algorithm bypasses most of the work associated with projecting a release schedule during all but the last pass.
Slots Specific to This Method
None
* Max Release Ignored
The value is ignored. See “Max Release Applies (default)” for details.
Slots Specific to This Method
None
Key Control Point Space Use
This category appears only if the Operating Level Balancing method is selected in the Flood Control category. This method category and its methods exist for convenience of algorithm development, and may not be available in the future.
The allocation of space by the key control point balancing method may be respected or ignored, for purposes of experimentation.
* Key Control Point Balancing Share (default)
On all passes but the last, allow subject reservoirs to use only as much space at key control points as has been allocated to them. A reservoir that is not a subject of a key control point gets no share of that key control point’s empty space on any pass but the last. On the last pass, all space is available on a first-come, first-served basis.
Slots Specific to This Method
None
* First-Come, First-Served
Ignore the space allocations at the key control points. Every full reservoir has rights to space at key control points on a first-come, first-served basis.
Slots Specific to This Method
None
Operating Level Mapping
This category appears only if the Operating Level Balancing method is selected in the Flood Control category.
Throughout the flood control computations, the Operating Level Balancing method converts operating levels to storages and vice versa. The mappings used for these conversions are defined in the Operating Level Table, which is a periodic slot, that is to say, the mapping changes with time. This method category exists to determine which timestep is used for the Operating Level Table lookups (interpolations).
Note:  This method exists for the purpose of approximating SUPER results.
* Simulation Timestep (default)
Use the current rules controller’s simulation timestep for the periodic slot lookups and interpolations. When selected, the current simulation timestep is the date used in the (interpolated) table look-up, even when looking up such things as forecast storages at the end of the balance period. Thus, if a storage V translates to operating level 8.0 on the current simulation timestep, but to operating level 8.1 at the end of the balance period, and V is the storage at the end of the balance period, the operating level at the end of the balance period will be considered 8.0.
Slots Specific to This Method
None
* Forecast Timestep
Use forecast timestep in question for the periodic slot lookups and interpolations, when looking up storages and levels at that timestep. Thus, if a storage V translates to operating level 8.0 on the current simulation timestep, but to operating level 8.1 at the end of the balance period, and V is the storage at the end of the balance period, the operating level at the end of the balance period will be considered 8.1.
Slots Specific to This Method
None
Tandem Balancing
This category appears only if the Operating Level Balancing method is selected in the Flood Control category.
There may be many ways to balance reservoirs that are in tandem (one downstream from another). This category is a place-holder for alternative methods for doing this.
* None
If selected, no special action is taken to balance tandem reservoirs. Any downstream tandem may serve to store water released from above on any pass, but only up to the lower of the tandem’s assigned balance level (Balance Level) and the balance level of the pass.
Note:  The downstream reservoir can only store water if there is zero Surcharge Release.
Slots Specific to This Method
None
* Two-Reservoir Midpoint (default)
If selected, a downstream tandem may store water as above (None) and possibly a little more: it will find the midpoint of the forecast operating levels of the two reservoirs, and store the amount of water that will both bring the upstream reservoir to that midpoint and bring the downstream reservoir to that midpoint. (Of course, later in the algorithm, such stored water may be drained.)
Note:  The downstream reservoir can only store water if there is zero Surcharge Release.
Starting storages for two-reservoir balancing are as follows.
• Upstream reservoir: the original forecast storage at the end of the balance period plus tandem storage scheduled here from upstream (through either the end of the forecast period or the end of the balance period, depending on the Tandem Storage Considered method selection, q.v.) minus the volume already scheduled to be stored in intervening reservoirs.
• Downstream tandem reservoir: the original forecast storage at the end of the balance period plus tandem storage scheduled here from other upstream reservoirs (through either the end of the forecast period or the end of the balance period, subject to the Tandem Storage Considered method selection, q.v.) minus the volume released on the first timestep by any proposed flood control release from a prior pass, with a floor of the storage equivalent to the lesser of the balance level of the pass and the assigned balance level. (This method is not invoked until the flood pool has already been filled to this floor level.)
The method is invoked at most once for each {upstream, tandem} pair in any pass of the algorithm, and then only after the tandem’s conservation pool is filled and its flood pool is filled up to the smaller of the pass balance level and the assigned balance level of the tandem reservoir. Once invoked, this method computes a balance level B (between the balance levels for the starting storages) and volume V such that moving volume V from the upstream reservoir to the tandem will leave them both at level B. The return value of the method is the volume V, and the flood control algorithm is free to move up to V from the upstream to the downstream reservoir. By this means, and only by this means, will a downstream reservoir be filled above the balance level of a pass on that pass, or above its assigned balance level on any pass.
If the downstream reservoir’s projected balance level is higher than that of the upstream reservoir (based on the starting volumes as described above), the return value will be 0.0 (no additional tandem storage).
The details of the algorithm for finding the volume V are as follows:
The method is looking for a point of intersection between two lines:
Line 1 is the line X=Y.
Line 2 is the line between two points P1 and P2.
Each point P(J) represents what it would take to bring the full reservoir down to level J and the tandem up to level J.
P(J) = (volume that the full reservoir contains above level J, volume that can be stored in the tandem to take it to level J).
The method finds the balance level J such that P(J) is on the line X=Y. This is done in two steps: find points P1 and P2 where P1 is in the lower half of the space defined by the line X=Y and P2 is in the upper half. Then the method finds the point of intersection between the line (P1,P2) and the line X=Y.
1. Find points P1 and P2. Start with
x1=the volume that the full reservoir contains above the tandem’s balance level, and
y1=0
This point (x1,y1) represents bringing the full reservoir to the tandem’s level and storing nothing in the tandem. Clearly this point is in the region where x > y.
2. Now find a point P(J) for some J that falls in the upper half of the graph defined by X=Y, that is, where x <= y:
Start with J = tandem’s balance level + 1.
P(J) = (volume that the full reservoir contains above level J, volume that can be stored in the tandem to take it to level J).
If x <= y, then P(J) falls in the upper half of the plane and P2 is P(J). If not, set P1 = P(J) and increment J by 1, and recompute P(J) until a P(J) is found that is in the upper half of the graph. This is P2.
3. Now that we have a J such that x <= y, we find the point of intersection between P1 and P2. Compute the slope of the line between P1 = (x1,y1) and P2=(x2,y2):
The volume V to release is:
Invoking this method on one pair of reservoirs changes the state of the downstream reservoir, and subsequent invocation with a different upstream reservoir may change it yet again. Repeated invocations over several passes tends to bring the collected upstream reservoirs in balance with the tandem, thus, to some extent, with each other.
Slots Specific to This Method
None
Modify Inputs to Two-reservoir Midpoint
This category appears only if the Two-reservoir Midpoint method is selected in the Tandem Balancing category. This method category allows the user to modify the behavior of the Two-Reservoir Midpoint method to more closely mimic SUPER. The Two-Reservoir Midpoint method, as described above, takes into account the volume of tandem storage that has already been scheduled to be stored in the upstream reservoir by a reservoir upstream of it (this could have happened if the more upstream of the two were “fuller” and therefore processed first). The SUPER algorithm does not take this volume into account, so RiverWare offers this category so the user can select whether to mimic SUPER or to use the Two-Reservoir Midpoint method. See “Two-Reservoir Midpoint (default)” for details.
The two methods in this category are described below.
Note:  This category exists for the purpose of approximating SUPER results.
* Omit Tandem Storage from Upstream Reservoir (default)
SUPER does not include tandem storage in the upstream reservoir for the purpose of computing the starting storage of the upstream reservoir. Tandem storage is considered in the downstream reservoir.
Slots Specific to This Method
None
* None
Include tandem storage in both reservoirs.
Slots Specific to This Method
None
Tandem Storage Management
This category appears only if the Operating Level Balancing method is selected in the Flood Control category. This method category allows the user to control the accuracy of the tandem storage calculations used to propose flood control releases.
The SUPER algorithm treats tandem storage as blocks of water moved, without regard to the times they are released or arrive.
Note:  This method exists for the purpose of approximating SUPER results.
* Do Not Route Tandem Storage (default)
SUPER treats tandem storage as blocks of water moved instantaneously, without regard to the times they are released or arrive. This method allows RiverWare to more closely mimic the SUPER behavior. Following are consequences of not routing the water.
• water that is scheduled for tandem storage cannot be released as soon as it arrives; it can be released only at the end of the release schedule, and
• such water is released at the end of the release schedule, even if it has not been released from above yet, or might all have arrived after the end of the forecast period, and
• such water is accounted for in total when computing a Two-Reservoir Midpoint balance, or for computing space left in the flood pool for holding more tandem storage, regardless when it is released or might arrive, and
• since the algorithm does not know when this water arrives at a tandem reservoir, it does not check, after the first timestep, that a release does not dip into the conservation pool.
Slots Specific to This Method
None
* Route Tandem Storage
Water scheduled for tandem storage is routed, and its arrival times are known to the Operating Level Balancing method, so it can release the water as soon as possible. For the purpose of computing starting storages for the Two-Reservoir Midpoint, the method can be more accurate in its knowledge of the storages in the two reservoirs. Nevertheless, there are options for selecting the quantity of tandem storage water for which to account (see “Tandem Storage Considered”).
Slots Specific to This Method
None
Tandem Storage Considered
This category appears only if the Route Tandem Storage method is selected in the Tandem Storage Management category. When water scheduled for tandem storage is routed, its arrival times are known.
The flood control algorithm balances reservoirs based on their projected storages at the end of the balance period. In a sense, the end of the balance period is the end of the time when there is some confidence in the forecasts. The question arises: if we release water today to store downstream, we know it will arrive, so do we care when it arrives? Should the fact that we released it be enough to consider it stored at its destination? This category lets us choose one of two ways of answering that question. Myriad other possibilities (such as considering only water released on the first timestep, or scheduling storage only on the first timestep or only during the balance period) are not implemented.
* Arrives in Forecast Period (default)
The flood control algorithm considers all the water that arrives at a tandem within the forecast period to contribute to the tandem’s storage. This means that water released after the end of the balance period is considered also.
Slots Specific to This Method
None
RB is forecast to be at level 10.0 and RC is forecast to be at level 5.0 at the end of the balance period. The key control point balancing method assigns level 7.0 to all three reservoirs. On the first pass, at balance level 7.0, RC takes on 100 units from RB, released as { 40, 30, 20, 10}. Since the forecast period is 5 days long, the arrival hydrograph for this release schedule from RB is {4, 19, 30, 25, 15}, leaving 7 units that are routed off the end of the forecast period. Thus, in future calculations based on the forecast storage in RC, 93 units of volume will be added to RC’s forecast storage. RC will be free to release on day 1 an additional 4 units of volume, and on day 2 an additional 19 units of volume, and so on. If the Two-Reservoir Midpoint method is selected, the starting volume for RC will henceforth include 93 units of volume above its forecast volume at the end of the balance period.
* Arrives in Balance Period
The flood control algorithm considers only that water that arrives within the balance period to contribute to the tandem’s storage. This means that water released within the balance period is the only water considered.
Slots Specific to This Method
None
Priority Determination
This category appears only if the Operating Level Balancing method is selected in the Flood Control category.
Methods in this category determine the timing of the priority determination of reservoirs.
* None (default)
This is not a valid method; an error will be posted if selected.
* End of Prior Timestep, Fixed
The reservoirs in the subbasin are given priorities based on their “fullness” at the end of the prior simulation timestep, if in the flood pool at that time. If a reservoir is in the flood pool at the end of the prior timestep, its ending operating level is its priority. If not, its forecast operating level at the end of the balance period becomes its priority. These priorities are used for the entire duration of the flood control method, regardless how much water is scheduled for release from any reservoir in the subbasin during the method’s computations.
When this method is selected, the set of “full” reservoirs on any pass is processed in the order of the predetermined priorities, above. If reservoirs are to be added to the set, the Reservoir Set category (q.v., below) selection must be Reservoirs Starting in or Entering Flood Pool.
Slots Specific to This Method
Forecasted Operating Level
Type: Agg Series Slot
Units: Lengths
Description: There is one column for each reservoir in the subbasin (this is recreated at run initialization). Each column stores the forecasted operating level; that is for the current timestep, the operating level a the end of the balance period. Thus, if the balance period is 4. The value shown on this slot at timestep 1 is the forecasted operating level at timestep t+3 (current plus three timesteps). This operating level is from the first pass only.
Information: This slot is invisible but can be viewed in the computational subbasin’s Special Results details on the Model Run Analysis tool; see “Model Run Analysis—Special Results Details Dialog” in USACE‑SWD Modeling Techniques.
I/O: Output only
RA ended yesterday’s simulation at level 4.8, RB at 8.1, RC at 4.4. RA is forecast to be at level 5.6 at the end of the balance period, RB at 10.0, and RC at 4.9. The priorities are assigned as follows: RA: 5.6, RB 10.0, RC 4.4. On each pass, the reservoirs will be processed (given a chance to consume channel space) in this order: RB, RA. RC will not be processed, unless the Reservoir Set category selection is Reservoirs Starting in or Entering Flood Pool, in which case, it will be processed on the last pass if it takes on tandem storage to bring it into the flood pool.
* End of Balance Period, Varies
Flood control considers only the reservoirs’ forecast operating levels at the end of the balance period. Those priorities are recomputed at each pass of the algorithm, based on the latest forecast storages, which take into account proposed release schedules and proposed tandem storage. At the beginning of each pass, the entire subbasin’s set of reservoirs is considered. The last pass is demand-driven, so that if reservoir A’s new releases change the state of empty space in a way that might affect reservoir B, reservoir B is reprocessed.
Slots Specific to This Method
Forecasted Operating Level
Type: Agg Series Slot
Units: Lengths
Description: There is one column for each reservoir in the subbasin (this is recreated at run initialization). Each column stores the forecasted operating level; that is for the current timestep, the operating level a the end of the balance period. Thus, if the balance period is 4. The value shown on this slot at timestep 1 is the forecasted operating level at timestep t+3 (current plus three timesteps). This operating level is from the first pass only.
Information: This slot is invisible but can be viewed in the computational subbasin’s Special Results details on the Model Run Analysis tool; see “Model Run Analysis—Special Results Details Dialog” in USACE‑SWD Modeling Techniques.
I/O: Output only
Not Linkable
RA ended yesterday’s simulation at level 4.8, RB at 8.1, RC at 4.4. RA is forecast to be at level 5.6 at the end of the balance period, RB at 10.0, and RC at 4.9. The initial priorities are assigned as follows: RA: 5.6, RB 10.0, RC 4.9. On the first pass, the reservoirs will be processed (given a chance to consume channel space) in this order: RB, RA. As soon as RC takes on enough storage to put it above the balance level of a pass, it will be processed. Likewise, the other reservoirs will be re-prioritized on each pass, according to their projected levels that result from the projected releases on the prior pass.
Reservoir Set
This category appears only if the Priority Determination category selection is End of Prior Timestep, Fixed. This category allows a variation on that method.
Note:  This method exists for the purpose of approximating SUPER results.
* Reservoirs Starting in Flood Pool (default)
Reservoirs will not be added to the set of reservoir considered on any pass. If a reservoir starts in the conservation pool and takes on tandem storage, which puts it into the flood pool, it will be considered for making releases in this invocation of the Operating Level Balancing flood control method. Such water will not be considered for release until the next simulation timestep.
Slots Specific to This Method
None
* Reservoirs Starting in or Entering Flood Pool
If a reservoir starts in the conservation pool and takes on tandem storage, which puts it into the flood pool, it will be considered for making releases in this invocation of the Operating Level Balancing flood control method.
Slots Specific to This Method
None
Smoothing Releases
This category appears only if the Operating Level Balancing method is selected in the Flood Control category. This method category and its methods exist for convenience of algorithm development, and may not be available in the future.
The Operating Level Balancing method applies heuristic schemes (Allowable Falling Release Change, Allowable Rising Release Change, and Maximum Release Variation) designed to smooth the reservoirs’ release graphs, as described above, by limiting the change in release from one timestep to the next, or by assuming a stepped-down hydrograph with a given change at each timestep. The releases considered at each timestep may include: the so-far-computed flood control release, the surcharge release, the flood control minimum release and the “through release”. “Through release” refers to water released from upstream reservoirs that flows through a downstream tandem reservoir. This water is the “through release” of the tandem. The through releases may be considered among, or excluded from, the set of releases used in the smoothing heuristics. Through releases are ultimately folded into the flood control releases, but at the time of the smoothing operations, they are not yet folded in.
Note:  This method exists for the purpose of approximating SUPER results.
* Consider Flood Control and Surcharge Only (default)
Do not consider through releases (or any other releases that might be added with future development).
When checking for empty space at a control point (applying Max Release Variation), do not consider surcharge or through releases if the method selection for Pass Behavior is Undo and Recompute Max Release.
Slots Specific to This Method
None
* Consider All
Consider all releases that have been computed for this reservoir at the time the smoothing operation is applied.
If the method selection for Pass Behavior is Undo and Recompute Max Release, this method selection has no effect on the smoothing operation using Max Release Variation (trim) when checking for empty space at control points. When running with Undo and Recompute Max Release, only flood control releases are considered for smoothing purposes at control points.
Slots Specific to This Method
None
Last Pass Timesteps May Increase
This category appears only if the Operating Level Balancing method is selected in the Flood Control category. This method category and its methods exist for convenience of algorithm development, and may not be available in the future.
When the Operating Level Balancing method runs the final pass of the flood control algorithm, it may subject each timestep’s proposed releases to the same constraints as prior passes (except the Key Control Point Max Release and Key Control Point Space Use never apply on the last pass), or it may add an additional constraint to timesteps after the first.
Note:  This method exists for the purpose of approximating SUPER results.
* Current Simulation Timestep Only (default)
Limit increases in releases after the first timestep of the schedule on the last pass. Releases on timesteps after the first are subject to one more constraint on the final pass: that they do not exceed the larger of
• the value proposed on the prior pass for the timestep, and
• the value proposed on this pass for the prior timestep minus the trim value (Maximum Release Variation slot).
This method allows some reservoirs to make larger releases than they might otherwise make, and reduces releases for some reservoirs on the current simulation timestep. Its effect is not predictable.
Slots Specific to This Method
None
If the Last Pass Timesteps May Increase selection is Current Simulation Timestep Only, this constraint is applied. After the first two of three passes, RA’s proposed release schedule is {50, 70, 90, 30, 10}. Its Maximum Release Variation (trim) is 10, and its Allowable Rising Release Change is 20. Now we run the final pass, and, having eliminated the constraints imposed by the key control point CPY, we could now release {80, 100, 100, 100, 90}. This constraint says that we will release {80, 70, 90, 80, 70}. The first timestep is unconstrained here; the second is constrained by both (or either, since they are the same) the value proposed on the prior pass (70) and the value proposed on this pass, prior timestep (80) minus the trim value (10). The third day is constrained by the prior schedule. The fourth day is constrained by 90-10=80, which is larger than 30, so it is the upper bound, and the last day is also constrained by the prior timestep minus trim.
* Entire Forecast Period
Let the last pass behave like all other passes, except the Key Control Point Max Release and Key Control Point Space Use never apply on the last pass.
Slots Specific to This Method
None
Water Rights Allocation
The selected method in this category is executed by the SolveWaterRights RPL function; see “SolveWaterRights and SolveWaterRightsWithLags” in RiverWare Policy Language (RPL).
* None
There are no slots or calculations associated with this method.
* Prior Appropriation
This method, if selected, is executed by the SolveWaterRights RPL function; see “SolveWaterRights and SolveWaterRightsWithLags” in RiverWare Policy Language (RPL). See “Water Rights Allocation” in Accounting for details on the Water Rights Allocation solver. The method allocates water from a specified “allocatable flow” supply chain to prioritized water accounts in the specified subbasin, meeting the “first in time, first in right” requirement.
Slots Specific to This Method
Top of Conservation Pool
Type: Scalar Slot
Units: none
Description: The Operating Level that represents the top of the conservation pool
Information: This slot appears on the subbasin only for the convenience of propagating the value to all reservoirs in the subbasin (propagation is optional). Reservoirs that hold any storage rights accounts must have the Top of Conservation Pool slot defined. (See the documentation for the Reservoir Object, Operating Levels category.)
I/O: Input only
Shortage Tolerance
Type: Scalar Slot
Units: FLOW
Description: Any shortage less than this amount will be considered zero by this water rights allocation method. Choosing a non-zero value for this slot will reduce the amount of processing spent on very small allocation differences (e.g., in making cutbacks).
Information:  
I/O: Input only
Lag Distance
Type: Scalar Slot
Units: NONE
Description: Maximum lag in number of timesteps from any headwater passthrough account in the subbasin to the downstream-most passthrough account in the subbasin. This slot keeps track of passthrough account lags only (not return flow lags).
Information: This value is computed when the subbasin is verified (either through the GUI due to user actions, or at the beginning of a run), and is used to compute the local timestep offsets of passthrough accounts in the subbasin.
I/O: May not be input.
Minimum Appropriation
Type: Scalar Slot
Units: FLOW
Description: Any potential appropriation less than this amount will be reduced to zero by this water rights allocation method. Choosing a non-zero value for this slot will reduce the processing spent on making very small allocations.
Note:  RiverWare uses a minimum of 1e-12 cms for this value. This is not a default; it is the smallest functional value that RiverWare uses, even if you choose a smaller value (e.g., zero) for this slot.
Information:  
I/O: Input only
Type: Not linkable
Account Equal Priority Allocation
The selected method in this category is executed by the SolveWaterRights RPL function; see “SolveWaterRights and SolveWaterRightsWithLags” in RiverWare Policy Language (RPL). The method specifies how allocation of water is calculated for accounts that have equal priority dates.
* None
No method is selected for handling equal priority accounts during the SolveWaterRights RPL function, and an error is generated if there are accounts with equal priority dates in the computational subbasin when the RPL function is executed.
* Share Proportionally with Limits
This method, if selected, is executed under the SolveWaterRights RPL function; see “SolveWaterRights and SolveWaterRightsWithLags” in RiverWare Policy Language (RPL). When two or more accounts are encountered with an equal priority date, this method iteratively shares available water based on the proportion of cumulative water right to available flow, limited by the minimum downstream proportion. See “Computing Appropriation Without Subordination for Equal Priority Accounts” in Accounting for information on the Water Rights Allocation solver and a detailed explanation of this calculation.
Account Initial Request
These methods disaggregate Annual Request (user input) slot on Diversion Accounts from a 1 Year timestep to 1 Day or 1 Month timesteps on a set of accounts in the subbasin (typically used for water rights appropriations; see “Water Rights Allocation” in Accounting for details. The result is written into the Initial Request slot on the account. Initial Request is used by the Water Rights solver. You may specify the multipliers used to disaggregate the demands in terms of periodic or series data. In either case, RiverWare selects the proper periodic or series slots to use based on the timestep size from the run controller. Two timestep sizes are supported: 1 Day and 1 Month.
The method operates only on diversion accounts on objects in this subbasin on which the Disaggregated by Subbasin method is selected in the Initial Request category. See “Disaggregated by Subbasin” in Accounting.
The selected method is executed at the beginning of the run if this subbasin is enabled. It disaggregates the 1 Year timesteps into timesteps of the Initial Request slots on the accounts for the range of timesteps that covers both the run period and the accounting period.
Conceptually, the coefficients have units of 1/sec, so the Initial Request value for a given timestep is a flow, which is stored in internal units (cms).
flow = (Annual Demand in m3) * coefficient / seconds-in-the-given-timestep
If not all accounts in the subbasin use the same coefficients for disaggregation, alternative subbasins can be defined for each set of accounts that share coefficients.
* None
There are no slots or calculations associated with this method. Select this method if you are not interested in disaggregating annual demands.
* Periodic Coefficients
This method uses a periodic slot to define the coefficients.
Slots Specific to This Method
Daily Demand Coefficients
Type: Periodic Slot
Units: none
Description: Multipliers to be applied to an account’s Annual Request slot value to yield an Initial Request slot value in a non-leap year when the run timestep is a day.
Daily Leap Year Demand Coefficients
Type: Periodic Slot
Units: none
Description: Multipliers to be applied to an account’s Annual Request slot value to yield an Initial Request slot value in a leap year when the run timestep is a day.
Monthly Demand Coefficients
Type: Periodic Slot
Units: none
Description: Multipliers to be applied to an account’s Annual Request slot value to yield an Initial Request slot value in a non-leap year when the run timestep is a month.
Monthly Leap Year Demand Coefficients
Type: Periodic Slot
Units: none
Description: Multipliers to be applied to an account’s Annual Request slot value to yield an Initial Request slot value in a leap year when the run timestep is a month.
Information: Not linkable.
* Series Coefficients
This method uses a series slot to define the coefficients.
Slots Specific to This Method
Daily Demand Coefficient Series
Type: Series Slot
Units: none
Description: Multipliers to be applied to an account’s Annual Request slot value to yield an Initial Request slot value when the run timestep is a day.
Monthly Demand Coefficient Series
Type: Series Slot
Units: none
Description: Multipliers to be applied to an account’s Annual Request slot value to yield an Initial Request slot value when the run timestep is a month.
Local Inflow Spatial Disaggregation
The Local Inflow Spatial Disaggregation category contains three methods: the default, no action method, None, the WAM Precipitation Curve Number method, and the Drainage Area method. Both the WAM Precipitation Curve Number method and the Drainage method take known gage flows and estimate the flow at intervening or upstream Ungaged Control Points. The WAM Precipitation Curve Number method calculates an equivalent precipitation, using an empirical equation to relate watershed parameters, gage flows and precipitation. The Drainage Area method calculates a ratio between incremental gage drainage area and the ungaged drainage area to distribute flows. Spatial disaggregation is calculated at the start of the run for all enabled subbasins.
The three categories of disaggregation methods are executed in the following order:
1. Local Inflow Spatial Disaggregation
2. Local Inflow Temporal Disaggregation
3. Incremental Local Inflows. This category may include forecasting.
The computational subbasin executes the disaggregation methods at the beginning of a run and subsequently sets the relevant disaggregated local inflow slots as inputs on control points and reservoirs. In practice, users may run the model once to perform the disaggregation, then disable the subbasins related to disaggregation and save the model. When this method is used, future model runs will not execute the disaggregation methods and users will avoid the computational expense of disaggregating the local inflows at the beginning of each run. Should users wish to re-calculate their disaggregation methods, they should re-enable the subbasins and start a model run.
While the actual computation of the disaggregation occurs via the three methods on the computational subbasin, the data for the disaggregation is stored in method dependent slots on control points and reservoirs.
* None
This method is the default for the Local Inflow Spatial Disaggregation category and should be selected when spatial disaggregation of local inflows is not desired.
There are no slots specifically associated with this method.
* WAM Precipitation Curve Number
This method computes the Distributed Flow values for all Ungaged Control Points in the subbasin given the known Distributed Flow values of the downstream Gage Control Point, upstream Gage Control Points (if any), and excluded Gage Control Points (if any). There are no slots specifically associated with this method on the subbasin. The relevant data is held in method dependent slots on the control points and is accessed by the computational subbasin. See “WAM Precipitation Curve Number” for details on these slots and the Local Inflow Spatial Disaggregation on Subbasin method on the Control Point.
The WAM Precipitation Curve Number method disaggregates using methods found in the Water Availability Model (WAM) developed by Dr. Ralph Wurbs at Texas A&M University. The WAM Precipitation Curve Number method is executed on the computational subbasin at the beginning of run if the subbasin is enabled. The method calculates the Distributed Flow at each ungaged control point using the NRCS curve number, mean precipitation, and drainage area of both the gaged and ungaged control points.
The downstream Gage Control Point calculates the gain in the basin, using the difference in Distributed Flow between the downstream gage control point and its upstream gage control point(s) as defined in the downstream gage. The effect of excluded gages is defined below.
The downstream Gage Control Point calculates the area of the basin, subtracting the area of all upstream gages from the area provided in the downstream gage. The upstream gage curve number and upstream gage mean precipitation are scaled by area and subtracted from the downstream gage curve number and mean precipitation, also scaled by area. The resulting curve number and mean precipitation are scaled by 1/area to calculate the updated curve number and mean precipitation.
Excluded gages may be defined in the Ungaged Control Point, to change the gain calculation for its downstream gage control point. For most basins, the Excluded gages list is not needed. Each Ungaged Control Point maintains its own list of excluded gages. When a gage is placed in the list, the downstream gage ignores that excluded gage when solving the gain, curve number, and mean precipitation at the downstream control point.
The algorithm is described in the following steps.
1. All of the Ungaged Control Points in the computational subbasin are visited to perform the spatial disaggregation of flows to Ungaged Control Points. For each Ungaged Control Point to be calculated, the Downstream Gage is visited, and the incremental flow for that gage is calculated. Distributed Flow from upstream gages is subtracted from the Distributed Flow in the currently computed gage. Any upstream gages that are not tributary to the ungaged point may be left in the gage (not subtracted) using Excluded Gages list. This list may be different for each Ungaged Control Point, based on its location in the subbasin. The resulting set of incremental flows is only used for calculations pertaining to the current Ungaged Control Point.
2. The drainage areas are checked. An error occurs if the total drainage area of the Upstream Gage Control Points are equal or larger than the drainage area of the Downstream Gage Control Point or the Ungaged Control Point.
3. Incremental drainage area at the Downstream Gage Control Point is calculated, subtracting the sum of the drainage area for all Upstream Gage Control Points, except for those specified in the Excluded Gage Control Points list.
4. The incremental curve number at the Downstream Gage Control Point is calculated. The curve number is area weighted, subtracting the area weighted curve numbers from Upstream Gage Control Points, except for those specified in the Excluded Gage Control Points list.
5. The incremental mean precipitation at the downstream gage is calculated. The mean precipitation is area weighted, subtracting the area weighted mean precipitation from Upstream Gage Control Points, except for those specified in the Excluded Gage Control Points list.
6. Incremental drainage area at the Ungaged Control Point is calculated, subtracting the sum of the Drainage Area for all Upstream Gage Control Points.
7. The incremental curve number at the Ungaged Control Point is calculated. The Curve Number is area weighted, subtracting the area weighted curve numbers from Upstream Gage Control Points.
8. The incremental mean precipitation at the Ungaged Control Point is calculated. The mean precipitation is area weighted, subtracting the area weighted mean precipitation from Upstream Gage Control Points.
9. The incremental runoff (Q) at the Downstream Gage Control Point is computed by dividing the monthly incremental inflow at the Downstream Gage Control Point by its incremental drainage area.
10. The precipitation depth (P) at the Downstream Gage Control Point is calculated through an iterative solution (bisection) given the runoff computed in the previous step and the value of S as follows.
11. If the Downstream Gage Control Point runoff (Q) is less than or equal to zero, the precipitation depth (P) at the Downstream Gage Control Point is 0.2 times the value of S.
12. The precipitation depth at the Ungaged Control Point is computed by adjusting the precipitation depth at the Downstream Gage Control Point by the ratio of the mean precipitation depth (M) at the ungaged and gaged control points.
13. In order to avoid a divide by zero error and the better match reality, the Downstream Gage Control Point’s mean precipitation depth must be greater than zero. For consistency, the Ungaged Control Point’s mean precipitation depth must also be greater than zero.
14. The runoff at the Ungaged Control Point is then computed using curve number equation using Pungaged and Sungaged for the Ungaged Control Point.
15. The computed value for the runoff is then converted to incremental streamflow. Incremental streamflow is added to the Upstream Gage Control Point streamflow to calculate an initial estimate of streamflow at the Ungaged Control Point.
16. The initial estimate is compared to the downstream gage flow, and the minimum is selected. The results at the upstream gage point never exceed the downstream gage flows.
17. Set the results to the Distributed Flow slot as inputs.
The iterative solution for Precipitation in Step 10 is solved using the bisection method. The bisection routine is an incremental search method in which the function is reevaluated at the midpoint of the interval between the values of the previous two guesses to determine on which side of the midpoint the root lies. Depending on which side of the midpoint the root lies, the midpoint becomes either the upper or lower bound to the search interval. The interval is again divided in half and the function is reevaluated at the midpoint. This procedure is repeated until the solution is obtained. The bisection method typically uses the maximum and minimum values for the unknown variable and finds the midpoint of these to use as the seed value to start the iteration. While the minimum value of Precipitation is zero, the maximum value is not clearly defined at the start of step 10, thus a seed value of P = Mean Precipitation will be used to start the bisection routine. If the right hand side (RHS) of the equation in step 10 is smaller than the runoff (the left hand side (LHS) of the equation) the value of P will become twice the previous value for P (i.e., twice the Mean Precipitation). This will be repeated until the RHS is larger than the LHS, indicating that an upper bound for P has been determined. From here the bisection method continues in the usual fashion. If the seed value of P results in the RHS of the equation in step 10 being larger than LHS, the value of P will become 0.5 times Mean Precipitation (i.e., the midpoint between the minimum value, 0, and the initial value, Mean Precipitation). From here the bisection method proceeds in the typical fashion. The bisection method will continue until two successive solutions are within convergence of each other or until maximum iterations is reached. Convergence is defined as the convergence criteria set on the gage control point’s Distributed Flow slot.
Note:  The empirical equations in this method use units of acres for drainage area, acre-feet per month for flow, inches per month for runoff and inches for precipitation. Curve Number is unitless. Users may enter data in any units and the values will be internally converted for the computation.
The method will set the non-gage control points’ Distributed Flow slots as input to avoid these values being cleared in subsequent model runs. After the WAM Precipitation Curve Number is completed, all control points will contain a value in the Distributed Flow slot for all timesteps in the slot. After the WAM Precipitation Curve Number method is completed, data is made available for the next stage of the disaggregation or forecast depending on which is the next selected method.
Note:  All steps of the disaggregation and forecast will be taken in sequence: the local inflow spatial disaggregation (if any) occurs first, the local inflow temporal disaggregation (if any) occurs next, and then the calculation of incremental values (if any).
If a non-none Local Inflow Temporal Disaggregation method is the next selected method, the Distributed Flow values will be used in the temporal disaggregation calculations. If the Compute Incremental Local Inflows method is the next selected method, Distributed Flow values are copied into the Cumulative Local Inflow slot for the computation of incremental flows, but only if the timestep sizes of the two slots match. If no other disaggregation or forecast method is selected, the Disaggregated Flow slot is copied into the Local Inflow slot. This copying of slots occurs during beginning of run.
The default timestep size for the Distributed Flow and Mean Precipitation slots is months. This can, however, be changed by the user by configuring the timeseries and is independent from the model timestep size. It is up to the user to make sure the timestep size and associated data are appropriate.
Model Setup
The computational subbasin must be set up for each subbasin in which flows will be spatially disaggregated. On the computational subbasin, select WAM Precipitation Curve Number method from the Local Inflow Spatial Disaggregation category. Append the relevant control points to the subbasin. Each spatial disaggregation subbasin should include at least one Ungaged Control Point, where flow will be determined using the Gage Control Point(s) as a reference. Each Ungaged Control Point should be included in only one subbasin.
For each control point in the computational subbasin, the WAM Precipitation Curve Number method must be selected from the Local Inflow Spatial Disaggregation category. Selecting the WAM Precipitation Curve Number method enables the Gage Control Point category. Select the Gage Control Point method from the Gage Control Point category for each gage control point in the basin.
Note:  Upstream control points do not need to be a member of this subbasin, but they need to be a member of at least one subbasin.
All other control points should have None selected in the Gage Control Point category. If necessary, change the timestep size of the Distributed Flow and Mean Precipitation slots (default is 1 Month). Input data into the Drainage Area, Curve Number, and Mean Precipitation slots on all control points and the Distributed Flow slot on the gage control point.
* Drainage Area
This method computes the Distributed Flow values for all non-gage control points in the subbasin given the known Distributed Flow values of the Gage Control Point. There are no slots specifically associated with this method on the subbasin. The relevant data is held in method dependent slots on the control points and is accessed by the computational subbasin. See “Drainage Area” for details on these slots and the Local Inflow Spatial Disaggregation on Subbasin method on the Control Point.
The Drainage Area method disaggregates using the drainage area ratio between the Ungaged Control Point and the downstream Gaged Control Point. The downstream Gage Control Point calculates the gain in the basin, using the difference in Distributed Flow between the downstream gage control point and its upstream gage control point(s) as defined in the downstream gage. Excluded gages may be defined in the Ungaged Control Point, to force the calculation to ignore the existence of that gage when solving the gain at the downstream control point.
The downstream Gage Control Point calculates the gain in the basin, using the difference in Distributed Flow between the downstream gage control point and its upstream gage control point(s) as defined in the downstream gage. The effect of excluded gages is defined below.
The downstream Gage Control Point calculates the area of the basin, subtracting the area of all upstream gages from the area provided in the downstream gage.
Excluded gages may be defined in the Ungaged Control Point, to change the gain calculation for its downstream gage control point. For most basins, the Excluded gages list is not needed. Each Ungaged Control Point maintains its own list of excluded gages. When a gage is placed in the list, the downstream gage ignores that excluded gage when solving the gain at the downstream control point.
The algorithm is described in the following steps.
1. All of the Ungaged Control Points in the computational subbasin are visited. For each Ungaged Control Point to be calculated, the Downstream Gage is visited, and the incremental flow for that gage is calculated. Distributed Flow from upstream gages is subtracted from the Distributed Flow in the currently computed gage. Any upstream gages that are not tributary to the ungaged point may be left in the gage (not subtracted) using Excluded Gages list. This list may be different for each Ungaged Control Point, based on its location in the subbasin. This set of incremental flows is only used in the remaining calculations pertaining to the current Ungaged Control Point.
2. The drainage areas are checked. An error occurs if the total drainage area of the Upstream Gage Control Points are equal or larger than the drainage area of the Downstream Gage Control Point or the Ungaged Control Point.
3. Incremental drainage area at the Downstream Gage Control Point is calculated, subtracting the sum of the drainage area for all Upstream Gage Control Points tributary to the Ungaged Control Point.
4. Incremental drainage area at the Ungaged Control Point is calculated, subtracting the sum of the Drainage Area for all Upstream Gage Control Points.
5. The ratio of incremental drainage area of the Ungaged Control Point to the Gaged Control Point is used to scale the downstream gage incremental flows.
6. Any upstream gages that are tributary to the Ungaged Control Point are added to the result of step 5.
7. The results are stored as input in the Ungaged Control Point’s Distributed Flow slot.
Local Inflow Temporal Disaggregation
The Local Inflow Temporal Disaggregation category contains two methods: the default, no action method, None, and the Specified Factors method. These methods are described below.
The selected method is executed at the beginning of the run if the subbasin is enabled. The three disaggregation methods are always executed in the following order:
1. Local Inflow Spatial Disaggregation
2. Local Inflow Temporal Disaggregation
3. Incremental Local Inflows, which may or may not include forecasting.
* None
This method is the default for the Local Inflow Temporal Disaggregation category and should be selected when temporal disaggregation of local inflows is not desired. There are no slots specifically associated with this method.
* Specified Factors
This method computes the Temporally Disaggregated Flow on all control points in the subbasin by multiplying the Distributed Flow value (monthly default) on each control point by the Temporal Disagg Factors (same timestep as run) located on the computational subbasin. There is one slot specifically associated with this method on the subbasin, the Temporal Disagg Factors slot. The other relevant data is held in method dependent slots on the control points and is accessed by the computational subbasin. See the Local Inflow Temporal Disaggregation on Subbasin method on the Control Point for details of these other slots.
The Specified Factors method sets the Temporally Disaggregated Flow slot on each control point to the product of the Distributed Flow value (on the control point) and the Temporal Disagg Factors value (on the subbasin). These values are set as input to avoid being cleared in subsequent model runs. After the temporal disaggregation is completed, all control points will contain a value in the Temporally Disaggregated Flow slot for all timesteps in the Temporal Disagg Factors slot.
The default timestep size for the Distributed Flow slot is 1 Month, however, this can be changed by the user by configuring the timeseries and is independent from the model timestep size. The user is responsible to ensure that the timestep size and the associated Temporal Disagg Factors data is appropriate. The timestep size for the Temporally Disaggregated Flow and Temporal Disagg Factors slots is always the same as that of the run control.
Temporal Disagg Factors
Type: SeriesSlot
Units: Fraction
Description: Proportion of the Temporally Disaggregated Flow on an object (usually daily) to the Distributed Flow on the object (usually monthly). Generally, the Temporal Disagg Factors should average to 1.0 over the Disaggregated Flow’s timestep. For example, in the typical case, the daily Temporal Disagg Factors over any month should average to 1.0.
Information: Typically generated from historical data. The value must be greater than or equal to zero.
I/O: Required input
Model Setup
The computational subbasin must be set up for each subbasin in which flows will be temporally disaggregated. On the computational subbasin, select the Specified Factors method from the Local Inflow Temporal Disaggregation method category. Input data in the Temporal Disagg Factors slot on the computational subbasin. Append the relevant control points to the subbasin. Each temporal disaggregation subbasin should include all control points that will use the same Temporal Disagg Factors data for the disaggregation.
For each control point in the computational subbasin, the Specified Factors method must be selected from the Local Inflow Temporal Disaggregation category. If no values exist in the Distributed Flow slot (i.e., if spatial disaggregation was not/ will not be performed) enter the necessary data.
Incremental Local Inflows
The Incremental Local Inflows category is used to calculate the incremental local inflow to control points and reservoirs within the computational subbasin given the cumulative local inflows. The three disaggregation methods are always executed in the following order:
1. Local Inflow Spatial Disaggregation
2. Local Inflow Temporal Disaggregation
3. Incremental Local Inflows, which may or may not include forecasting.
* None
This method is the default for the category and should be selected when cumulative local inflow data is not used or when calculation of incremental local inflow is not desired. There are no slots specifically associated with this method.
* Compute Full Run Incremental Local Inflows method
This method, executed at the beginning of run for all timesteps in the run, calculates the incremental local inflows to all control points and reservoirs within the computational subbasin using the cumulative local inflows. There is no forecasting in this method.
There are no slots specifically associated with this method. The Cumulative Local Inflow and Incremental Local Inflow slots on control points and the Cumulative Hydrologic Inflow and Incremental Hydrologic Inflow slots on reservoirs as well as the routing methods in the intervening Reaches will be accessed during the calculation.
Solution Algorithm
Following is a description of the solution algorithm including step-by-step descriptions. The Compute Full Run Incremental Local Inflows method on the computational subbasin will execute at the beginning of a run and will set the new Incremental Local inflow slot on control points and the new Incremental Hydrologic Inflow slot on reservoirs with an Input flag. Because these slots are not dispatch slots, no object dispatching will occur. In practice, users will perform the calculation of incremental values, then save the model and disable the subbasins related to the calculation of incremental values. Thus, in future model runs the Compute Full Run Incremental Local Inflows method will not be executed. This practice allows users to avoid the computational expense of calculating the incremental local inflows at the beginning of each run. Should users wish to re-execute the Compute Full Run Incremental Local Inflows method, they should re-enable the subbasin and start a model run. The second, and subsequent times, the model is run, the calculated values that were set with an input flag will be overwritten with the new values.
The method calculates the Incremental Local/Hydrologic Inflow as the difference between a downstream control point or reservoir’s Cumulative Local/Hydrologic Inflow and the upstream control point's cumulative local inflow that is routed downstream through the intervening Reaches on that timestep. Following is the solution procedure.
Solution Steps
The method execute using the following steps; the details of these steps are described in the paragraphs below. See Figure 8.5 for an example of the computation.
1. Group all control points, reservoirs and confluences in the subbasin into { U, D } pairs, where U is a control point upstream of D, and D is U’s closest downstream control point, reservoir, or confluence. If the Ignore Reservoirs boundary method is selected, only control points and confluences are considered when creating the {U, D} pairs. For each { U, D } pair, repeat steps 2 - 5.
2. Obtain the upstream object’s Cumulative Local Inflow array (i.e., all timesteps). In the forecasting case, forecast the Cumulative Local Inflow using the method selected in the Generate Forecast Local Inflow category. Store the forecasted cumulative flow in the Forecasted Cumulative Local Inflow.
3. Route the upstream object’s Cumulative Local Inflow (or Forecasted Cumulative Local Inflow for forecasting) array through the intervening Reach(es) using the routing coefficients on the Reach(es).
4. If the downstream object is a confluence, store the routed array in its unused Temp Inflow{2,1} array. If the downstream object is a control point or reservoir, calculate the downstream object’s Incremental Local/Hydrologic Inflow at timestep t by subtracting the routed cumulative local inflow arriving downstream at time t from the downstream object’s cumulative local inflow at time t. Repeat for all timesteps t.
Incrementaldownstream(t)= Cumulativedownstream(t) - Routed Cumulativeupstream(t)
5. If the downstream object is a control point or a reservoir, set the downstream object’s Incremental Local/Hydrologic Inflow slot with the Input flag.
6. Move to next { U, D } pair. If no more pairs, move to step 7.
7. Group all confluence, control points, and reservoirs in the subbasin into { U, D } pairs, where U is a confluence upstream of D, and D is U’s closest downstream control point, reservoir, or confluence. If the Ignore Reservoirs boundary method is selected, only control points and confluences are considered when creating the {U, D} pairs. For each { U, D } pair, in upstream-to-downstream (partial-) order, repeat steps 8 - 11.
8. Add the upstream confluence’s Temp Inflow 1 array to its Temp Inflow 2 array and store the value in the Cumulative Local Inflow array.
9. Route the upstream object’s Cumulative Local Inflow array through the intervening Reach(es) using the routing coefficients selected on the Reach(es).
10. If the downstream object is a confluence, store the routed array in its unused Temp Inflow{2,1} array. If the downstream object is a control point or reservoir, calculate the downstream object’s Incremental Local/Hydrologic Inflow at timestep t by subtracting the routed cumulative local inflow arriving downstream at time t from the downstream object’s cumulative local inflow at time t. Repeat for all timesteps t.
Incrementaldownstream(t)= Cumulativedownstream(t) - Routed Cumulativeupstream(t)
11. If the downstream object is a control point or a reservoir, set the downstream object’s Incremental Local/Hydrologic Inflow slot with the Input flag.
12. Move to next { U, D } pair and return to step 8.
Step 1: Grouping Objects into Upstream Control Point - Downstream Object Pairs
The first step of the Compute Full Run Incremental Local Inflows method is to create internal tables of all control points, reservoirs and confluences in the subbasin. These tables are used to create a list of all pairs of objects { U, D }, where U is a control point upstream of D, and D is U’s closest downstream control point, reservoir or confluence. If the Ignore Reservoirs boundary method is selected, only control points and confluences are considered when creating the {U, D} pairs. The computation of incremental local inflow (i.e., steps 2-5) will be performed on each of these { U, D } pairs. These pairs can be processed without regard to order.
Note:  Where confluences exist, the two upstream branches of the confluence must be processed prior to the downstream section of the confluence. For this reason, the Compute Full Run Incremental Local Inflows method will process all pairs with a control point upstream first (steps 2-5) and process all pairs with a confluence upstream second (steps 8-11). This ordering ensures that the proper data will be available to process the downstream section of the confluence.
Note:  For the first (i.e., top-most) control point in the subbasin the Cumulative Local Inflow is also the incremental local inflow, thus no incremental flow must be computed for the top-most control point.
Step 2: Obtain Upstream Cumulative Local Inflow
For each { U, D } pair (the upstream object is a control point), the Compute Full Run Incremental Local Inflows method will obtain the data for all timesteps in the upstream object’s Cumulative Local Inflow slot.
Step 3: Computation of Routing
Step 3 of the Compute Full Run Incremental Local Inflows method routes the Cumulative Local Inflow values through the intervening reaches. For this, it first finds all intervening reaches and grabs their routing coefficients, computing a composite routing vector as it goes. This assumes that all reaches use a linear routing method. Because of time lags, the routing must be done for all timesteps before moving to the next { U, D } pair.
Step 4: Calculate Incremental Local Inflow for Downstream Object
When the downstream object is a control point or a reservoir: After obtaining the upstream object’s routed cumulative local inflow, the Compute Full Run Incremental Local Inflows method will calculate the incremental local inflow at timestep t for the downstream object by subtracting the routed cumulative local inflow arriving downstream at time t from the downstream object’s Cumulative Local Inflow at time t (Eqn. 1). This is repeated for all timesteps in the Cumulative Local Inflow slot of the downstream object and the data is stored in the internal Incremental Local Inflow array. When the downstream object of the pair is a confluence: the Compute Full Run Incremental Local Inflows method does nothing at this step
Step 5: Set the Incremental Local/Hydrologic Inflow slot
The last step of processing the {Control Point, D} pairs is to set the appropriate slot(s) depending on the current pair’s downstream object type (i.e., control point, reservoir or confluence). When the downstream object is a control point or a reservoir: the method will set the Incremental Local/Hydrologic Inflow slot with the Input flag to the values in the Incremental Local Inflow array. If the downstream object is reservoir, the method will set the Incremental Hydrologic Inflow slot with the Input flag to the values in the Incremental Local Inflow array. When the downstream object of the pair is a confluence: the Compute Full Run Incremental Local Inflows method stores the routed cumulative local inflow in the first unused Temp Inflow 1 or 2 slot on the confluence.
Step 6: Repeat for next pair
Step 7: Grouping Objects into Upstream Confluence- Downstream Object Pairs
After processing {Control Point, D} pairs, the Compute Full Run Incremental Local Inflows method uses its internal tables of all control points, reservoirs and confluences in the subbasin to create a list of all pairs of objects { U, D }, where U is a confluence upstream of D, and D is U’s closest downstream control point, reservoir or confluence. The computation of incremental local inflow (i.e., steps 7-10) will be performed on each of these { U, D } pair. These pairs are processed in upstream-to-downstream (partial-) order. By the time any {Confluence, D} pair is processed, the confluence’s two branches will have Temp Inflow 1 or 2 arrays filled from steps 2-5 or from execution of the following steps on an upstream pair.
Step 8: Obtain Upstream Cumulative Local Inflows
For each { U, D } pair (the upstream object is a confluence), the Compute Full Run Incremental Local Inflows method will sum the Temp Inflow 1 or 2 slots to obtain the values for the Cumulative Local Inflow array. If either or both of the Temp Inflow 1 or 2 slots does not contain values (i.e., one or both of the confluences upstream tributaries does not contain a control point), the values in the slot will default to 0.0.
Steps 9, 10, 11, and 12:
These steps are identical to Steps 3, 4, 5, and 6, above.
Figure 8.5  Schematic of method computation
* Compute Forecast Period Incremental Local Inflows
In the forecasting case, the Compute Forecast Period Incremental Local Inflows method on the Computational Subbasin will be executed at the beginning of each timestep to set the Local Inflow on each Control Point and the Hydrologic Inflow Forecast on each reservoir. Unlike the non-forecasting case, the subbasin and these methods must remain enabled for all runs as the local inflows are calculated on each timestep and are not given an input flag. NOTE: It is important that subbasins with Compute Forecast Period Incremental Local Inflows method selected stay enabled. This is because the forecasting takes place once each timestep over the forecast period. This is different than the application of the Compute Full Run Incremental Local Inflows for which users are encouraged to execute the method only once and then disable the subbasin.
The method first forecasts the Cumulative Local/Hydrologic Inflow throughout the forecast period and then calculates the Local Inflow or Hydrologic Inflow Forecast as the difference between a downstream control point or reservoir’s Cumulative Local/Hydrologic Inflow Forecast and the upstream control point's forecasted cumulative local inflow that is routed downstream through the intervening reaches on that timestep.
There are no slots specifically associated with this method. The Cumulative Local Inflow slots on control points and the Cumulative Hydrologic Inflow slots on reservoirs as well as the routing method(s) in the intervening reach(es) will be accessed during the calculation. Method execution occurs at the beginning of a timestep for all enabled subbasins with the method selected.
Note:  This method does not support the case where there is a routing reach directly below a confluence. Instead, insert a control point below the confluence, above the reach.
Solution Algorithm
Check Method Selections
First the selected method will be initialized and the subbasins will be checked for errors. The Compute Forecast Period Incremental Local Inflows method will first check that every control point and reservoir in the subbasin has a forecasting method selected. All control points and reservoirs in the subbasin must have a forecasting method selected to execute the Compute Forecast Period Incremental Local Inflows method. If some of the objects have a forecasting method selected and some do not an error message is posted. The error message will state that all objects in the subbasin must either do forecasting or none of them may. If all of the reservoirs and control points in the subbasin have a forecasting method selected then the Compute Forecast Period Incremental Local Inflows must be executed.
The algorithm is very similar to the algorithm for the existing Compute Full Run Incremental Local Inflows method except it will execute on each timestep and compute forecasted incremental inflows throughout the forecast period. Following is a description of the steps this method executes. See “Solution Steps” for more information, as the steps taken there are similar.
Group Pairs
The Compute Forecast Period Incremental Local Inflows method computes the forecasted incremental flows and sets the Local Inflow slot by looping through all pairs of objects in subbasin. It first groups all reservoirs, control points and confluences into {upstream, downstream} pairs and then process all {Control Point, D} pairs, next all {Reservoir, D} pairs and finally all {Confluence, D} pairs.
Note:  If a reservoir is a headwater reservoir (or has no upstream objects on which the flow is cumulative), the reservoir will not get processed as it is never the downstream object in a pair. In this case, it is advisable to create a separate computational subbasin of all headwater reservoirs and select the “Reservoirs Only” method on the subbasin. See “Reservoirs Only” for details on this method.
Compute over Forecast Period
Instead of computing incremental values for the entire range of values in the Cumulative Local Inflow slot, the computation will be done only for the current timestep and the remaining timesteps in the forecast period.
Calculate Forecasted Cumulative Local Inflow (Reservoirs and Control Points upstream)
For the {Control Point, D} pairs and {Reservoir, D} pairs, the Compute Forecast Period Incremental Local Inflows method will call to the forecasting methods to calculate and set the slot Forecasted Cumulative Local/Hydrologic Inflow. Before calling to the forecasting method on the reservoir or control point, the method will first set the boolean argument calledFromSubbasin to TRUE. This will tell the forecasting method to recesses values of the Cumulative Local Inflow and set the Forecasted Cumulative Local/Hydrologic Inflow slot.
Route Forecasted Cumulative Local Inflow (Reservoirs and Control Points upstream)
Next, the Forecasted Cumulative Local/Hydrologic Inflow from the upstream object will be routed downstream through the intervening reaches resulting in an array of routed Forecasted Cumulative Local/Hydrologic Inflows. This step is analogous to the step in the existing Compute Full Run Incremental Local Inflows method that routes the Cumulative Local Inflow downstream.
Compute Forecasted Incremental Local Inflow (Reservoirs and Control Points upstream)
Next, the routed forecasted cumulative local/hydrologic inflow from the upstream object is subtracted from the Forecasted Cumulative Local/Hydrologic Inflow of the downstream object. This value is then entered in the Local Inflow slot (Hydrologic Inflow Forecast slot on the reservoirs if the Geometric Recession or Exponential Recession forecasting method is selected, Hydrologic Inflow slot on the reservoirs if the Coefficient and Exponent method is selected). This step is analogous to the step in the existing Compute Full Run Incremental Local Inflows method that subtracts the routed Cumulative Local Inflow of the upstream object from the Cumulative Local Inflow of the downstream object to set the Incremental Local Inflow slot.
Note:  In this application the Local Inflow slot is NOT set with the input flag, whereas in the non-forecasting method, the Incremental Local Inflow is set with the input flag.
The avoid reproducing code and to work with existing functions set up for the existing Compute Incremental Local Inflows method, an internal utility function, getSlotsForComputeIncrs, is used on the reservoir and the control point. This function return three arguments: upstream slot name, downstream slot name, and target slot. This function checks method selection on the control point or reservoir and sets the three arguments.
For the control point, if a forecasting method is selected and the Compute Forecast Period Incremental Flows method is selected, the getSlotsForComputeIncrs arguments are: Forecasted Cumulative Local Inflow (up), Forecasted Cumulative Local Inflow (down), and Local Inflow (target). If no forecasting method is selected and the Compute Incremental Flows method is selected, the getSlotsForComputeIncrs arguments are: Cumulative Local Inflow (up), Cumulative Local Inflow (down), and Incremental Local Inflow (target).
For the reservoir, if the Geometric Recession or Exponential Recession forecasting method is selected and the Compute Forecast Period Incremental Flows method is selected, the getSlotsForComputeIncrs arguments are as follows:
Forecasted Cumulative Local/Hydrologic Inflow (up), Forecasted Cumulative Hydrologic Inflow (down), and Hydrologic Inflow Forecast (target). If the Coefficient and Exponent forecasting method is selected and the Compute Incremental Flows method is selected, the getSlotsForComputeIncrs arguments are: Forecasted Cumulative Local/Hydrologic Inflow (up), Forecasted Cumulative Hydrologic Inflow (down), and Hydrologic Inflow (target). If no forecasting method is selected and the Compute Full Run Incremental Flows method is selected, the getSlotsForComputeIncrs arguments are: Cumulative Hydrologic Inflow (up), Cumulative Hydrologic Inflow (down), and Incremental Hydrologic Inflow (target).
Process the Confluences
The algorithm for {Confluence, D} pairs is similar to the existing Compute Incremental Local Inflows algorithm. Instead of storing the routed Cumulative Local Inflow in the Temp Routed 1 or 2 slots on the confluence, this method will store the routed forecasted cumulative local inflow in the Routed 1 or 2 slots on the confluence. These two slots will then be summed as in the existing algorithm to calculate and set the Routed Outflow.
Reservoir Boundary for Incrementals
The Reservoir Boundary for Incrementals category on the computational subbasin is instantiated when one of the Incremental Local Inflows category methods are selected. The selected Reservoir Boundary for Incrementals method establishes whether the computation of incremental local inflows should stop at reservoirs or continue through reservoirs.
* Stop at Reservoirs
This method is the default for the Reservoir Boundary for Incrementals category and should be selected when cumulative local inflow data is cumulative only until a reservoir is reached in a river system. When this method is selected the computation of incremental local inflows will stop at a reservoir and begin again below the reservoir. Between a reservoir and a downstream control point there will be no subtraction of cumulative local inflows to determine the incremental flow at the downstream control point. It is assumed that the cumulative local inflow data is also the incremental local inflow data for the first control point downstream of a reservoir in a subbasin.
* Continue Through Reservoirs
This method should be selected when cumulative local inflow data is cumulative throughout the entire river system including reservoirs. When this method is selected the computation of incremental local inflows will continue through reservoirs. Between a reservoir and a downstream control point the reservoir’s routed cumulative local inflow will be subtracted from the control point’s cumulative local inflow to determine the incremental local inflow at the downstream control point.
* Ignore Reservoirs
This method should be selected when cumulative local inflow data is cumulative throughout the entire subbasin but reservoir are not included, i.e. the reservoirs do not have any cumulative or incremental hydrologic inflows. When this method is selected, reservoirs do not need to be included in the subbasin and should not have an incremental flow method selected. If the reservoir is in the subbasin and has an incremental flow method selected, an error will be issued that method selection is inconsistent. When the incremental flow calculation is processing pairs of objects, it will skip the reservoir and find the next downstream object (either a control point or confluence).
* Reservoirs Only
This method, available only when the Compute Forecast Period Incremental Local Inflows method is selected, should be selected when the user wishes 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. Typically, the user would set up one subbasin containing all of the headwater reservoirs and other reservoir for which this applies. When the subbasin executes the Compute Forecast Period Incremental Local Inflows method, the Cumulative Hydrologic Inflow is forecasted into the Forecasted Cumulative Hydrologic Inflow and then copied to the Hydrologic Inflow Forecast slot.
Control Point Variable Routing Coefficients
This category is used to compute a set of control point Routing Coefficients based on the previous flows in the system. The category is dependent on having the Operating Level Balancing selected in the Flood Control category.
* None
This method is the default for the Control Point Variable Routing Coefficients category and should be selected when a calculation of routing coefficients is not desired. There are no slots specifically associated with this method.
* Compute Aggregate Coefficients
The Compute Aggregate Coefficients method allows the user to recalculate the Control Point routing coefficients based on flow in the reaches between the Control Point and its associated Reservoirs. There are no slots specifically associated with this method.
This method executes at the beginning of the timestep to recalculate routing coefficients for member Control Points based on the existing flows throughout the subbasin. It does the following:
ForEach Control Point in the computational subbasin:
ForEach Reservoir in the Upstream Reservoir list slot:
ForEach Reach between the current CP and the upstream reservoir, get the
previous timestep’s Inflow.
On the Reach.Variable Lag Coefficients slot, look-up the previous
Inflow on the column map to select the appropriate column of
coefficients to use. Store the column number for use below.
EndFor
When the “Compute Aggregate Coefficient” control point method is selected, if
the looked-up column for the Inflow on each Reach is the 0th column
On the CP, copy the values from the Routing Coefficients to the
Computed Routing Coefficients. The standard values will be used.
Else, recalculate the coefficients as follows (This is used for each timestep
when the “Compute Aggregate Coeffs every Timestep” control point method is
selected):
Starting at the upper most reach, route a unit Inflow (i.e. 1.0 cms)
through the reaches. Each reach must use the set of coefficients
determined from the inflow. Any unknown inflows are assumed to be 0.0.
The set of outflows at the lowest reach represents the coefficients.
Set the Computed Routing Coefficients table slot for the
appropriate reservoir
EndFor, Move on to next Reservoir in upstream list and repeat
EndFor, Move on to next Control Point in the subbasin and repeat
In this algorithm, the Inflow represents the flow for the previous timestep including previous surcharge forecasts, previous Flood Control releases, previous hydropower and any local flows.
See “Compute Aggregate Coefficients” for details on the required Control Point methods. See “Variable Step Response” and “Variable Step Coefficients” for details on the required reach methods. See “Alternative Routing Coefficients Methods” in USACE‑SWD Modeling Techniques for details on using this method for USACE-SWD models.
Initialize Flow Slots for Routing
This category contains methods that are used to initialize slots that are required to be known for routing to solve at the start timestep. It sets values in these slots at pre-simulation timesteps according to the selected method. There are three methods: the default, no-action None, Backcast Zeros and Backcast Initial Value. No slots are added by any of these methods.
The methods are executed at the beginning of run. When either the Backcast Zeros and Backcast Initial Value are executed, an internal helper method is called that does the work. There are four parts to this helper method:
2. Resize the slots, if necessary, to include the earliest dispatch timestep.
4. Set values on slots, as required.
Following is a detailed description of these steps.
1. Loop through the Computational Subbasin’s objects to identify slots of interest
The helper method considers each simulation object belonging to the Computational Subbasin and creates a list of slots that are required for initialization
The following slots are added if they are not linked to an upstream object, i.e. they are the headwater in the basin.
Note:  The slots consider their linking status to determine if they are headwater object. However, linking the slot to a DataObject, though not truly an upstream object, will cause the slot to be left off the list.
– Aggregate Reach.Inflow
– Confluence.Inflow1
– Confluence.Inflow2
– Control Point.Inflow
– Gage.Inflow
– Inline Power Plant.Inflow
– Reach Inflow
The following slots are added if the slot is linked. In the code, the slot at the downstream end of the link is added to the list of slots. Since the two slots are linked, values will propagate.
– Inline Pump.Outflow
– Pipeline.Outflow
– Reservoir.Outflow
– Reservoir.Seepage (when instantiated)
The following slots are added based on the specified conditions
– Reach.Diversion: added to the list if it is in use (i.e. instantiated by method selection) and linked.
– Reach.Return Flow: added to the list if it is in use and linked.
– Reach.Local Inflow: added to the list if it is in use.
Diagnostics for this specific process exist under Dispatch Management, SimObj.
2. Resize the slots
For each of the slots of interest, the helper method resizes the slots, as necessary, to include the first possible dispatch timestep. The first possible dispatch timestep is unique for each object and is determined as follows:
– Look for the earliest input on the current object and any linked upstream objects. See “Initialization” in Solution Approaches for more information on this algorithm.
– For objects that are a part of a subbasin with either the Backcast Zeros or Backcast Initial Value method selected, the method will look downstream at each Reach object and sum the required number of routing timesteps. For each downstream Reach, the required number of pre-simulation timesteps is as follows:
• No Routing: 0 timesteps
• Step Response, Variable Step Response, Impulse Response routing:
• Time Lag or Variable Time Lag: lag rounded up to the next timestep. (e.g. 36hr lag in a model with a 1 Day timestep means 48 hrs = 2 days or 2 pre-simulation timesteps are required)
If a Reach does not have one of these routing methods selected, an error will be issued and the run will stop. The search is stopped when a reservoir or other object that does not dispatch before the start of the run is met or the downstream most point in the basin is found. The earliest timestep found by this algorithm is the first dispatch timestep for that object.
Note:  This search algorithm is only valid for certain objects. The following objects will return an error if included in the subbasin as they have multiple outflows:
• Bifurcation
• Pipe Junction
Objects not typically on the main channel will not work in the search algorithm.
3. Determine the value to set
The helper method determines the value to use for initialization based on the selected method as described for either the Backcast Zeros or Backcast Initial Value method.
4. Set values on slots
Based on the slot of interest and given the earliest dispatch timestep and an initialization value, a fairly simple algorithm is used to set those values on the slot. For each timestep between the earliest dispatch timestep and the initial timestep (inclusive), if the value on the slot is not valid, it is set to the initialization value. As always, these method will not overwrite any inputs that exist on the slot.
Note:  When initializing Reservoir.Seepage, if the Single Seepage Value method is selected on the reservoir, at the beginning of the run, the Seepage is set equal to the Single Seepage Value if the initial Seepage is not input. Then when the Backcast Initial Value method executes, it will have an initial value that it will then back-cast, no further inputs are required. If the user wishes to Backcast Zeros, they will need to input a 0 on the initial Seepage, otherwise the scalar value will be used for the initial timestep and zeros for all other pre-simulation timesteps. As always, inputs will not be overwritten by these methods.
* None
This is the default, no-action method. This should be selected when the user wishes to explicitly input required initialization values directly onto the flow slots.
* Backcast Zeros
The flow value 0.0 is used to initialize all required pre-simulation values. This should be selected when the user does not wish to input a value for the initial timestep and / or a flow of 0.0 is acceptable for initialization.
* Backcast Initial Value
The earliest known pre-simulation value from the slot is used for initialization. The algorithm begins with the initial timestep and works backwards towards the earliest dispatch timestep. It finds the earliest valid value before encountering an invalid (NaN) value. The found value is returned for initialization. If no invalid value is found, the value at the earliest dispatch timestep is returned (although it will have no effect). If the value at the initial timestep is invalid, an abortive error is issued.
Groundwater Computation
This category is used to specify the setup for linked groundwater modeling in RiverWare, and the role that the computational subbasin plays in this modeling. Currently, the only groundwater model that can be linked with RiverWare is MODFLOW.
* None
This is the default method. There are no slots associated with this method.
* Link to MODFLOW 2000 RIP ET
Note:  RiverWare’s connection with MODFLOW is currently not functional. This method has been disabled and cannot be selected. An error will be posted at model load if this method was previously selected. Contact CADSWES for help.
When this method is selected eight additional categories are made available. These categories contain features that allow the user to dynamically link a RiverWare Model with a MODFLOW 2000 model. See “RiverWare / MODFLOW Connection” for details.For the dynamic link between the programs to work, the user must select a method in certain categories. Following is a list of the available categories and whether the category requires a method selection.
• Reach Stage category - Required method selection
• Reach Gain Loss category - Required method selection
• Groundwater Elevation category - Required method selection
• Groundwater Lateral Flux category - Required method selection
• WaterUser Surface Return Flow category - Optional method selection
• AggDiversion Site Surface Return Flow category - Optional method selection
• Reach Diversion category - Optional method selection
• Reach Local Inflow categories - Optional method selection
Note:  In MODFLOW cells and stream segments are indexed by layer, row, column and/or by segment number. In these eight categories, the user is able to select a method and can designate specific MODFLOW cells/segments as belonging to a simulation object which must be included in the computation subbasin. In cases where multiple cells correspond to the same object, the computational subbasin method will aggregate and disaggregate the cell values to the corresponding object as necessary.
Slots Specific to This Method
None
Reach Stage
This category is dependent on selection of the Link to MODFLOW 2000 RIP ET method in the Groundwater Computation category; see “Link to MODFLOW 2000 RIP ET”. This category should be used in conjunction with the Reach Gain Loss category on which a method other than None should be selected.
* None
This is the default method. There are no slots associated with this method.
* Weighted Interpolation
Note:  RiverWare’s connection with MODFLOW is currently not functional. This method has been disabled and cannot be selected. An error will be posted at model load if this method was previously selected. Contact CADSWES for help.
This method calculates a stage elevation for each of the MODFLOW cells specified by the user in the Reach Stage and GainLoss Map slot. The stage is interpolated from between the Reach.Inflow Stage and Reach.Outflow Stage and is shown in the Reach Stage to MODFLOW slot. The calculated stage, for each cell in the Reach Stage to MODFLOW slot, is transferred to MODFLOW and used in the RIV package calculations. Figure 8.6 shows the interpolation equation. In some cases the river channel may span more than one cell in width, when this occurs the user may chose to set their weights so that all cells along a row will receive the same stage.
Slots Specific to This Method
Reach Stage and GainLoss Map
Type: Table slot
Units: No Units
Description: Maps a MODFLOW cell(s) to a Reach specified on the subbasin
Information: The layer, row, and column of each MODFLOW RIV cell is input by the user and the corresponding Reach object needs to be set as the row title. Interpolation weights corresponding to the Inflow Stage and the Outflow Stage on the Reach also need to be input for each MODFLOW RIV cell. The sum of the Inflow Stage Weigth and Outflow Stage Weight for a single cell should add up to 1.
I/O: Input only
 
 
Layer
Row
Column
Inflow Stage Weight
Outflow Stage Weight
Reach0
1
1
4
0.8
0.2
Reach0
1
2
4
0.5
0.5
Reach1
1
4
6
0.7
0.3
Reach1
1
4
7
0.7
0.3
Reach Stage to MODFLOW
Type: Table Series slot
Units: Length
Description: Interpolated stage (elevation) value for each MODFLOW cell specified in the Reach Stage and GainLoss Map slot. The column labels are automatically defined at the beginning of the run, in MODFLOW initialization. The user unit configuration (m, ft, etc.) selected on this slot must match with the units used in MODFLOW.
Information: Transferred to MODFLOW
I/O: Output only
 
 
Reach1
1,1,4
m
Reach1
1,2,4
m
Reach2
1,8,6
m
Reach2
1,9,7
m
t
553.2
552.7
551.4
550.9
t+1
553.32
552.5
551.7
550.8
t+2
553.27
552.6
551.5
550.9
Figure 8.6  Stage Interpolation Equation
Figure 8.7  Example mapping of MODFLOW cells to reach objects for interpolation and summation
Reach Gain Loss
This category is dependent on selection of the Link to MODFLOW 2000 RIP ET method in the Groundwater Computation category; see “Link to MODFLOW 2000 RIP ET”. This category should be used in conjunction with the “Reach Stage” category on which a method other than “None” should be selected.
* None
This is the default method. There are no slots associated with this method.
* Summation
Note:  RiverWare’s connection with MODFLOW is currently not functional. This method has been disabled and cannot be selected. An error will be posted at model load if this method was previously selected. Contact CADSWES for help.
The river GainLoss for each cell(s) in the Reach Stage and GainLoss Map slot is gathered from MODFLOW and set in the Reach GainLoss from MODFLOW slot. For each Reach, the individual gain/losses will be summed and mapped to the Reach.Total MODFLOW GainLoss slot. Figure 8.8 shows the summation equation.
Slots Specific to This Method
Reach Stage and GainLoss Map
Type: Table slot
Units: No Units
Description: Maps MODFLOW cell(s) to a Reach specified on the subbasin
Information: The layer, row, and column of each MODFLOW RIV cell is input by the user and the corresponding Reach object needs to be set as the row title. The sum of the Inflow Stage Weight and Outflow Stage Weight for a single cell should add up to 1.
I/O: Input only
 
 
Layer
Row
Column
Inflow Stage Weight
Outflow Stage Weight
Reach1
1
1
4
0.8
0.2
Reach1
1
2
4
0.5
0.5
Reach2
1
8
4
0.6
0.4
Reach2
1
9
4
0.3
0.7
Reach GainLoss from MODFLOW
Type: Table Series slot
Units: Flow
Description: Each MODFLOW RIV cell specified in the Reach Stage and GainLoss Map slot contains a river GainLoss value transferred from MODFLOW. The column labels are automatically defined at the beginning of the run, MODFLOW initialization. The user unit configuration (cfs, ft3/day, etc.) selected on this slot must match with the units used in MODFLOW.
Information: Transferred to RiverWare from MODFLOW.
I/O: Output only
Figure 8.8  GainLoss Summation Equation
Groundwater Elevation
This category is dependent on selection of the Link to MODFLOW 2000 RIP ET method in the Groundwater Computation category; see “Link to MODFLOW 2000 RIP ET”. This category should be used in conjunction with the “Groundwater Lateral Flux” category on which a method other than “None” should be selected.
* None
This is the default method. There are no slots associated with this method.
* Weighted Interpolation
Note:  RiverWare’s connection with MODFLOW is currently not functional. This method has been disabled and cannot be selected. An error will be posted at model load if this method was previously selected. Contact CADSWES for help.
This method calculates an head (elevation) for each of the MODFLOW cells specified by the user in the GroundWater Elevation Upstream Map and GroundWater Elevation Downstream Map slots using a weighted interpolation. An individual cell head is interpolated from between two GroundWater object’s heads (elevations) (GroundWater Storage.Elevation) and set in the GroundWater Elevation to MODFLOW slot. The calculated elevation for each cell in the GroundWater Elevation to MODFLOW slot is transferred to MODFLOW. Figure 8.9 shows the interpolation equation. The GroundWater Elevation Upstream Map and GroundWater Elevation Downstream Map slots should contain the same list of MODFLOW cells.
Slots Specific to This Method
GroundWater Elevation Upstream Map
Type: Table slot
Units: No Units
Description: Maps a MODFLOW cell to a GroundWater Storage object specified on the subbasin
Information: The layer, row, and column of each MODFLOW GHB cell is input by the user and the corresponding upstream GroundWater Storage object needs to be set as the row title. Interpolation weights corresponding to the upstream GroundWater Storage object also need to be input. The sum of the Upstream Elevation Weight and Downstream Elevation Weight for a single cell should add up to 1.
I/O: Input only
 
 
Layer
Row
Column
Upstream Elevation Weight
GW 1
1
1
1
0.7
GW 1
1
2
1
0.5
GW 2
1
6
1
0.4
GW 2
1
7
1
0.2
GroundWater Elevation Downstream Map
Type: Table slot
Units: No Units
Description: Maps a MODFLOW cell to a GroundWater Storage object specified on the subbasin
Information: The layer, row, and column of each MODFLOW GHB cell is input by the user and the corresponding downstream GroundWater Storage object needs to be set as the row title. Interpolation weights corresponding to the downstream GroundWater Storage object also need to be input. The sum of the Upstream Elevation Weight and Downstream Elevation Weight for a single cell should add up to 1.
I/O: Input only
 
 
Layer
Row
Column
Downstream Elevation Weight
GW 1
1
1
1
0.3
GW 1
1
2
1
0.5
GW 2
1
6
1
0.6
GW 2
1
7
1
0.8
GroundWater Elevation to MODFLOW
Type: Table Series slot
Units: Length
Description: Interpolated elevation (head) value for each MODFLOW cell as specified in the GroundWater Elevation Upstream Map and GroundWater Elevation Downstream Map slots. Value for each corresponding MODFLOW cell is interpolated between the Upstream and Downstream GroundWater objects. The column labels are automatically defined at the beginning of the run, in MODFLOW initialization. The user unit configuration (m, ft, etc.) selected on this slot must match with the units used in MODFLOW.
Information: Transferred to MODFLOW
I/O: Output only
Figure 8.9  Groundwater elevation head interpolation calculation
Figure 8.10  Example mapping of MODFLOW cells to groundwater storage objects for interpolation and summation
Groundwater Lateral Flux
This category is dependent on selection of the Link to MODFLOW 2000 RIP ET method in the Groundwater Computation category; see “Link to MODFLOW 2000 RIP ET”. This category should be used in conjunction with the “Groundwater Elevation” category on which a method other than “None” should be selected.
* None
This is the default method. There are no slots associated with this method.
* Summation
Note:  RiverWare’s connection with MODFLOW is currently not functional. This method has been disabled and cannot be selected. An error will be posted at model load if this method was previously selected. Contact CADSWES for help.
This method sums fluxes from the MODFLOW cells and writes the summed values into the RiverWare GroundWater Storage object. The GainLoss for each cell in the GroundWater Lateral Flux Map slot is gathered from MODFLOW and set in the GroundWater Lateral Flux from MODFLOW slot. For each GroundWater object the individual lateral fluxes will be summed and mapped to the GroundWater Storage.Lateral Flux from MODFLOW. Figure 8.11 shows the summation equation.
Slots Specific to This Method
GroundWater Lateral Flux Map
Type: Table slot
Units: No Units
Description: Maps a MODFLOW cell to a GroundWater Storage object specified on the subbasin
Information: The layer, row, and column of each MODFLOW GHB cell is input by the user and the corresponding GroundWater object needs to be set as the row title.
I/O: Input only
 
 
Layer
Row
Column
GW 1
1
1
1
GW 1
1
2
1
GW 1
1
3
1
GW 2
1
4
1
GW 2
1
5
1
GW 2
1
6
1
GW 2
1
7
1
GroundWater Lateral Flux from MODFLOW
Type: Table Series slot
Units: Flow
Description: Each MODFLOW GHB cell specified in the GroundWater Lateral Flux Map slot will contain a Lateral Flux value transferred to RiverWare from MODFLOW. The column labels are automatically defined at the beginning of the run, in MODFLOW initialization. The user unit configuration (cfs, ft3/day, etc.) selected on this slot must match with the units used in MODFLOW.
Information: Transferred to RiverWare from MODFLOW
I/O: Output only
Figure 8.11  Lateral flux summation equation
WaterUser Surface Return Flow
This category is dependent on selection of the Link to MODFLOW 2000 RIP ET method in the Groundwater Computation category; see “Link to MODFLOW 2000 RIP ET”.
* None
This is the default method. There are no slots associated with this method.
* One to One Exchange
Note:  RiverWare’s connection with MODFLOW is currently not functional. This method has been disabled and cannot be selected. An error will be posted at model load if this method was previously selected. Contact CADSWES for help.
This method maps the Water User. Surface Return Flow to MODFLOW slot value to the WaterUser Surface Return Flow to MODFLOW slot for each corresponding segment designated in the WaterUser Surface Return Flow Map slot. The surface return flow values in the WaterUser Surface Return Flow to MODFLOW slot are transferred to MODFLOW and assigned as inflow into the specified segment.
Slots Specific to This Method
WaterUser Surface Return Flow Map
Type: Table slot
Units: No Units
Description: Maps a MODFLOW STR or SFR segment to a Water User object specified on the subbasin
Information: The segment number of each MODFLOW STR or SFR segment receiving a surface return flow is input by the user and the corresponding Water User object needs to be set as the row title.
I/O: Input only
 
 
Segment
WaterUser1
2
WaterUser2
13
WaterUser Surface Return Flow to MODFLOW
Type: Table Series slot
Units: Flow
Description: Surface water return flow to each MODFLOW segment specified in the WaterUser Surface Return Flow Map slot. The column labels are automatically defined at the beginning of the run, MODFLOW initialization. The user unit configuration (cfs, ft3/day, etc.) selected on this slot must match with the units used in MODFLOW.
Information: Transferred to MODFLOW
I/O: Output only
AggDiversion Site Surface Return Flow
This category is dependent on selection of the Link to MODFLOW 2000 RIP ET method in the Groundwater Computation category; see “Link to MODFLOW 2000 RIP ET”.
* None
This is the default method. There are no slots associated with this method.
* One to One Exchange
Note:  RiverWare’s connection with MODFLOW is currently not functional. This method has been disabled and cannot be selected. An error will be posted at model load if this method was previously selected. Contact CADSWES for help.
This method maps the AggDiversion Site.Total Surface Return Flow slot value to the Agg Diversion Site Surface Return Flow to MODFLOW slot for each corresponding segment designated in the Agg Diversion Site Surface Return Flow Map slot. The surface return flow values in the Agg Diversion Site Surface Return Flow to MODFLOW slot will be transferred to MODFLOW and assigned as inflow into the specified segment.
Slots Specific to This Method
Agg Diversion Site Surface Return Flow Map
Type: Table slot
Units: No Units
Description: Maps a MODFLOW STR or SFR segment to a AggDiversion Site object specified on the subbasin
Information: The segment number of each MODFLOW STR or SFR segment receiving a surface return flow is input by the user and the corresponding AggDiversion Site object needs to be set as the row title.
I/O: Input only
 
 
Segment
AggDiversion0
11
AggDiversion1
15
Agg Diversion Site Surface Return Flow to MODFLOW
Type: Table Series slot
Units: Flow
Description: Surface water return flow to each MODFLOW segment specified in the Agg Diversion Site Surface Return Flow Map slot. The column labels are automatically defined at the beginning of the run, in MODFLOW initialization.The user unit configuration (cfs, ft3/day, etc.) selected on this slot must match with the units used in MODFLOW.
Information: Transferred to MODFLOW
I/O: Output only
Reach Diversion
This category is dependent on selection of the Link to MODFLOW 2000 RIP ET method in the Groundwater Computation category; see “Link to MODFLOW 2000 RIP ET”.
* None
This is the default method. There are no slots associated with this method.
* One to One Exchange
Note:  RiverWare’s connection with MODFLOW is currently not functional. This method has been disabled and cannot be selected. An error will be posted at model load if this method was previously selected. Contact CADSWES for help.
This method maps the Reach.Diverion slot value to the Reach Diversion to MODFLOW slot for each corresponding segment designated in the Reach Diversion Map slot. The diverted flow value(s) in the Reach Diversion to MODFLOW slot are transferred to MODFLOW and assigned as inflow into the specified segment(s).
Slots Specific to This Method
Reach Diversion Map
Type: Table slot
Units: No Units
Description: Maps a MODFLOW STR or SFR segment to a Reach object specified on the subbasin
Information: The segment number of each MODFLOW STR or SFR segment receiving a diversion inflow is input by the user and the corresponding Reach object needs to be set as the row title.
I/O: Input only
 
 
Segment
Reach2
5
Reach4
7
Reach Diversion to MODFLOW
Type: Table Series slot
Units: Flow
Description: Diversion value for each MODFLOW segment specified in the Reach Diversion Map slot. The column labels are automatically defined at the beginning of the run, MODFLOW initialization. The user unit configuration (cfs, ft3/day, etc.) selected on this slot must match with the units used in MODFLOW.
Information: Transferred to MODFLOW
I/O: Output only
Reach Local Inflow
This category is dependent on selection of the Link to MODFLOW 2000 RIP ET method in the Groundwater Computation category; see “Link to MODFLOW 2000 RIP ET”.
* None
This is the default method. There are no slots associated with this method.
* One to One Exchange
Note:  RiverWare’s connection with MODFLOW is currently not functional. This method has been disabled and cannot be selected. An error will be posted at model load if this method was previously selected. Contact CADSWES for help.
A drain return flow for each segment specified in the Reach Local Inflow Map slot is gathered from MODFLOW and set in the Reach Local Inflow from MODFLOW slot. The Reach Local Inflow from MODFLOW slot on the subbasin is mapped to the specified Reach.Local Inflow MODFLOW Return slot.
Slots Specific to This Method
Reach Local Inflow Map
Type: Table slot
Units: No Units
Description: Maps a MODFLOW STR or SFR segment to a Reach object specified on the subbasin
Information: The segment number of each MODFLOW STR or SFR segment receiving a diversion inflow is input by the user and the corresponding Reach object needs to be set as the row title.
I/O: Input only
 
 
Segment
Reach1
17
Reach3
18
Reach Local Inflow from MODFLOW
Type: Table Series slot
Units: Flow
Description: Each MODFLOW segment specified in the Reach Local Inflow Map slot contains a local inflow (return flow) transferred from MODFLOW to RiverWare. The column labels are automatically defined at the beginning of the run, MODFLOW initialization. The user unit configuration (cfs, ft3/day, etc.) selected on this slot must match with the units used in MODFLOW.
Information: Transferred to RiverWare from MODFLOW
I/O: Output only
Computational Subbasin Functionality Guide
Following is a description of functionality associated with the Computational Subbasin (and therefore member objects) that spans multiple user methods. Presented is a description, how to define a model, configure objects, and an example case for each of the functionalities. The Computation Subbasin specific categories and methods are described above. Currently, the only functionality described is the RiverWare-MODFLOW connection.
RiverWare / MODFLOW Connection
Note:  RiverWare’s connection with MODFLOW is currently not functional. The methods have been disabled and cannot be selected. An error will be posted at model load if methods were previously selected. Contact CADSWES for help.
A dynamic link between RiverWare and MODFLOW 2000 (Harbaugh et al., 2000) allows the interaction between surface water and shallow groundwater to be incorporated into RiverWare. In RiverWare, the Reach, Water User, Aggregate Diversion Site (AggDiversion Site), and GroundWater Storage (GW) Objects each contain methods that, when selected, allow an object’s data to be exchanged with MODFLOW. Data from these RiverWare objects is used as input into the MODFLOW General Head Boundary (GHB), River (RIV), Streamflow-Routing (STR), and updated Stream Flow Routing (SFR) packages. In the model setup, the user specifies the RiverWare objects and MODFLOW cell(s) or segment(s) involved in data exchange using the Computational Subbasin object. The Computational Subbasin displays cell by cell values for exchanged data. The MODFLOW 2000 executable provided with RiverWare includes one non-standard MODFLOW package Riparian Evapotranspiration (RIP-ET) (Maddock and Baird, 2003). While no data is exchanged between the RIP-ET package and RiverWare, this package is incorporated since it is applicable to regions where interaction between surface water and groundwater is highly active. This section describes how to set up a RiverWare-MODFLOW linked model.
How a Dynamic Link Between RiverWare and MODFLOW Works
During a run in which RiverWare and MODFLOW are linked, the two models run in parallel, exchanging data at each timestep (the RiverWare timestep must match the MODFLOW stress period). To accomplish this interaction, when the user initiates a RiverWare-MODFLOW run RiverWare starts up a separate “MODFLOW server” process to perform the MODFLOW simulation. This executable is distributed and installed with RiverWare and contains all of the MODFLOW 2000 functionality, as well as the ability to communicate with RiverWare. This communication between RiverWare and the MODFLOW server is accomplished using an Interprocess Communication (IPC) mechanism appropriate for the platform on which RiverWare is running.
In RiverWare, the data exchange is defined and managed through the use of Computational Subbasins. The Computational Subbasin is a collection of objects that also contains methods and data used to define how information is exchanged between the two models. Figure 8.12 is a schematic of the overall data exchange managed by the Computational Subbasin.
Figure 8.12  Interactions among RiverWare objects, computational subbasin, slots, servers, and MODFLOW routines
MODFLOW Library
The MODFLOW algorithms incorporated into the MODFLOW server executable was taken directly from the MODFLOW 2000 source code with some minor modifications. MODFLOW2000 introduced the concept of a process, the computations associated with a particular set of equations. The Parameter Estimation Process requires several MODFLOW “simulations,” and this functionality was achieved by introducing an outermost iteration into the MAIN procedure. A model which uses this process would not fit into the current framework -- RiverWare requires a MODFLOW model that iterates through the stress periods just as RiverWare iterates through timesteps. Thus in the modified MODFLOW subroutines, the parameter estimation loop was removed. Figure 8.17, which is taken from the MODFLOW 2000 documentation, illustrates the main flow of control for the MODFLOW program.
The MODFLOW libraries contained within the RiverWare server includes the following subroutines, several of which are primarily based on MODFLOW’s MAIN procedure. They are listed in the order they will be called by RiverWare.
1. Initialize RiverWare - Beginning of Run behavior
2. Initialize: This creates shared data structures of the appropriate size and reads data that applies to all timesteps.
GLO DF, AL, and RP (DF = Define, AL = Allocate, RP = Read & Prepare)
GWF AL
OBS, SENS, and PES AL
GWF RP
OBS, SEN, and PES RP
PES RW
GWF AL and RP
3. “Begin Timestep” behavior in RiverWare
4. Begin MODFLOW Stress Period: Advance to the next stress period, read the appropriate data from RiverWare. Execute:
GWF ST
RP
5. Set RiverWare data: given data for the current stress period for a set of variables, use these values to override the values set by RiverWare during the “Begin Timestep” behavior.
6. Do MODFLOW Time Step Loop Period: perform the computation and output associated with the remainder of the current stress period. This is the timestep loop which is basically the remainder of the MAIN subroutine:
GWF AD
Iteration Loop
GWF FM
GWF AP
GWF OC, BD, OT
OBS FM
Parameter Sensitivity Loop
Iteration Loop
SEN FM
SEN AP
SEN OT
7. Get RiverWare data: get the MODFLOW values needed by RiverWare for the current timestep. Execute the RiverWare timestep, i.e. alternate between dispatching objects and firing rules as necessary.
8. Continue to the next timestep and repeat starting at Step 3.
Data Exchange Slots
The Reach, GroundWater Storage, Water User and AggDiversion Site objects may all be linked with MODFLOW. Table 8.2 summarizes the data exchanged between the two models. Each RiverWare simulation object that contains exchanged data is listed by object type and slot name. The table indicates if the value shown on the Slot is a single value, a summed value, or an interpolated value (summed or interpolated values indicate that a RiverWare object may be associated with multiple MODFLOW cells). The direction of data exchange is noted and whether the data exchange is mandatory when linking the two models or if the data exchange is a user selectable option.
 
Table 8.2  Data exchanged between RiverWare and MODFLOW
Simulation Object
Slot
From
To
MODFLOW PACKAGE
MODFLOW Variable
Sum, Interpolation, or Single Value
MODFLOW Identifier
Reach
Total MODFLOW GainLoss
MODFLOW
RiverWare
RIV
River
Leakage
SUM
Multiple cells (Layer,Row, Column)
Reach
Inflow Stage and Outflow Stage
RiverWare
MODFLOW
RIV
Stage
Interpolation
Multiple cells (Layer,Row, Column)
GroundWater Storage
Lateral Flux from MODFLOW
MODFLOW
RiverWare
GHB
Head
Dep Bounds
SUM
Multiple cells (Layer,Row, Column)
GroundWater Storage
Previous Elevation
RiverWare
MODFLOW
GHB
Bhead
Interpolation
Multiple cells (Layer,Row, Column)
Reach
Local Inflow
MODFLOW Return
MODFLOW
RiverWare
STR or SFR
Stream Flow Out or Stream Leakage
(Flow Into Stream Reach)
Single Value
Segment #
Water User
Surface Return Flow
RiverWare
MODFLOW
STR or SFR
Flow
Single Value
Segment #
AggDivSite
Total Surface
Return Flow
RiverWare
MODFLOW
STR or SFR
Flow
Single Value
Segment #
Reach
Diversion
RiverWare
MODFLOW
STR or SFR
Flow
Single Value
Segment #
At the beginning of each timestep [t], RiverWare transfers the following variables to MODFLOW; see Table 8.2 for a detailed description.
1. Reach Object: Inflow Stage and Outflow Stage at [t-1] (disaggregated for each MODFLOW cell)
2. Reach Object: Diversion at [t-1] (if Diversion goes to riverside drains or low flow channel)
3. Water User Object: Surface Water Return Flow [t-1]
4. AggDiversion Site Object: Total Surface Water Return Flow [t-1]
5. GroundWater Storage Object: Previous Elevation at [t] (same as Elevation at t-1) (disaggregated for each MODFLOW cell)
After sending this data to MODFLOW, RiverWare waits for MODFLOW to execute its timestep [t]. MODFLOW then sends data to the subbasin which writes values to the following RiverWare slots:
1. Reach Object: Total MODFLOW GainLoss at [t] (aggregated for each object)
2. Reach Object: Local Inflow MODFLOW Return at [t]
3. GroundWater Storage Object: Lateral Flux From MODFLOW [t] (aggregated for each object)
RiverWare then solves for timestep t using these values. Then the controller moves to [t+1].
Note:  The simulation timestep/stress-period size must be the same in RiverWare and MODFLOW.
Configuring RiverWare: Environment Variables and Diagnostics
First, a few environment variables need to be defined. Since MODFLOW is started from RiverWare, an environment variable must be set containing the PATH to the directory containing the MODFLOW.nam file(s).
• In Windows, from the Start menu, select Control Panel, then System, choose the Advanced Tab, then click on the Environment Variable button. Under the User Variables section, select the New button.
• Enter the following:
– Variable Name: RIVERWARE_MODFLOW_DIR
– Variable Path: (enter the path to the folder containing the MODFLOW.nam file(s), e.g. C:\Temp\ModflowModels)
In order to view the MODFLOW diagnostics in RiverWare a second environment variable will need to be set:
– Variable Name: MODFLOW_SERVER_DIAG
– Variable Path: 1 (or any other non-zero value)
• Diagnostics for the MODFLOW servers must also be enabled From the menu bar on the RiverWare Workspace select Utilities, then Diagnostics Manager, then Workspace, in the Show Diagnostics For: section put a check next to ‘Client Server’.
Model Setup
To begin, a MODFLOW model(s) should be created and tested. Some MODFLOW modeling details as they pertain to the MODFLOW RiverWare connection are provided here, but in general, it is assumed that the user already knows how to set up and use a MODFLOW model. In RiverWare, the user must decide how many and the type of objects they need. Since MODFLOW and RiverWare model spatial resolutions may differ, more than one MODFLOW cell can be associated with a RiverWare object. The user must decide what MODFLOW cells are associated with each object. See “Example” for a simple example model.
Input instructions for each object involved in the data exchange are discussed in detail in the following sections. These sections are broken into mandatory and optional data exchange configurations.
Note:  In MODFLOW, the type and number of model cell boundary conditions should not change between stress periods. For example if 10 GHB cells are used in the first stress period the same 10 GHB cells must also be used in all stress periods in the model. This must be true of all boundary conditions in the model regardless if the boundary conditions are those that exchange data with RiverWare.
Computational Subbasin
A computational subbasin is a user configured subbasin that is used to specify a group of objects and the computations that should be performed on those objects. Once the user has set up their RiverWare simulation model, all simulation objects that are to exchange data with MODFLOW must be grouped into subbasins. See “Subbasin Manager” in User Interface for more information on creating subbasins and adding objects to them.
• Create a Computational Subbasin - The subbasin name must correspond to the MODFLOW model’s “.nam” file.
• Add Objects to a Subbasin - All objects that exchange data with MODFLOW must be included in the computational subbasin. Each computational subbasin should connect with only one MODFLOW model.
• Open the subbasin and configure it: The computational subbasin object may be accessed in two ways: by clicking the Open button in the Edit Subbasins dialog, or by selecting Workspace then Open Computational Subbasin from the main RiverWare menu.
The open subbasin dialog has two views: Slots and Methods. The slots view will be empty until a method has been selected. In the Methods view, highlight the Groundwater Computation category and select the Link to MODFLOW 2000 RIP ET method (see “Link to MODFLOW 2000 RIP ET”).
Eight new categories are now available; select the desired methods from these categories:
Each of the eight dependent categories have “None” as the default method. The “None” method has no associated slots and performs no computations. The methods in each of these categories preform different computations but the slot associated with each method are very similar. Each method contains a Map slot and a Data Exchange slot (except the Groundwater Elevation category which contains two Map slots and a Data Exchange slot). For example when the Weighted Interpolation method is selected in the Reach Stage category, the Reach Stage and GainLoss Map slot and the Reach Stage to MODFLOW slot are enabled. The user must supply input for the Reach Stage and GainLoss Map. This slot maps a Reach object’s data to one or more cells in a MODFLOW model. See “User Methods” for details on these categories, methods, and slots.
The user must supply a list of the cells that exchange data with RiverWare. The Reach Stage and GainLoss Map slot contains five columns: Layer, Row, Column, Inflow Stage Weight, and Outflow Stage Weight (see “Reach Stage and GainLoss Map”). The Layer, Row, and Column correspond to the MODFLOW cell identification. The inflow and outflow stage weights are used in the interpolation equation; see “Appendix A: MODFLOW Package Description” for an explanation of the interpolation equation.
Note:  The two weights corresponding to a single cell must add up to 1.
Likely it will be easiest for the user to import data into the Map slots. Imported data may be tab or space-separated. Imported data is assumed to be in the same units as shown in the Edit Slot dialog. The entire precision of an imported value will be preserved, although only the selected display precision is shown.
Note:  Import (Fixed Size) truncates incoming data if the data file contains more rows than the slot, and leaves existing data if the data file contains fewer rows than the slot. Import (Resize) automatically resizes the slot to match incoming data. The data will not be imported if the number of columns in the data does not match the number of columns needed in the slot or the data file contains unnecessary characters. See “File Menu” in User Interface for more information on importing data.
Once the data is entered the user must edit the row labels. The rows should be labeled with the name of the corresponding object. From the slot dialog select View, then Edit Row Labels, highlight one or more rows in the Edit Row Labels dialog and push the Set Label(s) to an Object Name button, this invokes the object selector (initialized with the correct object type and only those objects in the subbasin), and highlight the corresponding object title and hit the Ok button in the object selector dialog. When finished assigning row titles, hit the Ok button in the Edit Row Labels Dialog.
Data must be arranged so that all the cells pertaining to one object appear in contiguous rows. For example the user is not allowed to have rows 0-4 correspond to Reach 0, rows 4-8 correspond to Reach 1, and then row 9 again correspond to Reach 0. Instead the user should have rows 0-5 correspond to Reach 0 and rows 5-9 correspond to Reach 1.
Once the user has set up the Map slots, the Data Exchange slot(s) units must be configured. The units in the Data Exchange slots must be consistent with the units used in MODFLOW model(s). To set the corresponding units, select View, then Configure from the slot menu. Then, set the units for all columns at once:
Units must be set for the following Data Exchange slots the Reach Stage, Reach GainLoss, GroundWater Elevation, GroundWater Lateral Flux, WaterUser Surface Return Flow, Agg Diversion Site Surface Return Flow, Reach Diversion, and Reach Local Inflow when in use.
• Enabling Subbasin: Once the subbasin has been configured, make sure it is enabled. To enable a subbasin select Subbasin, then Enable Subbasin in the open subbasin object.
Note:  The subbasin will not perform any computations if it is not enabled.
Reach Object
In RiverWare a river channel can be represented with a Reach object. When a MODFLOW model is connected with RiverWare the same river channel should be represented using a RIV type boundary condition in MODFLOW. As shown in Table 8.2, some of the data exchanged between the two models is mandatory and some optional. The first subsection below describes mandatory data, this data is necessary for the linked models to run and the user must select and assign values as described. The second subsection describes two optional data exchanges. None, one, or both of the optional exchanges may be assigned on a single Reach.
Mandatory Data Exchange: Reach Configuration
• MODFLOW Link Category: For each Reach that is to transfer data between RiverWare and MODFLOW, the user must select the Link to MODFLOW method in the MODFLOW Link Category Reach (see “Link to MODFLOW”). The MODFLOW Link Category Reach is dependent upon selection of the No Routing, Time Lag, Variable Time Lag, or Muskingum Cunge method in the Routing category. When the Link to MODFLOW method is selected, the Total MODFLOW GainLoss slot becomes available. The MODFLOW RIV boundary condition calculates flow into or out of a cell from an external source in proportion to the difference between the head in the cell and the stage in the river. The value shown in the Total MODFLOW GainLoss slot is the sum of this flux over all the cells associated with a Reach. A negative flux on the Reach.Total MODFLOW GainLoss slot indicates flow out of the river to the aquifer. The user must assign MODFLOW cells to a Reach using the Computational Subbasin structure; see “Reach Gain Loss”.
The MODFLOW Link Category Reach also contains the method No Link to MODFLOW. This method should be selected when the user does not wish to link a Reach with MODFLOW. See “No Link to MODFLOW”.
Note:  A RiverWare model may contain both Reach objects that are linked to MODFLOW and Reach objects that are not linked to MODFLOW
• Stage: A Stage calculation method must be selected in the Stage category; see “Stage”. The MODFLOW RIV boundary condition calculates flow into or out of a cell from an external source in proportion to the difference between the head in the cell and the stage in the river. To calculate this gain/loss between the river and the underlying aquifer, MODFLOW must have a stage value for each corresponding RIV boundary cell. The user must assign an initial inflow and outflow, as well as, initial inflow stage and outflow stage to every Reach that is linked with MODFLOW. All inflow and outflow stages proceeding the initial input will be calculated from the previous timesteps inflow and outflow by RiverWare for each RIV boundary cell and transferred to MODFLOW. The user must assign MODFLOW cells to a Reach from the Computational Subbasin.
Note:  In MODFLOW the user must have the option flag (CBC) entered in Line 2 of the RIV package input file. If this flag is not turned on, space is not allocated for the RIV package in the MODFLOW internal array and RiverWare cannot access the exchanged variables
Optional Data Exchange Reach Configuration
A surface water body (e.g. riverside drain) could be represented in MODFLOW using the STR or SFR packages. When a surface water body is defined in this manner it does not need to be explicitly represented in RiverWare. Flow between this type of MODFLOW surface water body, and a RiverWare Reach is optional. The user may choose to assign a return flow from a MODFLOW surface water body to a RiverWare Reach and/or a diversion from a RiverWare Reach to a MODFLOW surface water body.
Note:  In the MODFLOW STR and SFR package, stream/river/drain networks are assembled using reaches and segments. Reaches are joined together to form segments and all reaches in a segment share the same model properties. A reach can span up to one model cell, while segments can span multiple cells. Segments are numbered sequentially starting with the most upstream segment. The reaches in a segment are also numbered sequentially starting at the most upstream reach. Inflow and outflow along a MODFLOW stream network (STR or SFR) can only occur on the first and last reaches in a segment, respectively (with one exception in the SFR package, see Purdic et al., 2004). This must be considered when the user matches corresponding variables between a RiverWare Reach and a MODFLOW segment. It is suggested that the user create tributary and diversion segments that are to be used only for data exchange with RiverWare.
• Local Inflow: A return flow from a surface water body represented in MODFLOW (e.g. riverside drain) to a RiverWare Reach is optional. This return flow must be diverted from a MODFLOW STR or SFR segment and can be specified as a local inflow into a RiverWare Reach. The user needs to select the Local Inflow MODFLOW Return method in the Local Inflow and Solution Direction category; see “Local Inflow MODFLOW Return”. The slot Local Inflow MODFLOW Return, is associated with this method and displays the value transferred from MODFLOW. The STR or SFR segment in MODFLOW providing the return flow is assigned using the computational subbasin structure. To avoid potential issues with data transfer, one RiverWare Reach is limited to connect with one MODFLOW segment.
Note:  While a Reach that is assigned to receive a MODFLOW return flow may be linked with the MODFLOW RIV package (see Mandatory Data Exchange Reach Configuration) this is not required and the user may set the RiverWare Reach to receive only the Local Inflow MODFLOW Return. When this occurs the Reach.MF GainLoss slot will contain NaNs.
• Diversions: A diversion from a Reach to a surface water body in MODFLOW (e.g. riverside drain) is optional. The method selection for a diversion is the same whether or not the user intends to divert to another RiverWare Object or MODFLOW. The user needs to select a method in the Diversion from Reach category and input a value into the Diversion slot (shown to the right); see “Diversion from Reach”. The diversion from the Reach is assigned as inflow into a MODFLOW STR or SFR segment. The user assigns the MODFLOW segment to receive the inflow using the computational subbasin structure. If no MODFLOW segment is assigned to the diversion, the user may link the Diversion as an inflow into another RiverWare object. Flow may only be diverted from a Reach to one object at a time (e.g. one Reach cannot divert flow to both a MODFLOW segment and a RiverWare Water User).
Note:  A Reach that has a Diversion to MODFLOW assigned may be linked with the MODFLOW RIV package (see Mandatory Data Exchange Reach Configuration) however this is not required and the user may set the Diversion as the only data exchange with MODFLOW. When this occurs the Reach.MF GainLoss slot will contain NaNs.
GroundWaterStorage Object
In a RiverWare-MODFLOW linked model, the GroundWater Storage (GW) object is used to incorporate boundary conditions into the RiverWare model and to manage GW return flows from RiverWare Water Users. Flux between the GW object’s head and head in the MODFLOW aquifer is computed for the lateral MODFLOW boundaries in MODFLOW. In addition to this flux, two other fluxes are calculated in RiverWare and are accounted for in the GW object’s storage equation. The second flux, is the flux between linked GW objects. The third flux, is a head-based flux between a GW object and a low-resolution MODFLOW model. The low resolution MODFLOW model head need to be input by the user into RiverWare using the Head Based Percolation method. As shown in Table 8.2 all data exchanged for the GW object is mandatory.
Note:  In MODFLOW, boundary conditions are a necessary component in the MODFLOW model. Information from a low-resolution regional-scale groundwater model may be interpolated in space and/or time, by the user for inclusion directly in both the RiverWare and MODFLOW models. Along the lateral MODFLOW boundaries in the first layer the user should assign GHB boundary conditions where the elevation from RiverWare GW objects is used as the external source head in the GHB calculations. All other MODFLOW model edge boundaries may be assigned as the user chooses, since they do not require an interaction between RiverWare and MODFLOW and are not discussed in this document.
Mandatory Data Exchange Reach Configuration
• GW Solution Type: The user must select the Link to MODFLOW GW method in the Solution Type (see “Link to MODFLOW GW”), for the GW object to exchange data with MODFLOW. Six slots are associated with the Link to MODFLOW GW method:
– Aquifer Area
– Elevation
– Previous Water Table Elevation
– Inflow from Surface Water
– Specific Yield
– Lateral Flux from MODFLOW
The first five slots are also used by other Solution Type methods; see “Solution Type”. The last slot Lateral Flux from MODFLOW is specific to the Link to MODFLOW GW method. Cells associated with the first boundary type or lateral boundary should be represented in MODFLOW using the GHB boundary condition. The GHB package simulates flow into or out of a cell from an external source in proportion to the difference between the head in the cell and the head assigned to the external source. To calculate this flux, MODFLOW needs an external head value for each GHB boundary cell. The user is required to assign an initial Elevation to every GW object that is linked with MODFLOW. The initial elevation head for each corresponding GHB boundary cell is calculated by interpolating the elevation between two GW objects in RiverWare. The user can assign upstream and downstream GW objects to individual cells using the computational subbasin; see “Groundwater Elevation”. In addition to an initial Elevation, the user is required to assign an Aquifer Area and Specific Yield on each GW object. Optionally, the user may link a GW objects’ Inflow from Surface Water slot with another RiverWare object.
Two other methods are available in the Solution Type, these methods should be selected when the user does not wish to link a GW object with MODFLOW.
Note:  One model may contain both GW objects linked to MODFLOW and GW objects that are not linked to MODFLOW.
Note:  In MODFLOW the user must have the option flag (CBC) entered in Line 2 of the GHB package input file. If this flag is not turned on space is not allocated for the GHB package in the MODFLOW internal array and RiverWare cannot access the exchanged variables.
• Specify Connected Groundwater Objects: The second flux, is the flux between linked GW objects. The user may choose to link a GW object with none, one or two other GW objects. The methods available in the Lateral Link Direction category are: No Connected Groundwater Objects, Upstream, Downstream, and Upstream and Downstream; see “Lateral Link Direction”. When a method other than No Connected Groundwater Objects is selected, the following slots are available: Previous Adjacent Elevation, Conductance, and Groundwater Flow. The user is required to assign a Conductance between the two objects and must link the Previous Adjacent Elevation of one object to the Previous Elevation in the other object. For example if GW1 and GW2 are to be linked and GW1 is the upstream of GW2. Then the Previous Elevation slot on GW1 needs to be linked with the Previous Adjacent Elevation Upstream slot on GW2, and the Previous Elevation Downstream slot on GW1 needs to be linked with the Previous Elevation slot on GW2.
• GW Deep Percolation: The third flux, is a head-based flux between the GW object elevation and a low-resolution MODFLOW model head elevation. This flux can be represented using the Head Based Percolation in the GW Deep Percolation category; see “Head Based Percolation”. The method contains three slots: Percolation, Deep Aquifer Conductance, and Deep Aquifer Elevation. The Deep Aquifer Elevation represents the MODFLOW head elevation (from a low-resolution MODFLOW model) and must be input by the user. The user also needs to input a Deep Aquifer Conductance value for each GW object.
Water User
Linking a Water User object to MODFLOW is optional. The user may link none, some, or all the water user objects in a RiverWare model to MODFLOW.
Optional Data Exchange Water User Configuration
A surface water body (e.g. riverside drain) can be represented in MODFLOW using the STR or SFR packages. When a surface water body is defined in this manner it does not need to be explicitly represented in RiverWare. Flow between this type of MODFLOW surface water body and a RiverWare Water User is optional. The user may choose to assign a surface return flow from a Water User to a surface water body represented in MODFLOW (e.g. riverside drain).
Note:  In the MODFLOW STR and SFR package, stream/river/drain networks are assembled using reaches and segments. Reaches are joined together to form segments and all reaches in a segment share the same model properties. A reach can span up to one model cell, while segments can span multiple cells. Segments are numbered sequentially starting with the most upstream segment. The reaches in a segment are also numbered sequentially starting at the most upstream reach. Inflow into a MODFLOW stream network (STR or SFR) can only occur on the first reach in a segment, respectively (with one exception in the SFR package). This must be considered when the user matches corresponding variables to the Water User. It is suggested that the user create tributary and diversion segments that are to be used only for data exchange with RiverWare.
Surface Return Flow
A surface return flow from a water user to a surface water body in MODFLOW (e.g. riverside drain) is optional. The user needs to select the Link to MODFLOW WU method in the MODFLOW Link Category WU category; see “Link to MODFLOW WU”. The Surface Return Flow is calculated when methods are selected in both the Return Flow and Return Flow Split categories. The Surface Return Flow from the Water User is assigned as inflow into a MODFLOW STR or SFR segment. The user assigns the segment to receive the return flow using the computational subbasin structure. If no MODFLOW segment is assigned, the user may link the surface return flow as an inflow into another RiverWare object. The user may input a value for the Surface Return Flow at the initial timestep if desired, otherwise an initial inflow value of zero will be transferred to MODFLOW for use in the first timestep.
AggDiversion Site
Linking an AggDiversion Site object to MODFLOW is optional. The user may link none, some, or all the AggDiversion Site objects in a RiverWare model to MODFLOW.
Optional Data Exchange AggDiversion Site Configuration
A surface water body (e.g. riverside drain) could be represented in MODFLOW using the STR or SFR packages. When a surface water body is defined in this manner, it does not need to be explicitly represented in RiverWare. Flow between this type of MODFLOW surface water body and a RiverWare AggDiversion Site is optional. The user may choose to assign the surface return flow from a AggDiverson Site to a surface water body represented in MODFLOW (e.g. riverside drain).
Note:  In the MODFLOW STR and SFR packages, stream/river/drain networks are assembled using reaches and segments. Reaches are joined together to form segments and all reaches in a segment share the same model properties. A reach can span up to one model cell, while segments can span multiple cells. Segments are numbered sequentially starting with the most upstream segment. The reaches in a segment are also numbered sequentially starting at the most upstream reach. Inflow into a MODFLOW stream network (STR or SFR) can only occur on the first reach in a segment, respectively (with one exception in the SFR package). This must be considered when the user matches corresponding variables between a RiverWare Water User and a MODFLOW segment. It is suggested that the user create tributary and diversion segments that are to be used only for data exchange with RiverWare.
Total Surface Return Flow
It is optional to link the Total Surface Return Flow from all the Water User elements on an AggDiversion Site as inflow into a surface water body in MODFLOW (e.g. riverside drain). The user needs to select the Sequential Structure as the AggDiversion Site Link Structure and the Link to MODFLOW WU method in the MODFLOW Link Category AggDiv category; see “Link to MODFLOW WU”. The Total Surface Return Flow is calculated as the sum of the individual element’s Surface Return Flow slot. The Total Surface Return Flow on the AggDiversion Site may be assigned as inflow into a MODFLOW STR or SFR segment using the computational subbasin structure. If no MODFLOW segment is assigned the user may link the total surface return flow as an inflow into another RiverWare object. The user may input a value for the Total Surface Return flow at the initial timestep if desired, otherwise an inflow value of zero will be transferred to MODFLOW for use in the first timestep.
Example
A simple example model is shown below. This example does not fully detail the setup of either a MODFLOW or RiverWare model. Instead it highlights the variables exchanged between the two model and shows how the user might match up MODFLOW cells with RiverWare objects.
Figure 8.13 is a schematic of a RiverWare model. Figure 8.14 is a schematic of how one RiverWare model matches up with two MODFLOW models and the variables that are passed between RiverWare and MODFLOW.
Figure 8.13  RiverWare Example Model
Figure 8.14  MODEL Interaction Overview: RiverWare Model with MODFLOW data exchanges
Figure 8.15 is a schematic of how MODFLOW Model A matches up with the RiverWare model. In the MODFLOW model the blue cells represent RIV boundary conditions, green cells represent GHB boundary conditions, and the pink/purple cells indicate STR or SFR boundary conditions. The purple cells indicate the beginning a MODFLOW STR or SFR segment. The blue cells are partitioned into regions by black dividers, these regions represent all the cells corresponding to a given Reach and each region is labeled with the Reach name. The variables exchanged between the Reach and the blue cells are river Stage, as an elevation, and MF GainLoss (see Table 8.3). For each RiverWare Reach, the Stage (interpolation) and MF GainLoss (summation) equations use the same MODFLOW cell to Reach correspondence. The division between GW objects is slightly more complicated than for the Reach, only one GW object is needed for summation of the “Lateral Flux from MODFLOW” from each cell, while two GW objects are needed to interpolate a GW head “Elevation” for each cell. The green cells (GHB) between the black dividers are summed to obtain the “Lateral Flux from MODFLOW” for the indicated RiverWare GW object. “Elevation” heads are interpolated for all green cells (GHB) between the gray dividers.
Figure 8.15  MODEL Interaction Overview: MODFLOW Grid with RiverWare object affiliations shown
• Green = GHB - Model Boundary
• Blue = RIV - Main River Channel
• Pink/Purple = STR - Riverside Drains, Purple indicates the first reach in a segment the segment number is shown
• White = Cells not associated with the GHB, RIV, or STR packages - cells that will that will not communicate with RiverWare.
Figure 8.14 shows the flow between a surface water body in MODFLOW and a surface water body in RiverWare. Figure 8.15 shows the same flows as corresponding to either the first (purple) or last reach in a MODFLOW segment.
All objects corresponding to MODFLOW Model A are grouped into a subbasin named ModelA, those associated with MODFLOW Model B are grouped into a subbasin named ModelB.
 
Subbasin name: ModelA
 
Subbasin name: ModelB
 
Reach 0
Reach 3
Reach 1
Reach 4
Reach 2
GW 10
GW 0
Water User 2
GW 1
 
GW 2
 
GW 3
 
GW 4
 
GW 5
 
GW 6
 
GW 7
 
GW 8
 
Water User 0
 
Agg Diversion 0
 
Table 8.3 is for use in the Reach Stage, Weighted Interpolation and Reach Gain Loss, Summation methods; see “Groundwater Computation”. This is used to assign RIV boundary cells to a Reach object. Stage and river GainLoss variables will be communicated between the two models. Inflow and Outflow Stage Weights are used in the interpolation equation. The user will input the layer, row, column, the inflow stage weight and outflow stage weight of each cell. The user will need to define the row heading as the appropriate Reach from one included on the subbasin.
 
Table 8.3  Example Reach Stage and GainLoss Map slot
 
Layer
Row
Column
Inflow Stage Weight
Outflow Stage Weight
Reach0
1
1
4
0.8
0.2
Reach0
1
2
4
0.5
0.5
Reach0
1
2
5
0.5
0.5
Reach0
1
3
5
0.8
0.2
Reach0
1
3
6
0.8
0.2
Reach0
1
3
7
0.8
0.2
Reach1
1
4
6
0.7
0.3
Reach1
1
4
7
0.7
0.3
Reach1
1
5
6
0.5
0.5
Reach1
1
5
7
0.5
0.5
Reach1
1
6
7
0.3
0.7
Reach1
1
6
8
0.3
0.7
Reach2
1
7
7
0.9
0.1
Reach2
1
7
8
0.9
0.1
Reach2
1
8
8
0.8
0.2
Reach2
1
9
8
0.5
0.5
Reach2
1
10
8
0.3
0.7
Reach2
1
10
9
0.3
0.7
Reach2
1
10
10
0.3
0.7
Reach2
1
11
9
0.1
0.9
Reach2
1
11
10
0.1
0.9
Table 8.4 is used in the Groundwater Elevation, Weighted Interpolation method to map GHB boundary cells to a GW object; see “Groundwater Computation”. The upstream weight is used in the elevation interpolation equation. The user will input the layer, row, and column of each cell and the upstream elevation weight. The user will also need to define the row heading as the appropriate GW object from one included in the subbasin. This table should contain the same list of cells as the GroundWater Downstream Map
 
Table 8.4  Example GroundWater Elevation Upstream Map slot
 
Layer
Row
Column
Upstream Elevation Weight
GW 0
1
1
1
0.9
GW 0
1
2
1
0.7
GW 0
1
3
1
0.5
GW 0
1
4
1
0.3
GW 0
1
5
1
0.1
GW 1
1
6
1
0.7
GW 1
1
7
1
0.5
GW 1
1
8
1
0.3
GW 2
1
9
1
0.8
GW 2
1
10
1
0.6
GW 2
1
11
1
0.4
GW 2
1
12
1
0.2
GW 5
1
1
20
0.9
GW 5
1
2
20
0.7
GW 5
1
3
20
0.5
GW 5
1
4
20
0.3
GW 5
1
5
20
0.1
GW 6
1
6
20
0.7
GW 6
1
7
20
0.5
GW 6
1
8
20
0.3
GW 7
1
9
20
0.8
GW 7
1
10
20
0.6
GW 7
1
11
20
0.4
GW 7
1
12
20
0.2
Table 8.5 is used in the Groundwater Elevation, Weighted Interpolation method to map GHB boundary cells to a GW object; see “Groundwater Computation”. The downstream weight is used in the elevation interpolation equation. The user will input the layer, row, and column of each cell and the downstream elevation weight. The user will also need to define the row heading as the appropriate GW object from one included in the subbasin. This table should contain the same list of cells as the GroundWater Upstream Map
 
Table 8.5  Example GroundWater Elevation Downstream Map slot
 
Layer
Row
Column
Downstream Elevation Weight
GW 1
1
1
1
0.1
GW 1
1
2
1
0.3
GW 1
1
3
1
0.5
GW 1
1
4
1
0.7
GW 1
1
5
1
0.9
GW 2
1
6
1
0.3
GW 2
1
7
1
0.5
GW 2
1
8
1
0.7
GW 3
1
9
1
0.2
GW3
1
10
1
0.4
GW3
1
11
1
0.6
GW 3
1
12
1
0.8
GW 6
1
1
20
0.1
GW 6
1
2
20
0.3
GW 6
1
3
20
0.5
GW 6
1
4
20
0.7
GW 6
1
5
20
0.9
GW 7
1
6
20
0.3
GW 7
1
7
20
0.5
GW 7
1
8
20
0.7
GW 8
1
9
20
0.2
GW 8
1
10
20
0.4
GW 8
1
11
20
0.6
GW 8
1
12
20
0.8
Table 8.6 is used to map GHB boundary cells to a GW object. The user will input the layer, row, and column for each cell. The user will also need to assign the appropriate GW from one included on the subbasin as the row heading.
 
Table 8.6  Example GroundWater Lateral Flux Map slot for the Groundwater Lateral Flux, Summation Method
 
Layer
Row
Column
GW 0
1
1
1
GW 0
1
2
1
GW 0
1
3
1
GW 1
1
4
1
GW 1
1
5
1
GW 1
1
6
1
GW 1
1
7
1
GW 2
1
8
1
GW 2
1
9
1
GW 3
1
10
1
GW 3
1
11
1
GW 3
1
12
1
GW 5
1
1
20
GW 5
1
2
20
GW 5
1
3
20
GW 5
1
4
20
GW 6
1
5
20
GW 6
1
6
20
GW 6
1
7
20
GW 7
1
8
20
GW 7
1
9
20
GW 8
1
10
20
GW 8
1
11
20
GW 8
1
12
20
 
Table 8.7  Additional slots that exchange data between RiverWare and MODFLOW
Simulation Object
Slot Value Received
MODFLOW Segment
Reach 2
Diversion
4
Water User 0
Surface Return Flow to MODFLOW
2
AggDiversion 0
Total Surface Return Flow
7
Reach 1
Local Inflow from MODFLOW
6
* References
Harbaugh, A.W., Banta, E.R., Hill, M.C. and McDonald, M.G., 2000. MODFLOW-2000, The U.S. Geological Survey Modular Ground-Water Model - User Guide to Modularization Concepts and the Ground-Water Flow Process: U.S. Geological Survey Open File Report 00-92.
Maddock, T. and Baird, K.J, 2003. A Riparian Evapotranspiration Package for MODFLOW-96 and MODFLOW-2000. Department of Hydrology and Water Resources University of Arizona Research Laboratory for Riparian studies, University of Arizona, December 2003.
Prudic, D.E., Konikow, L.F., and Banta, E.R., 2004. A New Streamflow-Routing (SFR1) Package to Simulate Stream-Aquifer Interaction with MODFLOW-2000: U.S. Geological Survey Open File Report 2004-1042.
Appendix A: MODFLOW Package Description
Figure 8.16, which is from the MODFLOW 2000 documentation, illustrates the MODFLOW process.
Note:  A Parameter-Estimation Loop is not performed in the RiverWare-MODFLOW library.
Figure 8.16  MODFLOW Control Flow (from MODFLOW 2000 documentation)
GHB and RIV Packages
The MODFLOW input files are similar for the GHB and RIV packages. Each cell that is designated in the GHB or RIV package is identified by Layer, Row, and Column. The Stage or the Bhead must be assigned in each time-step/period and for each qualifying cell. For example, the Stage parameter in MODFLOW corresponds to the value interpolated for a particular cell from the Inflow and Outflow Stages on the RiverWare Reach. An example of the input items lines in the GHB and RIV package that contain the variables of interest are shown below. The variable of interest is indicated in bold text (in this case the river stage and elevation).
Note:  Data transferred from RiverWare to MODFLOW may not necessarily be directly input into the input file, here the input file configuration is shown to clearly identify the variable of interest.
MODFLOW Input:
GHB Package
Item 4b or Item 6 (Layer Row Column Bhead Cond(fact) [xyz])
RIV Package
Item 4b or Item 6 (Layer Row Column Stage Cond(fact) Rbot [xyz])
Figure 8.17  GHB Package Flux Equation
Figure 8.18  RIV Package Gain/Loss Equation
After the Bhead or Stage are assigned in each time-step/period and for each qualifying cell. The fluxes will be calculated by MODFLOW and transferred to RiverWare. The MODFLOW output files identify the fluxes (gain/loss and lateral flux) as a rate for each specified cell by layer, row, and column. An example of the of the standard formatted MODFLOW output file (.lst) is shown below. The variables of interest are indicated in bold text.
Note:  Data from MODFLOW to be transferred to RiverWare or vice versa may not necessarily be taken directly from the Output file or input directly into the input file, however the configurations for these files shown to clear identify the variable of interests.
MODFLOW Output:
.lst File for GHB
Head Dep Bounds Peroid # Step # (Titles included)
Boundary # Layer # Row # Col # Rate # (Titles included, one row for each boundary cell, Boundary number is sequential order from input file, the Boundary number is not included in the input File)
.lst File for Riv
River Leakage Peroid # Step # (Titles included)
Reach # Layer # Row # Col # Rate # (Titles included, one row for each reach, Reach number is sequential ordering from input file, the Reach number is not included in the input File)
STR and SFR Packages
Inflow into a Segment
The STR or SFR packages in MODFLOW will be used to represent the riverside or interior drains. In these packages the surface return flow from the Water User must be specified as inflow into a segment. Inflow may only be specified into the first reach of a segment. There are two scenarios for inflow entering a segment: a single headwater inflow (there is no other source of flow into the segment) or multiple inflows (tributary inflow). The value entered for Flow (see input description below) in the STR and SFR packages differs slightly.
Note:  The instructions below are meant to define what parameters in MODFLOW will receive a value from RiverWare and are not full input instructions for the STR and SFR packages.
In STR the value entered for Flow can be one of the following
• headwater stream - Flow is the total inflow into the segment
• stream with tributaries - Flow must be -1 to indicate that inflow into the segment is the outflow of one or more tributary segments
• diversion stream - Flow is the total inflow into the segment.
In SFR the value entered for Flow can be one of the following
• headwater stream - Flow is the total inflow into the segment
• stream with tributaries - Flow is additional specified inflow or withdraw from the segment
Note:  This additional flow does not interact with the ground-water system in this segment.
• diversion stream - value entered for Flow is not necessarily a flow quantity, the input changes depending on the diversion option chosen
For both STR and SFR, if the return flow enters a headwater stream segment then the surface return flow can be entered as the Flow value. For STR, if the return flow is in addition to another inflow then a tributary segment must be defined to handle the return flow. The surface return flow can then be entered as the Flow value in the tributary segment. For SFR, if the surface return flow is in addition to another inflow then the surface return flow can be entered as the Flow value in the segment or can be entered as the Flow value in a tributary segment. The surface return flow will be transferred from RiverWare to MODFLOW and input as Flow into the specified segment. The STR and SFR packages input configurations are different. The item/line numbers in the packages that contain the Flow value are shown below. The variable of interest (in this case surface return flow or surface water inflow) and the critical segment identification are indicated in bold text.
MODFLOW Input:
STR Package
Item 4b or Item 6: Layer Row Column Seg Reach Flow Stage Cond(fact) Sbot Stop
Note:  Stage, Sbot, Stop are all elevations
SFR Package
Item 2 (KRCH IRCH JRCH ISEG IREACH RCHLEN)
Item 4b or Item 6a: NSEG ICALC OUTSEG IUPSEG {IPRIOR} {NSTRPTS} FLOW RUNOFF ETSW PPTSW {ROUGHCH} {ROUGHBK} {CDPTH} {FDPTH} {AWDTH} {BWDTH}
Note:  Variables in {brackets} are not always specified in the input file. NSEG=segment #, NSEG is the same as ISEG which is entered in Item 2 and contains the layer, row, and column designation.
Diversion from a Segment
The return flow from a riverside or interior drain can be specified as a diversion in MODFLOW. No leakage can occur along a diversion segment. The diversion options available in each package are described below.
In STR, only one diversion option is available, a specified diversion. A segment must be declared as a diversion segment, the value entered as Flow (see STR input below) is the total flow diverted into the segment from the upstream segment.
Note:  If he Flow value in this segment is greater than the upstream segment outflow then no flow will be diverted. This diversion is removed from the last reach in the segment.
In SFR, there are several diversion options available. All diversions are taken out of the last reach in a segment, expect for the first option below. In the first option flow is diverted by specifying the a negative flow value for Flow in item 4b or 6a. In options 2 through 5 a segment must be declared as a diversion segment, the value entered for Flow changes depending on the option chosen. The diversion option is specified in MODFLOW using the IPRIOR flag.
• Specified diversion, flow diverted using this option is subtracted from the first reach in a segment.
• Specified diversion, flow diverted using this option is subtracted from the last reach in a segment and any remaining flow is routed as tributary inflow at the beginning of the next segment. This diversion option assumes that all flow in the segment can be diverted. IPRIOR = 0.
• Specified diversion, same as second option except, if the specified diversion is greater than flow in the segment then no flow will be diverted. IPRIOR=-1
• A specified fraction of the flow in the segment is diverted. IPRIOR=-2
• All excess flow beyond a given threshold is diverted. IPRIOR=-3
The item/line numbers corresponding to the input and output for the STR and SFR packages in MODFLOW for diversion flow are described below. An example excerpt from the MODFLOW input file and standard formatted output file (.lst) are shown below. Depending on which option is chosen the diversion may be easier to obtain from the input or the output file. For Option 1 the Flow value in item 4b or 6a is the amount diverted. For options 2-5 the value entered for Flow is not necessarily the amount diverted (for more detailed instructions on this value refer to USGS 2004-1042 p.44-45). The flow diverted to the segment can be read more easily from the output file as Flow Into the Stm Rch. The variable of interest (in this case diverted flow) and the critical segment identification are indicated in bold text.
Note:  Data from MODFLOW to be transferred to RiverWare or vice versa may not necessarily be taken directly from the Output file or input directly into the input file, however the configurations for these files shown to clear identify the variable of interests.
MODFLOW Input:
STR Package
Item 4b or Item 6: Layer Row Column Seg Reach Flow Stage Cond Sbot Stop
Note:  Stage, Sbot, Stop are all elevations
SFR Package
Item 2 (KRCH IRCH JRCH ISEG IREACH RCHLEN)
Item 4b or Item 6a: NSEG ICALC OUTSEG IUPSEG {IPRIOR} {NSTRPTS} FLOW RUNOFF ETSW PPTSW {ROUGHCH} {ROUGHBK} {CDPTH} {FDPTH} {AWDTH} {BWDTH}
Note:  Variables in {brackets} are not always specified in the input file
NSEG=segment #, NSEG is the same as ISEG which is entered in Item 2 and contains the layer, row, and column designation.
MODFLOW Output:
.lst File for STR
Stream Flow Out, Time Step #, Stress Peroid #
Layer, Row, Column, Stream-Number, Reach Number, Flow Into Stream Reach, Flow Into Aquifer, Flow out of Stream Reach, Head in Stream (Column Headings)
.lst File for SFR
Stream Leakage Peroid # Step #
Layer, Row, Col, Stream Seg. No., Rch Number, Flow Into Strm. Rch., Flow Into Aquifer, Flow out of Stm. Rch., Ovrlnd. Runoff, Direct Precip, Stream ET, Stream Head, Stream Depth, Stream Width, Streambed Conductnc., Streambed Gradient (Column Headings)
 

1 except when permitted at a control point by means of a flooding exception (method selection) at that control point.

2 with a minimal spread in operating levels

3 By “schedule”, we mean a proposed release for each timestep in the forecast period. Only the first timestep’s release will be simulated after the flood control rule function returns, but the flood control algorithm proposes a schedule for the entire forecast period to attain smoothness in release hydrographs and to respect priorities in the presence of routing.

4 The method determines a reservoir’s excess water, VOL, which is the volume of water in the reservoir at the end of the balance period that is above the balance level of the pass. The goal is to release VOL over the forecast period, but as soon as possible. There is no guarantee that the entire VOL will be released by the end of the balance period.

5 As the reader will see, user-selectable methods, described below, modify the meaning of a “forecast operating level at the end of the balance period”. For the purpose of this discussion, think of it as the forecast storage at the end of the balance period as computed before the flood control method was called, plus any water proposed for release from an upstream reservoir on a prior pass and arriving for storage within the balance period, minus water proposed for release within the balance period on any prior pass. Methods that modify its meaning include Operating Level Mapping, Tandem Balancing, Modify Inputs to Two-Reservoir Midpoint, Tandem Storage Management, Tandem Storage Considered.

Revised: 06/03/2019