The preparations needed in a study model may be more extensive than a real-time model depending on the complexity of the model. Although the "observed" data being used plays a role, the relevant aspects are the identification of the local inflows and specifying where observed data is required.

Create a Copy of the Network and an Associated Alternative.

Since the changes to your network can be extensive and potentially problematic for your study, we strongly recommend that you create a copy of the network and an associated alternative before making any changes for computing local flows. By making a copy of the study network and using the copy exclusively for the computation of the local inflows, any changes you make to the network for the computation of local flows will not affect the study model.

See Guide for Running a Reservoir Pool Firm Yield Analysis with ResSim for instructions and shortcuts for making the copies of the network and alternative.

Configure the Network for Computing Local Flows

The network changes that should be considered and addressed for a complex study model include:

  • Remove distributed locals. A local Inflow should be identified only at a gage location, where a total (observed) flow is available. More specifically—the only local flows that should be identified in the network are at the headwater junctions and at the interior junctions that represent gage locations for which (observed) total flow data is available.
    Any local flow currently identified at a junction where there is no gage should be deleted. This will include the local flows that represent a fraction of a single local flow hydrograph that has been distributed to two or more junctions; the total local flow should (already) be identified at the appropriate gage location.
    Any headwater junctions (on an ungaged tributary) that used a distributed inflow hydrograph or a basin-weighted multiple of a neighboring basin's inflow hydrograph should be carefully labeled so that it can be assigned a zero-inflow hydrograph in the alternative.
  • Associate an Observed flow with each junction where local flow will be computed and with the outflow junction of each reservoir upstream of a junction where local flow will be computed.
    To address both these points requires two steps. The first step is performed on the reservoir network and is described here. The second step is performed on the alternative and is described later in this section.
    In the network, place a checkmark next to the junction's flow (outflow) variable on the Observed tab of the Junction Editor for all junctions with an entry on the local flow tab and for all reservoir outflow junctions. Hint: the junction outflow is usually the first Flow variable in the list of Variables on the Observed Data tab of the Junction Editor; the associated Location name should be the name of the junction itself.
  • Remove losses from the routing reaches. Seepage losses are already accounted for (hidden) in the observed flow at a gage. If your reaches also remove water due to seepage, it will be "doubly-accounted for" in the computed locals.
  • Remove diversions…unless they are gaged. Like seepage, ungaged diversions are already accounted for in the observed flow at a gage. If you don't want to delete the diversions, set the Diversion Method of each diversion to Constant and set the value to zero. If you have a gaged diversion, set its Diversion Method to Time-Series.
  • If your model has one or more reservoirs with multiple inflow junctions and the inflows are not gaged, reconfigure each reservoir so that:
    • The reservoir has only one inflow junction. This is because there is no way to compute the individual local inflow from each tributary without observed data at each tributary inflow to the pool.
    • The flow from all upstream tributaries is appropriately routed to that single inflow junction. This is because all upstream flow must be routed to the inflow junction in order to compute the local inflow to the pool; the computed inflow to the pool is used as the observed flow at the inflow junction.
  • Verify the routing. With the local inflows farther apart than they may have been in the study network, you should double-check that each routed observed hydrograph from an upstream gage compares well with the observed hydrograph at the next downstream gage. Also, pay attention to the timestep of the observed data. If it does not match the timestep of the study model alternatives, your routing parameters, or even your routing method, may need to be adjusted to properly route the observed flows.

Be sure to save the network when you are done making the necessary change an before you start configuring the alternative.

Prepare the Input Time Series Data

Before configuring the alternative you will need for computing local flows, you should prepare the data you are going to need for those computations. There are two types of data you'll need—the data that represents the "observed" data at a gage and the dummy data that will be over-written by the computed local flows.

The data that represents the observed data at the gages in your watershed will likely fall into one of the following three categories:

  • Actual observed data—this data is the historic gage record of observations that has been cleaned up and verified, a process that involves filling-in missing values, correcting invalid values, and verifying or correcting questionable values. This data also includes the computed data that is generated using the observed data such as flows values from observed stage and reservoir inflows from observed reservoir elevations and releases.
  • Unimpaired or Modified data—this data uses the historic record and adjusts it by adding back in estimates of evaporation losses and diversions. By making these adjustments to the observed data, the modified data can be used to generation the local inflows needed as input for a variety of different operational scenarios. These alternatives often result in the pool elevations that deviate significantly from what was observed which equates to evaporation quantities that did not occur historically. These alternatives may also use diversion demands that do not reflect what occurred historically.
  • Computed or Synthetic data—this data is generated by an external process that is informed by the historic record in order to simulate or estimate potential future hydrology. An example of this type of data would be the flows computed by a climate change model.

