new manual modsim

8/15/2019 New Manual modsim

1/68

MODSIM:

Decision Support System

for River BasinManagement

Documentation and User Manual

John W. Labadie and Marc L. BaldoDepartment of Civil Engineering

Colorado State University

Roger LarsonU.S Department of the Interior

Bureau of Reclamation

Pacific Northwest Region

May 2000


2/68

1

Table of Contents

Introduction

This Manual

Getting Started in MODSIM

Example Network 1

Solving the Network Example Network 2

MODSIM Overview

Networks Define the System

Hydrologic State

Nodes – River System Locations

Non-Storage Nodes

Demand Nodes

General

Demands at Reservoirs

Return Flows and Groundwater Pumping

Flowthru Demands

Reservoir NodesGeneral

Hydropower

Reservoir Target Contents and Balance Tables

Reservoir Systems, Account Balance Months, and the Bypass Outflow Link

Parent and Child Reservoirs

Links – River System Pathways for Network Flow Distribution

Artificial Nodes and Links

General Flow Links

Natural Flow Links

Storage Ownership Links

Accrual Links

Other Link Types

Network Solution Steps Natural Flow Step

Storage Step

Some Powerful Modeling Constructs in MODSIM

Exchange Limit Link

Reservoir Outflow Link

Rent Pool

Last Fill

Reservoir Target Storage

Flood Control

More on Parent-Child Reservoirs

Relax Accrual

Minimum Flow Demands

The Prineville/Crooked River Example Network

Two Simple Rent Pool Examples

Examples Using Watch Logic and Disconnected Networks

A Perl Script Example – Friant/Kern Project Accounting

MODSIM Menu Bar

File Edit Settings Utility View Window Help


3/68

2

MODSIM Toolbar

Data Editor Details

Non-Storage Node Demand Node Storage Node Link


4/68

3

Introduction

MODSIM is a general-purpose river and reservoir operations simulation model. It was originally developed by Dr.

John Labadie of Colorado State University (CSU) in the mid-1970's and has been used to simulate operations of

river systems throughout the world. Since 1992, an ongoing joint development agreement between CSU and the U.S.

Bureau of Reclamation Pacific Northwest Region has resulted in enhancements to MODSIM that allow the model to

simulate physical operation of reservoirs and water demand with a great deal of flexibility.

MODSIM data sets can be developed for daily, weekly, and monthly time steps. Streamflow routing can be handled

through the use of lag coefficients. There is considerable flexibility in representing consumptive use demands and

flow requirements and their associated water rights, including exchanges. Reservoir operations include target

storage, hydropower, tailwater effects, evaporation, and seepage.

A primary focus of Reclamation's contribution in the joint development effort has been in the accounting of reservoir

storage contract arrangements such as accrual rights, ownership contracts, water service contracts, and rental pool or

water banking. Prioritized reservoir balancing allows the user to fine-tune the distribution of system storage

throughout the simulation season. MODSIM has a Glover equation groundwater model built in the model's code that

has been successfully used in systems with fairly simple unconfined aquifer / river streamflow interactions. Work has

also begun to make a general-purpose linkage between MODSIM and MODFLOW - the USGS groundwater system

simulation model.

The network solution algorithm along with the iteration convergence sequence for return flows and watch logic gives

the model user enormous flexibility to simulate operations of complex river systems. Watch logic is a term to

describe the model's ability to define operational parameter limits for a simulated feature based on simulated results

of another feature in the network. Perl scripts that tailor operation parameters while the model is running go a step

further to allow for the simulation of detailed basin specific conditions. Perl scripts can also be used to customize

model input and output.

This User’s Manual

This manual is an attempt by several MODSIM users to establish a baseline of information about the full range of the

model’s capabilities. Because a rote listing of MODSIM features might overwhelm newer users, and since one of the

best ways to learn a model is to use it, this manual was conceived largely as a set of examples.

It starts with two very simple examples of MODSIM models and a walkthrough of the network solution process for

systems with natural flow priorities. These sections are intended to appeal to the new MODSIM user by presenting

most of the mechanics used in working with the model and providing an introduction to the most fundamental of

MODSIM concepts via a hands-on experience.

The MODSIM Overview section then provides a discussion of most model capabilities and features from a general

point of view.

This is followed by a number of more complex examples, each of which highlight one or more of MODSIM’s

features.

The document concludes with sections on the MODSIM Menu, the MODSIM Toolbar, and Node and Link InputData Spreadsheets.


5/68

4

Getting Started in MODSIM

A set of examples can be used to introduce many of the powerful modeling capabilities of MODSIM and walk

through the process of creating river basin networks.

The user is expected to be comfortable using a Windows environment, including locating files within a directory

structure, and should be able to use an ascii text editor to create and look at data files. The user is also expected to be familiar with basic river basin modeling concepts such as inflows, demands, reservoir target storage, channel

limits, and minimum flows, although no previous exposure to the MODSIM model is assumed.

Example 1 will start with the mechanics of simple network building, attaching data, running the model, and looking

at output while demonstrating how MODSIM handles the most basic features of river system modeling. Further

examples will demonstrate progressively more complex capabilities.

Example Network 1

Some Initial Settings

On the menu bar, click on Settings…Run Type and select Calibration. English units, Monthly time step, and a one-

year run are already set by default, but you can check these at the Settings…Units and Settings…Time Scale menuoptions. For the first example this is all that needs to be set before starting to create the network.

Construct the Network from Nodes and Links

The network building icons are located on the MODSIM toolbar. Click on the blue

circle and then click in three different places on the MODSIM screen to create three non-

storage nodes. Click on the red triangle and then click once in the MODSIM screen to

add a reservoir node to the network. Click on the pink square and then click in two

different places on the MODSIM screen to create two demand nodes.

Now click on the MOVE tool, which allows you to move nodes on the screen from one

place to another. While the MOVE tool is highlighted, click once on a node, move the

mouse, click again, and the node repositions itself to the location of your second click.Use the MOVE tool to arrange the nodes as seen in Figure 1. Don’t worry about the

names yet.

Next add links between the nodes. Click on the LINK tool, and for each link, click first

on the upstream node and then on the downstream node. Each link requires two clicks.

Make all the connections shown in Figure 1.

To remove a node or a link if you make a mistake, click on the DELETE tool and then on each item that is to be

removed. Use the File…Save As menu option to save the network you have created as example1.xy. You now have

the structural framework for a new model, and next you will add data to nodes and links.

Add Data to Nodes and Links

A right click on any node or link will pop up a spreadsheet-type form for entering data. All data forms have a place

to enter names. Open data forms and add names to four nodes as shown in Figure 1. For example, right-click on the

Headwater node, type the name Headwater in the Node Name field, and click on OK to close the data editor. Do the

same for the Reservoir, Demand1, and Demand2.

Now we want to add the following data to the model:

Fi ure 1 – Exam le1


6/68

5

• Headwater – inflow,

• Demand1 – demand and priority,

• Demand2 – demand and priority,

• Reservoir – max, min, and initial storage; target storage and priority; head/area/capacity table.

Pop up the Headwater node data editor. There are three data tabs for non-storage

nodes – Name/Capacities, Import Node Data, and Inflow. The Name/Capacities tabhas just one field – the Description – for a more detailed description of the node if

needed. The Import tab allows a constant annual inflow to be distributed over the

months of the year. The Inflow tab allows the entry of time series inflow data. Our

network is already set up for one year of input data, and you can enter the values in the

Inflow tab as shown in Figure 2.

Pop up the Reservoir data editor. The Name/Capacities tab for a Reservoir provides fields for max, min, and initial

volumes. Enter values as shown in Figure 3. The Reservoir Data tab is where data for target storage is entered.

Type in data as shown in Figure 4. This tab also has the data field for target storage priority – enter 150 in this field.

The tab labeled “Area/Cap./Elev./Hydraulic Cap” is where data that sets up the geometry of the reservoir is entered.

Type in data as shown in Figure 5.

Pop up the data editor for Demand1. The Time Series tab allows entry of demand

