INSTRUCTIONAL MANUAL FOR THE

WATER ANALYSIS MODULE (WAM)

VERSION 1.0

5/27/09

Prepared by:

Behrens1, D., Wm. E. Fleenor1, J. DeGeorge2 and F. Bombardelli1

Center for Watershed Sciences

of the

John Muir Institute of the Environment

at the

University of California, Davis

1 Civil & Environmental Engineering Department; UC Davis 2Research Management Associates; Fairfield, CA

Overview  The following instructional text is an overview of the tidally- and cross-section-averaged finite element Water Analysis Module (WAM). The model was developed by the Resource Management Associates, Inc. (RMA) as part of the first phase of the Delta Risk Management Strategy (DRMS) program. The document is presented as a set of instructions from which users can design their own modeling scenarios for the Sacramento-San Joaquin Delta in WAM. Since no graphical interface currently exists for the program, it discusses operation of the model based on manipulation of the many files required for running various parts of the model. The manual does not provide an extensive overview of the model logic and physics, although links to website-hosted documents with information about WAM are provided throughout the text. Emphasis is placed in describing the submodels and control files within WAM, which are collectively responsible for controlling water operations, net delta area losses of water (NDAL), hydrodynamics and water quality (HD), and the breach sequence of flooding islands. The inputs defined within these files are discussed in detail. Additionally, the manual provides an example for changing WAM from one modeling scenario to another, and describes utilities available to display and process output data from the model results. Much of the information provided within the many files that are required for WAM to function is derived from extensive research or calibration. The user must exercise caution in making edits to files that control important model aspects. Information such as reservoir operations logic or dispersion coefficients should not be changed without contacting the persons who developed these parts of the model, to ensure a proper understanding of the relevant parameters. The manual provides information about all of the files necessary for performing simulations with WAM and how they can be edited, so that the user can gain insight into their respective roles.

Table of Contents  1. Introduction....................................................................................................................5

1.1. Model inception......................................................................................................5

1.2. Prior uses of WAM.................................................................................................5

1.3. WAM Requirements...............................................................................................6

1.4. Computational efficiency........................................................................................7

1.5. Salt transport in WAM............................................................................................7

1.5.1. Dispersion in Delta channels and islands.......................................................7

1.5.2. Calibration and error......................................................................................8

1.6. File directory.........................................................................................................11

1.7. Model Geometry ..................................................................................................12

1.7.1. Channel network..........................................................................................12

1.7.2. Island and channel elements........................................................................13

1.7.3. Channel simplifications...............................................................................14

1.7.4. Viewing node and element properties.........................................................15

1.7.5. Node and element numbering......................................................................18

1.8. Base data ..............................................................................................................19

2. Running WAM.............................................................................................................22

2.1. Potential applications for WAM...........................................................................22

2.2. Steps for running WAM.......................................................................................23

2.3. An example case...................................................................................................25

2.4. Analyzing model results.......................................................................................29

2.5. Sample results.......................................................................................................30

3. Basic edits.....................................................................................................................33 3.1. Control file information and simulation timeline.................................................33

3.1.1. Introducing island information and submodel control files........................34

3.1.2. Setting WAM output log preferences.........................................................35

3.1.3. Setting WAM simulation timeframe...........................................................35

3.1.4. Specifications for running repeated breach events......................................35

3

3.1.5. Setting a timeline with unique, non-repeating breach events......................36

3.2. Breach sequence....................................................................................................36

3.3. Hydrodynamics and Water Quality (HD) control file..........................................38

3.3.1. Calling essential files...................................................................................40

3.3.2. Dispersion and 'Displacement Volume' information...................................42

3.3.3. Assigning model output nodes.....................................................................43

3.3.4. Adjusting water quality standards................................................................44

3.4. Specifying boundary conditions...........................................................................46

3.4.1. Flow and salinity boundary conditions........................................................47

3.4.2. Delta internal flows and exports..................................................................48

4. Advanced edits.............................................................................................................50 4.1. Island and breach information……......................................................................50

4.1.1. Island identification and spatial data............................................................51

4.1.2. Identification of possible island breaches....................................................52

4.1.3. Cross reference of island identification.......................................................52

4.2. Water operations submodel ………......................................................................53

4.3. NDAL submodel...................................................................................................55

4.3.1. NDAL control file........................................................................................57

4.3.2. Island identification information..................................................................57

4.3.3. Number of days in each month....................................................................58

4.3.4. Ambient environment characteristics..........................................................58

4.3.5. Changes in ambient conditions....................................................................60

4.3.6. Island characteristics....................................................................................61

4.3.7. Diversions....................................................................................................61

4.3.8. Drains...........................................................................................................62

4.3.9. Seepage........................................................................................................63

4.3.10. NDAL calibration files..............................................................................63

References.........................................................................................................................65

Appendices........................................................................................................................66

4

