New Manual modsim
-
Upload
muhammad-rehan-anis -
Category
Documents
-
view
254 -
download
0
Transcript of 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
-
8/15/2019 New Manual modsim
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
-
8/15/2019 New Manual modsim
3/68
2
MODSIM Toolbar
Data Editor Details
Non-Storage Node Demand Node Storage Node Link
-
8/15/2019 New Manual modsim
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.
-
8/15/2019 New Manual modsim
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
-
8/15/2019 New Manual modsim
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
-
8/15/2019 New Manual modsim
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/15/2019 New Manual modsim
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
-
8/15/2019 New Manual modsim
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
-
8/15/2019 New Manual modsim
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.
-
8/15/2019 New Manual modsim
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
-
8/15/2019 New Manual modsim
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.
-
8/15/2019 New Manual modsim
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
-
8/15/2019 New Manual modsim
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
-
8/15/2019 New Manual modsim
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
-
8/15/2019 New Manual modsim
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.
-
8/15/2019 New Manual modsim
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
-
8/15/2019 New Manual modsim
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
-
8/15/2019 New Manual modsim
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.
-
8/15/2019 New Manual modsim
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
-
8/15/2019 New Manual modsim
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.
-
8/15/2019 New Manual modsim
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.
-
8/15/2019 New Manual modsim
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.
-
8/15/2019 New Manual modsim
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
-
8/15/2019 New Manual modsim
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
-
8/15/2019 New Manual modsim
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