data for each time step of the model run. Enter data as shown in Figure 6. Now click

on the Demand Seasonal Distribution tab. This tab has the data field for the demand

priority. Enter a value of 100. Leave the other fields blank.

Edit the data for Demand2 in the same way, but enter values of 50 for all 12 time

steps in the Time Series tab and enter a value of 200 in the Priority field on the

Demand Seasonal Distribution tab.

Figure 5 – Reservoir Geometry

Figure 4 – Res Target Storage

Fi ure 3 – Reservoir Volumes

Fi ure 2 – Headwater Inflow

Figure 6 – Demand1 Time Series


7/68

6

And that is all the data we will need for Example1. Save your work using the File…Save menu option or by clicking

on the Save icon on the toolbar.

Running the Model

When you run a MODSIM model, output can be saved for all nodes and links or for a group of selected nodes and

links. This allows a user to limit the quantity of output for very large networks. Nodes and links can be selected or un-selected one by one using the Select Tool (the arrowhead on the toolbar). Since our example1 is very small,

however, we can easily look at output for the whole network. Output for all nodes and links is provided when either

everything is selected or nothing is. This can be facilitated with the Edit…Select All or Edit…Select None menu

options.

To run the model, use the menu option File…Run MODSIM. Run-time messages are displayed on the Status Bar at

the bottom of the MODSIM window. A history of these messages can be viewed using the CRR icon on the toolbar

to pop up a read-only text window.

Output Files

Six output files are created and stored in the directory where the network xy file is located. Each file has the same

root name as the xy file, and the file extensions are ACC, DEM, FLO, GW, OUT, and RES. These output files arecomma-and-quotes delimited ascii text and can be read by any text editor or imported into spreadsheet programs.

For our simple example, we will want to examine 3 of these files.

DEM – contains information about activity at demand nodes, including the node number, node name (if there is one),

time step date, demand, surface water used to satisfy the demand, groundwater used to satisfy the demand, and total

shortage.

FLO – contains information about link activity, including the link number, link name (if there is one), time step date,

link flow, link loss, and link natural flow. This last data item is only important when a network is using water rights

and distinguishing between natural flow and storage ownership.

RES – contains information about reservoir node activity, including the node number, node name, time step date,

beginning storage, ending storage, target storage, spill, evaporation rate, evaporation loss, seepage, unregulated inflow, upstream release, groundwater activity, downstream release, pump out?, hydropower production, and ending

elevation.

Output Graphs

MODSIM results can be viewed graphically using an external graphing package called TeeChart. To enable using

TeeChart, use the menu option File…Preferences to pop up a list of setting preferences used in MODSIM. Select

Graph Path, and type in the directory location where the TeeChart.exe file is located on your computer.

To look at MODSIM results graphically, highlight the Graph Tool (GRAF) on the toolbar, select a type of graph to

view with the menu option Settings…Graph Type, and then click on the link, reservoir, or demand whose results you

want to see.

Example1 Output

Choose the Demand/Supply/Shortage… graph type and click on Demand1 and Demand2 to pop up the views of their

output. Now set the graph type as Reservoir Storage/Target Storage vs. Time and click on the Reservoir node pop

up this graph. TeeChart windows can be resized so you can look at all of them at one time.

Target storage in the reservoir rises to 9000 AF in May, and there is not enough water to satisfy both of the demands

and also the higher target storage requirement. Since the priority order is Demand1, Reservoir, and then Demand2, it


8/68

7

is Demand2 which suffers a shortage in this month while all the available water is being kept in the Reservoir to try

to minimize the shortage to target storage. In fact, even though the target storage begins to fall in July, Demand2

does not get any more water delivered until September, when the combination of inflows and target storage has left

some water available again.

Variation Runs and Output

We can learn more about MODSIM by making some slight changes in the input data and examining the differences

they create in the model outcome.

First, change the target storage priority to 50, save the model (as example1a), run it again, and re-generate graphs for

the demand and reservoir nodes. This time we see that Demand1 is also shorted, as the now highest priority

Reservoir tries (in vain) to meet the high target storage requirement by keeping all the inflow and releasing nothing

until September when conditions improve.

A common problem for new MODSIM users is an infeasible solution error message. This happens when the network

solver cannot find a solution for the problem in a particular time step, and the model run is brought to a halt. For

example, let’s look at what would happen if we had more flow into our network. Add inflow to the non-storage node

below the Reservoir – 100 AF for each month September through December – perhaps representing imports from

some source outside our small basin. Save the network (as example1b) and re-run the model. An infeasible solutionresults – a detailed message can be seen in the CRR window. In September, Demand1 had a requirement for 200

AF, so the extra inflow could be used there with the result that the Reservoir release would be 100 AF less than in

the previous run. But in October, with no requirement at Demand1 and Demand2 only needing 50 AF, there is no

way the network solver can reach a solution because there’s nowhere for the extra 50 AF to go.

The usual precaution against this problem is to put a “sink” at the bottom of the network.

This is a demand node with a high demand but very low priority which is there to absorb

any “leftover” flow in the network. Add a demand node to the bottom of the network as

shown in Figure 7, call it Sink, enter constant demands of 9999 for each month, and enter

a priority of 4999. Save this network (as example1c) and re-run the model. The network

will now run for the whole year. Notice also that the results for Reservoir storage have

changed with this run. In previous runs without the Sink, whenever the Demands were not

sufficient to draw inflow through the reservoir, water was allowed to remain in thereservoir over and above target storage. Now that there is a Sink at the bottom of the

system, the reservoir will release water above that which is necessary to maintain its target

storage.

Try out different priority and input time series combinations of your own to get

comfortable with the functionality presented so far.

Solving the Network

The network flow algorithm used by MODSIM to simulate water distribution needs to see the river system as a set of linear equations. One of the equations is the objective function, which simply states that for all links in the network,

the sum of the flow in each link multiplied by the cost assigned to the link is some value. The cost assigned to each

link is simply a relative priority number, and algorithm seeks to minimize the objective function value by assigning

flow to the least cost links possible, subject to constraints. Constraints are such things as preservation of mass

balance at each node and over the entire network.

In this network view of things, links contain the data that is important to the solver, and nodes are basically points

Fi ure 7 – Networkwith Sink


9/68

8

between links. In our example network, we have entered all of our data in nodes. We will now see how that data

gets translated into a link structure that can be handed to the network solver. Figure 8 shows the complete network

that would be constructed for Example1, and the values shown represent the problem of the first time step.

In Figure 8, notice the six additional nodes to the right of the network that you created for Example1. STORAGE,

DEMAND, MASSBAL, GW, SPILL, and INFLOW are artificial nodes – added to the system and connected to the

river system nodes and to each other by artificial links. Each of the artificial links in

Figure 8 has a numeric notation representing the link lower bound, upper bound, and cost. Let’s examine each link

individually.

Three artificial links connect any system reservoir with the artificial STORAGE node – evaporation, excess storage,

and target storage. Our network does not have evaporation, so the lower and upper bounds are simply zeros.

Typically though, the upper bound on the link would be calculated as the evaporation rate multiplied by the surface

area calculated from the average of beginning of month storage and target storage. Cost on this link is automatically

very low since evaporation is going to happen no matter what other conditions might be in effect. The excess storagelink has a lower bound of 0 and an upper bound equal to the difference between the target storage and the maximum

storage, or in our case 8000. Cost on this link is an automatic 0, which neither encourages nor penalizes storage

above target. The target storage link lower bound is the minimum storage, the upper bound is the value set by the

user, and the cost is calculated from the priority set by the user via the formula [-50,000 + (10 * Priority)]. A target

storage priority of 150 results in a cost of –48500.

The STORAGE node in turn is connected to the MASSBAL node by a single artificial link whose bounds are a

Fi ure 8 – Artificial Network


10/68

9

summation of the evaporation, excess storage, and target storage link bounds.

Each reservoir also has an artificial link to the artificial SPILL node. The purpose of this structure is to capture

extreme events that would otherwise render the solution infeasible. The bounds and cost on this link are set

automatically with a lower bound of 0, an upper bound high enough to capture any conceivable spill, and an

