Object Dispatching Patterns

Although a model may solve in many different ways, depending on its inputs and outputs, object types often dispatch in predictable ways. Several patterns of dispatching emerge from this modeling approach.

Two Reservoirs With Tailwater-dependent Energy

Two Reservoirs whose states are interdependent will alternately dispatch until they reach a stable solution. The most common example of this inter-reservoir iteration is an upstream reservoir with an Energy request whose tailwater elevation is dependent on a downstream Reservoir. The Turbine Release to meet the Energy request becomes the Inflow to the lower Reservoir. If Outflow is known, the lower Reservoir solves for a new Pool Elevation, which influences the Tailwater Elevation and Operating Head of the upstream reservoir. The iteration proceeds as follows:

1. The upstream Reservoir starts the iteration by dispatching with Solve given Energy, Inflow and calculating an Outflow required to meet the Energy request. This initial value is based on incomplete tailwater data. The value propagates across a link to the downstream Reservoir.

2. The upstream and downstream Reservoirs iterate with the following steps until they converge:

a. The downstream Reservoir dispatches with Solve given Inflow, Outflow and calculates a new Storage and Pool Elevation based on the Outflow from the upstream Reservoir (Inflow) and its user-input Outflow. This Pool Elevation propagates across a link to the Tailwater Base Value of the upstream Reservoir.

b. The upstream Reservoir dispatches with Solve given Energy, Inflow and solves for a new Turbine Release to meet the Energy request based on the backwater effects of the downstream Reservoir (Tailwater Base Elevation) and resulting change to its Operating Head. The Outflow value propagates across a link to the downstream Reservoir.

Bidirectional Canal

The Canal object behaves differently from other objects in RiverWare. Due to instability of three object iterations, the group of objects surrounding a canal must be solved simultaneously. The order of execution is as follows.

1. One of the two Reservoirs dispatches with Solve given Inflow, Outflow.

a. Canal Flow is linked but not known, so the Reservoir sets its current Pool Elevation to the previous timestep’s Pool Elevation and exits the dispatch.

2. The other Reservoir dispatches with Solve given Inflow, Outflow.

a. Canal Flow is linked but not known, so the Reservoir sets its current Pool Elevation to the previous timestep’s Pool Elevation and exits the dispatch.

3. The Canal dispatches with Solve given Elevation 1, Elevation 2, which requires the following known values:

– Elevation 1

– Elevation 2

– Previous Elevation 1

– Previous Elevation 2

4. The Canal then solves a set of up to seven linear equations to determine the flow through the Canal. The flow value, and its inverse, are set on the Flow 1 and Flow 2 slots. These values propagate across links back to the Reservoirs.

5. Both Reservoirs redispatch independently. Since Canal Flow is linked and known, the dispatch can now solve for all of the Reservoir parameters.

See Solve given Elevation 1, Elevation 2 in Objects and Methods for details on the canal dispatch method.

Reach and AggDiversionSite Interaction

Reach objects which are linked to an Aggregate Diversion Site also have a special dispatching order. The amount of flow in the Reach determines the quantity of water available for diversion from the Reach, and the amount actually diverted affects the quantity of Outflow from the Reach. The order of dispatching is as follows.

1. The Reach dispatches with one of two Dispatch Methods because of a known Inflow or Outflow.

a. If Inflow is known, the Dispatch Method is Solve given Inflow, No Routing. If the Diversion slot on the Reach is linked but not known, the Available for Diversion slot is set equal to the Inflow.

b. If Outflow is known, the Dispatch Method is Solve given Outflow, No Routing. If the Diversion slot on the Reach is linked but not known, the Available for Diversion slot is set equal to the user-specified minimum Available for Diversion.

2. The Available for Diversion value propagates across the link to the Aggregate Diversion Site.

3. The Aggregate Diversion Site dispatches with Solve Lumped given Total Diversion Request, Solve Sequential given Total Diversion Requested, or simply propagates values across links, depending on the selected Linking Structure. In all cases, a Total Diversion value is determined for the Aggregate Diversion Site. This value propagates across a link to the Diversion slot on the Reach.

4. The Reach can now redispatch and solve for its Inflow or Outflow.

Revised: 01/05/2024