The Confluence Water Resources Planning Model

Confluence: Specifying the Base Case

We begin with a 'blank slate', a starter system schematic with a single demand node.

Base Case Schematic

We then add demand nodes, supplies, reservoirs, treatment plants, transmission links, etc. to represent the base case system.The schematic can be simple or complex, depending on the system being modeled, and can be edited simply by clicking and dragging icons. It is the gateway to viewing and editing the data underlying any system component.

Defining System Components

Double-clicking on any supply source, reservoir, treatment plant or demand node reveals a data form on which the attributes of that system component can be viewed and edited. The 'base data' form at the right shows the baseline definition of a river diversion, including its current capacity, cost characteristics, and various operating rules.

Shadow Prices

In any time step (e.g. daily or monthly), Confluence will dispatch available supplies to meet demands subject to a variety of user-specified constraints, such as source and transmission capacities, water rights, available streamflow, annual volume limitations, seasonal operating patterns, etc. Once these constraints are met, the order in which supplies are used is governed by shadow prices. The user assigns each supply source a shadow price, and it is this value, added to any treatment and/or pumping costs that the water produced by the source must incur, that determines the value of that source in the model's economic dispatch.

Reservoir Rule Curves

Each reservoir is divided into zones by a set of user-defined rule curves. Each zone is assigned a shadow price, which then govern how the reservoir is drawn down and how it is used relative to other supplies.

Transmission Linkages

The user then specifies the bi-directional capacities, pumping costs, losses, and other attributes of the transmission linkages along which water will be conveyed.

Demands

The next step is to describe future demands. Confluence provides considerable flexibility here, recognizing the many ways in which water utilities develop demand forecast. On this form, you point to named series of growth rates or monthly distributions that you define. (The use of pointers is key to maximizing the usability and precision of Confluence.)

Elsewhere, you can define the relationship between daily demand and weather over an historical record of any duration.

Conservation

You can also lay out a menu of conservation programs that includes an unlimited number of elements, with virtually unlimited flexibility in how each program's savings, participation rates and costs vary over time. These programs can be turned on or off in whole or in part to easily test their impacts on resource strategies.

Defining the Simulation

Once the system configuration and demands have been defined, it is time to spell out the details of the simulation itself, including:

The forecast period covered by the simulation.

The method to be used to sample from historical records of streamflows and weather, and the locations of the files in which this historical data is stored.

The time step of the simulation (daily or monthly). To maximize analytical efficiency, the time step for different months can be defined independently (for example, daily for peak-season and monthly for rest of year).

Key benchmarks on which outputs should be based, and diagnostic tables to be produced.

Running the Simulation

Now that the base water supply and delivery system and the simulation details have been defined, it is time to run the system simulation. Run times depend on your operating system, the complexity of the water system, and the simulation definition, but are typically very fast.

Outputs

The simulation produces a wide variety of charts and graphs as well as tables which enable detailed system diagnostics. The data underlying any chart or graph is immediately available for export to any other Windows application for additional analysis.