extremely high cost. The high cost essentially prevents flow from entering this link unless there is literally nowhere

else for it to go. (To try this out yourself, go back to the example1a network and add several thousand AF to some of the inflows on the Headwater node. Notice that this flow seems to disappear from the system once the reservoir fills

up to maximum capacity. This is because without a sink demand node at the bottom of the system to accommodate

the extra inflow, there is nowhere else for the water to go. Look in the .RES output file, and you should see values in

the Spill column.)

The SPILL node is in turn connected to the MASSBAL node with a link whose bounds are a summation of artificial

spill link bounds from all system reservoirs.

Each demand node in the system has an artificial link to the artificial DEMAND node. The lower bounds on these

links are 0, upper bounds are equal to the amount of the demand, and the cost is calculated from the user-set priority

by the same formula used for target storage [-50,000 + (10 * Priority)]. The parameters on the artificial links for

Demand1, Demand2, and Sink are [0, 0, -49000], [0, 50, -48000], and [0, 9999, -10] respectively as shown in Figure

8.

The DEMAND node in turn is connected to the MASSBAL node by a single artificial link whose bounds are a

summation of the upper and lower bounds on all of the individual artificial links from demand nodes to the

DEMAND node.

MASSBAL has inflow links from the STORAGE, DEMAND, and SPILL artificial nodes. It has only one outgoing

link however, which is connected to the artificial INFLOW node. This link has as its upper bound the sum of

carryover storage conditions and all system inflows. In the first timestep of our model, initial storage in the

Reservoir node serves as the carryover storage – 2000 AF – and the inflows total 741 AF. The upper bound on the

MASSBAL-INFLOW link then is 2741. The INFLOW node is in turn connected directly with each reservoir and

inflow point in the system. Links to reservoirs have upper and lower bounds equal to the carryover storage, and links

to inflow points have upper and lower bounds set to the value of the inflows at those locations.

Finally, all of the “non-artificial” links also have upper and lower bounds and costs set by the user, and they

complete the network to be solved.

It is in this way that a river system is formulated into a network problem that can be submitted to the solver. The

solution process is an attempt to find an overall lowest cost path for all flow sources to travel through the network to

the MASSBAL node. Following the example in Figure 8, the least cost link is the evaporation link, but the upper

bound on this link is 0 so we can’t put any flow in it. The next least cost link is the one from Demand1 to

DEMAND, but the upper bound here again is 0. Moving up to the next least cost link brings us to the target storage

link with an upper bound of 2000. So 2000 of the incoming 2741 can go in the target storage link. The link from

Demand2 to DEMAND has the next lowest cost and an upper bound of 50, so 50 AF of the 741 can go to this link.

Finally, the Sink link with a cost of –10 has an upper bound of 9999 which is plenty to accommodate the remaining

691 AF.

More complex river systems obviously require far greater efforts to find the optimal path for all flow sources, but the

process just described serves as a reasonable introduction. A complete discussion of the lagrangian relaxation

algorithm can be found in Appendix A.

The one artificial node that we haven’t yet discussed is the GW (groundwater) node. Example1 does not use

groundwater capabilities. The artificial GW node is treated much like a reservoir but without artificial evaporation

or target storage links, and it can’t spill. It has carryover storage though, and gets artificial links to represent

transactions with return flow and pumping operations.


11/68

10

Finally, a couple of additional notes on the functionality of the Example1 system:

• Note that if the priority on the Sink node is changed to 5000 instead of 4999, the cost becomes the same as the

cost on the excess storage link. Theoretically, each time the model is run an arbitrary choice is made between

the artificial Sink link and the excess storage link. In practice, if you try this, the extra 691 AF will always

follow the excess storage link and end up stored in the reservoir. (Why is this again, and do we need to explain

it here?)• Recognize that flow is assigned to links in a least cost order, but these assignments are constrained spatially by

the ability of the network to physically get flow to those links. If inflow comes in too far downstream in the

network to physically be able to get to some very low cost link, it cannot be assigned to that link and will have to

take a more expensive path.

• Understand the difference between the priority of a system operation and the priority value attached to the

system node. The lower the priority value the more important the operation is, since it translates into a lower

artificial link cost.

Example Network 2

This example will be used to demonstrate the use of links for water

rights, the relationship between link costs and node priorities,loading data from pre-prepared ascii files, channel limits, and

flowthru demands. Start up MODSIM and open the file

example2.xy. This file contains the structure of the new example

and some parameter data, but you will be using a utility to add the

time series data to the nodes. First save the network under a new

name (example2a) to preserve the original file.

This network has 4 demands. Notice that Demands 1, 2, and 3 do

not have a priority value entered with the node data. Right-click on

any link to a demand and look at the Water Rights tab on the data

spreadsheet that pops up. A date is entered in the W.R. Date field.

MODSIM can translate these dates into costs which are used in the

network solution algorithm. To generate the costs, use theUtility…Sort Water Rights menu option. Notice that cost values

are now entered in the link data spreadsheets.

The fourth demand is a Flowthru demand, which MODSIM uses to

model instream flow requirements. Because it does not represent a

consumptive use of water, setting up this kind of demand requires

some additional data. Right click on this node to pop up the data

editor and look at the Demand Node Data tab. Flow which is

delivered to a flowthru demand can be distributed among one to ten

nodes according to fractions of the delivery amount. Notice that in

order to specify a node here it has to have a name. The Flowthru Fractions fields correspond to the above Flowthru

Node fields, and it is important to note that active flowthru fractions do not have to add to one. In other words, you

can, in effect, create flow in your system. This can be dangerous, of course, but the capability can also be usefulwhen crafting certain complex situations. Finally, the Bypass Credit Link should be specified if you want an

offstream flowthru demand to consider flow in the main channel as contributing toward meeting the demand. Notice

that each link is automatically given a name equivalent to its number. You can change the name or leave it as the

link number, but this is what is selected from the Bypass Credit Link pulldown list.

It would be tedious to enter time series data by hand for larger networks and certainly for models with long

simulation periods, so MODSIM has a utility to assist with doing this. Time series data can be developed separately

Fi ure 9 – Exam le 2 Network


12/68

11

and stored in ascii data files for import into a MODSIM model. The ascii files must have root names corresponding

to the names of the node for which they contain data (and names are case sensitive), and file extensions are specific

for the type of data as follows:

• Inflows - ***.inf

• Reservoir Target Storage - ***.trg

• Demands - ***.dem

•

Evaporation Rates - ***.evp

Input data files have been constructed for demands Demand1, Demand2, Demand3, Flowthru, and Sink, for inflows

Headwater and Gain, and for Reservoir target storage. These files are located in the input directory which came with

your MODSIM users manual package. Open one or more of these files with a text editor to examine their format.

They contain no labels and no commas – only numbers. The first data point must correspond to the first date that is

specified in the model date settings. Each value must be separated from all others by at least one space, carriage

return, or tab. It doesn’t matter how many data values are on each line – this is entirely up to the convenience of the

person preparing the data.

Let’s load the data. Under the File…Import menu option, select ADA File. A file selection box pops up. Navigate

to the directory where the data files are stored and select the Headwater.inf file. MODSIM will let you know that

one file has been read successfully. Look at the Inflow tab in the data editor for the Headwater node and you should

see values where there previously were none. This is fine if you only need to add data to a few nodes, but it’s also possible to load data for many nodes at one time. Back under the File…Import option, now select ADA Directory.

Navigate again to the directory where the data files are stored and select any one of the files that need to be imported.

MODSIM will display a message that it has successfully imported multiple files. Any file that is located in this

directory that corresponds to a node in the network gets imported if you use this option. Open the data editors for

the nodes in the example2a network and you will see that data for demands, inflows, and target storage has been

imported.

Save the network and run the model.


13/68

12

MODSIM Overview

MODSIM is a simulation model. A proficient user creates and modifies data sets through a graphical user interface

(GUI) which represents physical features of a river system as a series of nodes and links. Operational parameters are

represented by data fields entered into spreadsheet-like tables associated with the nodes and links. Operation is