Although each of these potential data sets may require that you make specific changes or adjustments to the network and alternative before using them to compute local inflows, but for the most part they are interchangeable if the network is set up as described above. What remains are some data management tasks in preparation for configuring your alternative:

  • Gather the data. If you haven't done so already, assemble the observed data for all the gage locations and reservoirs in the model. This includes, if necessary, computing the inflows to the reservoirs using the reservoir elevation-storage tables and the observed elevations and releases. Both reservoir inflow and outflow will be used as observed data for the computation of the local flows into and below the reservoir.
  • Create a zero flow time series that spans the same time frame as the observed data. This time series will be used as the inflow to the headwater junctions where observed inflow is not available.
  • Create a time series for each local inflow to be computed. For each location where local inflow is to be computed, make a copy of the zero flow time series and name it for its location and parameter. For example, if you will be computing a local flow for the Carmichael junction, give the associated zero flow time series a pathname such as:
    //Carmichael/Flow-Local//1HOUR/Computed/


Configuring the Alternative for Computing Local Flows

Most of the work in configuring the alternative is in mapping (associating) the right data to the right input. To be sure you don't forget a key requirement, implement the following steps carefully and completely.

  • Open the Alternative Editor and select the alternative to be used for computing local flows. This should be the alternative you created when you made a copy of the network.
  • On the Run Control tab, verify that the time step matches the interval of the observed data; it doesn't make much sense to compute hourly inflows from daily data. But be careful here—if the alternative has a different timestep than the observed data, then the network was probably originally configured for that same timestep. Double-check that discrepancy this was addressed during the routing verification step. If not, you may need to go back to the network and adjust the routing parameters to properly route the observed data.
  • On the Operations tab, assign an operation set to each reservoir in your network. Although this may have already been taken care of when you first created the alternative, if you had to re-build one or more reservoirs due to multiple inflows, you may find there are reservoir that need your attention. Note—when your network and alternative are properly configured, the reservoir operations are irrelevant to the computation of local flows. However, if you have a guide-curve-only or an at-site-rules-only operation set at each reservoir, use it instead of the study model's operations; there's no point wasting compute time on downstream or system operations.
  • On the Lookback tab…
    • Set the Lookback Release for one of the outlets of each reservoir to Time-Series and set the rest of the outlets to Constant with a value of 0.0.
    • Set the Lookback Elevation for each reservoir to Time-Series. Since the reservoir operations are irrelevant to the computation of locals, the lookback elevation values should also be irrelevant; however, when you review results, you don't want to confuse yourself with nonsense at the reservoirs so realistic starting elevations should be used.

      If you do not have observed elevation data for a reservoir, set the Lookback Elevation to Constant and set the value to the guide curve elevation for that reservoir.
    • Set the Lookback Diversion of each ungaged diversion to Constant with a value of zero. For each gaged diversion, set the Lookback Diversion to Time-Series.
  • On the Time-Series tab…
    • For each gaged headwater inflow, set the pathname to the observed flow data for that gage.
    • For each ungaged headwater inflow, set the pathname to the generic zero flow time series that you created.
    • For each interior junction where local flow will be computed, set the pathname to the uniquely-named zero flow time series that you created for that location.
    • For each reservoir Lookback Release, set the pathname to the observed reservoir release data.
    • For each reservoir Lookback Elevation, set the pathname to the observed reservoir pool elevation data.
    • For each diversion Lookback Diversion and Input Time Series, set the pathname to the observed flow at the diversion gage.
  • On the Observed Data tab…
    • For each reservoir outflow junction, set its outflow to the pathname of the reservoir's observed release data.
    • For each reservoir inflow junction, set its outflow to the pathname of the reservoir's computed inflow data.
    • For each remaining interior junction where local flow will be computed, set its outflow to the pathname of the associated gage's observed flow data.
    • For each gaged headwater junction, set its outflow to the same pathname you used for the junction's inflow, the observed flow data for that gage.

Configure the OSI

Once your network, alternative, and input data are ready, you can configure the OSI to compute the local flows. Refer to "Configuring the OSI (and Your Alternative) to Compute Local Inflows" for the instructions on configuring the OSI and defining Local Flow OSI Variables.