1. Introduction  WAM can be used to analyze a wide range of scenarios involving changed hydrology in the Delta including sea level rise, island failures, and anticipated management alternatives. WAM was developed to act as a tool for allowing assessment of ecosystem and economic consequences and associated risks related to levee breaches in the Sacramento-San Joaquin Bay Delta Estuary (herein referred to as the "Delta"). WAM tracks water management and Delta water quality response before, during, and after island breach events, and can simulate emergency operations, repair, and the recovery period for each event. 1.1. Model inception WAM was developed during phase I of the Delta Risk Management Strategies (DRMS) program (DRMS, 2007) in order to fill the need for a reasonably accurate and computationally fast model that could help provide decision information for Delta stakeholders. The DRMS project was authorized by the California Department of Water Resources (DWR) to perform a risk analysis of the Delta and Suisun Marsh and to develop strategies for managing those risks, in response to Assembly Bill 1200. The approach for developing the WAM is given in two Initial Technical Framework (ITF) papers (DRMS, 2006a, 2006b), which are available on the DRMS website (http://www.water.ca.gov/floodmgmt/dsmo/sab/drmsp/itfp/). Providing a comprehensive management plan for the Delta may in some cases require simulation of hundreds of levee breach scenarios. Each of these events would require excessive amounts of computation time to simulate when using a two- or three-dimensional hydrodynamic model, especially when also considering economic and management based decisions. WAM represents a balance of the physics of constituent transport in a channel network with optimal water management strategies in a way that allows simulations of breach events to be performed very rapidly. 1.2. Prior uses of WAM WAM was originally intended to simulate single or multiple breach events in the Delta at multiple times during the period from 1921 to the present. The goal was to see how the effects of a unique breach event on adjacent channel water quality would vary among past years with different conditions. The expected result of this analysis would provide a guideline for the effects of possible levee failures in future years. WAM was also used extensively in a report that discussed the need for a change in policy in the Delta (Lund et al., 2008). This report was prepared by a team of researchers from the Center for Watershed Sciences (University of California, Davis) and the Public Policy Institute of California. The goal of the hydrodynamics part of the study was to provide a general understanding of trends in flows and salinity concentrations within the Delta for potential new operating conditions. In this case, only the parts of the model responsible

5

for hydraulic calculations, changes in inflows and exports, and sea level rise were used. To acknowledge the difference between this modified model and the full version, the authors referred to it as the "Tidally Averaged Model" (TAM). TAM was used to compare a set of management alternatives regarding Delta exports for the 1981-2000 water year period, with and without sea level rise (Fleenor et al., 2008) 1.3. WAM requirements WAM is a finite element model that uses cross-section averaged velocities and temporally averaged tidal fluctuations. It is intended to simulate the movement and distribution of conservative tracers throughout estuarine systems with rapid computation. In the initial applications of the WAM model, emphasis has been placed on salinity in the Delta. Although the term "water quality" is often used interchangeably with salinity here, there is potential for analyzing other constituents in the future (URS, 2007). The model has the capability to represent transport of other waterborne constituents, such as suspended sediment or dissolved organic carbon, but these have yet to be addressed. Simulations with WAM for the Delta require:

1. boundary conditions of discharge and salinity at various measuring stations throughout the Delta, listed in Section 3.4.

2. water export operations, including exports from the Banks and Tracy pumping facilities, a record of Delta Internal Consumptive Use (DICU) and upstream dam outflows.

3. reservoir management strategies involving water releases from upstream dams during different types of years.

4. internal operation of the Delta Cross Channel gates and other seasonal gates and barriers in the Delta.

5. geographical information for Delta islands susceptible to breach events 6. information about ambient environmental inputs such as temperature and

precipitation during the simulation period. 7. dispersion coefficients developed from two- or three-dimensional models already

in place for the Delta (e.g. RMA2, TRIM, UnTrim) WAM requires many input files for its simulations. Several control files direct the model to create outputs based on templates, allow the user to set the simulation time, manipulate the breach period, and specify which files contain the necessary input information. Figure 1.1 provides a visual schematic of model operations (regarding use of input files and generation of outputs), and Figure 1.2 lists some the files necessary for running the model. The schematics do not represent the logic of the model, but instead show the sequential order in which files are called and generated. Tables A1 and A2, located in the appendix, provide a complete list of files necessary for running WAM, as well as outputs.

6

1.4. Computational efficiency When WAM was developed, a central requirement was the capability to evaluate Delta scenarios much more rapidly than other available models. WAM can simulate a 20-year period in less than 20 minutes, whereas a comparable simulation from DSM2 and the RMA Bay-Delta model would require 10 and 480 hours, respectively (Fleenor et al., 2008). The increased efficiency is a result of the following simplifications:

• Cross-section averaged channel velocities with trapezoidal cross sections • Tidally averaged mean-sea level at the downstream boundary • Simplified model network with aggregated channels • Minor cross-channels replaced with mathematical regressions

Averaging across channel cross-sections as well as across tidal cycles eliminated much of the computational time required for simulations, but increased the challenge of estimating dispersion accurately. The simplified model network eliminates the need to model hydrodynamics and ensuing salt transport in some minor Delta channels, treating them as off-channel storage or as part of the Sacramento or San Joaquin Rivers. The techniques are discussed in Section 1.7. 1.5. Salt transport in WAM 1.5.1. Dispersion in Delta channels and islands  Longitudinal dispersion of saline tidal water is of fundamental importance when attempting to predict the distribution of salt in an estuary (Monismith et al., 2002). One of the difficulties in developing WAM was the inclusion of longitudinal dispersion processes despite the cross-section and tidally averaged flow approximations. To account for these simplifications, the following actions were taken:

• Existing results from 3-dimensional TRIM/UnTrim and the 2-dimensional RMA Bay-Delta models were used to characterize dispersion

• Dispersion values from these model results were related to channel and Delta outflow characteristics

• Relations between dispersion values and channel and flow characteristics were obtained for reaches of the Delta with similar mixing characteristics

The dispersion coefficient (necessary for the RMA11 engine to solve the advection-diffusion equation during simulations) was disaggregated into components associated with different physical processes. Dispersion values were related to the horizontal Richardson number and net Delta outflow. The WAM HD submodel (Section 3.3) obtains dispersion values using the horizontal Richardson number and net Delta outflow that it calculates during each time step. The method is described in more detail by URS (2007, Appendix H).

7

8

Dispersion through island breaches is estimated using results from the 2-dimensional RMA Bay-Delta model. A 50-breach event with 20 flooded islands was simulated with the RMA Bay-Delta model. WAM calculates dispersion into the flooded island using manually tuned exchange efficiencies. Data from the 2004 Jones Tract failure was used to verify WAM's ability to simulate dispersion in the Delta after an island failure, showing promising results. However, Fleenor et al. (2008) have noted that while WAM appears to capture the initial inflow of salt into the Delta after an island failure, the additional dispersion associated with water continually pulsing through the breach is not adequately captured for failures in all parts of the Delta. 1.5.2. Calibration and Error  Calibration and verification of WAM is discussed in depth in Appendix E of the report from URS (2007). WAM was calibrated for the period from October 1991 through September 2003, a period with no breaches. Both URS (2007) and Fleenor et al. (2008) show that the average error for salinity values based on this calibration are below 20 percent for most stations within the interior Delta (east of Chipps Island). Despite this, care should be taken in interpreting results, especially in outlying Delta stations. As illustrated in Figure A2, in the Appendix, WAM results near the boundaries of the Delta may reflect boundary salinity inputs more closely than actual tidal dynamics.

Figure 1.1. Schematic of files called and generated while running of WAM

9

Figure 1.2. Essential files necessary for running WAM

10

1.6. File Directory  For simplicity, WAM should be split into three main folders that separate different components of the model. As a default, the basedata folder contains boundary condition data and information about internal flows and consumptive uses in the Delta. The default folder geometry houses the file that contains the entire 1-dimensional channel network that serves as the computational domain of the model. Finally, the default folder run-calibdaily contains the majority of the input and control files necessary for directing the model to the other files, and serves as the default location for model output files. All file names and locations used in this manual are provided as defaults, and may be changed by the user as long as proper care is given to the interconnectivity. Additionally, the file structure for separating various parts of the model is presented here in a suggested form. When changing filenames, file locations, or the file structure, the points where files and locations are specified in the model input files must reflect the changed name and location.

Figure 1.3. Default file directory housing the WAM model

11

1.7. Model Geometry  1.7.1. Channel network  As shown in Figure 1.4, the model domain for WAM consists entirely of 1-D channel networks composed of line elements connecting nodes. Elements are 500m long and represented with trapezoidal cross-sections. Velocity and salinity values are averaged across channel cross-sections within this network. The fact that the model uses entirely 1-D geometry greatly simplifies the calculations necessary to predict flow and salinity in the Delta. When the elements and nodes are generated and put together to create the 1-D network for WAM, two files are written that store the geometry data. The first file, drms-xx.geo, located in the calibdaily folder, provides the necessary geometry data for running WAM. The file is not intended for direct editing by the user. The second file is drms-xx.msh, a file that can be manipulated through the RMA interface tool RMASIM. Both files should be located in the geometry folder.

Figure 1.4. 1-D channel network used in WAM     

12

1.7.2. Island and Channel Elements  The 1-D network is composed of island and channel elements, and the distinction between these two types is important. Figure 1.5 gives a distinction between island and channel elements in the vicinity of Sherman Island. Channel elements have associated geometry that reflects actual channel bathymetry measurements. The length-to-width ratio of channel segments is high, which allows several important simplifying assumptions regarding the mechanics of shallow water flow, and also allows transfer of dispersion information from more complex models to WAM with good confidence. These elements are associated with trapezoidal cross-sections and are assumed to always carry at least a minimal amount of flow. Island elements have geometry information based on the topography of Delta islands, most of which have never carried any flow (apart from irrigation). The length-to-width ratio is relatively small, making it more difficult to properly represent flooded islands with a 1-D network. To compensate for the great size of many of the islands, island nodes are strung together in many cases to form multiple channels through the island, representing possible tidal excursion routes, if the islands were ever flooded. It is difficult to model dispersion in flooded islands, since actual dispersion data for such an event are nearly absent from the literature.

Sherman Island

Sacramento R.

San Joaquin R.

Channel nodes

Island nodes Sherman Island

Sacramento R.

San Joaquin R.

Sherman Island

Sacramento R.

San Joaquin R.

Channel nodes

Island nodes

Figure 1.5. Island and channel nodes in the vicinity of Sherman Island

13

1.7.3. Channel simplifications  Since the Delta consists of an extensive network of channels, flows in many channels were aggregated to gain computational efficiency. Conceptually, WAM treats the Delta as having a main axis along the San Joaquin River, with fresh water transferred from the Sacramento and Mokelumne Rivers on the north side of this axis to the export locations on the south side, as shown in Figure 1.6. The schematic does not show all channels included in the network, but indicates the most important flow paths and internal flow locations. Delta internal consumptive use flows were aggregated using multiple linear regressions. Regressions were made between net flow in the nearest quadrant (e.g. northwest, northeast, southeast, southwest) of the Delta and each internal flow location. For channels with temporary barriers, separate regressions were made with and without a closed barrier. The methods are discussed in more detail by URS (2007, Appendix D).

Figure 1.6. Simplified conceptual map of the 1D model network. Modified from URS (2007)

14

Internal flow locations considered by WAM include the following:

• Delta Cross Channel and Georgiana Slough: transfers water from Sacramento to Mokelumne River through gates operated at the Delta Cross Channel

• Threemile Slough: connects Sacramento and San Joaquin Rivers between Sherman and Twitchell Islands

• False River: connects San Joaquin River and Old River near Franks Tract • Turner Cut: transfers water between San Joaquin River and Middle River • Old River at Head: represents net tidal flow from the San Joaquin to Old River at

Head. Temporary barriers operated at Grantline Canal and the Old River affect flow

Delta Internal Consumptive Use (DICU), the use of Delta water on islands for agriculture and other purposes, is accounted for using aggregated locations for water extraction and return. The locations are indicated in Figure 1.6, and are a simplification of the reality, an extensive set of pumping locations spread across over 70 islands. DICU is addressed with the NDAL submodel, described in Section 4.3.

1.7.4. Viewing node and element properties  Element and node properties can be viewed using RMASIM, which is a proprietary tool developed by RMA. Actual availability of this tool is subject to arrangement with RMA. To edit or view the components of the channel network, the user must first start the program file, rmasim.exe. From the file menu select open project (Figure 1.7). In the popup menu, select drms-geometry.rsp and select open.

Figure 1.7. Opening the project that contains the computational mesh To view the computational mesh, select the edit menu. Next, select “Computational Mesh” and in the popup menu choose drms-48.msh and select open (Figure 1.8).

15

Figure 1.8. Opening the computational mesh editor Once the mesh editor is open, the 1-D network can be viewed in detail. To see a particular region in higher detail, select the magnify tool (Figure 1.9). With the left mouse button, drag a rectangular region that you would like to see up close. When finished dragging, right click with the mouse to zoom.

To see a region in detail, select the magnify tool

To see a region in detail, select the magnify tool

Figure 1.9. Finding the “zoom" tool in the mesh editor Once a region of interest in the Delta is magnified, it can be useful to see properties of the elements or nodes. The properties can be viewed by accessing the map dropdown menu. From the dropdown menu, choose Display options and mesh. When the box appears, a number of properties can be made visible on the view panel. To view channel geometry, check the "1-D Channel Geom" box (see Figure 1.10).

16

Figure 1.10. Display options for the computational mesh Viewing channel geometry, shown in Figure 1.11 below, allows the user to see how the 1-D network of WAM approximates the actual channel system in the Delta, and how it addresses flow through inundated islands.

Channel flow in Sacramento River

Approximated flow through flooded Twitchell Island

Channel flow in Sacramento River

Approximated flow through flooded Twitchell Island

Figure 1.11. Geometry of channel and flooded island network

17

1.7.5. Node and element numbering  It may also useful to view the numbers of the elements and nodes that make up the network. Node and element numbers are referenced in many of the user-defined files that control WAM (for example, inflow locations are specified by node number), and can be referred to easily by viewing the model network.

Figure 1.12. 1-D line elements (left) and nodes (right) with numbering displayed Editing nodes in the computational mesh Every node in the 1-D channel network contains spatial data in the form of a cross-section profile with a corresponding wetted area that changes with water level (see Figure 1.13). The cross-section at each node is defined by (1) its bottom width, (2) its left and right bank slopes, and (3) the elevation of the bottom of the channel. A fourth parameter, “off-channel storage”, accounts for areas to the left or right of the channel that are only wet during certain water elevations (e.g. tidal marshes). Usually this term is neglected unless a significant amount of water is consistently flowing through a substantial tidal marsh adjacent to the channel network. To edit the cross-section data at a node, select the arrow tool and left click on a node. In the dropdown menu, select edit. The Node Editor window that appears allows the user to change any of the attributes of the node.

18

To edit a node or group of nodes, select the arrow tool

To edit a node or group of nodes, select the arrow tool

Figure 1.13. Editing a node in the mesh editor

1.8. Base Data  WAM requires boundary condition data for river inflow points, export data for the pumps at several pumping facilities, the Delta Cross Channel operation and data of internal consumptive uses of water within the delta. The type of data necessary consists of:

• river inflows • water exports • consumptive uses • concentration data of salinity or any conservative tracer that is of interest to the

user

In many cases, salinity will be the most important parameter, but in other cases, sediment, dissolved organic carbons (DOCs) and many other constituents may be of interest. Large databases of flow and salinity data are available in the Delta through the Interagency Ecological Program (IEP) online at (http://www.iep.ca.gov/). Models such as CalSim and DayFlow provide data based on calibrated algorithms and fill in information where actual measurements are absent. At some sites, such as Vernalis on the San Joaquin River, or Freeport on the Sacramento River, sediment transport data are available. Available data in the Delta are by no means perfect, and in some cases reported data may be off by a considerable margin from realistic values (Fleenor et al., 2008). Errors can result from a misuse of datum, failure to calibrate equipment, or simple human error on some cases. In any case, available data should be viewed with the same type of caution as model results. Together, model outputs and available data provide WAM with the information it needs to perform simulations. The two primary uses of these data are for (1) use as boundary

19

conditions at upstream and downstream sites, and (2) comparison of model results with actual values within the Delta for calibration and verification. As a default, boundary condition data are located in the basedata folder, Figure 1.14:

Figure 1.14. Contents of the basedata folder Within the basedata folder, 2005A01ADV.DSS and 2005A01ASV.dss are CalSim output DSS files, which will not be discussed here. The file CalibDaily.DSS is the source of all flow and water quality data used during WAM model runs. A viewing application capable of reading the .dss file extension is necessary to read this. HEC-DSSVue, is a free application capable of reading, creating or modifying these files, and is provided by the Hydrologic Engineering Center (HEC) of the U.S. Corps of Engineers at (http://www.hec.usace. army.mil/software/hec-dss/hecdssvue-dssvue.htm). An example layout of the file CalibDaily.DSS shown by this viewer is shown in Figure 1.15.

Figure 1.15. Layout of CalibDaily.dss using HEC-DSSVue

20

Within CalibDaily.dss, data can be viewed by selecting a record and clicking on the Plot button, shown below in Figure 1.16.

Figure 1.16. Plotting a set of data from a dss file using HEC-DSSVue Data can also be displayed in tabular form, using the Tabulate button. The data can be copied directly from the popup window to a spreadsheet (see Figure 1.17). For heavy use, one should consider using the Excel/DSS utilities also available at the HEC website.

Figure 1.17. Displaying DSS data in tabular form.

21

2. Running WAM 

2.1. Potential applications for WAM  Running a scenario in WAM requires the user to make a number of decisions regarding model inputs, expected outputs and the roles of the various parts of the model. WAM was designed specifically for the purpose of analyzing a very large number of possible cases in the Delta, both historical and hypothetical. Events of interest which fit into modeling capabilities include:

1. Sea level change: Rising sea levels will increase the tidal influence in the Delta and make it more difficult to maintain the Delta as a fresh water system. DWR has begun making initial assessments of the effects of climate change and associated sea level rise on the Delta. WAM has the capability to model the effects of various changes in sea level (Lund et al., 2008; Fleenor et al., 2008).

2. Changes in inputs from rivers that lead into the Delta: River inflows into the

Delta are affected by a number of issues related to upstream management. Continued change in management practices will provide a number of questions regarding long-term effects to the water quality in the Delta. A current example is the restoration of San Joaquin River flows to a higher fraction of their historical value. A flow increase is expected to begin in 2009. Currently, the San Joaquin River supplies elevated salinity water to the Delta, and a potential use of WAM would involve modeling the effects of increasing San Joaquin River flows.

3. Island Breach events: Island breaches are of particular interest because the cost

of repair is substantial. Breaches also jeopardize Delta agriculture and exports by drawing salt water eastward from Suisun marsh. When this happens, many months can go by before the pumps that provide water to the SWP and CVP can return to operation. The risk of levee failures and subsequent island inundations is increasing, as islands continue to subside, levees age, and sea level rises (Lund et al., 2007; Lund et al., 2008).

4. Changes in Delta exports: The current plan for water exports from the Delta may not continue indefinitely. Recent work indicates that the Delta is not manageable as an exclusively freshwater ecosystem, and that fish resources, agriculture, and exports for municipal use are not all viable under the current system. Fleenor et al. (2008) analyze the effects of different types of water management strategies on water quality in the Delta.

22

2.2. Steps for Running WAM  The procedure for initializing and running WAM is straightforward, despite the current lack of a graphical user interface. The steps reviewed below are the most important, but are not exhaustive; modeling certain scenarios will in some cases require different steps of initialization. However, the outline provided here is adequate for the majority of scenarios, and is summarized by a schematic in Figure 2.1. Setting a timeline: The model timeline is specified in the file wamconfig.dat (see Section 3.1). To limit model computation time and disk space, the timeline of the model scenario should be limited to several decades within the historical period. An important consideration is that the first 2-6 months of model simulation will often reflect the initial salinity conditions (which are estimates in some cases) rather than the true effects of flows and tidal exchange. Boundary Conditions: Boundary conditions (discussed in Section 3.4) should not be altered unless the user wishes to analyze the effects of changing salinity, flow, or export conditions. Changing these parameters will require editing the file CalibDaily.dss and storing the new versions of it (reflecting each of the user-made changes) within the file system. Gate Operations: Delta Cross Channel Gate operations have not been discussed thoroughly in this manual, and it is not recommended that they be changed without an understanding of their purpose and current use in the Delta. The "internal flows" section of the boundary conditions control file wam-flows.dat (Section 3.4.2) control gate operations, as does the input field "USEORHTS" in the file hydro-wam.dat, which controls the operation of the barriers on the Old River and elsewhere. NDAL Submodel: The NDAL submodel is discussed in Section 4.3. The effects of this submodel on flows and water quality in the Delta can be turned on or off by the user. Switching the effects off is equivalent to forcing base conditions throughout the historical record. Water Operations Submodel: The water operations submodel is described in Section 4.2. As with the NDAL submodel, the user can control the effects of this submodel on flows and water quality in the Delta. Island Breaches: Island breaches are discussed in two sections of this manual. All possible breach scenarios are introduced in the islands.dat file described in Section 4.1. The scenarios are activated by the breach sequence control file, wamseq.dat, which is described in Section 3.2. If the user decides not to include island breaches in the modeling scenario, wamseq.dat must be checked to make sure that no sequences are currently activated. Sea Level Rise: Sea level rise is accounted for in two ways in WAM. The user-specified value (in meters) of sea level rise must be added to the mean sea level at the downstream

23

boundary condition, in the file rma2simple.rm2. Additionally, an input field requires the user to specify sea level rise in the file wamseq.dat (see Section 3.2). If no sea level rise is desired, the first step can be ignored. However, the sea level rise must be explicitly set to 0.0 feet in wamseq.dat. Initiate Model Run: When all steps are complete, the user can initiate the model run by starting the file run-wam.bat. Once initiated, the input files edited by the user are called on by the model in the order shown in Figure 2.1.

Figure 2.1. Steps required for preparing and running WAM

24

2.3. An Example Case  In this section, steps will be shown for transitioning WAM from one example scenario to a second, with results shown in Section 2.5. Initial Scenario: Timeline: January 1990 - December 2003 Boundary Conditions: Historical Values Gate Operations: historical Island Breaches: None NDAL submodel: Base case Water operations submodel: Base case Sea Level Rise: 1 foot Second Scenario: Timeline: January 1990 - December 2003 Boundary Conditions: Salinity Reduced at all upstream boundaries by 10% Gate Operations: historical Island Breaches: None NDAL submodel: Base case Water operations submodel: Base case Sea Level Rise: 0.0 feet Editing WAM inputs to correspond to the second scenario 1. Create a new boundary condition data file: In order to protect the original boundary condition data, a copy of CalibDaily.dss needs to be made. Next, the user needs to rename the copy so that the model pulls boundary conditions from the modified file, rather than the original. Once this is renamed, it is necessary to edit the name given for this file in hydro-wam.dat (See Section 3.3.1), since this is where the model is directed to the boundary condition data. 2. Change salinity at inflow points The salinity for all of the major river inputs to the Delta needs to be decreased by 10 percent by editing the boundary condition control file, wam-flows.dat. Some of these inputs are specified as constant values that can be changed directly within this file. Others need to be changed by editing the DSS file created in the first step. As shown in Figure 2.2, each input point to the Delta has a reference line that controls flow data followed by a reference line that controls water quality. In some cases, there are more than two lines present for each input point. When this is the case, several of the lines are

25

preceded by a semicolon (;). These lines are not read by the model. The active lines that must be edited are those which are not preceded with a semicolon.

Figure 2.2. Changing boundary salinity conditions in wam-flows.dat For boundary condition values that must be changed in the new user-edited version of CalibDaily.dss, the reference lines must be located within a DSS viewing application. The method for this is described in Section 3.4.1. Once the specific boundary data line is located, the values need to be changed by using the utilities menu. Within this menu, choose math functions (see Figure 2.3). In the new window that opens, open the arithmetic tab, set the operator to "multiply", and select a constant of 0.9 (reducing salinity values by 10 percent by multiplying all values by 90 percent). When the salinity values are changed, they should match the numbers given in Table 2.1. Table 2.1. Salinity values at Delta inflow points for initial scenario and second scenario Station Initial scenario salinity

(μS/cm) Final scenario salinity (μS/cm)

Sacramento River at Freeport

150 135

Yolo Bypass 150 135 SJR at Vernalis Variable variable Mokelumne 200 180 Calaveras Variable variable

26

Figure 2.3. Editing the salinity values in wam-flows.dat 3. Adjusting sea level Sea level rise was set in the initial scenario to 1.0 ft. For this scenario, it needs to be set to 0.0 ft. To change this, the user must first open the file rma2simple.rm2, which is the template file used for providing input to the RMA2 engine. The adjustment needs to be made before RMA2 is called by WAM because RMA2 calculates flows and water levels used by other parts of the model. Within rma2simple.rm2, there are several locations where the sea level at the North Bay must be adjusted. Figure 2.4 shows the first location, which is near the top of the file. The other locations occur at lines denoted by the label "/* tide at GG". There are four of these locations, one of which is shown in Figure 2.5. The final change that the user must make regarding sea level rise is in the file wamseq.dat. The procedure is discussed in detail in Section 3.2.

27

Figure 2.4. First entry of mean sea level in the file rma2simple.rm2

Figure 2.5. Locations of mean sea level within the file rma2simple.rm2 4. Starting the model run To run the model after the changes described in steps 1 through 3 are made, the user must execute the file run-wam.bat. The execution produces a set of output files, most of which allow the user to debug various parts of the model. For a complete list of output files, refer to Table A2 in the appendix. The most important output file for analysis is hydrowq.dss, a DSS file that stores all of the hydrodynamics and water quality information generated during the model simulation. The file displays results for each of the nodes in the 1-D model network that were specified by the user as display points, based on a procedure shown in Section 3.3.3. The next section describes the procedure for displaying the results and transferring them to figures.

28

2.4. Analyzing model results  WAM data stored in DSS files can be easily transferred to spreadsheets, and it can also be displayed using the RMA tool RMAPLT, which is a proprietary tool of RMA that is not discussed here. If the application HEC-DSSVue is used for displaying DSS data produced by WAM, data can be copied directly from the window containing tabulated data and entered into a spreadsheet program for further analysis or for plotting figures. There are also Excel utilities available from HEC that ease transfer of files into Excel from DSS.

Figure 2.6. Transferring data from hydrowq.dss to a spreadsheet

29

2.5.  Sample Results  As a sample result of a WAM simulation, the result of changing the salinity by 10 percent at all boundary conditions is demonstrated in Figures 2.7a and 2.8a, for two stations in the Delta. Figures 2.7b and 2.8b show the modeled response for the same stations if flows were changed, rather than salinity. The case of reducing salinity by 10 percent was discussed above as an example for running WAM. The results indicate that the changing salinity of Delta inflows has relatively little effect over the total salinity, since the majority of the salt in the Delta is derived from tidal water arriving from Suisun Bay, rather from river inflow sites. Changes in net flow rates into the Delta at the boundaries appear to have a greater effect. For example, as shown in Figure 2.7b, reducing the inflows to the Delta by 10 percent increases the salinity at Jersey Point by over 20 percent during the summer of 1981.

Figure 2.7a. Model response at Jersey Point (RSAN018) for changes in salinity of Delta inflows

30

Figure 2.7b. Model response at Jersey Point (RSAN018) for changes in Delta inflows

Figure 2.8a. Model response at Rio Vista (RSAC075) for changes in salinity of Delta inflows

31

Figure 2.8b. Model response at Rio Vista (RSAC075) for changes in Delta inflows

32

3. Basic Edits  The files described in this section provide the information necessary for WAM to perform most simulations, and to establish filenames and locations for outputs. They are the most likely to be edited, and are depicted in the central columns on figures 1.1 and 1.2. Basic edits include:

• editing names and locations of files that WAM needs • setting the timeline of simulations • creating a sequence of island breaches • editing the commands to the HD submodel • changing boundary conditions

In most cases, the files consist of several pages of ASCII data. The lines of ASCII text provide information that allow the user to manipulate how WAM uses the various submodels. The data in these files also determine the simulation timeline, tell the model where to find boundary condition data, and perform other key tasks. Data in these files are typically arranged:

• in rows, where filenames of inputs, outputs, or templates are specified by the user so they can be found and called on by the model, or

• in column format, where elements of columns refer to specific islands or breach locations, and tell the model to perform certain actions.

The following section describes the meaning of inputs in these files.

3.1. Control file information and simulation timeline  wamconfig.dat is the first control file read by run-wam.exe. The file:

• directs WAM to the files that control the island data and the NDAL, water operations, and HD submodels

• creates an output log file and controls the amount of data recorded from the simulation

• sets the timeline (and time intervals, if a breach is simulated multiple successive times) of model simulation

The various parts of this file reflect the fact that WAM can be used to simulate either a single set of unique breach events throughout the historical period, or a single breach event occurring at multiple alternate times during the record. Some inputs of this file correspond only to the latter case. The components of the file are shown below in Figure 3.1, and described in the subsequent section.

33

Figure 3.1. Contents of the file wamconfig.dat 3.1.1. Introducing island information and submodel control files 

1. ISLANDFILE: Specifies the file islands.dat, which provides basic island and breach information (see Section 4.1)

DICUCONTROLFILE: Specifies a file that governs Delta Internal Consumptive Use (DICU). The NDAL submodel calculates consumptive use, and is controlled by the file dicu.dat. Within this manual DICU and NDAL are sometimes interchanged, since both titles have been given to the same submodel throughout the development of WAM. Essentially, the NDAL submodel accounts for DICU as well as other evaporation, precipitation and other factors. It is described in detail in Section 4.3.

WATEROPCONTROLFILE: Specifies the file that controls the water operations submodel, water-op.dat (see Section 4.2).

34

HYDROCONTROLFILE: Specifies the file hydro-wam.dat, which controls the HD submodel (see Section 3.3).

3.1.2. Setting WAM output log preferences 

2. LOGFILE: Specifies the file (wamconfig.out ) which WAM uses to record its initialization and calculation steps.

LOGLEVEL: Sets the level of detail provided in the log file. Setting this to "0" provides no log data, while setting it "10" displays every step that the model takes. Raising the log level is useful for debugging, but doing so also takes up more disk space.

3.1.3. Setting WAM simulation timeframe  This section includes commands which reflect the initial use of WAM - to run each breach sequence multiple times with different start dates. It is important to note that WAM can be set to perform this type of action or it can be modified to run a specific set of breach events that do not repeat.

3. FIRSTYEAR: First year of model simulation

FIRSTMONTH: First month, expressed as "mm" (e.g. 10, for October)

MonthInterval and YearInterval: These categories were included because they were necessary for the types of model simulations that WAM was originally intended to perform. When modeling the effect of a single breach event occurring at different times throughout the historical record, it is necessary to specify intervals at which the same breach event is run. Setting MonthInterval to "12" and YearInterval to "100" prevents WAM from running a scenario multiple times. FIRSTWETMONTH: Not currently used by the model LASTWETMONTH: Not currently used by the model

3.1.4. Specifications for running single, repeated breach events 

MINSIMMONTHS: Minimum simulation time for WAM to run a series of repeated breaches

35

MINRECOVERYMONTHS: Minimum number of months required to repair a levee breach LASTSIMMONTH: Forces WAM to end a breach simulation on a given month for each year.

3.1.5. Setting a timeline with unique, non­repeating breach events 

To simulate a time period with unique breach events, use the FIRSTYEAR and FIRSTMONTH commands to indicate the starting time of the breach. To adjust the time frame of the simulation, modify MINSIMMONTHS to adjust the duration. The simulation will end after the specified number of months. To prevent breach events from repeating for each year of the simulation, set MonthInterval to "12" and YearInterval to "100".

3.2. Breach Sequence  The file islands.dat, called by WAM, stores information for each possible breach scenario. The information includes identification numbers that describe all possible breaches by island, location, and size. The purpose of the breach sequence submodel is to specify a series of breaches within the simulation time frame from the list of potential breach locations given in islands.dat. The user edits this submodel by modifying the files tamseq.dat to specify which islands breach, and at what time during the simulation. The breach sequence consists of:

• an initial breach event • a repair (if desired) • pumping to extract flood water that intruded during the breach, and • recovery

Even when no breaches are desired for the simulation period, some effort is required to edit this submodel. Simulating a sequence in which no breaches occurs requires that the user specify the "baseflow" scenario. Consideration must be given to the stability of the model when scenarios requiring multiple breaches are developed. Also, dispersion must be taken into account when simulating island failures. Dispersion in a flooded island is not as simple as dispersion in a narrow channel, and must be provided from 3-D model results of flooded islands, as discussed in Section 1.5.1. These have been provided from runs of the RMA Bay Delta and TRIM/UnTrim models, and are available in the file dispersion.dat, described on page gg. Figure 3.2 gives an example of a wamseq.dat layout.

36

Figure 3.2. Example layout of the file wamseq.dat, which allows users to edit the breach sequence submodel

1. SEQNAME: A name string that describes the model event. It may or may not include an actual breach event. Examples of events include ‘baseflow’, ‘seismic’, ‘flood’, and several others.

2. SEQCODE: A string code used to identify sequence output (file names and .dss

paths). Spaces are not allowed.

3. SEQTYPE: A string to allow the user to edit the sequence event type. Type identifiers include: 0 (blue sky), 1 (seismic), and 2 (flood).

37

4. SEALEVELRISE: The value does not set the value of sea level rise in the model.

Rather, it is a measure of the effect of sea level rise on dispersion. The amount of sea level rise is specified in the file rm2simple.rm2 as the downstream stage boundary condition, described in section 2.3.

5. BREACH: Represents an individual breach event. The string is represented as

(Day of breach, Island ID, Breach ID)

6. REPAIR: Individual breach repair. The string is represented as (Day of repair, Island ID, Breach ID)

7. PUMPSTRT: Beginning or change in pumping out of the breached island. The

string is represented as (Day of event, Island ID, pumping rate (cfs))

8. RECOVER: Event of full island recovery. The string is represented as (Day of recovery, Island ID)

 

3.3. Hydrodynamics and Water Quality (HD) Control File1  The submodel responsible for controlling the hydrodynamics and transport of salinity in the Delta is in some ways the most important component of WAM. It allows the user to directly modify parameters that are needed by the RMA2 and RMA11 engines to simulate Delta hydrodynamics and salt transport. Conceptually, the main tasks that the HD submodel performs are the following:

• Simulate island flooding • Find volume needed to flush salt out of Delta • Simulate salt transport during the flushing stage (when reservoirs release water to

bring the Delta back to the pre-breach state) • Determine whether export pumping is possible and find how much freshwater

inflow is necessary. It is connected to the water operations submodel (Section 4.2)

• Simulate salt transport during and after recovery (or in normal conditions if no breaches are activated)

To perform these tasks, the HD submodel interacts with the NDAL and water operations submodels. When no island breaches are simulated, the extent of these interactions is limited. By editing the file that controls this submodel (as a default, hydro_wam.dat), the user controls whether or not the model allows the water operations or NDAL submodels to have any effect on flow or salinity calculations in the Delta.

1 HD submodel authored by John DeGeorge of RMA email: jfdegeorge@rmanet.com

38

The tasks outlined above can be altered or modified by the user by manipulating inputs in the default file hydro_wam.dat. The actions controlled by this file include the following:

• Directs WAM to input files and controls the output filenames and locations. • Controls which input data values (e.g. CALSIM, DAYFLOW, or water quality

values) are read by the model. Section 1.8 describes these inputs. • Switches the water operations and NDAL submodels on or off (i.e. tells the model

whether or not to recognize the influences of water operations, DICU, or changes in water cycling when an island fails)

• Sets restart options, for cases when the user wishes to model many possible scenarios within the same hydrologic record

• Tells WAM how to account for dispersion of saline water in the channel and flooded island networks

• Allows the user to specify which nodes within the 1-D model network will produce output data for model simulations

• Specifies water quality standards for different types of years (i.e. wet, dry, etc.) at several locations in the Delta.

• Allows the user to specify representative nodes for island breach locations and adjacent channel nodes. The nodes are used in the NDAL submodel.

• Creates possible breach scenarios and links breach locations from islands.dat to grid elements. It is used in the breach sequence submodel, discussed in Section 3.2.

Figures 3.3 through 3.8 display the components of the file, which are explained in sequential order.

39

3.3.1. Calling essential files 

Figure 3.3. Specification of input, output, and restart files. Switches for turning on/off the effects of water operations and NDAL submodels on Delta hydrodynamics and water quality

1. RMA2TEMPLATE: Directs the WAM model to a template file which creates inputs for the hydrodynamics engine, RMA2. In turn, RMA2 generates flows and water levels that are used on various parts of WAM. File rm2simple.rm2 is the default file in this case. For the most part, the file draws on information already specified in other user-edited control files.

RMA11TEMPLATE: The file specified here (rma11simple.r11, in this case) by the user allows WAM to generate a template for presenting inputs to the RMA11 model. RMA11 generates water quality data (e.g. salinity transport) using the hydrodynamics information given as outputs from RMA2.

2. RMA2INPUT: The file specified here (z.rm2, as a default) provides inputs for the RMA2 model written from the template in rm2simple.rm2.

40

RMA11INPUT: The file (z.r11, as a default) provides inputs for the water quality model, RMA11.

3. HYDROBCFILE: The specified file, wam-flows.dat, defines DSS data to be used for boundary conditions in WAM. The file is discussed in Section 3.1.

HDYDRODSSFILE: Refers to the DSS file CalibDaily.dss that contains all the flow and water quality data, which is used by wam-flows.dat to create boundary conditions for WAM. DSSSTARTDATE: Beginning date of the desired simulation time expressed in the format: ddmmmyyyy (e.g. 01Apr1986) DSSENDDATE: Ending date of the desired simulation time, expressed in the format: ddmmmyyyy (e.g. 31Dec2006)

4. USEBASECSFLOW: A switch that refers to the water operations submodel. Setting this to "0" allows the water operations submodel to change flows in the Delta used for water quality calculations in RMA11. Setting this to "1" has the opposite effect, equivalent to using historical water operations, regardless of any changes to the Delta (base case). For any simulation other than the base case, the water operation submodel should be taken into account (i.e. this switch value should be set to "0")

USEBASEDICU: A switch that refers to the NDAL submodel. A value of "0", here allows the NDAL submodel to effect flows in the Delta used for water quality calculations in RMA11. A value of "1" prevents NDAL from changing flows. NDAL logic is necessary for accurate water quality measurements. Therefore, the switch value here should be set to "0" for all simulations, unless the NDAL submodel is being recalibrated.

5. USEORHTS: A switch that allows the user to specify whether the gate at the Old River Head station is operating by a time series or regular schedule.

6. INPUTRST: Allows the user to specify whether the model produces "restart

points", which serve as checkpoints within a model simulation. When these are generated, a model simulation can be resumed from one of these points with the calculated flow and salinity conditions as initial conditions. Creating restart points makes it easier to run scenarios in which a single breach event is modeled at various points in the historical record, because it prevents any need for beginning every successive model run from the year 1921. It may not be necessary when a model scenario involves a single breach occurring at a single time in the historical record.

41

Setting this equal to "1" causes WAM to generate restart points. A value of "0" tells WAM not to generate restart points. SAVERST: A value of "1" causes WAM to save restart points as output files. A value of "0" prevents this. An advantage of saving restart points is clarity, since it allows the user to see the conditions for each possible restart point and choose when to insert a simulation period within the historical record. A disadvantage is file space consumption, as this generates a large number of output files. INPUTRSTROOT: This input tells WAM where to look for restart files within the file directory when they are called during a model run.

3.3.2. Dispersion and 'Displacement Volume' information

7

8

9

77

88

99

Figure 3.4. Dispersion and 'displacement volume' section of hydro-wam.dat

7. DISPFILE: The file entered here (dispersion.dat, as a default) contains dispersion information regarding Delta channels and flooded islands.

8. Tuning parameters regarding 'displacement volume': When an island fails, the

new volume is typically too large to be filled by Delta freshwater inflows alone. As a result, salt water from Suisun Marsh begins to flood into the Delta, sometimes far enough to cause irrigation or exports to the SWP and CVP to halt temporarily. The volume of fresh water required to push the salt water out of the Delta to a pre-breach location is an important parameter which varies based on the phase of the tidal cycle during the breach and the volume of the inundated island. The "displacement volume" is supplied by upstream reservoirs, which may have difficulty in allocating the correct amounts depending on the dryness of the year.

42

The parameters presented here are related to the fresh water volume required to flush the intruding salt water boundary out of the Delta. They were set during the initial creation of WAM, and should not be adjusted by the user without contacting John DeGeorge of RMA.

9. Tab delimited data for 'displacement volume' data: The data also correspond to

different possible scenarios for releasing "displacement volume" water into the Delta. It should not be edited by the user.

3.3.3. Assigning model output nodes

Figure 3.5. Assigning stations for which output data will be given after WAM completes simulation

10. Choosing output locations: In this segment of the file, the user can choose nodes in the 1-D channel network to assign as data output locations. Each row corresponds to a station for DSS data output. If no nodes were chosen here, WAM would produce no flow or water quality results. To edit this section the user should choose locations of interest in the Delta and locate the nearest node points by following the procedure described in Section 1.7.4. The "ANG" column requires an approximate orientation of the elements attached at each end of the chosen node, given in radians. The "Station Name" column allows the user to specify a name for the nodes which are chosen as output locations.

43

3.3.4. Adjusting Water Quality Standards The next section of the file allows the user to edit standards for water quality at various parts of the Delta. The assignment is necessary because different legislative (or other administrative) acts in the Delta involving multiple stakeholders can require water quality to be maintained at a certain level for certain parts of the year.

11

12

13

Station name, as it would be seen in the IEP database. RSAC081 refers to the Sacramento River station at river mile 81 .

14

Generic station identifier

1111

1212

1313

Station name, as it would be seen in the IEP database. RSAC081 refers to the Sacramento River station at river mile 81 .

1414

Generic station identifier Figure 3.6. Setting water quality standards for stations in the Delta

11. EXPORTECLIMIT: The parameter controls the allowable salinity for exports of fresh water out of the Delta. Values given here should be provided in units of mS/cm

44

12. Describe the year-type identifiers used within this section. The type of year, which is relevant for water quality standards, is denoted as follows:

1: wet year 2: above normal 3: below normal 4: dry 5: critical

13. WQSTNAME: A generic station identifier. The first station listed in this section

(Collinsville in this case) is assigned a value of "1". The next station (Emmaton in this case) is given the value "2", and so on. No more than 10 stations can be entered into the water quality standards section of this file, and the numbering scheme was created for clarity. In the rightmost column, the user enters an actual name for the station.

WQSTSTRM: The value is identical to the generic station identifier, and should be the same in both columns WQSTPOS: In the left column, the user needs to enter the generic station identifier. WQSTNODE: The value in the left column represents the generic station identifier. The right column is the node number from the 1-D channel network (see section 1.7.4 for directions for finding nodes) that corresponds to the station of interest.

14. Water Quality Standard data (WQST): The "loc" column simply reiterates the

arbitrary island identifier given in WQSTNAME. The "yrtype" column refers to the year types listed above in (12). Values in the "month" column refer to months of the year, with "1" referring to January and "12" referring to December. Values in the "day" column refer to the start day during the month indicated in the column directly left of this value. Water quality standards are enforced starting on the day and month given in these two columns, and ending when a new day and month are introduced. The "EClimit" is the total allowable salinity in mS/cm starting on the date supplied by the 2 columns to its left and continuing to until a new date and limit is given (in the subsequent row).

45

151515

Figure 3.7. Assigning island reference nodes

15. Island reference nodes: The section assigns identification to nodes within each island. It should not be modified by the user.

161616

Figure 3.8. Breach identifiers (used in wamseq.dat; see Section 3.2)

16. Breach control structure data: The data in this section indicate the location and identification number for breaches on each island. It should not be modified by the user.

3.4. Specifying Boundary Conditions  WAM boundary conditions can be edited by directly altering base data (i.e. Calibdaily.dat, see Section 1.8) or by altering inputs in wam_flows.dat. The file wam_flows.dat directs the model to call on certain base data records contained in CalibDaily.dss to use as boundary conditions, and allows users to manually set constant values for boundary condition values of salinity or flow (see Figure 3.9).

46

Inside wam_flows.dat are two main parts:

1. a section regarding flow and salinity boundary conditions at river input locations 2. a section which addresses Delta internal flows.

For both sections, any parameter can be represented either by values in CalibDaily.dss, or other DSS file, or values set as constants by the user.

Boundary flow conditions given in .dss file

Boundary flow conditions specified directly as a constant value

Boundary flow conditions given in .dss file

Boundary flow conditions specified directly as a constant value

Figure 3.9. Contents of the inflow and water quality portion of the file tam-flows.dat

 

3.4.1. Flow and Salinity Boundary Conditions  As shown in the first section of wam_flows.dat, river inflow and salinity inputs into the delta are divided into nine boundary locations:

1. Sacramento River at Freeport 2. Yolo Bypass 3. San Joaquin River at Vernalis 4. Mokelumne River 5. Calaveras River 6. Old River (River mile 34) 7. Middle River 8. Old River (at Head), and 9. Napa and wastewater inflows.

47

For each station there is a reference to salinity and flow data. For data referenced in CalibDaily.dss, the reference line is written in a code that corresponds to the data’s location in CalibDaily.dss. HEC-DSSVue allows the user to search for data using six dropdown menus, called parts. The reference line has several entries separated by the “/” symbol. When read in order from left to right, these represent parts A-F, and the entry represents the word that needs to be selected in each menu. Empty parts are simply blank between the separators (e.g., //). Reference lines beginning with the symbol “;” are simply commented out and not read by the model.

Figure 3.10. Locating data corresponding to pathnames given in the file tam-flows.dat

3.4.2. Delta internal flows and exports  The lower half of the file wam_flows.dat consists of reference lines that account for internal flows and exports. Entries account for Delta outflows from pumping plants both within (DICU) and at the boundary (SWP, CVP, CCWD) of the Delta. In addition, Delta Cross Channel (DCC) flows and flows through several sloughs that connect main river channels in the Delta can be edited. The procedure for editing data described in the previous section is valid here as well. Delta Cross Channel and Georgiana Slough The first two lines read by WAM in this section, as indicated in Figure 3.11 in this default case ("FC_FLOW(931,5)..." and "FC_FLOW(-1,20)...") represent aggregated

48

flow through the DCC and Georgiana Slough. When the DCC gate is closed, WAM treats the internal flow in this section of the Delta as flow from Georgiana Slough only, with flows based on a regression between Georgiana Slough flows and net flows at a point in the northeastern quadrant of the Delta (URS, 2007). When the DCC gate is open, WAM uses a different regression accounting for flows in both channels. As discussed in Section 1.7.3 above, WAM treats these two conduits as a single channel in this way. Figure 3.11. Internal flows segment of wam_flows.dat Additional internal flow conduits The DSS pathnames for the flow regressions representing flows through Turner Cut, False River and Three Mile Slough are also indicated in Figure 3.11. Since there are no gates on these channels, WAM uses data from single regressions to characterize the flow in each of these conduits. Exports Also shown in Figure 3.11, exports are accounted for at the CVP, SWP and CCWD export locations. To model hypothetical export cases, the user can modify these export data. The datasets (indicated by the pathnames in this file) need to be altered in the file CalibDaily.dss. Modifications should not be performed on the original CalibDaily.dss file, but a copy, in order to maintain the original data.

49

4. Advanced Edits  The user modifications discussed in the previous section do not include certain edits that may pertain to more advanced modeling scenarios. For example, when modeling the effects of climate change or continued island subsidence, it may be necessary to change actual island characteristics or data pertaining to environmental parameters other than just mean sea level or the breach sequence. The advanced edits discussed in this section include:

• Changing basic island information • Modifying the water operations submodel • Modifying the NDAL submodel

Island volumes will increase over time, assuming continued subsidence. Volume changes would change the hydrodynamics involved with breach events, since larger volumes of water would be required to fill any newly opened islands. In turn this may affect upstream water releases, as more water would be required to flush out tidal water during the flushing and recovery phases (URS, 2007). To account for these changes, the file islands.dat needs to be modified, as discussed below. The water operations submodel should not be modified unless major changes occur regarding the operation of dams upstream of the Delta. The submodel uses information about the relative wetness of each year and breach information supplied by the breach sequence (Section 3.2) in conjunction with reservoir operations logic to determine upstream water releases into the Delta. The submodel is described here for illustration. Similarly, much of the NDAL submodel should remain unchanged. The NDAL submodel balances water losses from Delta islands by addressing aggregated DICU, evaporative losses and precipitation. Changes in DICU patterns or in climate can be modeled by modifying this submodel.

 

4.1. Island and breach information  The file islands.dat is one of the first files called by WAM after it is initiated. It serves the following purposes:

• Give each Delta island an identification number • provide basic island information, including geometry and elevations • List all possible breaches for each island • Give economic value to each island

The breach information is later called on by the HD submodel and the breach events are activated in the breach sequencing file, wamseq.dat, discussed in Section 3.2. The

50

economics portion of the file was developed by URS, and will not be addressed here. It should not be edited by the user unless it is desirable to model a breach scenario that has ot already been introduced in this file. n

 4.1.1. Island Identification and Spatial Data  The first section of the file islands.dat addresses basic island spatial data and identification information, which are later accessed by other parts of the model. As with the later sections, data are column-separated. Figure 4.1 displays some of these data. The columns are identified as follows: ID: Island identification number, assigned in alphabetical order NAME: Island name InitFlood: A switch that indicates whether the island is initially flooded or intact. "1" indicates that the island is flooded, while "0" indicates that it is intact. Perimeter: Island perimeter, measured in feet Min Elev: Minimum island elevation, measured in feet. Mean Elev: Mean island elevation, measured in feet. NGVD+0 water area: Water surface area of each island if they were to flood, estimated at the NGVD 29 datum. A value of "-1" indicates that the island is either flooded or has a minimal surface area. Volume: Island volume, in acre-ft. A value "-1" indicates that the island is either flooded or has a minimal volume.

Figure 4.1. Island identification and spatial data, from the file islands.dat

51

4.1.2. Identification of possible island breaches  The section defining breaches is also column formatted. However, misalignment of the column headings to the data with which they correspond can cause confusion. In some parts of the section, large names such as "Brannon-Andrus" from the island name column displace the rest of the data in the row to the right. Care needs to be given when viewing or editing the data. Columns are defined as follows, with increasing numbers corresponding to the sequence of columns from left to right: Column 1: Breach ID. Used later in the breach sequence file, described in Section 3.2. The number does not restart for each island. Each breach ID will have a characteristic island, and location. Column 2: Island ID. Assigned in the previous section of the file. Column 3: Island name. Assigned in the previous section of the file. Column 4: Breach number. An island can have one breach or several. T he numbering order restarts for each island. Column 5: The column is no longer used by the model Column 6: Breach width, measured in feet. The initial estimates given for this vary by island volume, ranging from 10 to 1300 feet. Column 7: Breach depth, measured in feet. Initial estimates vary from 0 to 10 feet Column 8: Initial breach state.

Figure 4.2. Breach identification section of the file islands.dat 4.1.3. Cross reference of island identification  The following section of the file (shown in Figure 4.3) is a linear map used to cross reference island IDs from the parts of WAM developed by with those developed by URS, and should not be modified.

52

Figure 4.3. Economic information segment of the file islands.dat

4.2. Water operations submodel2  Delta levee breach incidents that result in island flooding can substantially alter Delta water operations. A single flooded island will in some cases draw enough saltwater from Suisun Bay to stop the exports of freshwater to central and southern California for months, or longer. Furthermore, when an island floods, larger amounts of fresh water are required to return the salinity boundary in the Delta to its pre-breach state. Fresh water releases would be required to prevent jeopardizing agriculture in the Delta and exports to the rest of California. The water operations submodel is necessary because it allows WAM to simulate the complicated and time-varying responses to island breach events, as well as to long term changes such as sea level rise. A more detailed description of this submodel is given by URS (2007, Appendix B). The simulation of a levee breach scenario from start to finish is subdivided into three phases within the water operations submodel:

1. Island flooding: The inflow of water on a breached island immediately changes Delta hydrodynamics and water quality. The total volume required to fill the islands and restore overall balance comes from river inflows and from the saltwater downstream in the Suisun Bay. The hydrodynamics submodel is responsible for calculating the sources, amounts and distribution routes of the required inflows to the island, and characterizes the resulting Delta salinity distribution at the time a stable flow situation has been reestablished.

2. Flushing: During the flushing period, the model's focus is on freshwater inflows,

tidal mixing, dispersion, dilution of salinity, and reestablishment of a fresh water/saline water interface at the pre-breach location. The model assigns flushing releases from upstream reservoirs to push the freshwater/saltwater

2 Water operations submodel authored by Walter Bourez of MBK Engineering email: bourez@mbkengineers.com

53

boundary downstream. Flushing releases are limited by reservoir low-level outlet capacity and available water.

3. Limited Pumping: When upstream freshwater releases have returned Delta water

to a sufficient quality for export pumping, the model focuses on the maintenance of the Delta’s water quality and calculating how much water can be exported. Often, returning the Delta to a state in which water is acceptable for export requires full repair of any breaches, since flooded islands increase the volume of tidal flow and the resultant tidal mixing in the Delta. During the limited pumping phase, normal D-1641 provisions are assumed to be in force. D-1641 requirements can be found at < http://www.waterrights.ca.gov/baydelta/d1641.htm>

The purpose of the Delta water operations submodel is to represent these operations, assuming that stakeholders want to restore the island to its pre-breach state. The submodel is closely tied to the hydrodynamics and water quality submodels. When a breach event occurs, ongoing reservoir releases and Delta exports are managed based on the water quality of the Delta, so it is impossible to set release or export strategies without simultaneously evaluating the evolution of Delta water quality. The water operations submodel can be edited by manipulating the file waterop-base.dat, which contains information about upstream dam releases (i.e. inflows into the modeling domain) and pump intake amounts (anthropogenic outflows from the system). Necessary information here includes State Water Project (SWP) and Central Valley Project (CVP) demands and entitlements, dam capacities and outflow rules, and water travel times from dams to the Delta. The amount of water released to the Delta and exported at the two pumping facilities is controlled by the relative wetness of the year, which is indicated in the file yeartype.dat.

54

Figure 4.4. Contents of the file waterop-base.dat

4.3. NDAL submodel3  Within WAM, the Net Delta Area Losses (NDAL) submodel (also referred to as the Delta Internal Consumptive Use submodel) calculates the water balance in Delta islands resulting from inflows, outflows, seepage, and evaporation. Each of these processes has some effect from agriculture on the island, and can change drastically due to breaches. To represent NDAL within WAM, the Delta is divided into five groups that represent each of the major Delta flow paths as defined in the hydrodynamics and water quality submodel. NDAL focuses on irrigable areas within the Delta, as well as wetlands, permanently flooded areas, and waterways. When an island is not flooded, agriculture on the island calls for inflows of freshwater for irrigation, and water also seeps onto the island surface from the channels at a rate that is dependant upon the head difference between the water surface elevation in the channel and the surface of the island. Return flows from island agriculture add salinity to the water in the channels. Breach events drastically change the magnitudes of the components of this balance.

3 NDAL submodel authored by Stacy Tanaka of Watercourse Engineering email:stacy.tanaka@watercourseinc.com

55

Initially, inflows to the island and evaporative losses from the surface rapidly increase. When an island is repaired, seepage and return flow are resumed. Irrigation recommences if adjacent channel salinity is of appropriate quality. For a repaired island, NDAL checks channel salinity calculated by the HD submodel and determines whether adjacent channel water is fresh enough for agricultural use. In sum, the NDAL submodel assesses in-Delta water demands based on normal irrigation net consumptive use, breach event details, islands flooded, channel salinity, and repair progress (URS, 2007). To edit the NDAL submodel, the user can change any of the inputs in the file dicu.dat. In addition to this, several "flat" files (i.e. files that are only used as inputs for the NDAL submodel, and are not used elsewhere in the WAM) provide input data to the submodel. The “flat” files contain information regarding the various inputs and outputs in the water balance of an island, or group of islands, as well as information regarding calibration data and environmental factors such as temperature and carbon dioxide (Table 4.1). Table 4.1. The 'flat file' inputs into the NDAL submodel, and their purposes Information type Default filename Description NDAL control file Dicu.dat Main control file for NDAL data Island identification information

AreaInformation.txt Islands identified by assigned DICU group, type of area, etc.

# days in each month Dayspermonth.txt Number of days in each month Precipitation.txt Rainfall information Evaporation.txt Evaporation information, constant

across the entire Delta

Ambient environment characteristics

Maxsalinity.txt Maximum allowable salinity concentration

Co2inc.txt Increase in carbon dioxide in the atmosphere

Changes in ambient conditions

Airtempinc.txt Increase in ambient air temperature Diversions.txt Water diversions for agriculture Drains.txt Drainage rate Seeps.txt Island seepage when no breach has

occurred

Island characteristics

Seepbreach.txt Island seepage when inundated Calibcalsim.txt Makes net Delta consumptive use

calculated by NDAL match consumptive use calculated by CALSIM model

Calibdicudivseep.txt Makes net Delta diversion and seepage values match between those calculated by NDAL and DWR's DICU model

Calibration files

Calibdicudrn.txt Makes net Delta drainage rates match between those calculated by NDAL and DWR's DICU model

56

 4.3.1. NDAL Control File  The control file dicu.dat only contains one row of data separated by comma into 11 columns. In order from left to right, these columns can be explained as follows:

1. Determines whether NDAL draws data from text "flat files" listed in Table 4.1. or from a DSS file. (0 = DSS, 1 = flat file)

2. Stand alone option (0 = NDAL operates inside WAM, 1 = NDAL operates on its own)

3. Surface area units flag (0 = acres, 1 = ft2) 4. Volume units flag (0 = acre-ft, 1 = ft3) 5. Maximum number of evaporation groups present in the Delta (WAM was

developed to use evaporation rates averaged across the entire Delta) 6. Maximum number of precipitation groups present in the Delta 7. DSS starting month (October, in this case) 8. DSS starting year (1921) 9. Maximum simulation event, in days (29,950 is the number of days from October

1, 1921 to December 31, 2006) 10. File unit number 11. Print flag (0 = do not print, 1 = print)

Figure 4.5. Contents of dicu.dat 4.3.2. Island Identification Information  The file areainformation.txt (Figure 4.6) provides identification numbers for each island in the Delta regarding four categories that are relevant to the NDAL submodel: area type, area group assignment, evaporation group assignment, and precipitation group assignment. The categories represent the 4 columns of comma-separated data, in order from left to right. They are described as follows:

1. area type: A value of "1" corresponds to an island which has not been flooded. A value of "0" refers to inundated islands or wetland areas.

2. area group assignment: This regards the DICU grouping of Delta islands. Each island should fall within one of the five DICU groups

3. evaporation group assignment: Since only one value of evaporation is used for the Delta, this will remain a value of one, unless WAM is modified

4. precipitation group assignment: Islands are divided among 37 precipitation groups within the Delta.

57

Figure 4.6. Contents of areainformation.txt file 4.3.3. Number of Days in Each Month  This file was created so the NDAL calculator could produce results that could be converted to monthly-averaged values. The file consists of a single column, in which the first row represents the number of days in October, 1921. Each successive row gives the number of days in the following month, ending with the month of December, 2006.

Figure 4.7. Contents of dayspermonth.dat file  4.3.4. Ambient Environment Characteristics  Precipitation The precipitation.txt file, along with evaporation.txt and maxsalinity.txt, is written as a set of comma-separated columns in which rows represent months during the record (in sequential order from top to bottom) and columns represent the 37 precipitation groups in the Delta (in sequential order from left to right). Values were given by DWR, and should not be changed by the user unless a scenario involving increased rainfall over the historical record is desired.

58

Precipitation group 1

Precipitation group 2

Precipitation group 3

October, 1 921

November, 1 921

December, 1 921

Precipitation group 1

Precipitation group 2

Precipitation group 3

October, 1 921

November, 1 921

December, 1 921

Figure 4.8. File precipitation.txt, with row and column values defined. Values represent precipitation for a particular precipitation group during a specific month within the record Evaporation Evaporation rates used in NDAL represent the average pan evaporation rate for the Delta. The first column in the file evaporation.txt lists in sequential order the evaporation across the Delta for each month during the period from October 1921 to December 2006. Evaporation data should be viewed in a text program other than Wordpad, since the data columns don't align correctly. Textpad is a free alternative available at <http://www. textpad.com/download/>.

Figure 4.9. The file evaporation.txt, viewed with the application Textpad

59

Maximum salinity The file maxsalinity.txt, gives the limiting salinity for agriculture to operate for each island during each month of the 86 year hydrological record. Whenever salinity in the channels adjacent to any island exceed this limit (5000 μS/cm, as a default), irrigation stops. The primary causes for a rise in salinity are

• low freshwater inflows to the Delta (during dry years) coinciding with peak tides from San Francisco Bay

• island inundation (which draws saline water into the Delta) • sea level rise (drastically increases the influence of salt water tides in the Delta)

The maxsalinity.txt file is written similarly to precipitation.txt. Here, columns represent islands in the Delta, listed in sequential order from left to right (e.g. the leftmost column represents the first island listed in the file islandinfo.dat: Bacon Island, while the next column to the right represents Bethel island, and so on). As with the other files described in this section, rows represent months during the hydrological record, in sequential order starting with October, 1921.

Figure 4.10. Contents of the file maxsalinity.txt 4.3.5. Changes in Ambient Conditions  To some degree, the NDAL submodel allows users to make adjustments to climate change in modeling scenarios. The files co2inc.txt and airtempinc.txt allow the user to incorporate monthly increases in atmospheric carbon dioxide and ambient temperature change. Precipitation and evaporation can also be changed to reflect changes in climate by editing the files precipitation.txt and evaporation.txt.

60

Figure 4.11. Contents of the files co2inc.txt (left) and airtempinc.txt (right) 4.3.6. Island Characteristics   DWR identifies 142 DICU sub-regions within the Delta (DWR, 1995), which include all of the 71 islands considered in the WAM model. DWR has made estimates for the monthly diversions, returns and seepage associated with each sub-region. DICU is represented within WAM by aggregating the 142 sub-regions into five groups. All islands are assigned to a group and the specific sub-region’s DICU is cataloged by month for multiple year-types. Here, "island characteristics" refers the three main components of DICU (i.e. diversions, drainage, and seepage) and an additional term accounting for seepage after island inundation. Each of the components are described in this section. 4.3.7. Diversions  In a dynamic Delta, in which sea level rises or in which certain islands inundate and are recovered, agricultural diversions will be highly variable in response to abnormal salinity conditions in Delta channels. However, it is useful for the sake of comparison to provide a base case in which diversions only respond to historic changes in salinity. The base case is provided in the file diversions.txt. As with other flat files used by NDAL, the data are separated into a series of rows and comma-separated columns. The meaning of these rows and columns are shown in Figure 4.12.

61

October, 1 921

November, 1 921

December, 1 921

Bacon Island Bethel Island B ishop Tract

October, 1 921

November, 1 921

December, 1 921

Bacon Island Bethel Island B ishop Tract

Figure 4.12. Contents of the file diversions.txt 4.3.8. Drains  Drainage rates are also sometimes referred to as Delta "return flows" and are typically associated with post-irrigation flows from Delta islands to Delta channels. The format for this file, shown in Figure 4.13., is identical to that of diversions.txt, with column elements corresponding (in sequential order from left to right) to islands listed in the file areainformation.txt.

Figure 4.13. Contents of the file drains.txt

62

4.3.9. Seepage  Under normal conditions, for any Delta island that has been subsiding, seepage flows will bring water from Delta channels to the surface of adjacent Delta islands. The rate of flow is a function of the head difference, which is greatest for islands with the greatest amounts of subsidence (refer to the file islands.dat, p. 51). Figure 4.14. shows the file seeps.txt, which contains seepage data calculated by DWR for the historical period. An additional file, seepbreach.txt (also shown in Figure 4.14.), corresponds to seepage rates when each island is inundated. Flooded island seepage values are small, since the head difference between the island and the adjacent channels becomes negligible after a breach.

Figure 4.14. Contents of the files seeps.txt (left) and seepbreach.txt (right) 4.3.10. NDAL Calibration Files  Outputs from the NDAL submodel were calibrated to match both CalSim and DWR consumptive use outputs. NDAL output is calibrated with the results from these models by applying a flow to each island during each month of the record, which accounts for the water volume difference between model results. Since these calibration flows account for differences in water volume between model results, they can be either positive or negative. The file calibcalsim.txt, shown in Figure 4.15, contains the calibration flows for matching NDAL and CalSim consumptive use outputs. Calibration flows for matching NDAL and DWR model results are split into two files, both of which are shown in Figure 4.16.. Calibration for DWR diversion and seepage flows are given in calibdicudivseep.txt, and calibration for DWR drainage flows in calibdicudrn.txt. The user specifies whether calibration flows are added to flows computed by WAM. The method is specified in the HD control file, described in the next section. Calibration flows should not be changed, since they affect the validity of NDAL calculations. However, the user must decide whether to allow WAM to combine these calibration flows with computations from the RMA2. Combining them will slightly change the water quality data computed by RMA11, within WAM. Typically, these calibration flows amount to a very small fraction (~1-2 %) of unaffected channel flows.

63

Figure 4.15. Contents of the file calibcalsim.txt. Each of the five columns represents one of the five aggregated DICU subgroups (in order from left to right) shown on Figure 1.6.

Figure 4.16. Contents of calibdicudivseep.txt (top) and calibdicudrn.txt (bottom). Columns represent the five aggregated DICU groups used in WAM

64

References California Department of Water Resources (DWR). 1995. Estimation of Delta Island Diversions and Return Flows. February. California Department of Water Resources (DWR). 2007. Delta Risk Management Strategy Program. <http://www. drms.water.ca.gov/> DRMS. 2006a. ITF Paper: Upstream Water Management/Delta Water Operations / Delta Island Water Use. Prepared by URS Corporation/Jack R. Benjamin & Associates, Inc., Prepared for Department of Water Resources. September, 2006. DRMS. 2006b. Delta Risk Management Strategy (DRMS). Initial Technical Framework Paper: Hydrodynamics / Water Quality. Prepared by URS Corporation/Jack R. Benjamin & Associates, Inc. Prepared for Department of Water Resources. September, 2006. Fleenor, W., Hanak, E., Lund, J., and J. Mount. 2008. Technical Appendix C: Delta Hydrodynamics and Water Salinity with Future Conditions. Public Policy Institute of California, San Francisco, CA, 51 pp. Lund, J., E. Hanak, W. Fleenor, R. Howitt, J. Mount, and P. Moyle. 2007. Envisioning Futures for the Sacramento-San Joaquin Delta. Public Policy Institute of California, San Francisco, CA, 300 pp. Lund, J., Hanak, E., Fleenor, W., Howitt, R., Mount, J., Moyle, P., and W. Bennett. 2008. Comparing Futures for the Sacramento-San Joaquin Delta. Public Policy Institute of California, San Francisco, CA. Monismith, S., Kimmerer, W., Burau, J. and M. Stacey. Structure and Flow-Induced Variability of the Subtidal Salinity Field in Northern San Francisco Bay. Journal of Physical Oceanography 32(11): 3003-3019. State Water Resources Control Board. 2000. Revised Water Right Decision D-1641, Sacramento, California, March 15, 2000. Available at: <http://www.waterrights.ca.gov/Decisions/ D1641revs.pdf> URS Corporation/Jack R. Benjamin & Associates, Inc.(URS). 2007. Technical Memorandum, Topical Area: Water Analysis Module, prepared for DWR.

65

Appendix  Table A1. Alphabetical list of files necessary for WAM simulations Filename File type Function Airtempinc.txt Flat file Increase in air temperature, used in the

NDAL submodel AreaInformation.txt Flat file General island information, used in NDAL

submodel Calibcalsim.txt Flat file Calibration file, for matching NDAL and

CalSim outputs Calibdicudivseep.txt Flat file Calibration file, for matching NDAL

diversion and seepage values with those calculated by DWR's DICU model

Calibdicudrn.txt Flat file Calibration file, for matching NDAL drainage values with those calculated by DWR's DICU model

Co2inc.txt Flat file Increase in atmospheric carbon dioxide, used in the NDAL submodel

Dayspermonth.txt Flat file List of days per month, from October 1921 to December 2006

Dicu.dat Control file NDAL submodel control file Dispersion.dat Control file Contains dispersion coefficients used by

RMA11 Diversions.txt Flat file Diversions information for NDAL

submodel Drains.txt Flat file Drains information for NDAL submodel Drms-xx.geo Binary

geometry Bathymetry for the finite element network

Evaporation.txt Flat file Evaporation data, used in the NDAL submodel

Hydro-wam2B.dat Control file Hydro/water quality module control file Islands.dat Control file Breachable island information Maxsalinity.txt Flat file Maximum allowable salinity, used in the

NDAL submodel Precipitation.txt Flat file Rainfall data, used in the NDAL submodelRma2simple-wamB.rm2 Input file Main input file containing file names,

simulation period, coefficients, controls, etc.

Rma11Simple.r11 Template Template that allows WAM to write inputs for the RMA11 model

Run-consoleinput-wam2B.txt

template Lists files for wam.exe to call when running model

Run-wam.exe Executable MS-DOS batch file that executes model

66

67

Seepbreach.txt Flat file Seepage values after an island breach event, used in the NDAL submodel

Seeps.txt Flat file Seepage values for Delta islands, used in the NDAL submodel

wam_flows.dat Control file Flow boundary data wam-calibdaily.dat Control file Sets timeline of simulation Wam-seq.dat Control file Sets time sequence of breach events Waterop-base.dat Control file Water operations module control file Wam.exe Executable

file WAM engine

Yeartype.dat Flat file Specifies yearly relative wetness Table A2. Output and intermediate files generated by WAM Filename File type function Drms-calsimbcs.vrs Binary velocity

result Velocity, flow, water surface elevation, wetting, drying, particle tracking

Drms-calsim-ec.brs Binary water quality result

Constituents concentrations

Hydrowq-wam.dss Results file Simulated water quality data of most recent wam run

Wamlog-calibdaily.out Log file Log of most recent wam run z.r11 Template RMA11 input z.rm2 Template RMA2 input

Figure A1. Comparison of WAM and RMA simulations for the base case scenario at (top) Prisoners Pt, (middle) Three Mile Slough and (bottom) Jersey Point

68

69

Figure A2. Comparison of WAM and RMA simulations for the base case scenario at (top) Mokelumne R. near SJR, (middle) SWP and (bottom) Chipps Island