simulated for a series of sequential time steps.

MODSIM uses a network flow algorithm as the mechanism to simulate water distribution in the river system. The

river system is represented by a series of linear equations. One of the equations is the objective function, which

simply states that the summation over all links in the network of the flow in each link multiplied by the cost assigned

to the link is some value. The cost assigned to each link is simply a relative priority number. The other equations are

called constraints and include equations that guarantee the preservation of mass balance at each node and over the

entire network. The optimization algorithm minimizes the objective function while meeting all constraints for a

single time step.

Networks Define the Simulation

Data sets, called networks, can be created to simulate operations of a given river/reservoir system in many different

ways. In a very simple representation of a river system, the user can connect local gain nodes, reservoirs, and

demands all in a serial on-stream manner and give each demand and reservoir node a relative priority number. Nodeswith numerically lower priority numbers (less cost) will be satisfied before nodes with higher priority numbers. In

this type of network, reservoir content targets directly compete with demands. Links between nodes can be given a

maximum flow level (upper bounds) and costs to constrain the distribution of flow and simulate a desired operation.

Example 1 has one off-stream demand but is essentially this kind of network.

The model user can alternatively choose to simulate water rights (or some other incremental prioritization of flow) as

a basis for water distribution by placing the demands and/or reservoirs off-stream and connecting these nodes to the

river with links that represent natural or storage rights. Each link that represents a flow right has a priority date which

is translated to a relative cost (priority number). Each water right link can have a maximum flow rate (upper bound)

and, optionally, a seasonal capacity or maximum volume over each year of simulation. Storage contract

arrangements are also represented by links from the river to the demand, and data is entered which specify the

amount of the contract and the particular reservoir account with which the contract is associated.

In each time step simulated, the model iterates a number of times to converge to an optimal solution. Iteration is

required to allow the model to dynamically define things like reservoir evaporation, diversion return flow, watch

logic flows, and instream flow demands. These values are dependent on the solution of the network but are not

established directly through the normal cost distribution network algorithm. During the first iteration, estimates of

these values are made so the network can be solved. After a few additional iterations, the calculated values are

compared with previous iteration values. The iteration process ends when the difference between values in

consecutive iterations is smaller than a defined tolerance.

A network is defined to be run in one of two simulation modes: 1) calibration mode, or 2) management mode. In

calibration mode reservoir targets and demands must be input for each time step of the simulation. This mode of

simulation is convenient for computing local gains to the river system based on observed river flows, diversions, and

reservoir contents. Trial and error is used to select routing coefficients, return flow parameters, evaporation, seepage

rates, etc. which result in local gains and total flow hydrographs that compare well with observed records. Inmanagement mode, these calibrated parameters and the hydrologic state (wet, average, dry) are defined and the

model is used to simulate alternative scenarios.

Hydrologic State

Hydrologic state is an indicator of water availability that can be used to determine river basin operations. The


14/68

13

hydrologic state is represented by an index number between one and three to seven (i.e. any hydrologic state table

must have at least 3 and no more than 7 index levels). The index number is determined at the beginning of each time

step by comparing data for one or more reservoirs to levels defined in a table. Using a monthly time step as an

example, say there are seven indices for each month. At the beginning of the time step, the inflows and previous

month’s contents for specified reservoirs are added together and this sum is divided by the sum of maximum contents

for the same reservoirs. This number is compared with the index limits for the month in the defined hydrologic state

table. If the number is less than the first table value for the given month, the hydrologic state index is defined as one.If the computed number is greater than the sixth table value, the index is seven. The hydrologic state index can be

used to define the priority number and target contents of a reservoir, to define the total season demand, distribution,

and priority of a demand, and to define the level of contribution or subscription to the rental pool for a given season.

A network (data set) can have more than one defined hydrologic state, allowing great flexibility in defining river

system management operations.

Nodes - River System Locations

There are three types of nodes: 1) non-storage nodes, 2) demand nodes, and 3) reservoir nodes. Each type of node

has a button on the GUI tool bar. A new node is created by clicking on the appropriate button and then clicking on

the GUI canvas. A right-click on the new node will pop up spreadsheets where parameters and time series data for

the node can be entered.

Non-Storage Nodes

Non-storage nodes (blue round circles on the GUI canvas) are used to represent points of interest along the river

such as river gages, diversion dams, tributary confluence points, and locations where return flow or groundwater

discharge enters the river system. Besides a name and description, the only data that are input for non-storage nodes

are local gains (inflow). Local gains are entered as a time series with an input value for each time step of the

simulation period. For monthly time steps, local gains can also be entered as an annual value with a constant

monthly distribution pattern.

Demand Nodes

GeneralDemand nodes (purple square nodes on the GUI canvas) are used to represent both consumptive diversion demands

and flowthru/non-consumptive demands. The demand can be entered explicitly as a time series, as an annual value

with a constant monthly distribution pattern, or as a weekly value with a daily distribution pattern. Demands can also

be calculated dynamically based on flow in a given link or delivery to another demand in the network. If an exchange

credit link or exchange credit node is specified for a demand node, the demand is set equal to the flow passing

through that link or the delivery at that node during the previous iteration of the same time step. This feature allows

tremendous flexibility in tying the physical operation or water supply accounting for a node to conditions and

operations in another part of the network.

Demands at Reservoirs

If water rights are being simulated and a demand diverts water directly from a reservoir, the user must place the

demand upstream or downstream of the reservoir rather than directly at the reservoir. If an upstream location is

selected, the demand will not be able to divert water from the reservoir storage. This may be appropriate if thedemand is physically located near the headwaters of the reservoir and cannot depend on the reservoir storage for

delivery. If the demand needs to have access to the reservoir storage, the demand should be placed downstream of

the reservoir.

Return Flows and Groundwater Pumping

Return flows are designated as percentages of diversion. The infiltration rate is the percentage of the time step

diversion that can be expected to come back to the system as return flow. This total can be returned to the river


15/68

14

system at up to ten locations, each with a percentage of the total infiltration and node-specific lag coefficients. Lag

coefficients can be defined by the user or generated by the model from Glover equation parameters: specific yield,

transmissivity, and average distance to the return location.

Groundwater pumping can be simulated with a demand node. Maximum withdrawal, relative cost of pumping, and

influenced nodes are defined by data input for the demand node. Depletion locations, represented by nodes, have a

percent of total withdrawal and lag coefficients (user- or model-generated) to simulate depletion of groundwater sources as a water supply.

Flowthru Demands

Non-consumptive demands can be simulated a couple of ways. The model allows the user to specify 100%

infiltration rate and return the delivery amount to one or more nodes in a manner similar to return flow from a

consumptive demand. Depending on the situation being modeled, this can be computationally wasteful and, from a

modeling intent, inexact. Most non-consumptive demands are simulated using flowthru (flow through) demands. The

user defines a demand as flowthru by filling in one or more Flowthru Node and Flowthru Fraction fields in the

demand data. Return flow from a flowthru demand is not lagged. The flow distribution to the flowthru nodes occurs

within the same time step as the diversion. Special logic keeps natural flow and storage water optionally segregated

as the return flow reaches the flowthru nodes for downstream redistribution.

In many cases, a flowthru demand needs to take credit for flow that is incidentally available from other operationalconsiderations. If the network is accounting for water rights or some other prioritized criteria by placing demands

off-stream, a bypass credit link is specified as the link immediately downstream of the node where the flowthru

demand diverts water from the river. Credit is taken for the flow in this link as a partial satisfaction of the demand. If

the bypass credit link is not specified, the demand will be attempting to be satisfied above and beyond the flow

already at that point in the river.

Reservoir Nodes

General

Reservoirs (red triangles on the GUI canvas) are defined by data representing physical, operational, and water

accounting concepts of storage reservoirs and diversion dams. Input data begins with the reservoir name, maximum,minimum, and initial contents. A table of area, content, elevation, and hydraulic capacity defines the shape of the

reservoir. If hydraulic capacity is entered, it is used to calculate a maximum release for the reservoir at the average

contents for the time step. Average area for the time step is used to compute evaporation. Evaporation rate is input as

a time series table. A single seepage rate can be entered to estimate reservoir seepage based on average content of

the time step.

Reservoirs are the keystones of several water management logic constructs in MODSIM. Many of these constructs

are briefly described below. More detailed information on how to use these capabilities is presented in the examples.

Hydropower

Power plants are modeled at reservoirs. Power plant capacity is entered in Kw. A three dimensional table is used to

enter power plant efficiency vs. flow vs. head. The head is computed by the average forebay elevation minus the

plant elevation or optionally the flow-dependent tailwater elevation. A table of the number of hours of generation per time step can be used to simulate maintenance downtime and peaking operation.

Reservoir Target Contents and Balance Tables

Target contents in MODSIM can also be thought of as maximum contents – the model will see no benefit to storing

water above this level. In calibration mode, target contents are entered for each time step and are usually historical

end-of-month storage values. In management mode, the table of target contents has a value for each minor time step

and each hydrologic state. The hydrologic state index is used to select the guide level and priority of the reservoir


16/68

15

target for the time step.

Reservoir nodes may optionally specify balance tables. This table defines a number of layers in the reservoir as

either percentages of maximum capacity or percentages of the time step target contents. The user specifies an

incremental cost for each layer. The lower the incremental cost, the more benefit (or less cost) there is to hold water

in that layer of the reservoir. By alternating the costs between reservoirs, the reservoirs will simulate operations that

tend to keep system reservoirs within the same relative layer.

Reservoir Systems, Account Balance Months, and the Bypass Outflow Link

Reservoir systems are used by MODSIM to handle the case when numerous implicit exchanges are allowed in the

network and physical water is allowed to be stored and released among the reservoirs in a manner that is independent

of the water rights accounting. For example, even though a downstream reservoir may have a senior storage right, it

may be advantageous to physically store water in an upstream reservoir and account for the storage fill as if it

occurred in the downstream reservoir. Imperfect operation for flood control, meeting instream flow requirements

from contracted water, and other operational considerations can lead to water belonging to a contract holder in one

reservoir to be physically in another reservoir. Flood control drafts below the amounts of accrued storage contract

water means that less physical water is in storage than has been theoretically accounted for. After the reservoir has

been allowed to refill from the flood control drafts, the total amount of physical water available needs to match the

paper accrual for the season. Account balancing and reservoir system numbers allow the user to simulate these kinds

of river basin administrative procedures.

When storage contract accounting is being modeled, the user defines the time steps when the system will be forced to

make the sum of the contract accounts and the physical reservoir contents equal each other. A switch is set for each

time step in the year that this is to be required. In a time step when account balancing is required, a number of

reservoirs can be pooled in a reservoir system. When the balance logic is called, all storage accounts for all

reservoirs with the same system number are summed. All ending contents of these reservoirs are also summed. A

ratio is computed and all storage accounts are adjusted so the two sums are equal.

The bypass outflow link is used in networks with water storage contract accounts to simulate flow passing through a

reservoir that is not accounted for as accrual to that reservoir.

Parent and Child Reservoirs

Water right and storage contract accounting procedures usually involve some sort of water exchanges to maximizedelivery efficiency and assure that each user receives their entitled portion of the water supply. In some basins, any

exchanges must be very explicitly defined and accounted-for to be allowed. Paper accounting for water distribution

for each instance must be defined and constrained according to the physical exchange capacity. In other basins,

exchanges are allowed to occur implicitly through general physical operation criteria. Paper accounting for the

entitlements in this context is completed after the physical operation has taken place. MODSlM allows networks to

be created to simulate either or both types of water exchanges.

One of the constructs that can be used to tailor the simulation of water storage accounting and exchanges is the

parent and child reservoir construct. Any reservoir is either a non-child, a parent, or a child. A parent reservoir by

definition has one or more child reservoirs whose capacities, contents, and storage contract accounts must total that

of the parent. Any reservoir with multiple storage accounts or with a single storage account that does not use the

entire storage capacity should use the parent/child construct. Storage accrual priorities are handled in links to the

child reservoirs (discussed in detail in the next section). Simply stated, child reservoirs with a zero system number are used where very strict explicitly defined exchanges are to be simulated. Child reservoirs with non-zero system

numbers and non-child reservoirs with non-zero system numbers allow the network to simulate implicit exchanges

while simulating both physical operation and water right based storage contract accounting.

More details on parent/child reservoir constructs and how they work will be presented after some more background

on network links and flow distribution.


17/68

16

Links – River System Pathways for Network Flow Distribution

MODSIM uses a network flow algorithm to drive the model solution. The data assigned to the model’s nodes and

links are distilled into a set of linear equations that represent both the physical river system and the water rights and

storage accounting issues as costs, upper bounds, and lower bounds for physical and artificial links. The solver

minimizes the objective function subject to node mass balance and specified link bounds constraints.

Artificial Nodes and Links

Headwater nodes, river system end sink nodes, and demands that are placed off-stream on the GUI canvas all look

like they are not completely connected back to the rest of the system as required by the network algorithm. Actually,

the model creates a number of nodes and links on the user's behalf in order to represent the various physical and

accounting constructs. The model user can think of these so-called artificial nodes and links (jointly referred to as the

artificial network) as a set of unseen nodes behind the GUI screen and links connecting the artificial nodes with the

nodes on the GUI canvas. The data that is entered for a node are used to set costs and bounds on artificial links to

and from the node. Priority numbers on reservoirs and demands are translated to costs on artificial target storage and

artificial demand links. Reservoir target contents and diversion demands set upper bounds of these links. The target

storage link is the link from the reservoir node to the artificial network that holds the water in the reservoir rather

than allowing the water to flow downstream. Costs, upper bounds, and lower bounds of many links (artificial and

user defined) are managed by model code between iterations in the time step solution process.

The GUI network builder allows the user to place a link between two nodes. What kind of link it is depends entirely

on the data that is attached to it. We can think of links as falling into 4 major categories, and additional data added

to links in these categories is used to invoke MODSIM’s more powerful and complex capabilities. In this section

we’ll discuss the 4 main link types.

General Flow Links

Links that represent reaches of the river between non-storage nodes typically have no specific information entered by

the user. The cost is usually zero and maximum capacity is a very large number. The user always has the option of

putting specific information in any of the links created on the GUI canvas. Entering inappropriate maximum,

minimum, or variable capacities and costs can lead to infeasible networks. If this is the case, the model will stop at

the infeasible time step and dump debugging information to assist the user in identifying the problem.

Natural Flow Links

Natural flow links are links that have a priority assigned by the model user, and they are used to transport water to a

demand node. The priority can be entered as a water right date that is later translated into a negative cost, or

alternatively the model user can enter the negative cost directly. Natural flow links are intended to represent natural

flow rights that entitle the demand to divert water up to a specified maximum or variable capacity.

Storage Ownership Links

If a link from a non-storage node to a demand has a parent link that is an accrual link (next paragraph), it is called a

storage ownership link and represents a reservoir storage contract or agreement. The volume of storage space under

contract is specified as the Ownership Amount and the Initial Amount is the assumed accrual at the beginning of the

study period. Rank is used if a demand has more than one storage ownership link and determines the relative order inwhich ownership links are selected when storage water is needed to satisfy the demand. The ownership link with the

lowest numeric rank will be used first.

Accrual Links

An accrual link is essentially a natural flow link that ends at a reservoir instead of at a demand. It has a negative

cost, and at least one link in the network defines the accrual link as its parent link. An accrual link supplies water to


18/68

17

a storage account, which is a block of storage space in a reservoir. The storage account competes for natural flow

along with other demands with natural flow rights in the basin. The seasonal capacity of an accrual link represents

the total size of the storage account.

Other Link Types

Exchange Limit Links, Reservoir Outflow Links, Rent Pool Links, and Last Fill Links will be discussed after someadditional information about MODSIM solution procedures and more complex capabilities has been presented.

Network Solution Steps

As described earlier, each time step solution requires a number of iterations to derive reservoir evaporation,

diversion return flows, flowthru returns, and watch logic values. These iterations are intended to converge on a

numerical solution. Each iteration in turn has distinct steps that handle the differences between the physical routing

of water through the system and the accounting of water for administrative purposes.

If the network has no storage contract agreements defined through ownership and accrual links, each iteration of the

time step solution process represents the physical operation of the river system. The relative priorities of the demand

and reservoir nodes together with natural flow right costs and bounds on links are used to achieve the simulation thatis desired.

As soon as ownership and accrual links are defined in a network to model storage contract agreements, the solution

process changes substantially. Each time step iteration in this type of network is now solved using a two-step process

– first a natural-flow-step and then a storage-step or physical-step. Natural flow steps essentially ignore storage

water in the system and complete a pure accounting of natural flow distribution. Storage steps use part of the

solution from the natural flow step as constraints and reintroduce storage water as a water supply resource. The

storage step represents the actual anticipated physical operation of the simulation.

An important part of this dual step process is MODSIM's management of links between the two iteration steps to

effectively remove storage water from consideration for the natural flow step and to reintroduce it to the system for

the storage step.

Natural Flow Step

Before a natural flow step is solved, outflow links from all reservoirs to the river are set to zero (or flood control

evacuation if the reservoir content is above the target storage for the time step). Likewise all links representing the

storage contracts to the demands are closed.

Natural flow links to demands are open with their assigned costs, upper bounds based on seasonal or maximum

capacity, and lower bounds of zero. Reservoir accrual links are also open with their assigned costs. The upper bound

on accrual links depends on several parameters set for the network. An accrual link has a seasonal capacity that is

equal to the volume of the storage account. This account represents the space in a reservoir which has a priority date

stated in the storage right permit granted by the state water resources department to the reservoir owner. A reservoir

may have one or more accounts, each of which is represented by an accrual link with an appropriate priority. The

sum of all prioritized accounts should normally equal the total capacity of the reservoir. Each account is allowed tofill up to its seasonal capacity (including any carryover accrual from a previous year) once in a single year. The

beginning time step of the accrual season is defined by the user through the GUI menu item Settings…Storage

Accounting Logic…Accrual Month. Another menu switch – Settings…Storage Accounting Logic…Relax Accrual

Storage – is a network toggle switch that determines whether accrual is to be constrained by physical space

availability or not. If this switch is off, accrual during the natural flow step is constrained by the amount of physical

space available in addition to the seasonal capacity. If the switch is on, accrual is allowed up the seasonal capacity

without regard to whether the water can be physically stored in the time step. Accrual can also optionally be


19/68

18

constrained to a maximum time step rate. Finally, accrual can be constrained by outstanding last-fill water; this is

explained later under the rent pool discussion.

Artificial target storage links are opened and set with an upper bound based on the time step hydrologic state index

and the table of target storage vs. hydrologic state for each reservoir. The cost of the target storage link is set to a

relative neutral value (-49000 by default) so it can compete equally with demand links. Artificial spill links are given

a small positive cost and a very large capacity. Any excess inflow which would cause reservoir content to exceed thetarget storage passes through the artificial spill link during the natural flow step. Any flow to a flowthru demand in

the previous storage step that goes through a link without the Storage Flow Only switch on enters the river at the

designated flowthru node. Any return flow from a diversion in the previous storage step enters the river at the

designated return nodes. The network is solved and represents the natural flow distribution for the time step.

Convergence is not checked after a natural flow step.

Storage Step

The distribution of natural flow from the natural flow step is used to set lower bound constraints on natural flow right

links in the storage step. This assures natural flow entitlements are met while introducing storage water and physical

operation constraints. The upper bounds of the natural flow links remain at the user-specified maximum or variable

capacity. But if the link switch Storage = NF is set by the user, the upper bound on the link is set to the amount that

flowed through the link in the natural flow step iteration.

Each demand that has storage ownership links to it is checked to see if it has demand that is greater than the natural

flow entitlements for the demand. One by one, storage ownership links to the demand are opened with an upper

bound set to either the accrual balance for the link or the residual demand. The order of ownership link selection is

based on the cost for each ownership link; the link with the lowest cost is selected first.

Reservoir outflow link upper bounds depend on the type of reservoir. If the reservoir is a non-child reservoir or a

child reservoir with a non-zero system number, the upper bound of the outflow link is a very large number. If the

reservoir is a child reservoir and has a zero system number, the upper bound is set to the maximum of any flood

control evacuation volume and the sum of the upper bounds on ownership links that have parent accrual links that

end at that child reservoir. If hydraulic capacity limits are specified, all outflow links (one normal outflow link for

each reservoir plus the bypass outflow link) are joined to an artificial node. The link from this node back to the river

gets an upper bound equal to the hydraulic capacity based on average contents during the time step.

Accrual link bounds are set based on the type of reservoir. Non-child and child reservoirs with non-zero system

numbers have their accrual link upper bounds set equal to seasonal capacity. Lower bounds are set to zero for these

accrual links. Accrual links to child reservoirs with zero system numbers are treated much like natural flow rights

and have their lower bounds set based on the last natural flow step iteration. Upper bounds are constrained according

to the seasonal accrual limit and physical space available.

Artificial target storage link costs are defined by an equation that uses the target storage priority established by the

user and will allow storage ownership links to be satisfied to the physical capability of the system while not allowing

natural flow rights to be satisfied from reservoir release directly. This is accomplished through the inherent cost

structure of the links: 1) ownership links have a translated cost of about -300,000, 2) target storage links have costs

of about -70,000 (compared to demand links cost of about -49,000), and natural flow links remain in the cost range

of about -10,000. Ownership links, when opened up to satisfy demand beyond the natural flow entitlements, willforce water to be released from storage because they have lower cost than the reservoirs' target storage links. Natural

flows have a higher cost than the reservoirs' artificial target storage links and therefore cannot force a storage release

in order to be satisfied. By default, return flows (determined from previous iterations) become part of the natural

flow to be distributed in the natural flow step. This includes return flow from storage water diversion. This can be

modified if necessary by a number of constructs including the Storage Flow Only link switch, watch logic, or the use

of Perl scripts.


20/68

19

Convergence is checked after the storage step. If the percent difference of flow values is less than a specified

tolerance, the time step solution is complete. If not, appropriate information is stored in memory, link costs and

bounds are reset for another natural flow step iteration, and the sequence is repeated until the convergence criteria is

met.

Some Powerful Modeling Constructs in MODSIM

Exchange Limit Link

Each link has a field for optionally specifying an Exchange Limit Link. This field is an example of logic generally

referred to as watch logic. MODSIM will watch the flow that went through the specified exchange limit link in a

previous iteration and set the upper bound on the link with the specified ELL to that flow value. This watch logic is a

tool to simulate explicitly defined exchanges where the allowed flow at some place in the network is contingent on

the flow somewhere else in the network. The logic can be used with small disconnected networks with flowthru

demands to simulate things like accumulated flow credit accounts, shared water rights between demands, and other

complex exchange constructs.

Reservoir Outflow Link

This link comes from a reservoir, ends at a non-storage node, and specifies itself as its own parent link. This link

needs to be identified for each reservoir that is to be managed in the two step iteration process explained above.

Rent Pool

Rent pool can simulate water banks or water service contracts. The capability was originally developed to model the

Upper Snake River rent pool construct (and the name stuck), but the functionality is general-purpose in nature and

can be applied to any basin with similar functionality. Simply stated, rent pool allows storage ownership to be

temporarily transferred to another demand. If a demand has more water entitlement than needed in a high runoff

year, the demand can contribute part or all of the ownership accrual to the rent pool. Other demands that need more

water than they have entitlement to can subscribe to rent pool water in a given year.

Ownership links have a data field where Rent Pool Limits can be specified, and an ownership link becomes a rent pool link also if these fields are filled in. Rent pool limits are positive or negative, depending on whether the water

user will be contributing water to the pool or renting water from the pool. A link cannot have both negative and

positive rent limits. Positive rent pool limits indicate that any accrual credited to an ownership link up to the value of

the rent pool limit is to be contributed to the rent pool. Negative rent pool limits indicate that the user wants to

subscribe to rent pool water. Note that for these renters’ links, the field for Ownership Amount will be zero – this

user doesn’t actually own water in the storage account specified by the parent link, which is why he wants to apply

for rent pool water.

Each accrual link potentially has its own rent pool. All rent pool contributions from associated ownership links are

summed for each accrual link. All rent pool subscriptions from associated rent links are summed for each accrual

link. If the sum of contributions is not equal to the sum of subscriptions, the greater of the two numbers is

proportionally reduced so the sums are equal, and the transfer of accrual credit is made. Note once again that rent

links (the links with the negative rent pool limits) are treated like ownership links except they can never accrualwater from the accrual link.

The rent pool limit can vary with the hydrologic state index and is re-set every year on the date specified in the GUI

menu item Settings…Storage Allocation Logic…Rent Pool Month. Reservoir evaporation is distributed as a

negative accrual to ownership and rent links proportionate to their accrued carryover.

Rent pool logic can also be used to simulate water service contracts, which administered such that the amount of


21/68

20

storage allocated to each contract holder is defined by the yearly reservoir fill level. There is no year to year

carryover account for each contract. This type of arrangement can be simulated by the rent pool logic by assigning

the entire reservoir to a fictitious owner (Reclamation) and renting the water out each year by the percentage

specified for each contract holder.

Last Fill

Last-fill logic is related to the rent pool. The Snake River Basin rent pool has an administrative rule that alters the

refill priority of rent water space that is used for specific purposes such as flow augmentation. The so-called last-fill

rule gives a junior priority to the space from which this last fill rent water is debited. If the rent water to be

contributed or rented is to be subjected to this rule, the rent pool link’s toggle switch Last Fill is set to on. Otherwise

the rent water space retains its original priority.

The last fill link comes from a non-storage node, ends at a reservoir, has a negative cost and specifies itself as its

own parent link. The cost is set to an appropriate value – usually, of course, numerically greater than the other

accrual links to the reservoir. The upper bound of the last fill link is dynamically set to the amount of space that has

been rented but that has not yet been refilled. This last fill priority is sticky and remains with the space until it refills,

at which time the space regains its original priority.

Reservoir Target Storage

MODSIM can use hydrologic state to determine the target storage level of a reservoir for a given time step. As

discussed above, the hydrologic state is derived at the beginning of each time step based on reservoir inflow data and

computed reservoir contents of the previous time step. MODSIM treats target storage as the maximum desired

reservoir level for the time step. This level is typically set at lower levels early in a wet flood control season

(minimum space requirement in dry conditions) to full at the normal refill time (usually by the end of June). In

MODSIM's view of things, there is no benefit to the network for storing water above the target storage value, so

water that would fill the reservoir above target storage level will pass downstream to the end of the river system if

not intercepted by a demand or another reservoir.

The values for the target storage levels for each hydrologic state along with the index limits in the hydrologic state

table and the minimum flow values for each state are derived through a trial and error process. The art of the

calibration process for MODSIM is deriving these values to represent the present operational practice. Historicreservoir contents and forecasts are used to derive a sorted list of hydrologic state table like values for each month.

Percentile values are used to determine the initial limits that end up being the hydrologic state table index limits.

Value smoothing between months and indices is done. The model is run a number of times while adjusting the index

limits, target storage levels, and some of the minimum flow requirements to calibrate the model until the desired

operation is simulated.

Flood Control

At flood control points in the river system a multi-link construct can be implemented in order to simulate flood flow

constraints. The normal channel capacity of a flood control point is set to the maximum flow of one of a two link

multi-link downstream of the river gage point. This could force the model to become infeasible if all reservoirs are

full and the water in a high runoff case has no place to go. The solution is to place a very large capacity and cost on

the remaining of the two-link multi-link. If a reservoir upstream is at or above its target content but not full, and theflow is at or above the channel capacity, reservoir inflow will be stored above the target up to the maximum capacity

of the reservoir before forcing water through the high cost link. Once all reservoirs are full and the channel capacity

is exceeded, water will be forced through the high cost link. This can represent controlling a flood at a downstream

point up to the ability of the reservoir system. One could extend this functionality to include surcharge and more

links in the multi-link to make it more and more costly to put water in surcharge vs. exceeding a channel capacity.


22/68

21

More on Parent - Child Reservoirs

Remember that any reservoir is a non-child, a parent, or a child. A parent reservoir has one or more child reservoirs.

The sum of the child reservoirs' capacity, contents, and storage contract accounts must represent the total of the

parent. A child reservoir cannot have a child reservoir (i.e. there are no grandchildren).

Child reservoirs are created using the reservoir tool and clicking once with the left mouse button on an existingreservoir to create each child. A number will appear to the upper right of the reservoir indicating how many children

have been added. The split and merge tools can then be used to visually dis-aggregate and aggregate the children

from the parent reservoir on the GUI canvas.

If a reservoir has children, accrual links and outflow links are connected to the children and not the parent.

Remember that accrual links allow reservoirs to accrue water to storage accounts, and that outflow from a reservoir

is the sum of the flow in the links coming from the reservoir node and the bypass outflow link.

As mentioned earlier, a child reservoir with a zero system number is managed very explicitly. In the natural flow

step, the outflow is constrained to water that needs to be evacuated for meeting a calculated flood space requirement.

In general, flood control space is based on the parent reservoir target storage and is prorated among the child

reservoirs. If one or more child reservoirs have non-zero target storage values, MODSIM will prioritize the space

allocation up to the target in each child. Accrual is constrained to seasonal accrual limits and physical spacerequirements. In the storage step, the outflow for a reservoir is set to the maximum of the space evacuation or the

sum of all ownership links demands from the space in that reservoir.

Child reservoirs with non-zero system numbers are managed in a manner similar to non-child reservoirs. In the

storage step, the priority number of the reservoir is translated to an artificial target storage link cost between the

natural flow links' cost and the storage ownership links' cost. The relative cost of the target storage link in relation to

other reservoirs in the system with non-zero system numbers will determine if a given reservoir will be drafted to

meet storage water demands.

Relax Accrual

If the network switch for Relax Accrual is off, accrual is constrained to seasonal accrual limits and physical space

availability as determined by the parent reservoir flood space distribution. If Relax Accrual is on, accrual is notconstrained by the space availability, and only seasonal accrual limits constrain the inflow in the natural flow step

iterations.

A Twist on Minimum Flow Demands

At each minimum instream flow demand a small construct can be developed using a non-storage node for return flow

and a large demand node that would receive the return flow water but allow storage water to return to the river only

in a storage step iteration. This is done by putting a positive cost on the link to the large demand node and a storage

only flag on the link from the return flow node to the river. The flag sets the upper bounds of a link to zero during a

natural flow step.

The flowthru demand logic allows the user to separate the return flow from a flowthru demand between natural flow

and storage water by placing the storage only flag on one of the links to the flowthru demand.


23/68

22

The Prineville/Crooked River Example Network

The Prineville/Crooked River model presented here demonstrates storage ownerships and group ownerships. In

addition, the use of storage limit links and exchange limit links will be discussed. The accompanying network file is

Prineville.xy, as pictured in Figure 10 below.

Figure 10 – Prineville/Crooked River Network

Storage Ownerships

In Example Network 2, natural flow rights were represented by entering a date in the W.R. Date field for a link

serving a demand node and generating the link cost by using the Utility...Sort Water Rights menu option. Many

systems, however, also require the distribution of stored water by right.

Storage water rights can be interpreted and administered in several ways. The approach in this example models

storage water rights as contractual agreements between the spaceholders and the Bureau of Reclamation.

Reclamation holds the natural flow right to accrue water to Prineville reservoir in priority, and delivers the stored

water to the spaceholders by request. Each spaceholder is limited to a contracted percentage of the reservoir fill, and

shares in the losses which occur due to operational releases, flood control and evaporation. The spaceholder =s

account behaves much like a bank account:

! water accrues each season to the spaceholder =s account;

!

the spaceholder withdraws water from the account as needed and the account balance is reduced accordingly;! the spaceholder can never withdraw more water than their current balance; and

! water can be carried over into the next accrual season (however carryover water is subject to flood control and

evaporation losses).

In this example the accrual season ends in October (using the menu option Settings...Storage Allocation

Logic…Accrual Date) and a new accrual season begins the following month.


24/68

23

Recall that when storage ownerships are introduced into a model, MODSIM uses the two-step iterative solution

process where each iteration first goes through a natural flow step and then a storage or physical step. Since

spaceholders frequently have primary natural flow rights and use their storage water as supplemental supply, this

two-step solution process effectively allows for natural flow rights to be used first, followed by storage rights.

Before entering the storage step, the lower bounds on natural flow links are set to the flows which were determined

in the natural flow step. This ensures that these natural flows will be maintained during the storage step. In thePrineville/Crooked River model, most of the demand nodes which are supplied by natural flow links also have

storage ownership links representing their storage contracts. If the demand could not be satisfied by natural flows,

the ownership links supplying the demand open up and water is released from the reservoirs to meet that need.

Ownership links can be identified by the entry in their Parent Link field, discussed in detail the section Ownership

Links and Group Ownership Links below.

Initial Settings

Familiarize yourself with the settings used in this model by checking out the following:

! Settings...Run Type – set to Management

! Settings...Hydrologic State – there is one Hydrologic State Table defined

! Settings...Storage Allocation Logic…Accrual Date – set to Oct

!

Settings...Storage Allocation Logic…Account Balance Dates – set to Oct and May

Reservoirs

Prineville Reservoir. Prineville Reservoir is constructed from 3 nodes and 3 links. The inflow node,APrine@,

introduces the historic gains to Prineville Reservoir. In this example gains were calculated from the change in end of

month contents plus monthly flows downstream of the dam, so gains include historical inflows to the reservoir,

rainfall, and releases. Losses due to evaporation and seepage are implicitly included as part of the historic local gain.

The reservoir node, APRINE@, stores accrued water (not to exceed the target storage); releases water in the current

time step to meet downstream requests or to meet the target storage; and allows for the carryover of water into the

next time step.

The accrual link, APrineville accrual@, represents the water right that is used to fill the reservoir. Inflow to the

reservoir which is not stored flows through the bypass out link, link 13. Total inflow to the reservoir is the sum of the flow in the accrual link and the bypass out link.

Water released from storage flows through the reservoir outflow link, link 12 (the user identifies this link as an

outflow link by setting its parent link number to itself). Total outflow from the reservoir is the sum of the bypass

outflow link (link 13) and the reservoir outflow link.

Target Storage values are entered for each month. Target storage values are the maximum desired reservoir contents

at the end of each time step. Releases are made from Prineville reservoir throughout the irrigation season to meet a

Labor Day (end of August) objective of 104,000 acre-feet. Target storage values were developed for each month to

draw down the reservoir linearly to meet the end of August target. If the flows requested by spaceholders do not

draw the reservoir down to the target storage value for the month, additional water is released to meet that month=s

target. Target storage values for winter and spring months were derived from flood control rule curves. Usually the

modeler would choose to vary target storage values by hydrologic state to mimic historic operations. But Prinevilleoperators rely on a linear interpolation from the fill date to the end of August and the clients requested the model to

always make 60,000 acre-feet of flood control space, so target storage values which do not vary with hydrologic state

were appropriate.

When developing a network that includes storage contract constructs, reservoirs that have nonzero system numbers

Acompete@ for the ability to hold water in storage against other reservoirs. The priority number given to a reservoir


25/68

24

is translated to a relative cost on the artificial target storage link during the storage step iteration of the solution

process in a given time step. As with all priorities and link costs in MODSIM, the lower the numeric value of the

priority, the higher the benefit for flowing water through the link. This is how MODSIM simulates reservoir storage;

it is actually a flow through the artificial target storage link. If the river system has two (or more) reservoirs with

nonzero system numbers, demands downstream from both reservoirs will tend to draw on the reservoir with the least

benefit for holding the water in storage. In this example, Ochoco Reservoir has a lower priority number (higher

benefit) of 70 compared to Prineville (80). Releases would be made from Prineville Reservoir first to meet demandsthat could be met from either. Note that in this example, demand magnitude and location are such that is not

necessary to have balance tables which would balance the amounts of water taken from the reservoirs when both can

satisfy demands.

Ochoco Reservoir. Ochoco Reservoir is constructed from 3 nodes and 3 links, similar to Prineville Reservoir.

The priority number selected for Ochoco Reservoir was explained above. Ochoco Reservoir has been given a

system number of 2 which, because it is nonzero, has the effect of forcing Ochoco storage water to compete with

Prineville if a demand downstream of both forces a release to be satisfied. The number 2 was selected intentionally

to be different from Prineville=s system number of 1. On selected time steps, storage ownerships= account balances

are adjusted so the sum of the A paper @ accounts equals the A physical@ water in the reservoir at the end of the time

step. Reservoirs with the same system number are pooled for this balancing exercise; the sum of the paper accounts

for all reservoirs with the same system numbers is compared with the sum of all these reservoir =s physical contents.Reservoirs with different system numbers have the A paper @ accounts balanced against the A physical@ water for the

reservoir by itself. In the example here, it was determined to be most appropriate that the accounts for each reservoir

be adjusted to sum the physical contents of each reservoir.

The forecast reservoir. The forecast reservoir is constructed from a reservoir node, Aforecast@, and an infinite sink

demand (actually, just a very large demand). The forecast reservoir does not represent a real world reservoir, but is

used in defining the hydrologic state. Inflows to the forecast reservoir are the sum of the current month through

September gains to Prineville Reservoir. These perfect forecasts are used by Hydrologic State Table 1 to categorize

the current month as entering a wet, average, or dry period. No water is stored in the reservoir because the target

storages are zero, but for purposes of calculating the hydrologic state, the Maximum Volume is set to 100,000 acre-

feet.

Hydrologic State

The hydrologic state settings are entered using the menu option Settings...Hydrologic State...Spreadsheet 1 of 1. The

Prineville/Crooked River model uses one hydrologic state table with 4 hydrologic states. A40@ is entered in

HydroState Subsystem field of Spreadsheet 1, identifying node 40 as the forecast reservoir. The percentage values

entered in the Factors fields were determined by sorting the inflow forecasts (which are also inflows to the forecast

reservoir), dividing by 100,000 (the volume of the forecast reservoir), and selecting the break points at about the 25,

50, and 75 percentiles.

In this network, demands are varied in annual amount and seasonal distribution depending on the hydrologic state.

Accrual Links

Prineville accrual. The link APrineville accrual@ connects the inflow node APrine@ to the reservoir node APRINE@. Water flows through this link to fill Prineville Reservoir with a 4/8/1914 water right. Inflow needed to satisfy

downstream water rights which are senior to this fill right does not pass through the accrual link, but instead bypasses

the reservoir node through the bypass out link, link 13.

The cost on the accrual link was generated by entering the date in the W.R. Date field and using the Utility...Sort

Water Rights menu option. Accrual can only occur in right, so that the accrual link competes with other natural flow


26/68

25

links in the system.

The Seasonal Capacity field entry allows the reservoir to fill through the accrual link to its maximum capacity of

148,633 acre-feet each accrual season (if the water is available in right from the inflow node APrine@). The accrual

season is set to end in October using the menu option Settings...Storage Allocation Logic…Accrual Date.

Three spaceholders share the accrual to Prineville: Ochoco Irrigation District (OID), other irrigators (nonOID), and uncontracted space (Reclamation). In the model, accrual is distributed proportionally to their accounts as water is

supplied through the accrual link.

Reclamation requests its water to meet an instream flow demand at a single location, the flow through demand node

75cfs. Spaceholder OID requests water to supply irrigation demand nodes ACRFeed1", ALBOchCr2", AOchMain4",

ADist@, ALBRye2". Spaceholder nonOID requests water to supply irrigation dema

new manual modsim

Documents