tRIBS User Manual (Version 3.0)

tRIBS model

tRIBS User Manual


Table of Contents

i. Foreword
1.0 Introduction
2.0 Model Design
    2.1 Model File Structure
    2.2 Model Class Diagrams
    2.3 Model Workflow Diagrams
    2.4 Computational Mesh
3.0 Model Input Formats
    3.1 Grid Input
    3.2 TIN Input
    3.3 Point Station Input
    3.4 Text File Inputs
4.0 Model Execution
    4.1 Download Instructions
    4.2 Compilation Instructions
    4.3 Run Instructions
    4.4 Creating Input Files
       4.4.1 Model Input File
       4.4.2 Soil and Land Use Grids
       4.4.3 Meteorological Point Data Input
       4.4.4 Meteorological Grid Data Input
    4.5 Model Output
5.0 Terrain Analysis for Model Setup
    5.1 Digital Elevation Models and Stream Networks
    5.2 Triangulated Irregular Network Models
6.0 HydroMeteorological Data Processing
    6.1 NEXRAD Stage III and WSI Radar Data
    6.2 Operational RFC Meteorological Data
7.0 Contacts and Further Readings


i. Foreword

The tRIBS (TIN-based Real-Time Integrated Basin Simulator) Distributed Hydrologic Model is a set of object-oriented, C++ programs that allow for the construction and simulation of catchment scale hydrologic processes on a Triangulated Irregular Network (TIN). The development of the tRIBS Model has been the result of hydrologic modeling and software development efforts performed by various researchers in the Ralph M. Parsons Laboratory in the Department of Civil and Environmental Engineering of the Massachusetts Institute of Technology. Model development continues at MIT and New Mexico Tech, among other partnering institutions. This document is intended to serve as a user manual for the tRIBS Model, including instructions on how to download, compile, set up and run tRIBS. In addition, an effort has been made to document the model software design using class and workflow diagrams. This guide assumes that the reader is familiar with the capabilities of the tRIBS Model and its intended purposes. More information concerning the model can be obtained through the tRIBS Research Description and Publication List. Additional instructions regarding the Mesh Generation can be found in the CHILD Model User Manual. tRIBS is copyrighted 2000-2002 by Enrique R. Vivoni, Valeri Y. Ivanov, Rafael L. Bras and Dara Entekhabi and may not be used for commercial purposes without written consent from the authors.

1.0 Introduction

A number of physically-based, distributed hydrologic models of varying degrees of complexity have been developed for the purpose of flood prediction. Physically-based models solve parameterized equations for fluid flow in the land components of the hydrologic cycle, rather than using the calibration approach of conceptual models. Distributed models try to resolve these physical processes in both space and time, leading to the implementation of numeric codes. Most physically-based, distributed models, however, tend to be so complex that execution times are prohibitively large. This drawback diminishes the capacity for model calibration and validation and eliminates the possibility for ensemble averaging or probabilistic forecasting. One of the major factors leading to the large execution times is the inefficiency in the representation of terrain inherent in a raster grid, the preferred mesh structure in most commercial or research-based distributed hydrologic models. This document elaborates on the use and application of a new distributed model that attempts to bypass many of the current difficulties by representing the terrain through triangulated irregular networks (TINs).

The TIN-based Real-time Integrated Basin Simulator (tRIBS) is a collection of C++ classes designed for distributed hydrologic modeling at small to mid-size catchment scales. The object-oriented software design offers several advantages over traditional procedural programming. In particular, by grouping data and functions operating on these variables into distinct classes, it becomes possible to separate the various hydrologic processes operating on the TIN mesh from the procedures for creating the mesh itself (Tucker et. al, 2001). The object-oriented approach also allows for code modularity in such a way as to facilitate model development through code reuse and integration or substitution of new process modules. Such a strategy permitted the development of the tRIBS model from the CHILD modeling framework (Tucker et. al, 1999) within a reasonable amount of time and effort. Hydrologic modules from the RIBS model (Garrote and Bras, 1995) and new hydrologic process models were incorporated into the CHILD framework as separate classes. In addition, the modularity allows for the integration of additional process modules and the potential for finite element modeling (FEM) within the existing mesh architecture.

The tRIBS User Manual is intended to serve as an introduction for new users to the TIN-based distributed hydrologic model. It will cover several topic areas relating to the design, setup, execution and proper usage of the model, in addition to discussing certain limitations and potential future improvements. An exhaustive explanation of each topic area is avoided to maintain this document as a short reference manual. tRIBS is currently a hydrologic research model and is not intended for commercial use and/or professional practice. As a research tool, tRIBS does relatively little error checking to ensure that all the input files are properly constructed. It is the responsibility of the user to make sure that the input file formats are correct and that parameter values are reasonable. This document provides sufficient information for the proper construction and execution of tRIBS. Further questions should be addressed to the authors or found in the various publications.

2.0 Model Design

The software design of the tRIBS Model is based on object-oriented C++ programming. The model classes support and use various object oriented methods including inheritance, polymorphism and virtual functions. In addition, the use of linked list and class templates is particularly important within the tRIBS code. As an object-oriented code, tRIBS constructs as set of objects that encapsulate variables and functions and declares their accessibility to other model objects. These objects are then used to carry out the various modeling functions in the hydrologic simulation. In order to best describe the software architecture of the model, it is important to first understand the file structure. Tables 2.1 and 2.2 list the directories and files that form part of tRIBS. For the new user, this is a starting point to begin to form a mental picture of how the model operates. After knowing the various class names, the user should inspect the Class Diagrams to understand the variables and functions within each class. Class Diagrams summarize the class properties in a visual format without recurring to the actual code. Work Flow Diagrams present how the model procedures flow from one to another, thus allowing a new user to grasp how various objects depend upon and call other objects. Again, these diagrams are tools for quick inspection and a more detailed understanding requires interpretation of the actual code. Since the total code for tRIBS includes approximately 60,000 lines of code within the various files, these tools for quick inspection should be very useful for the new tRIBS user. Note that some new classes have been added to the tRIBS model to handle parallelization routines.

2.1 Model File Structure

The tRIBS Model is organized into a single directory (called tRIBS) with various sub directories that contain the model C++ classes. Each sub directory encapsulates classes with similar functionality or behavior. Table 2.1 demonstrates the various sub directories found within the tRIBS directory, as a user would see upon downloading the source code. Various of these sub directories deal specifically with the hydrologic processes (tHydro, tFlowNet, tRasTin), others create the mesh architecture (tMesh, tMeshElements, tMeshList), while others are general purpose classes used for model execution (tSimulator, tInOut, tCNode) or within other classes (tArray, tList, tPtrList).  The Headers and Mathutildirectories contain global header files and mathematical utilities for the model, respectively. Two subdirectories have been added for parallelization (tGraph, tParallel).

Table 2.1  tRIBS Model Subdirectories

Headers

tInOut

tMeshList

Mathutil

tList

tPtrList

Utilities

tListInputData

tRasTin

tArray

tMesh

tSimulator

tCNode

tMeshElements

tStorm

tHydro

tFlowNet

tGraph

tParallel

 

 


In addition to the sub directories, the tRIBS directory contains a main function (main.cpp) and a makefile for each particular UNIX platform (makeSUN, makeLINUX, makeG5, makeIBM, makeSGI, makeALPHA, makeLAMPI, makeOPENMPI) and makefiles for the parallel model compilation (makeLINUX_PAR, makeMAC_PAR). Running the make file properly will create a directory to store the object files for each class (*.o) and the platform-specific executable (called tribs). Each sub directory will include the C++ class files (*.cpp used as convention) and the C++ Header Files (*.h). The reader is referred to various textbooks on C++ programming for more information on the structure for these files (Deitel and Deitel, 2001, Lippman and Lajole, 1998).  Table 2.2 shows a list of the code files in the tRIBS model for further reference.

 

Table 2.2 tRIBS Model Class and Header Files

tRIBS

main.cpp, makeFile

/Headers

Classes.h, Definitions.h, Inclusions.h, globalFns.h, globalFns.cpp, TemplDefinitions.h, tribs_os.h, tribs_os_ALPHA64.h, tribs_os_LINUX32.h

/Mathutil

geometry.h , mathutil.h, mathutil.cpp, predicates.h, predicates.cpp

/Utilities

InitialGW.cpp, RunTracker.cpp, RainInputCheck.cpp

/tArray

tArray.h, tArray.cpp, tMatrix.h, tMatrix.cpp

/tCNode

tCNode.h, tCNode.cpp

/tFlowNet

tFlowNet.h, tFlowNet.cpp, tFlowResults.h, tFlowResults.cpp, tKinemat.h, tKinemat.cpp, tReservoir.cpp, tReservoir.h, tResData.cpp, tResData.h

/tGraph

tGraph.h, tGraph.cpp, tGraphNode.h, tGraphNode.cpp

/tHydro

tEvapoTrans.h, tEvapoTrans.cpp, tHydroMet.h, tHydroMet.cpp

 

tHydroMetConvert.h, tHydroMetConvert.cpp, tHydroMetStoch.h, tHydroMetStoch.cpp tHydroModel.h, tHydroModel.cpp

 

tIntercept.h, tIntercept.cpp, tWaterBalance.h, tWaterBalance.cpp

tSnowPack.h, tSnowPack.cpp

tSnowIntercept.h, tSnowIntercept.cpp

/tInOut

tInputFile.h, tInputFile.cpp, tOutput.h, tOutput.cpp, tOstream.h, tOstream.h

/tList

tList.h, tList.cpp

/tListInputData

tListInputData.h, tListInputData.cpp

/tMesh

tMesh.h, tMesh.cpp, tTriangulator.h, tTriangulator.cpp, heapsort.h

/tMeshElements

meshElements.h, meshElements.cpp

/tMeshList

tMeshList.h, tMeshList.cpp

/tParallel

tTimer.h, tTimer.cpp, tTimings.h, tTimings.cpp, tParallel.h, tParallel.cpp

/tPtrList

tPtrList.h, tPtrList.cpp

/tRasTin

tInvariant.h, tInvariant.cpp, tRainfall.h, tRainfall.cpp

 

tResample.h, tResample.cpp, tVariant.h, tVariant.cpp

 

tRainGauge.h, tRainGauge.cpp

tShelter.h, tShelter.cpp

/tSimulator

tRunTimer.h, tRunTimer.cpp, tSimul.h, tRestart.h, tRestart.cpp, tSimul.cpp, tControl.h, tControl.cpp, tPreProcess.cpp, tPreProcess.h

/tStorm

tStorm.h, tStorm.cpp

 

The class names are indicative of the functionality for that particular class. Most files contain a single class that encapsulate the data and functions operating on the data within a single object. In some occasions, it has been convenient to include several interrelated classes within the same file. A list of all non-derived tRIBS Classes can be found in tRIBS/Headers/Classes.h. The main function is exclusively used in tRIBS to construct the various objects, while the simulation control itself is performed by the SimulationControl class. Further details on the classes and the flow of data in the tRIBS model are presented in concise, graphical format using diagrams.

 

2.2 Model Class Diagrams

Model class diagrams are a useful tool for summarizing the class properties, in terms of variables and functions, in a visual format without recurring to the actual code. Function and variable declarations are presented as they are implemented within the code, including knowledge of the accessibility of each object property and the use of other model objects. For the tRIBS model, the UML (Universal Modeling Language) has been used to create class diagrams through Microsoft Visio, part of the Microsoft Visual Studio development framework. The UML format is a standard diagramming language used by software engineers and architects to document model code. Table 2.3 presents a list of the model classes and references to the class diagram for each.

Table 2.3 tRIBS Class Diagrams

Templated Classes

Control and Storage Classes

Hydrologic Classes

tMesh

tTriangle

tHydroModel

tMeshList

tNode

tEvapoTrans

tMeshListIter

tEdge

tIntercept

tList

tCNode

tRainfall

tListNode

Point2D

tRainGauge

tListIter

Point3D

tHydroMet

tPtrList

vcell

tHydroMetConvert

tPtrListNode

Predicates

tResample

tPtrListIter

Simulator

tVariant

tArray

SimulationControl

tFlowNet

tMatrix

tRunTimer

tFlowResults

tOutput

tPreProcess

tKinemat

tCOutput

tControl

tWaterBalance

tListInputData

 

LandType

tIdArray

 

GenericLandData

 

 

SoilType

 

 

GenericSoilData

 

 

tStorm

 

 

tHydroMetStoch

 

 

tSnowPack

 

 

tSnowIntercept

 

 

tShelter



tResData



tReservoir

 

2.3 Model Workflow Diagrams

Model workflow diagrams present the steps followed during model execution in a graphical manner that facilitates understanding of the model procedures. The workflow could be documented at various levels of complexity (at the model level, at the class level and at the function level). Here, the model level is chosen as an appropriate representation and the details of the workflow within classes or functions are not shown for brevity. The tRIBS Model Workflow Diagram presents the model procedure at the coarsest level possible. For more information, the user is referred to the main.cpp and tSimul.cpp classes which encapsulate the model execution procedures.

 

2.4 Computational Mesh

The tRIBS Model inherited the Triangulated Irregular Network (TIN) mesh architecture directly from the CHILD model framework (Tucker et. al, 1999). As such, the model has the same capabilities as CHILD in constructing TIN meshes using the various options available in the tMesh class. In addition, some new input capabilities have been added that take advantage of the TIN creation capabilities of Arc/Info TIN (ESRI, 1996). These new input capabilities extend the mesh framework to the more complicated topography present in real world watersheds and also allow us to input "hydrologically" significant TIN terrain representations. The existing options for creating the computational mesh include:

Generating a synthetic rectangular mesh with random or hexagonal node arrangements.

Read in an existing tRIBS Mesh files from a previous run.

Generate a mesh from a given set of (x,y,z,b) points.

Generate a mesh from a Digital Elevation Model (DEM) Arc/Info ascii grid

Generate a set of points from an Arc/Info TIN ungenerate file (*.net)

Generate a set of points from an Arc/Info TIN ungenerate files (*.pnt, *.lin)


Additional details concerning the generation of the TIN input for the tRIBS Model will be discussed further in this document. It is important, however, to briefly describe the concept behind the TIN computational mesh for the two distributed hydrologic and geomorphologic models (tRIBS and CHILD). A TIN within these models can be described as a set of highly interconnected triangle objects that each possesses three edge and three node objects (as defined in MeshElements.cpp). The TIN mesh allows for flow and transport from TIN node to TIN node, along a triangle edge, using a finite difference approach. Hydrologic computations made at each TIN node (e.g. infiltration, evaporation, groundwater table elevation) are assumed valid over a region consisting of the Voronoi polygon associated with the node. In this way the Voronoi polygon is used as the control volume for mass conservation in the tRIBS model. The Voronoi polygon (or Thiessen polygon) is the dual diagram of the TIN mesh and can be computed by the intersection of perpendicular bisectors to each TIN edge. Since a unique relation exists between a TIN Mesh and its Voronoi Polygon Network (VPN), it is convenient to use both representations interchangeably within the model to simulate hydrological processes. For more details, the reader is referred to Tucker et. al (2001).

 

 

3.0 Model Input Formats

A schematic of the tRIBS Model Framework illustrates the various components and input types within the model. The tRIBS model is designed to accept input from various types of data formats: grid data, TIN data, point data and text tables. The grid data supplied to the model can be time-invariant (soils and land use) or time-varying (rainfall or weather) grids. The TIN data are inputted into the model in a variety of methods that represent the nodes within the mesh or represent the topography that is intended to be modeled. The method chosen to input the TIN data depends upon the particular application. The point data represent the values of time-varying parameters, such as meteorological data, that are available at specified points within the watershed. Resampling routines are available for geographically overlaying the grid or point data onto the Voronoi polygon mesh. Finally, text tables are used within the model for inputting parameter values associated with the soil and land use maps or the hydrometeorological data.

3.1 Grid Input

A standard ASCII grid format is used for all grid input to the model, which may include soil and land use reclassification fields, initial groundwater table depth, depth to bedrock and radar rainfall grids. The ASCII grid format used is a standard created by ESRI for the exchange of grid data for GIS applications. It consists of a small, 6-line header that describes the matrix data presented in the text file. This format is a convenient method for data exchange into GIS since the format is easily read by all ESRI software. In other software programs for visualization of matrix data (i.e. MATLAB), care must be taken when reading in the header information. Any extension name for the grid data can be used within tRIBS as long the filename is specified in the Model Input File. However, for visualization of the grid within GIS, an extension *.asc is required for the grid to be read properly (ESRI, 1996).

As mentioned previously, the grid input to the tRIBS model can consist of time-invariant watershed descriptors, such as soil and land use coverage grids, or time-varying, spatially-distributed hydrometeorologic forcings, such as radar rainfall estimates or grid meteorological data from numerical weather models. Although each grid input is treated differently within the model, the user input should be identical. It consists mostly of specifying the grid pathname within the Model Input File, as described in a later section. As illustrated in the tRIBS Model Framework, all grid input are resampled onto the TIN terrain representation created within the tRIBS model, and specifically onto the Voronoi Polygon Network (VPN).

 

ncols

6

 

 

 

 

nrows

6

 

 

 

 

xllcorner

346035

 

 

 

 

yllcorner

3979905

 

 

 

 

cellsize

2000

 

 

 

 

NODATA_value

-9999

 

 

 

 

-9999

-9999

-9999

0.511

0.111

-9999

-9999

-9999

0.951

1.873

0.239

-9999

-9999

-9999

0.824

0.412

0.444

1.051

-9999

3.123

0.154

0.853

-9999

-9999

1.090

2.541

0.288

-9999

-9999

-9999

2.241

0.312

-9999

-9999

-9999

-9999

Figure 3.1. Example of a standard ASCII grid file.

 

Figure 3.1 illustrates an example of a grid ASCII input to the model with the appropriate header information and the matrix of values. These values may be any particular type of input that needs to be resampled onto the tRIBS mesh. In this particular case, it represents NEXRAD radar rainfall values (in cm/hr) at a resolution of 2 kilometer by 2 kilometers within the perimeter of the Peacheater Creek Watershed (see Sample Application in tRIBS Watershed Downloads Page). Illustrated in the figure are various features to note: (1) the grid input must be composed of square grid cells (i.e. dx = dy = cellsize (in meters)), (2) the coordinate system is specified by the values of x and y at the lower left corner (in this case, UTM zone 15 coordinates are shown), (3) the entire grid can be rectangular, such that nrows and ncols can differ and (4) the NODATA_value can be used to represent cells outside of the domain of interest.

 

3.2 TIN Input

Topographic data is inputted into the tRIBS Model through a variety of methods that are implemented in the tMesh class.  For applications in real watersheds with complex topography and stream networks, the method of choice is to generate the TIN mesh within Arc/Info GIS and export it into a format that tRIBS can convert to a Points File (*.points). This Points File is then read during a subsequent model run. For tRIBS, a set of Arc/Info scripts have been created that manipulate the watershed Digital Elevation Model (DEM), the stream network, the watershed boundary and the bottom-valley floodplain to created a "hydrologically" significant TIN Terrain Model. Further details of these scripts are presented in the Terrain Analysis Section of this document. Exporting the TIN mesh from Arc/Info is performed through a procedure that ungenerates the TIN into a set of points (*.pnt) and lines (*.lin). tRIBS can read these files and construct from them a Points (*.points) file, an example of which is shown in Figure 3.2.

 

 

7

 

 

 

405

0

1

495

0

0

2

585

0

0

1

360

90

1

1

450

90

1

0

540

90

1

0

630

90

1

Figure 3.2 Example of a tRIBS Points File (*.points)

 

A Points File is a simple text file that contains a listing of point coordinates (x, y, z) and the boundary code (b) for each point (in that specific order) with a small header that indicates the total number of points in the file. The boundary code is indicative of the node position within the watershed: 0 (mesh interior node), 1 (closed mesh boundary node), 2 (open mesh boundary or outlet node), 3 (stream network node). Proper creation and consistency of the Points File is very important for the tRIBS Model and the *.points file should be carefully inspected using ArcView GIS or a similar environment. The Points File can be the appropriate method of TIN input for points obtained from a field survey, from a GIS point coverage, from a sampled DEM or from a ungenerated TIN mesh.

The Points File is the recommended TIN input for the tRIBS Model during the initial model construction, usually necessary when a new basin is modeled for the first time. After a successful tRIBS model run, the model outputs a set of files that describe the TIN mesh properties in greater detail, including the connectivity between nodes and the triangles within the mesh. The set of files includes: *.nodes, *.edges, *.tri and *.z. These files can be read directly into the model during subsequent model runs, thus avoiding the use of the *.points file and speeding up the process of mesh construction. Further details on both of these options will be discussed in subsequent sections and are also available in Tucker (1999).

 

3.3 Point Station Input

Hydrometeorological data can be inputted into the tRIBS model through methods for Point Station Input implemented in the tEvapoTrans and tRainfall classes and the tHydroMet and tRainGauge storage classes. Point Station Input is useful for providing meteorological data from a sparse set of weather stations or for providing rain gauge rainfall data, instead for radar rainfall maps, to the model. The data from these sparse stations or points is resampled onto the Voronoi Polygon Network (VPN) by using a Thiessen polygon method at the point coordinates. The station properties, including coordinates, are specified through an SDF file (Station Descriptor File), while the station data are provided in an MDF file (Meteorological Data File). Both file types are discussed in the section on Meteorological Point Data Input in this document.

 

3.4 Text File Input

Various types of text files are used in the tRIBS Model to specify model options, hydrologic parameters or control commands. The most important of the text files is the Model Input File (*.in). This file contains various required and optional parameters organized by keywords. The format for each parameter consists of a line of descriptive text followed by the value of the parameter itself on a second line. There are over 40 different keyword inputs in a typical Model Input File. These can be classified into various groupings: Model Run Parameters, Model Run Options and Model Input Files and Pathnames. Subgroupings include: Time Variables, Routing Variables, Mesh Generation, Resampling Grids, Meteorological Data and Output Data. More details concerning the Model Input File will be presented in the section on Model Input File in this document. 

Another important use of text files is for the reclassification of soil and land use grids into meaningful hydrologic parameters assigned to each Voronoi polygon. A simple text file is used to relate each cover class to the particular hydrologic parameter required for the model equations. It consists of a small header followed by a matrix of parameter values for each cover class. In the case of the soil reclassification table (*.sdt), the parameters are used to specify the soil hydraulic and thermal properties. In the case of the land reclassification table (*.ldt), the parameters are used to relate the cover type to the interception and evapotranspiration properties of the vegetation and land cover. Both types of files will be explain in greater detail in the section on Soil and Land Use Input.

A text file can also be used to run the model and specify the command line options desired during the run by using a Model Run File (*_run). This file consists of a single line that specifies the pathname of the tRIBS executable followed by the name of the Model Input File and the desired command line options.

 

3.5 Special Parallel Model Inputs

The tRIBS model utilizes the same model input formats (*.points file for TIN input, ASCII grids for vegetation and soils input, etc.) as in the tRIBS model. The parallel mode can be toggled on/off using the keyword PARALLELMODE in the tRIBS Model Input file (*.in). In this section, we will only provide details on the input of the graph partitioning files (*.graph). The graph files are utilized to specify how a large watershed domain is partitioned into subbasins and on which computer processor each subbasin is run on. There are currently three methods implemented to partition a domain: (1) A default partitioning of the graph; (2) A reach-based partitioning; and (3) An inlet/outlet-based partitioning. The various options can be selected utilizing the keyword GRAPHOPTION. The default graph partitioning is based on an automatic splitting of the internal node list. It is a simple method that does not permit user control or interaction. As a result, it may not be an optimal way for subdividing a domain into a well-balanced computational effort among different processors. The reach-based and inlet/outlet-based methods require user input of a file into tRIBS by specifying the filename using the keyword GRAPHFILE. The file structure varies for each type of domain decomposition. The following tables indicate the file structure for the reach-based and inlet/outlet-based approaches.

 

 Table 3.1 Reach-based Graph Input File (*.graph)

Processor ID (#)

Reach ID (#)

Processor ID (#)

Reach ID (#)

Processor ID (#)

Reach ID (#)

Processor ID (#)

Reach ID (#)

...

...

 

The reach-based graph input (Table 3.1) is essentially a two-column text file with no header. Column 1 holds the numerical IDs of the computer processors to be used (labeled from 0 to N) while Column 2 holds the numerical IDs (labeled from 0 to M) of the reaches to be run on the corresponding computer processors. The number of available computer processors will depend on the cluster in use. The number of reaches will depend on the size of the problem treated. For large domains, manual construction of the graph input file may become cumbersome. The reach IDs need to be determined from the *.reach file generated by the tRIBS model after mesh construction. This file is typically imported as a line coverage into a GIS package to identify the spatial location of each reach and their corresponding reach ID. The user will need to determine the most appropriate method for distributing the variuos reaches onto the available processors. Proper load balancing needs to be considered to distribute effort among different subbasins. Vivoni et al. (2006) presents a discussion of this issue with respect to some test cases.

The inlet/outlet-based graph input (Table 3.2) is essentially a three-column text file with no header. Column 1 holds the numerical IDs of the computer processors to be used (labeled from 0 to N), Column 2 holds the numerical IDs of the channel nodes that form the inlet (upstream) segment of a reach and Column 3 holds the numerical IDs of the channel nodes that form the outlet (downstream) segment of a reach. Inlet nodes are typically inside sub-basins along the headwater areas, while outlte nodes are typically the closest downstream location along the main channel. The inlet/outlet-based graph partitioning provides for flexibilty to the user, but may be more complicated to set up. The inlet/outlet IDs need to be determined from the *.voi file generated by the tRIBS model after mesh construction. This file is typically imported as a polygon coverage into a GIS package to identify the spatial location of each node and their corresponding ID. As with the above case, the user will need to experiment with the inlet/outlet partitioning in order to obtain proper load balancing and performance.

 

 Table 3.2 Inlet/Outlet-based Graph Input File (*.graph)

Processor ID (#)

Inlet ID (#)

Outlet ID (#)

Processor ID (#)

Inlet ID (#)

Outlet ID (#)

Processor ID (#)

Inlet ID (#)

Outlet ID (#)

Processor ID (#)

Inlet ID (#)

Outlet ID (#)

...

...

...

 

4.0 Model Execution

Execution of the tRIBS Model has been improved significantly for this release. A concerted effort has been made to provide a well document, standardized set of model inputs for the various types of formats previously discussed. In addition, the model output has been improved significantly in order to make use of the visualization capabilities of ArcView GIS and the time series analysis of MATLAB. Model screen output has been tailored to provide the user with only the necessary information about the status of the model run and sufficient detail as to possible errors. Despite this, the tRIBS model is a research-based code that does not provide as much error checking as could be possible or desirable. For this reason, the responsibility is placed on the user to provide the model with the appropriate inputs in the correct format. This document describes all model input and output in sufficient detail for the beginning user. More advanced users should consult the sample applications provided or the model code.

Execution of the parallel tRIBS Model is still quite experimental. We have not optimized the subbasins partitioning to achieve equitable distribution of labor on the individual processors. Nevertheless, the parallel version of the tRIBS Model is operational and can be tested by users for their own purposes. Most of the functionality (e.g., input, output, directory structure, etc.) remains identical to the original tRIBS model.

4.1 Download Instructions

The release of the tRIBS Model is intended solely for use as a research hydrology model. The distribution of the model code is provided only upon written consent from the authors. The tRIBS code is provided in a single tar formatted file called tribs.tar. The file should be unpacked using the tar UNIX utility and placed in a directory of choice:

        % tar -xvf tribs.tar

The tar bundle will contain the subdirectory structure and code files presented in Tables 2.1 and 2.2. An executable is not included in the tar bundle. A sample application for a synthetic element and for a complex watershed (Peacheater Creek) are available along with the model tar bundle. For most users, only an executable in the appropriate platform is provided along with the model examples.

 

4.2 Compilation Instructions

The tRIBS Model was originally written and compiled on an SGI Irix 6.5 UNIX system. Since the model design uses standard C++ programming structures, the compilation onto other UNIX platforms is straightforward. tRIBS has been compiled for a range of platforms (Mac G5, Alpha Tru64, Linux, Cygwin, IBM, Solaris). The current version should compile on all platforms without need for any major changes to the code by using the different makefiles provided. As an example, the model code is compiled for SUN Solaris by issuing the following command at the UNIX prompt:

        % make -f makeSUN [options]

The makefile provided allows for various options to be included after the command: clean (erases the previously compiled objects) and all (cleans and compiles the code). If no options are included, then the command simply compiles the code without removing the previous objects. The user should be warned that the compilation of certain low-level objects requires all objects to be recreated for proper functioning. For this reason, the all option is recommended. The make utility will create an executable called tribs in the current working directory. It will also place the object files under a directory _Objects_ that must be created within the directory of the executable.

To run the model using the parallelized option, the operating system requries the appropriate MPI libraries. The current version should compile on other platforms with MPI libraries without need for any major changes to the code. Several makefiles are provided for the particular compilation of tRIBS (makeLINUX_PAR and makeMAC_PAR). As an example, the model code is compiled for LINUX by issuing the following command at the prompt

        % make -f makeLINUX_PAR [options]

 

4.3 Run Instructions

In order to run the tRIBS Model, a Model Input File will be required. This file can have any name, but by convention the extension *.in is used. The model can be run from the UNIX command line by using the following syntax (within the same directory as the tribs executable):

        % tribs inputfile.in [options]

For running the model in parallel mode, mpirun (or a suitable alternative MPI command) is needed:

        % mpirun [options] ./tRIBS inputfile.in [options]

In the above, the command mpirun is particular for parallel model applications and it contains various possible options related to the assignment of particular processors. The user is recommend to check man mpirun and also the sample applications for the tRIBS Model.

Alternatively, the model can be run from a separate directory by specifying the pathnames of the executable and the Model Input File. An easier way of running the model is to create a Model Run File that contains the one line UNIX command presented above. Although Model Run Files can have any name, the extension *_run is used by convention. It is important to make sure that the Model Run File has read, write and execute permissions. These can be changed using the UNIX utility chmod.  Running the Model Run File (called here inputfile_run) would consist of issuing the following command:

        % inputfile_run > output

The arrow key (>) redirects the model screen output to a file called output. Without the arrow key, the model output associated with the progress of the run is directed to the screen. Various command line options are available when running the tRIBS model, either through the command line or through the Model Run File. Table 4.1 presents a list of these options with descriptions and default values.

Table 4.1 tRIBS Run Options (*_run)

Run Option

Description

Default Setting

-A

Automatic listing of rainfall fields

(default = off)

-R

Write intermediate states (spatial output)

(default = off)

-G

Run groundwater model

(default = off)

-F

Measured and forecasted rain

(default = off)

-M

Do NOT write headers in output files

(default = off)

-V

[NodeID] Verbose mode (output run-time info)

(default = off)

-O

On after simulation completion, awaiting user input

(default = off)

-K

Check input file for consistency

(default = on)

-H

Write intermediate hydrographs (*.mrf)

(default = off)

The most important of these options for the new user to be acquainted with are -R (write intermediate results), -G (run the groundwater model), -V (verbose screen output), -O (continuously on model state). The last of these should be used only if one wishes to keep the model in memory while changing the inputs specified in the Model Input File (all model inputs except the TIN Mesh can be altered). Redirecting the model screen output should not be done if the -O flag is used. Many of the other options have yet to be used to the fullest potential in tRIBS, especially those concerned with the use of forecasted rainfall. Further details on the run options are available in the tControl.cpp code.

 

4.4 Creating Model Inputs

As with any model, half the battle in getting a correct model run is in providing the appropriate model input. Without having all the correct model input, the tRIBS Model will exit with an appropriate error message. A properly setup run will begin and end by providing the user with the following message:

 

---------------------------------------------------------------

                 tRIBS Distributed Hydrological Model
                 TIN-based Real-time Integrated Basin Simulator
                 Ralph M. Parsons Laboratory
                 Massachusetts Institute of Technology

                 Version Number and Release Date

----------------------------------------------------------------

 

In between this header and footer, the model run output file obtained after redirecting the run file (output) will contain various sections relating to the model workflow: Reading Input Parameters, Creating Mesh, Creating Stream Network, Creating Resampling for Grids, Creating Output Files, Creating Hydrologic System, Hydrologic Simulation Loop, Deleting Objects and Exiting Program. A sample output or log file can be found in the sample applications described previously. In order to obtain a proper model run, however, the user must make sure that all model inputs, parameters and files are appropriately constructed and referenced in the Model Input File.

 

4.4.1 Model Input File

The tRIBS Model Input File (*.in) is currently the primary user interface to the model. Although not a graphical medium, it is an easy and efficient means of manipulating all modeling options, parameters and inputs. Not all of the parameters are required for every single run since choosing a particular option may require some additional parameters that an alternate option may not. Nevertheless, it is recommended to have as complete a set of parameters as possible. Those parameters that are not required for a particular run are ignored by the model. The *.in file contains various required and optional parameters organized by keywords. The format for each parameter consists of a line of descriptive text followed by the value of the parameter itself on a second line. Table 4.2 presents a list of the model parameters used in the tRIBS Model Input File. Note that all parameters are capitalized. The values associated with each parameter may be a number (int, double) or a string (pathname, extension). If the units are specified as ints or doubles, this implies that the parameters are dimensionless, otherwise a unit is expressed. The difference between a pathname and a base pathname is simply that the pathname includes the entire path plus the entire name of the file, including the extension, while a base pathname is only the path and the base name of the file (no extension). NOTE: All keywords in the inputfile must have a entry for proper model execution.

Table 4.2 List of Model Parameters in tRIBS Model Input File

Keyword

Units

Description

STARTDATE

date format

Date of start of simulation.

RUNTIME

hours

Total number of hours in run 

TIMESTEP

mins

Unsaturated zone time step 

GWSTEP

mins

Saturated zone time step

METSTEP

mins

Meteorological data input time step

ETISTEP

hours ET, interception and snow time step

RAININTRVL

hours

Rainfall data input time step

OPINTRVL

hours

Output interval

SPOPINTRVL

hours

Spatial output interval

INTSTORMMAX

hours

Interstorm interval

RAINSEARCH

hours

Rainfall search interval 

BASEFLOW

m3/s

Minimum baseflow discharge

VELOCITYCOEF

double

Discharge-velocity coefficient

KINEMVELCOEF

double 

Kinematic routing velocity coeff.

VELOCITYRATIO

double

Stream-hillslope velocity coeff.

FLOWEXP

double

Nonlinear discharge coefficient

CHANNELROUGHNESS

double

Uniform channel roughness value

CHANNELWIDTH

double

Uniform channel width 

CHANNELWIDTHCOEFF

double

Coefficient in width-area relation

CHANNELWIDTHEXPNT

double

Exponent in width-area relation

CHANNELWIDTHFILE

pathname

Input file name for channel widths

CHANNELCONDUCTIVITY
double
Hydraulic conductivity in channel
TRANSIENTCONDUCTIVITY
double
Hydraulic conductivity during transient period
TRANSIENTTIME
double
Time until transient period ends
CHANNELPOROSITY
double
Porosity in channel
CHANPOREINDEX
double
Pore index parameter in channel
CHANPSIB
double
Matric potential in channel

OPTMESHINPUT

int

Option for Mesh generation 

RAINSOURCE

int

Source of rainfall data

OPTEVAPOTRANS

int

Option for Evapotranspiration scheme

OPTSNOW

int

Option for snow

HILLALBOPT

int

Option for hillslope albedo

OPTRADSHELT

int

Option for radiation sheltering of snow

OPTINTERCEPT

int

Option for Interception scheme

OPTLANDUSE

int

Option for static or dynamic land cover

OPTLUINTERP

int

Option for land cover interpolation

OPTSOILTYPE
int
Option for soil parameter format

GFLUXOPTION

int

Option for Ground heat flux scheme

METDATAOPTION

int

Point or Grid weather data

CONVERTDATA

int

Processing weather or raingauge data

OPTBEDROCK

int

Option for uniform or variable depth

OPTGWFILE

int

Option for groundwater input file

WIDTHINTERPOLATION

int

Option for interpolating width variables

OPTRUNON

int

Option for hillslope runon

OPTRESERVOIR int Option for reservoir routing
OPTPERCOLATION
int
Option for channel percolation losses

INPUTDATAFILE

base pathname

Input file base name for Mesh files

INPUTTIME

int

Time slice for Mesh file input

ARCINFOFILENAME

base pathname

Input file base name for Arc files

POINTFILENAME

pathname

Input file name for Points files

SOILTABLENAME

pathname

Soil parameter reference table

SOILMAPNAME

pathname

Soil texture ASCII grid

LANDTABLENAME

pathname

Land use parameter reference table

LANDMAPNAME

pathname

Land use ASCII grid

GWATERFILE

pathname

Ground water ASCII grid

DEMFILE

pathname

DEM for sheltering

RAINFILE

base pathname

Radar Rainfall ASCII grids

RAINEXTENSION

extension

Extension for Radar Rainfall grids

DEPTHTOBEDROCK

meters

Uniform depth to bedrock

BEDROCKFILE

pathname

Bedrock depth ASCII grid

LUGRID

pathname

Dynamic land cover ASCII grid list

SCGRID

pathname

Spatially-variable soil parameter ASCII grid list

HYDROMETSTATIONS

pathname

Hydrometeorological station file

HYDROMETGRID

pathname

Hydrometeorological ASCII grid list

HYDROMETCONVERT

pathname

Hydrometeorological data input file

HYDROMETBASENAME

base pathname

Hydrometeorological data file

GAUGESTATIONS

pathname

Rain gauge station file

GAUGECONVERT

pathname

Rain gauge data input file

GAUGEBASENAME

base pathname

Rain gauge data file

RESPOLYGONID
pathname
Reservoir polygon ID file
RESDATA
pathname
Reservoir data table

OUTFILENAME

base pathname

tMesh and variable output

OUTHYDROFILENAME

base pathname

Hydrograph output 

OUTHYDROEXTENSION

extension

Extension for hydrographs

RIBSHYDOUTPUT

int

Compatibility with RIBS Output

NODEOUTPUTLIST

pathname

Node output list file

HYDRONODELIST

pathname

Node runtime output list file

OUTLETNODELIST

pathname

Interior node output list

FORECASTMODE

int

Forecast mode options

FORECASTTIME

int

Time in hours from start

FORECASTLEADTIME

int

Total lead time (hrs)

FORECASTLENGTH

int

Total forecast length (hrs)

FORECASTFILE

pathname

Forecast file directory

CLIMATOLOGY

double

Climatology rainfall (mm/hr)

RAINDISTRIBUTION

int

Spatial or lumped rainfall

STOCHASTICMODE

int

Stochastic model option

PMEAN

double

Mean rainfall intensity (mm/hr)

STDUR

double

Mean storm duration (hrs)

ISTDUR

double

Mean time interval between storms (hrs)

SEED

int

Random seed

PERIOD

double

Period of variation (hrs)

MAXPMEAN

double

Maximum value of mean rainfall intensity (mm/hr)

MAXSTDURMN

double

Maximum value of mean storm duration (hrs)

MAXISTDURMN

double

Maximum value of mean interstorm duration (hrs)

WEATHERTABLENAME

filename

Stochastic weather file name

TLINKE

double

Atmospheric turbidity parameter

MINSNTEMP

double

Minimum snow temperature allowed (Celsius)

TEMPLAPSE

double

Temperature lapse rate

PRECLAPSE

double

Precipitation lapse rate

 

The tRIBS Model Input File provides an appropriate means for summarizing the various modeling options and capabilities in the tRIBS Release. An exhaustive explanation of each item is avoided in this document for brevity and the user is referred to the more complete description tRIBS and CHILD descriptions:

 

Parallel Model Inputs

The use of the parallel version of the model led to the development of the following new keywords:

Table 4.3 List of Additional Inputs for Parallel Model Runs

Keyword

Units

Description

PARALLELMODE

int

Option to run as serial (0) or parallel (1) mode

GRAPHOPTION

int

Option for graph file type (0, 1 or 2) 

GRAPHFILE

filename

Reach connectivity (graph) filename

RESTARTMODE

int

Option for restart mode (0, 1, 2 or 3)

RESTARTINTRVL

hours

Time set for restart output

RESTARTDIR

pathname

Path of directory for restart output

RESTARTFILE

filename Filename of restart file

OPTVIZ

int

Option to write viz binary files

OUTVIZFILENAME

filename

Filename for viz binary files

 

Model Run Parameters: Restart Mode

The tRIBS model can now output binary files corresponding to the entire set of model states at a particulat time interval. This capability was created to facilitate model runs beginning in the middle of a simulation. This may be necessary for recovering from a system crash and can be very useful in data assimulation and forecasting schemes. The restart mechanism is invoked by using the RESTARTMODE keyword which has four options: No restart mechanism (option 0), Write files only (option 1), Read files only (option 2), Read and write files (option 3). In this context, writing implies making model output states at a specified interval defined by the keywork RESTARTINTRVL (in hours); while reading implies using a previously generated restart file as your initial state. The restart output is written to a directory specified by the keyword RESTARTDIR (pathname of directory); while the restart reading is from a file specified by the keyword RESTARTFILE (filename). The restart mechanism should be utilized with caution with respect to file space as the restart files can be large.

 

Model Run Parameters: Parallel Mode

The tRIBS model can now be run in either serial or parallel mode, depending on user selection. The keyword PARALLELMODE is used to specify either serial (option 0) or parallel (option 1) computation. If the parallel mode is used, then attention needs to be paid to the graph file partitioning option. Three methods for graph partitioning can be selected utilizing the keyword GRAPHOPTION: (a) A default partitioning of the graph (option 0); (b) A reach-based partitioning (option 1); and (c) An inlet/outlet-based partitioning (option 2). If either option 1 or 2 are selected, the keyword GRAPHFILE needs to be specified with the name of the graph file to be used (either reach or inlet/outlet based). Otherwise, no filename is required.

 

Model Run Parameters: Visualization Mode

The tRIBS model can now save model output in binary format for visualization purposes (using ParaView and Ensight). The keyword OPTVIZ is used to specify either no writing of visualization output (option 0) or writing of binary output files (option 1). If the visualization output is used, OUTVIZFILENAME is used to specify the name of the binary file to be written. 

 

Model Run Parameters: Time Variables

The first ten item codes or parameters in the tRIBS Model Input File are related to the various timesteps used within the model.  The STARTDATE keyword is used to indicate the starting time of the model simulation in the following format: MM/DD/YYYY/HH/MM (Month/Day/Year/Hour/Minutes). Values of the rainfall and meteorological inputs must exist for this starting date for the model to execute properly. The RUNTIME keyword is used to specify the number of hours in the total length of the simulation. Similarly, there must be hydrometeorologic data that span the period between the start date and the end date. The TIMESTEP parameter is used to specify the Unsaturated Zone computational time step in minutes. For proper execution, the unsaturated time step should be on the order of minutes. The GWSTEP represents the groundwater or Saturated Zone computational time step, also in minutes. Typically, the groundwater time step can be on the order of tens of minutes for most applications. METSTEP specifies the time step of hydrometeorological data input from weather stations, in minutes. This time step is usually set to 60 minutes since the weather parameters are available at this temporal resolution. ETISTEP specifies the interval for the evapotranspiration, interception and snow model calculations in hours. The RAININTRVL keyword is used for the input time interval of rainfall data, either from radar rainfall grids or from raingauges, in hours. This interval will depend on the resolution of the radar data which is available from 15 minute up to daily intervals. OPTINTVL notifies the model at what interval the model output will be produced. Finally, the last two parameters are related to the rainfall scheme. INTSTORMMAX is the amount of hours without rainfall that the model considers to be sufficient for an interstorm period to begin, while RAINSEARCH is the amount of hours that the model will search for the next rainfall file without producing an error message and exiting the program.

 

Model Run Parameters: Routing Variables

The tRIBS currently posesses a simplified hydrologic routing scheme inherited from the raster-based RIBS model (Garrote and Bras, 1995) for hillslope routing and a finite-element channel routing scheme. The model allows for non-linear routing based on the discharge at a single watershed outlet and two parameter values, the stream velocity and the hillslope velocity, shared by all TIN nodes of that particular type. The hydrologic routing scheme utilizes the discharge at the closest stream node to determine the hillslope velocity. Six routing parameters are specified to the model: BASEFLOW, VELOCITYCOEF, FLOWEXP, VELOCITYRATIO, CHANNELROUGHNESS, and CHANNELWIDTH. The first of these is used to specify the minimum flow in the stream network in cubic meters per second, a required parameter since the flow network velocities depend on the outlet discharge in some linear or nonlinear fashion. If the BASEFLOW parameter is not specified, a value of 0.001 cubic meters per second is assigned as default. VELOCITYCOEF is used to specify the coefficient in the relationship between the stream velocity and the outlet discharge, while the FLOWEXP is the exponent on the discharge in this relationship. Specifying FLOWEXP = 0 implies a linear relationship between the stream velocity and the outlet discharge. The VELOCITYRATIO keyword is the ratio between the calculated stream velocity and the hillslope velocity assigned to non-stream nodes. The last two parameters: CHANNELROUGHNESS and CHANNELWIDTH are both uniform parameters for the entire stream network in this model version. The roughness parameters refers to a non-dimensional Manning's coefficient while the width is a channel width in meters.

 

Model Run Options

A major section in the tRIBS Model Input File is dedicated to the model run options used to specify which hydrological processes are chosen for a particular model run. A brief discussion of each model run option is presented here for the sake of brevity. More details concerning the hydrologic processes themselves are available from other tRIBS documentation sources.

 

The OPTMESHINPUT keyword is used to indicate the option for inputting the topographic data into the model. It controls the sort of mesh data that is read by the model and necessary input data files related to the model mesh. Seven options currently are implemented within the tRIBS Model: 1 = tMesh files from a prior run are used to recreate the mesh (*.nodes, *.edges, *.tri, *.z); 2 = Point file used to create a new mesh (*.points); 3 = Arc/Info Grid file is read and sampled randomly to create the mesh; 4 = Arc/Info Grid file is read and sampled hexagonally to create the mesh; 5 = Arc/Info Ungenerated TIN file used to create a Points File (*.net); 6 = Arc/Info Ungenerated TIN files used to create a Points File (*.pnt and *.lin); 7 = Mesh constructed from scratch; 8 = Point File used with Tipper Triangulation procedure (*.points); 9 = Meshbuilder routines to deal with very large TIN domains (>200,000 to 10s of millions of nodes). The Meshbuilder is a separate executable that operates with an input file (*.in) and a points file (*.points). It is available for distribution through the code repository and should be compiled separately (a short readme describes its usage). 

 

The RAINSOURCE keyword is used to indicate the rainfall data source given to the model. Two types of radar rainfall data, as well as raingauge measurements are considered in the tRIBS Model: 1 = NEXRAD Stage III Radar (cm/hr); 2 = WSI Precip Radar (mm/hr); 3 = Rain Gauge station data (mm/hr).

 

The OPTEVAPOTRANS parameter indicates the evapotranspiration option selected during the model run. The choice of the particular option will set the required parameter values used from the land use reclassification table and the meteorological data file. Five options are available for evapotranspiration: 0 = Inactive; 1 = Penman-Monteith method; 2 = Deardorff method; 3 = Priestley-Taylor method; 4 = Pan Evaporation measurements. The OPTINTERCEPT option allows the user to choose between three particular interception routines: 0 = Inactive, 1 = Canopy storage method; 2 = Canopy water balance method. The choice of the particular option will set the required parameter values used from the land use reclassification table. The GFLUXOPTION keyword allows two types of ground heat flux calculations to be performed: 0 = Inactivel; 1 = Temperature gradient method, 2 = Force-restore method. The choice of the particular option will set the required parameter values used from the soil reclassification table.

 

The OPTSNOW parameter indicates the snow pack option used. Currently, either the single-layer energy balance module is on (OPTSNOW = 1) or off (OPTSNOW = 0). With the single-layer EB model, it has been found necessary to also input a minimum allowable temperature in Celsius (MINSNTEMP) in order to allow numerical stability. OPTRADSHELT  tells what radiation sheltering scheme is used: 0 = local; 1 = remote controls on diffuse shortwave radiation; 2 = remote controls on entire shortwave radiation; 3 = no sheltering.

 

The OPTLANDUSE parameter is used to indicate if static or dynamic land cover maps will be used in the simulation. Two options exist: OPTLANDUSE = 0 (static representation read in at the initial time period) and OPTLANDUSE = 1 (dynamic updating of the land cover at times specified by the available grids). If the dynamic updating is specified, then the user must indicate the pathname of the file containing the filenames of the ASCII grids to be read. This is specified using the keyword LUGRID (pathname to a Grid Data File, *.gdf). This file should contain the pathnames to the dynamic land cover grids. File naming convention only uses up to the hourly time stamp (no minutes, for example). The files need to be within the time boundaries of the simulation period. The keyword OPTLUINTERP allows for two types of interpolations between available land cover maps (at different time periods). OPTLUINTERP = 0 assigns the current gridded time step value to all model time steps up until the next available file. OPTLUINTERP = 1 linearly interpolates the land cover parameter values between two different grid time steps.


The OPTSOILTYPE keyword is used to activate the use of gridded soil parameter data input into the model. This option replaces the use of a soil grid index map and a soil parameter table. Two options exist: OPTSOILTYPE = 0, uses the traditional tabular soil data associated with a soil map of soil type numbers; OPTSOILTYPE =1, activates the use of gridded soil data, a new functionality. If OPTSOILTYPE = 1 then an additional folder named SoilTexture must be created in the main tRIBS directory where folders like Input and Output are located. This new folder should contain a database (*.gdf) file indicating the paths to all the grid files for each soil parameter. The format is similar to that used for the dynamic land cover maps. The directory path to the new folder is indicated under SCGRID keywrod in the Input File.

The METDATAOPTION is used to indicated the input format for the meteorological data: 0 = Inactive; 1 = Weather station point data; 2 = Grid meteorological data. The particular choice determines which type of text files, grid or point data files are required during model execution. The CONVERTDATA option is used to indicate whether or not meteorological pre-processing is activated: 0 = Inactive pre-processing; 1 = Activated pre-processing of meteorological data from RFC Point Data; 2 = Activated pre-processing of meteorological data from gridded observations provided by U. Wash (DMIP).

 

The OPTBEDROCK keyword is used to specify the format of the bedrock depth data: 0 = Uniform bedrock depth over the basin; 1 = Grid bedrock file. If OPTBEDROCK = 0, then the DEPTHTOBEDROCK keyword is required (input is a double), otherwise the BEDROCKFILE keyword is required (input is a path and filename with extenstion *.brd).

 

The OPTGWFILE keyword is used to specify the format of the initial groundwater input file. 0 = Resample ASCII grid file indicated in GWATERFILE; 1 = Read in Voronoi polygon file with groundwater levels output from previous run. GWATERFILE keyword only used for OPTGWFILE option 0, otherwise, the Voronoi GW file is read in through user interaction with model run (e.g. through screen).

 

The WIDTHINTERPOLATION keyword is used to specify whether or not channel widths will be interpolated between the measured and observed widths (= 0) or only between the measured channel widths (= 1), inputted to the model through the file name specified using the keyword CHANNELWIDTHFILE.

 

The STOCHASTICMODE keyword is used to specify whether or not stochastic rainfall forcing is used as an alternative to providing observed data from radar (grid field) or rain gauge (point). The stochastic mode is off (= 0) or on in various ways: Mean forcing (= 1), random forcing (= 2), sinusoidal forcing (= 3), mean and sinusoidal forcing (= 4) and random and sinusoidal forcing (= 5). The parameters of the stochastic mode include a random seed, a periodicity, a mean/max storm duration, a mean/max interstorm duration, a mean/max rainfall intensity. A complete stochastic weather generator for all climatic variables can also be utilized by specifying STOCHASTICMODE = 6 and a filename for WEATHERTABLENAME.


The OPTRESERVOIR keyword is used to activate the use of the linear reservoir module (tReservoir) in the model. 0 = Disable the use of Reservoirs. 1 = Activate the use of Reservoirs. If OPTRESERVOIR = 1 then additional information is required by specifying the path to the file containing the TIN nodes (or Voronoi polygons) to be used as reservoirs in RESPOLYGONID (*.res) and the path to the file containing the elevation-discharge-storage information for each type of reservoir in RESDATA (*.eds).


The OPTPERCOLATION keyword allows the user to select from several options for channel percolation losses. 0 = No channel percolation. 1 = Constant loss method where the infiltration rate is equal to the channel saturated hydrualic conductivity specified under CHANNELCONDUCTIVITY. 2 = Constant loss method with a transient period applied with the transient hydraulic conductivity specified as TRANSIENTCONDUCTIVITY and the transient time period specified as TRANSIENTTIME. 3 = Green-Ampt infiltration equation with the parameters specified as CHANNELPOROSITY, CHANPOREINDEX and CHANPSIB.

 

Model Input Files and Pathnames: Mesh Generation

When specifying the OPTMESHINPUT option, the model will require that the pathname of the input files be included within the Mesh Generation section of the Model Input File. The INPUTDATAFILE option is used to input the basename for the Mesh input files produced during a previous run (OPTMESHINPUT = 1), while the INPUTTIME keyword specifies the time slice for mesh input (for tRIBS, INPUTTIME should always be set to zero). If using OPTMESHINPUT = 2, then the POINTFILENAME keyword must be used to specify the pathname and filename of the Points File (*.points). If using OPTMESHINPUT = 2 through 6, then the keyword ARCINFOFILENAME specifies the pathname and basename for the Arc/Info grids or output files (*.asc, *.net, *.lin, *.pnt).

 

Mesh Input Files and Pathnames: Resampling Grids

The path and filenames of the grid input and the reclassification tables for the soil and land use data are grouped together within this section of the Model Input File. The soil grid (*.soi), land use grid (*.lan) and initial groundwater table position (*.iwt) are specified using the SOILMAPNAME, LANDMAPNAME and GWATERFILE keywords. The DEM used to derive the remote sheltering grids is specified by the DEMFILE keyword. The DEM used should encompass the study area and all significant surrounding topographic features, possibly outside the study area. The radar rainfall grid (for RAINSOURCE = 1 or 2) base name is specified using the RAINFILE keyword and the extension is inputted by using the RAINEXTENSION keyword.

 

Mesh Input Files and Pathnames: Meteorological Data

The path and filenames of the meteorological data are grouped together in this section of the Model Input File. If METDATAOPTION = 1, then the Station Data File (*.sdf) must be specified in HYDROMETSTATIONS and the Meteorological Data File (*.mdf) basename in HYDROMETBASENAME. Otherwise, if METDATAOPTION = 2, then the HYDROMETGRID keyword must contain the Grid Data File (*.gdf). If CONVERTDATA = 1, then the HYDROMETCONVERT parameter must specify the path and filename of the Meteorological Data Input (*.mdi) File.  If CONVERTDATA = 2, then the GAUGECONVERT parameter must be specify the path and filename of the rain gauge conversion file (*.mdi). The GAUGEBASENAME keyword is used to specify the base pathname of the MDF raingauge files. Finally, if RAINSOURCE = 3, then the GAUGESTATIONS keyword is used to specify the rain gauge SDF file. If CONVERTDATA = 3, then preprocessing of DMIP formatted observed energy forcings is performed. This results in an MDF file particular to the basin of interest (1992-2000 period) with somewhat altered list of meteorological parameters that can be ingested into the model. A separate SDF file must be prepared to correspond with this data.

 

Lapse rates have been implemented in the model for precipitation and temperature. The temperature lapse rate is assigned from TEMPLAPSERATE. The precipitation lapse rate is specified by PRECLAPSE in mm/m. Scattered light from opposing hillslopes can be a significant component of incoming radiations in snowy environments. HILLALBOPT = 0 uses the snow albedo for the hillslope albedo, HILLALBOPT = 1 uses the land-use albedo for the hillslope albedo, and HILLALBOPT = 2 uses a dynamic representation of albedo, where the snow albedo is used if there is snow in the canopy and a vegetative fraction weighted average of snow and land-use albedo is used otherwise.

 

Mesh Input Files and Pathnames: Output Data

The path and basenames of the output data are grouped in this section of the Model Input File. The keyword OUTFILENAME is used to specify the location and basename of the output mesh and the voronoi file (*.nodes, *.tri, *.edges, *.z and *_voi) as well as the dynamic variable output (*.pixel and *.dat). The keyword OUTHYDROFILENAME specifies the path and basename of the outputted hydrograph and hyetograph time series. The format of the hydrograph and hyetograph file (*.mdf) depends on the value of RIBSHYDOUTPUT: = 0, not compatible with RIBS output; or = 1, compatible with RIBS output. This distinction is necessary if the *.mrf files are to be used with the RIBS graphical user interface. The NODEOUTPUTLIST specifies the path and filename of the Node Output List (*.nol) file used to input the node IDs for dynamic variable output. The OUTLETNODELIST keyword specifies the interior stream nodes to be used for output of the interior hydrographs (*.nol file).

 

Model Modes: Rainfall Forecasting Mode

The tRIBS model can be used for real-time flood forecasting given predicted rainfall data from any number of sources (radar extrapolation, numerical weather prediction). Currently, the Rainfall Forecasting Mode allows the user to specify the forecast time, lead time and forecasting interval using the FORECASTTIME, FORECASTLEADTIME and FORECASTLENGTH keywords. The Forecasting mode is turned on using FORECASTMODE. Three options are available: Single or Updating forecast, Persistence Forecast or Climatological Forecasting. They differ in the product used after the forecasttime. For single or updating, the FORECASTFILE directory is read for the forecast product. Otherwise, a persistence of the last available rainfall or the climatological value are used. The RAINDISTRIBUTION enables the inputted rainfall to be spatially-averaged within tRIBS.


Model Modes: Stochastic Rainfall Mode

The tRIBS model can be forced with real rainfall data or stochastic rainfall input using the Eagleson or Rodriguez-Iturbe type Poisson storm process at a point. The Stochastic Rainfall Mode is invoked with the keyword STOCHASTICMODE specified as other than zero. The keywords PMEAN, STDUR, ISTDUR are used alone (option 1: mean forcing), in conjunction with the random seed SEED (option 2: random forcing), in conjunction with periodic forcing using the PERIOD, MAXPMEAN, MAXSTDURMN and MAXISTDURMN (option 3: sinusoidal forcing), in combination of both mean and sinusoidal (option 4: mean and sinusoidal forcing) or in combination of both mean and random forcing (option 5: mean and random forcing). The user should carefully review implications of selection with the tStorm class definition. A complete stochastic weather generator (Ivanov, 2004) for all climatic variables can also be utilized by specifying STOCHASTICMODE = 6 and a filename for WEATHERTABLENAME. See Ivanov (2004) chapter on stochastic climate forcing for more details.

 

4.4.2 Soil and Land Use Input

The description of the land surface characteristics in the tRIBS Model is achieved through the input of soil textural and land use/land cover data in the form of ASCII grids of a particular soil or land use code. The soil (*.soi) and land use (*.lan) grids are specified in the Model Input File by using the keywords SOILMAPNAME and LANDMAPNAME, respectively. Figure 4.3 presents an example of a soil or land use grid similar to the rainfall ASCII grid presented in Figure 3.1 for the Peacheater Creek basin at a resolution of 2 kilometers by 2 kilometers. As with other grid input, care should be taken to specify the grids in the same coordinate system as the topographic TIN data. The resampling routines included in the tResample class are designed to read the land use and soil cover grids and assign the appropriate codes to the TIN mesh nodes according to the geographic overlap of the two coverages. The geographic assignment is performed in one of two possible fashions, depending on the relative size of the grid input as compared to the Voronoi cell scale. For large input grids, such as those available from radar rainfall input, the resampling is performed by a nearest neighbor approach. For grid inputs at the scale of the Voronoi polygons, an aerial weighting is used to determine the dominant cover type. Further details are available elsewhere in the tRIBS documentation

 

 

nrows

6

 

 

 

 

ncols

6

 

 

 

 

xllcorner

346035

 

 

 

 

yllcorner

3979905

 

 

 

 

cellsize

2000

 

 

 

 

NODATA_value

-9999

 

 

 

 

-9999

-9999

-9999

1

0

-9999

-9999

-9999

1

0

0

-9999

-9999

-9999

1

0

1

1

-9999

0

1

1

-9999

-9999

0

0

1

-9999

-9999

-9999

0

0

-9999

-9999

-9999

-9999

Figure 4.3 Example of Soil or Land Use Class ASCII grid (*.soi and *.lan)

 

Once the land use and soil class codes are assigned to each Voronoi or TIN node, a set of procedures in tInvariant take care of constructing objects for each cover type. These cover type objects are referenced by the codes in the input grids and include references to the various parameter values associated with each cover type. The parameter values for the soil and land use grids are read from a reclassification table inputted separately into the model by using the keywords SOILTABLENAME and LANDTABLENAME. The format of these soil reclassification (*.sdt) and land use reclassification (*.ldt) tables are straightforward. They include a small header which specifies the number of cover types (#Types) and the number of variables for each type (#Params), as shown in Figure 4.4a and Figure 4.5a. The header is followed by a matrix of parameter values where each row represents one cover type and each column represents one parameter. Currently, there must be 12 parameters in the soil and land use reclassification tables. Without this appropriate number of parameters in the file, erroneous calculations may take place. In addition, the order and units of these parameters are fixed. Since parameter values outside the appropriate range may results in inaccurate calculations, the user should be careful to select realistic values from literature sources prior to model use. 

 

Figure 4.4a Soil Reclassification Table Structure (*.sdt)

#Types

#Params

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

ID

 Ks

thetaS

 thetaR

m

PsiB

f

As

 Au

n

ks

Cs

 

Figure 4.4b Soil Parameter Description

Parameter

Description

Units

Ks

Saturated Hydraulic Conductivity

[mm/hr]

thetaS

Soil Moisture at Saturation

[]

thetaR

Residual Soil Moisture

[]

m

Pore distribution index

[]

PsiB

Air Entry Bubbling Pressure

[mm] (negative)

f

Decay parameter

[mm-1]

As

Saturated Anisotropy Ratio

[]

Au

Unsaturated Anisotropy Ratio

[]

n

Porosity

[]

ks

Volumetric Heat Conductivity

[J/msK]

Cs

Soil Heat Capacity

[J/m3K]

 

Figure 4.4 presents the parameter values for the soil reclassification table. Notice that these parameters relate to the hydraulic and thermal properties of the soil cover type in the upper portions of the soil profile. Most of these can be directly related to the surface soil texture. The first nine parameters are essential for running the Unsaturated Zone Model while the last two are required if the keyword GFLUXOPTION = 1 (Wang and Bras, 1999). Detailed descriptions of each parameter and their use within the model equations is beyond the scope of this document and the user is referred to the available tRIBS documentation. Examples of a soil reclassification table, including parameter values in the appropriate range, are presented in the tRIBS Sample Application in the tRIBS Watershed Downloads Page.

 

Figure 4.5a Land Use Reclassification Table Structure (*.ldt)

 

 

#Types

#Params

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

ID

a

b1

 P

S

K

b2

Al

 h

Kt

Rs

V

LAI

 

 

Figure 4.5b Land Use Parameter Description

Parameter

Description

Units

A

Canopy Storage - Storage

[mm]

b1

Interception Coefficient - Storage

[]

P

Free Throughfall Coefficient - Rutter

[]

S

Canopy Field Capacity - Rutter

[mm]

K

Drainage Coefficient - Rutter

[mm/hr]

b2

Drainage Exponential Parameter - Rutter

[mm-1]

Al

Land-Use Albedo

[]

H

Vegetation height

[m]

Kt

Optical Transmission Coefficient

[]

Rs

Canopy-average Stomatal Resistance

[s/m]

V

Vegetation Fraction

[]

LAI

Canopy Leaf Area Index

[]

theta*_s

Stress threshold for Soil Evaporation

[]

theta*_t

Stress threshold for Plant Transpiration

[]

 

Figure 4.5 presents the parameter values for the land use reclassification table. Notice that these parameters relate to the interception and evaporation properties of the vegetative cover or land use type. Most of these can be directly related to the land use codes. The first two parameters are required if the keyword OPTINTERCEPT = 1, while the next four are required if OPTINTERCEPT = 2.  The final five parameters are required for various options of the keyword OPTEVAPOTRANS. Detailed descriptions of each parameter and their use within the model equations is beyond the scope of this document and the user is referred to the available tRIBS documentation. The last two parameters have been recently added to specify the soil moisture stress threshold for soil evaporation and plant transpiration. These used to be specified simply as 0.75*thetaS, but now the user is responsible for setting these in units [] consistent with other soil moisture thresholds. Examples of a land use reclassification table, including parameter values in the appropriate range, are presented in the tRIBS Sample Application in the tRIBS Watershed Downloads Page.

 

4.4.3 Meteorological Point Data Input

The input of meteorological data is essential for utilizing the tRIBS Model for continuous hydrologic simulations over storm and interstorm cycles. Meteorological input into tRIBS can from point data or grid data, depending on the data sources available (i.e. from weather observing stations or from numerical model predictions). The data input used for weather station data is based on the Point Station Data Input described previously.  The data input for the grid meteorological parameters is based on the structure to the radar rainfall input as described in the Meteorological Grid Input section of this document. The two data inputs are treated in a distinctly different manner within the model.  Whereas the entire point data time series is stored into an object (e.g. tHydroMet), the grid data is read sequentially for each time step without object storage. Figure 4.6 shows the two forms of meteorological data input and storage.

 

Figure 4.6 Meteorological Data Input Methods

Characteristic

Point Data

Grid Data

Input 

Station Descriptor File (*.sdf)

ASCII grids (*.txt, *.lan, *.soi)

 

 

Meteorological Data File (*.mdf)

 

 

Storage

Assignment to storage objects

Direct assignment to tCNode

Manipulation

Thiessen point resampling 

Grid resampling

Examples

tHydroMet, tRainGauge

tRainfall, tVariant, tInvariant

 

Note that the methodology for the input of meteorological data is reused for various purposes. For example. the tHydroMet object (used in tEvapoTrans), which stores data from weather stations, was simplified to create the tRainGauge class (used in tRainfall) with very similar functionality. The tRainfall grid manipulations where extended to read in time-invariant grid, such as land use and soils (tInvariant), and time-varying weather parameter grids (tVariant). The format of the Station Descriptor Files (*.sdf) and the Meteorological Data Files (*.mdf) is modified slightly depending on whether these contain meteorological, rain gauge or pan evaporation data. Figures 4.7 and 4.8 describe the format of the *.sdf and *.mdf files for the various applications, including comments on the parameters and units.

 

Station Descriptor File Structure

Figure 4.7a. Weather Station and Pan Evaporation SDF Structure

#Stations

#Params

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

StationID

FilePath

AbsLat 

 RefLat

AbsLong

RefLong

GMT

RecordLength

 #WeatherParams

Other

 


Figure 4.7b.
Rain Gauge SDF Structure 

 #Stations

#Params

 

 

 

 

 

 

 

 

 

 

StationID

FilePath

RefLat

RefLong

RecordLength

#RainParams

Elevation

 

Note that the following: #Stations is the number of total stations to be read, #Params is the number of parameters for each of the subsequent lines, StationID must be unique values for each station (starting at 0), the FilePath refers to the MDF file for that particular station and must be relative to the location of the executable, the AbsLong and AbsLat must be in decimal degree (lat/long), the RefLong and RefLat must be in the same coordinate system as the input grids and watershed TIN, Greenwich Mean Time (GMT) is difference in hours between the location and the Greenwich  Meridian (negative number in Western Hemisphere), the RecordLength is the length of the time series in the MDF file, the #WeatherParams and #RainParams are the number of parameters in the MDF file including the date and time, and Other is used for inputting additional station information, such as station elevation, if desired. Also note that these keywords are not included in the file, just the parameter value. An example of an SDF file is presented in the tRIBS Sample Application in the tRIBS Watershed Downloads Page.

 

Meteorological Data File Structure

Figure 4.8a. Weather Station MDF Structure

Y

M

D

H

PA

TD/RH/VP

XC

US

TA

TS

NR

...

...

...

...

...

...

...

...

...

...

...

 

 

Figure 4.8b. Rain Gauge and Pan Evaporation MDF Structure

Y

M

D

H

R/ET

...

...

...

...

...

 

 

Figure 4.8c. MDF Parameter Description

Parameter

Description

Units

Y

Year

[yyyy]

M

Month

[mm]

D

Day

[dd]

H

Hour

[hh]

PA

Atmospheric Pressure

[mb]

TD

Dew Point Temperature

[C]

RH

Relative Humidity

[%]

VP

Vapor Pressure

[mb]

XC

Sky Cover

[tenths]

US

Wind Speed

[m/s]

TA

Air Temperature

[C]

TS

Surface Temperature

[C]

IS

Incoming Solar Radiation

[W/m2]

NR

Net Radiation

[W/m2]

ET

Pan Evaporation

[mm/hr]

R

Rainfall

[mm/hr]

 

Note the following: the parameter names must be a placed in a header for each MDF file, the TD/RH and R/EP imply that either one of these parameters can be inputted into that particular field, there must be RecordLength number of lines following after the header in intervals, missing data must be inputted with the NO_DATA flag = 9999.99, and the units must be retained as indicated, including for IS, NR and TS (but not for ET). Rainfall (R) is typically specified in its own MDF file. Notice that the file does not contain a minute column. Nevertheless, sub-hourly data can be inputted into the model at intervals that are multiples of the TIMESTEP. For example, for 15-minute data, the user should specify four rows for each hour (same H) in order. A similar approach is taken for sub-hourly rain gauge data. Examples of MDF files for weather stations and raingauge stations are presented in the tRIBS Sample Application in the tRIBS Watershed Downloads Page.

 

4.4.4 Meteorological Grid Data Input

An alternative input format type for meteorological data is with the use of grid data. This option in the tRIBS model is used with the keyword METDATAOPTION = 2, while the more traditional weather station data is specified with METDATAOPTION = 1. The use of grid weather variables maybe convenient for inputting results from a numerical weather model that predicts the conditions of the atmosphere over large regions and produces grid output of temperature, wind or other fields. As described in Figure 4.6, the format for the meteorological grid input inherits its capability from the radar rainfall input in tRainfall, but with a slight modification necessary to deal with the multiple weather grids to be read for each time step. The additional information is provided through a text file for reading in meteorological input (*.gdf) as specified through the keyword HYDROMETGRID in the Model Input File. The structure of the Grid Data File or GDF is presented in Figure 4.9

 

Figure 4.9 Meteorological GDF File Structure

#Params

 

 

 

 

Latitude

Longitude

GMT

PA

Grid File Pathname

Grid Extension

TD

Grid File Pathname

Grid Extension

XC

Grid File Pathname

Grid Extension

US

Grid File Pathname

Grid Extension

TA

Grid File Pathname

Grid Extension

IS

NO_DATA

NO_DATA

TS

NO_DATA

NO_DATA

NR

NO_DATA

NO_DATA

RH

NO_DATA

NO_DATA

 

It is apparent from comparing the GDF file structure to the MDF and SDF files that there are similarities in the approaches. Note that the first line specifies the total number of parameters to be inputted, while the second line is used to input a representative absolute latitude, longitude and GMT values for all the input grids. The next #Params lines are used to specify the parameter code, the file pathname of the weather grid (including the basename of the file) and the extension given to the particular grid. The NO_DATA flag is used to specify that weather grids are not available for a particular parameter. As with the weather station data, all the keywords used to represent the parameters are fixed as well as the units, as specified in Figure 4.8c. A variation to the GDF format can be made so that grid values of evaporation can be directly inputted into the model, thus bypassing the model calculations. The required changes involve using only one parameter line with the parameter name ET and the corresponding filepath name and extension, in addition to specifying the keyword OPTEVAPOTRANS = 4 in the tRIBS Model Input File.

 

4.4.5 Land Cover Grid Data Input

An alternative input format type for dynamic land cover data is with the use of grid data. This option in the tRIBS model is used with the keyword OPTLANDUSE = 1, while the more static land cover  is specified with OPTLANDUSE = 0. The use of dynamic land cover variables maybe convenient for inputting remotely sensed vegetation fields. The format for the dynmaic grid input is similar to the meteorological grid input. Information is provided through a text file for reading in land cover grid input (*.gdf) as specified through the keyword LUGRID in the Model Input File. The structure of the Grid Data File or GDF is presented in Figure 4.10

 

Figure 4.10 Land Cover GDF File Structure

#Params

 

 

 

 

Latitude

Longitude

GMT

AL

Grid File Pathname

Grid Extension

TF

Grid File Pathname

Grid Extension

VH

Grid File Pathname

Grid Extension

SR

Grid File Pathname

Grid Extension

VF

Grid File Pathname

Grid Extension

CS

Grid File Pathname

Grid Extension

IC

Grid File Pathname

Grid Extension

CC

Grid File Pathname

Grid Extension

DC

Grid File Pathname

Grid Extension

DE

Grid File Pathname

Grid Extension

OT

Grid File Pathname

Grid Extension

LA

Grid File Pathname

Grid Extension

 

Note that the first line specifies the total number of parameters to be inputted, while the second line is used to input a representative absolute latitude, longitude and GMT values for all the input grids. The next #Params lines are used to specify the parameter code, the file pathname of the land cover parameter grid (including the basename of the file) and the extension given to the particular grid. The NO_DATA flag is used to specify the grids that are not available for a particular parameter. The parameter grids that can be inputtted are AL (albedo, Al), TF (free throughfall coefficient, P), VH (vegetation height, H), SR (stomatal resistance, Rs), VF (vegetation fraction, V), CS (canopy storage, A), IC (interception coefficient, b1), CC (canopy field capacity, S), DC (drainage coefficient, K), DE (drainage exponential coefficient, b2), OT (optical transmission coefficient, Kt) and LA (canopy leaf area index, LAI), which are described in Figure 4.5a and 4.5b in terms of units. 


4.4.6 Reservoir Data Input

The input of reservoir data into tRIBS enables the level pool routing simulation within the hydraulic channel routing scheme (tKinemat). To enable this routing option, there are two main files the user is required to provide. The Reservoir Polygon ID File provides information concerning the selected nodes to be used as Reservoirs. Figure 4.11 presents the format required in the Polygon ID file (*.res). The number of reservoirs (nReservoirs) specifies the number of TIN nodes (Voronoi polygons) that will be used as dam locations in the simulation. nNodeParams are the number of parameters required for each node, which should always be set at 3. In the body of the file, the user should include the ID number of the TIN node in the first column (NodeID, int, node selected by the user as a reservoir), followed by the type of reservoir the node will be (ResNodeType, int, type of reservoir associated with the node, linked to the RESDATA information) and the initial water surface elevation (Initial_H, double, meters) at the reservoir in the third column (empty reservoir should be specified as 0.0 m). When assigning the node to be used as a reservoir, the user should assign nodes that correspond to the start or the end of a river reach, to do so it is recommended to use the Voronoi mesh and stream network to identify potential nodes. An example of a *.res file is presented in Figure 4.12.

Figure 4.11 Format for the Reservoir Polygon ID File (*.res).

nReservoirs

 nNodeParams

 

 

 

 

NodeID

ResNodeType

Initial_H



 

Figure 4.12 Example of a Reservoir Polygon ID File (*.res).

4

 3

 

 

 

 

578867

0

0.0


575490
1
0.0

573514
2
0.0

574354
3
0.0


The second file that the user should provide is the RESDATA information (*.eds) related to the elevation-discharge-storage data of each reservoir type. Figure 4.13 presents the format required for the elevation-discharge-storage data file (*.eds). The header will include the number of types (nTypes) of reservoirs and the number of reservoir parameters (nResParams) required which should always be set to 4. The identifier for the type of reservoir should start with the number zero and be repeated for each row that describes an individual reservoir type. For a second reservoir type, the identifier would have a number of one. The second column will have the elevation (in meters) with the corresponding discharge (m3/s, double) and storage (1000 m3, double) for that elevation in the third and fourth column. An example of the reservoir data file (RESDATA) is presented in Figure 4.14, notice the change from 0 to 1 in the first column indicating the change from one reservoir type to another.


Figure 4.13 Format for the Reservoir Data File (*.eds).

nTypes

 nResParams

 

 

 

 

Type#

Elevation (m)

Discharge (m3/s)

Storage (1000 m3)

 

Figure 4.14 Example of a Reservoir Data File (*.eds).

2

 4

 

 

 

 

0

0

0

0

0
0.5
50
10
0
1
350
50
0
1.5
1200
300
0
2
1500
12000
1
0
0
0
1
0.5
10
100
1
1
20
400
1
1.5
30
800
1
2
40
1600


4.4.7 Soil Grid Data Input

Griddded soil data can be used as an alternative to the tabular soil parameter input. Similar to the Land Cover Grid Data Input, the use of grid data may be convenient for inputting soil parameters obtained from remotely sensed data. To activate the use of the gridded soil data the user must the keyword OPTSOILTYPE = 1 in the Input File (*.in). If OPTSOILTYPE = 0 then the use of the tabular data will be selected. The information is provided in a similar fashion as the dynamic land cover grids, through the use of a text file for reading soil grid input (*.gdf) specified through the keyword SCGRID in the Input File. The Structure of the soil grid data file or GDF is similar to the one seen in Figure 4.10. The user can copy the format required from Figure 4.15. The path name and abbreviation should be kept. The location of the GDF text file should be within the newly created folder "SoilTexture", as such, the location specified in the Input File should be: "SoilTexture/*.gdf". The format of each individual grid should follow the same specifications provided in Figure 4.3.

 

Figure 4.15 Soil Parameter GDF File Structure

#Params

 

 

 

 

Latitude

Longitude

GMT

KS

Grid File Pathname

Grid Extension

TS

Grid File Pathname

Grid Extension

TR

Grid File Pathname

Grid Extension

PI

Grid File Pathname

Grid Extension

PB

Grid File Pathname

Grid Extension

FD

Grid File Pathname

Grid Extension

AR

Grid File Pathname

Grid Extension

UA

Grid File Pathname

Grid Extension

PO

Grid File Pathname

Grid Extension

VH

Grid File Pathname

Grid Extension

SH

Grid File Pathname

Grid Extension

 

The parameter grids required are KS (Surface hydraulic conductivity, Ks), TS (Soil Moisture at Saturation, thetaS), TR (Residual Soil moisture, thetaR), PI (Pore distribution index, m), PB (Air entry bubbling pressure, PsiB), FD (Decay parameter, f), AR (Saturated Anisotropy Ratio, As), UA (Unsaturate Anisotropy Ratio, Au), PO (Porosity, n), VH (Volumetric heat conductivity, ks), and SH (Soil heat capacity, Cs), which are described in Figure 4.4a and 4.4b in terms of units.


4.5 Model Output

The tRIBS Model produces a number of output files that represent the time series or the spatial distribution of model state or output variables. Output variables include the position of moisture fronts in the unsaturated zone, water table elevation, surface runoff, subsurface flux, rainfall rate, interception loss, evapotranspiration, and information on the mesh triangulation, just to name a few. Currently, the time series output files are processes using MATLAB scripts while the spatial maps of model variables are read directly into Arc/Info or ArcView GIS for viewing using a set of AML scripts. Figure 4.16 summarizes the various output files created by a typical tRIBS model run.

 

 

Output File Type

Extension

Content Summary

Mesh Node File

*.nodes

Node (x,y), ID of spoke, boundary code.

Mesh Edge File

*.edges

ID of origin and destination node, ID of CCW edge.

Mesh Triangle File

*.tri

ID of vertex nodes, ID of neighboring triangles opposite the vertex node , ID of CCW edge originating with the vertex node.

Mesh Node Elevation File

*.z

Node elevation (meters).

Mesh Voronoi Geometry

*_voi

Arc/Info Generate format file with the Voronoi polygon geometry.

Basin Averaged File

*.mrf

Time series of outlet hydrograph (m3/s) and mean basin rainfall (mm/hr).

Hydrograph Runoff Types File

*.rft

Time series of outlet hydrograph by runoff type (m3/s).

Node Dynamic Output File

*.pixel

Time series of dynamic variables for a specific node.

Mesh Dynamic Output File

*timestamp_00d

Dynamic variable output for all mesh nodes at specific time.

Mesh Integrated Output File

*timestamp_00i

Time-integrated variable output for all mesh nodes.

Figure 4.16 Summary of tRIBS Output Files

 

The location of the output files is specified in the tRIBS Model Input File by using the keywords OUTFILENAME and OUTHYDROFILENAME. Typically, two separate directories are created within a basin output directory, one for the output related to the mesh (voronoi) and one with the output related to the hydrograph files (hyd). The keywords describe the pathname to those directories relative to the location of the executable and the basename to be given to all the files. The two directories facilitates the distinction between spatial and temporal output from the tRIBS Model. An important note to make is that the *.mrf, *.rft and *.dat files produced by the model are labeled with additional identifiers before the extension that relate to the time of the output. For each OPINTRVL time step, the model will produce output of the *.mrf type, while the *.rft file is produced only after completion of the entire run. The spatial output (*timestamp_00d) are determined by the time step specified in the SPOPINTRVL keyword. Time-integrated spatial output (*timestamp_00i) is produced only at the end of the simulation. The model also produces various files with a *.pixel extension followed by a node ID number at the end of the run. The *.pixel# files contain the dynamic variable output for a single node for all model times. The number of *.pixel# files produced is specified through a Node Output List (*.nol) File described in Figure 4.17.


 

 

#Nodes

 

 

 

 

 

 

NodeID1

NodeID2

NodeID3

...

Figure 4.17 Node Output List File Structure

A similar structure and file is used for the keyworkd HYDRONODELIST and OUTLETNODELIST. Using this file, allows the user to obtain the runtime hydrologic information in the unsaturated and saturated model for each time step as output to the screen, a useful tool for debugging. No filename suppresses the debugging information. A more detailed description of the output format for each file type is not included here for brevity. The user is referred to the CHILD User Manual (Tucker, 1999) for information on the Mesh Output Files and to the tRIBS Sample Application for more details concerning the output files particular to tRIBS. In addition, more information can be found in the tRIBS Temporal and Spatial Model Output section within the tRIBS website.

 

5.0 Terrain Analysis for Model Setup

An important task in the application of TIN-based distributed hydrologic models is the automatic creation of a TIN Terrain Model that is tailored specifically for watershed hydrology. Although the creation of a TIN terrain model through existing software packages is common, ensuring that a TIN model's resolution, features and representation are adequate for the purpose of TIN-based hydrologic modeling is a critical exercise that is often ignored in the modeling process. For example, various TIN-based watershed models apply a set constant resolution triangles to represent the watershed, a feature which does not take advantage of the topographic diversity in the watershed terrain and the potential for multiple resolutions. In addition, the creation of the TIN must also conform to various linear features present in the topography, which may include the stream network and the watershed boundary. These features ensure that the generation of the TIN Terrain model is "hydrologically" significant for distributed modeling purposes. Although various software packages exist for the creation of a TIN terrain model (e.g. Arc/Info, IDL and other finite element mesh generators), the use of Arc/Info is recommended due to its easier integration with the data sources required to create the hydrologic TIN model. For tRIBS, a set of Arc/Info scripts written in AML (Arc Macro Language) have been developed to take the various inputs describing the watershed and create a TIN which can ultimately be inputted into the tRIBS Model using options 5 or 6 of the keyword OPTMESHINPUT.

5.1 Digital Elevation Models and Stream Networks

The basic building block of the TIN mesh developed for watersheds with complex topography is the raster Digital Elevation Model (DEM). Topographic representation through Digital Elevation Models (DEMs) has increased our capability of modeling the surface and subsurface hydrologic processes that govern the rainfall-runoff conversion. High resolution DEMs are readily available from the US Geological Survey at various spatial resolutions. Typical data sets are derived from printed contour maps after procedures for digitizing and interpolating onto a regular grid. The highest resolution product from the USGS are the 7.5 minute DEM products (30 meters ground resolution). Higher resolution DEMs would require field surveying techniques, aerial photogrammetric analysis or LIDAR measurements that are currently difficult to obtain at a low cost. Recommended sources of DEM data include:

USGS Geographic Data

National Elevation Data Set

BASINS Watershed Data Set


Each data distributor will provide the topographic data is a slightly different format or projection. ArcView GIS or Arc/Info can be used to visualize the elevation data and perform many of the required hydrologic computations based on the topography. The DEM should be hydrologically corrected by removing pits or sinks, thus ensuring a continuous water flow over the watershed. Further DEM processing includes: (1) defining the cell slopes, (2) defining the flow directions, and (3) calculating the flow accumulations. Although the tRIBS model does not require any of these inputs directly, they are an important part of deriving the watershed boundary and the stream network. The stream network is computed from the flow accumulations grid by setting a threshold value on the definition of a stream cell. By comparing the drainage density between the DEM-based stream network to the drainage density of the blue-line vectors from a USGS Quad Sheet, one can determine an appropriate threshold parameter. Although not directly used in the modeling process, the hydrography vector data is an important source of information for obtaining the correct DEM-based stream network. Recommended sources of hydrography data include:

USGS Geographic Data

National Hydrographic Data Set

BASINS Watershed Data Set


Having the appropriate stream network, the derivation of the watershed boundary can be performed again within the ArcView GIS or Arc/Info environments. Specific details on the methods used to derive watershed descriptors is omitted from this document for the sake of brevity. The user is referred to a set of AML DEM processing scripts included in the TIAP software page as a starting point for watershed data analysis using DEMs.

 

5.2 Triangulated Irregular Network Model

A "hydrologically" significant TIN terrain representation consists of a set of triangular elements that together represent the important hydrologic features within a complex watershed. The multiple resolution capability of TIN models is a principal advantage to using a TIN representation. The use of multiple resolutions allows flat terrain to be represented with a coarser resolution as compared to a rugged landscape, thus having significant computational savings in regions of low-gradients within the watershed. Obtaining a multiple resolution TIN is performed by sampling the Digital Elevation Model at points considered to be topographically important at a global scale. Without entering into details, this implies that only points whose elevation is critical to the proper TIN representation, as compared to the original DEM, are kept within the TIN Terrain Model. All other points are discarded. This DEM sampling procedure permits high resolution to be used for rugged terrain and lower resolution for flat landscapes. Details concerning this procedure and the objective measures used to determine the appropriate sampling are presented elsewhere in the tRIBS documentation.

In addition to sampling the DEM to obtain a multiple resolution TIN, the generation of an appropriate terrain model for hydrological purposes should include the representation of linear features within the watershed. Two types of linear features are of critical importance: the watershed boundary and the watershed stream network. Ensuring that the TIN conforms to these linear features will result in capturing the appropriate watershed area and converging the terrain to the water bodies present inside the watershed. Techniques for incorporating the watershed boundary and the stream network have been developed and applied to a variety of watersheds. Various considerations that arise when computing the dual diagram or Voronoi Polygon Network (VPN) from the TIN have also been incorporated into the creation of the mesh. Again, more details are presented elsewhere in the tRIBS documentation.

The generation of a multiple resolution TIN mesh using the linear watershed features and the DEM sampling does not necessarily take into account the fact that a "hydrologically" significant TIN should have increased resolution near the stream network. Additional resolution near the channel network and within the floodplain is important when a hydrologic model considers the contraction and expansion of variable source areas for runoff. With poor spatial discretization within a floodplain, the runoff producing areas during a storm event are not well captured. For this reason, a set of procedures for identifying a floodplain and deriving a floodplain-scale, constant resolution TIN mesh from a watershed DEM have been developed. The floodplain TIN is then used as an input to the watershed-scale TIN to obtain a finer discretization of the near-channel source areas.

A manuscript describing the procedures for the generation of a TIN Terrain model with the hydrologic considerations in mind is in preparation with a set of example case studies and objective measures to guide the user in the proper selection of procedure parameters. The user is also referred to a set of AML TIN generation scripts included in the TIAP software page as a starting point for understanding the methods used to arrive at a "hydrologically" significant TIN Terrain Model.

 

6.0 Hydrometeorological Data Processing

Hydrometeorological data is a requirement in the tRIBS Distributed Hydrologic Model whenever the application calls for continuous hydrologic simulations over the storm-interstorm cycle or even during event-based modeling where the rainfall forcing is required. In either case, the appropriate hydrometeorological data must be obtained from available sources and preprocessed into a format amenable for input into the tRIBS Model. The processing of radar rainfall data and weather station data are briefly described in the following sections. Additional model capabilities, including rain gauge precipitation input and grid meteorological input, are omitted for brevity but have also been incorporated into the tRIBS model. Further details are available upon submitting a request to the authors.

 

6.1 NEXRAD Stage III and WSI Rainfall Radar Data

Various sources of rainfall data for hydrologic modeling are available through the National Weather Service (NWS) and other state, local or federal agencies. Rain gauges, the traditional sources of rainfall data, measure the amount of precipitation falling inside a calibrated bucket at a single point. Measurements from rain gauges are typically sparse in their spatial coverage (1 rain gauge for every 1-50 square kilometers) but reasonably accurate a single point. The use of rain gauges for distributed hydrologic modeling requires an interpolation of rainfall values over the watershed (using Thiessen polygons) so that each model computational element is assigned the value of its nearest neighboring gauge. An improvement upon the use of rainfall gauges can be obtained by using the spatially-variable rainfall fields available from radar sensors. In the United States, a significant effort has been made to sample rainfall fields through a nationwide network of weather radars. The NEXRAD system provides rainfall coverage for the continental United States by using approximately 160 individual radars that measure the three dimensional reflectivity field every six minutes at a spatial resolution of 2 kilometers by 2 kilometers.

For hydrologic modeling purposes, the NEXRAD reflectivity data from the individual radars have to be processed to obtain a mosaiced rainfall product that has been adjusted by raingauge values (mean-field bias adjustment). Various sources of NEXRAD data are available from different public and private sector distributors:

National Weather Service Stage III Data

Weather Services International (WSI)

DTN Weather Services


Each distributor performs a different set of correction and conversion algorithms to obtain accurate rainfall grids over the entire United States. The Stage III data is freely available from the NWS and well documented (e.g. Young et. al, 2000). The NEXRAD data is organized by monthly intervals and by River Forecasting Center (RFC) so that a mosaic for each RFC (e.g. Arkansas-Red River Basin) is available at hourly intervals on a 4 km by 4 km grid. The other two data sources are available from the distributors for a fee. More information about the data distribution and processing algorithms must be obtained from the corporations themselves, as they are proprietary.

The tRIBS Distributed Hydrologic Model has been used with both the NWS Stage III data and the WSI Corporation radar rainfall data. The NWS Stage III data was downloaded from the archived source as a collection of tar-gzipped binary files. A utility called read_xmrg is available from the NWS to read the binary file and convert them to ASCII grids (e.g. Figure 3.1) . Our work has used a previous version of this code named xmrgtoascster.c  to convert the binary format into a grid product in Polar Stereographic projection. Once in an amenable ASCII format, a set of Arc/Info Arc Macro Language (AML) scripts have been developed to convert the Polar Stereographic grids for the entire RFC into a grid for the particular watershed in a specific local coordinate system (in cm/hr) . The AML routine (radarconvert.aml) also perform the unpacking of the tar-gzip ball, calling of the xmrgtoascster program, as well as the projection and clipping of the rainfall grid. A useful paper describing the NEXRAD projections and coordinate system is Reed and Maidment (1998).  The Weather Services International (WSI) radar rainfall data is not freely available to the public. Through our project collaborators, Atmospheric and Environmental Research, Inc. (AER), we obtain rainfall ASCII grids in decimal degrees (in mm/hr) for the particular region of interest. The data are obtained at AER through a satellite feed, archived and preprocessed from the binary stream to an ASCII grid file structure. A set of AMLs have been developed for projecting, clipping and preparing the WSI data into the tRIBS grid input format (wsiconvert.aml). The WSI data are available at a 15 minute temporal resolution and up to a 2 km by 2 km grid spatial resolution. Comparisons between the WSI and Stage III radar products have shown that the WSI have an improved spatial resolution and remove many of the artifacts in the interpolation scheme used for the Stage III data. A report on this subject is in preparation.

In terms of the tRIBS Model, the use of the two radar rainfall sources is controlled by the keyword RAINSOURCE ( = 0, NEXRAD Stage III, = 1, WSI Product ) in the tRIBS Model Input File. The RAINFILE and RAINEXTENSION keywords are used to specify the pathname and basename, and the extension of the rainfall input grids. In addition, the RAININTRVL and RAINSEARCH keywords are used to specify the temporal spacing of the input rainfall grids and the maximum time over which the model will search for a new input rainfall grid. Finally, the tRIBS Model computes a basin-averaged rainfall hyetograph from the grid input rainfall fields, which is outputted as the second column of the hydrograph (*.mdf) file.

 

6.2 Operational RFC Meteorological Data

Various sources are available for hydrometeorological data through state, federal and local government agencies. In the United States, however, the distribution of weather data is neither standardized or centralized. Weather data, in general, is available in a number of different formats, sampling periods, number of parameters, record lengths, aerial extents and accuracy. Finding an appropriate source for input into a hydrologic model is not straightforward, even more so if you consider that a change in the any of the above properties alters the input code, data checks and calculations possible within the model. In the search for hydrometeorological data, the reader is referred to the following data sources:

NCDC Cooperative Summary of the Day (NOAA NCDC Site)
Hourly US Weather Observations (CD-ROM collection)
Operational RFC Point Data (NOAA Operational RFC Site)
State Mesonet Weather Network Data (e.g. Oklahoma Mesonet)

 

Other sources of data from meteorological stations and/or interpolations of weather observations are available from other government agencies or research institutions. For the tRIBS, the use of the Operational RFC Point Data was selected as the weather data source of choice. Among the reasons for this selection were the fact that the data is available freely for the entire United States at an hourly interval and includes all the necessary weather parameters necessary for a complete description of the atmospheric state. In addition, the Operational RFC Point Data is a collection of data provided to the River Forecasting Centers (RFC) from different data providers, including state-wide mesonets, for flood forecasting purposes. As such, this data source ensures appropriate compatibility with the weather information available real-time at the RFC centers. Finally, the data availability only lags behind the current date by one year, allowing recent events to be modeled without waiting for data releases that occur 2-3 years after the date of observations (e.g. CD-ROMs).

A drawback of the Operational RFC Point Data is the format in which it is provided (i.e. Informix database tables). The data files are extremely large (> 200 MB) since they provide the hourly weather data for all the stations within an RFC (i.e. Arkansas-Red River Basin) for an entire month. In order to deal with this data in a more efficient way within tRIBS, a preprocessor class called tHydroMetConvert was created. This class reads in the weather data from the RFC Point Data Files and produces the tRIBS HydroMet Station and HydroMet Data files (*.sdf and *.mdf, respectively) necessary for use with the evapotranspiration class (tEvapoTrans).

In order to use tHydroMetConvert, a separate text file must be created (*.mdi) that specifies the stations, parameters, file pathnames and options. An *.mdi file (Meteorological Data Input) has a simple structure, as shown in Figure 6.1 and an example can be obtained from the Sample Application available from the tRIBS Downloads Page.

Figure 6.1 Meteorological Data Input File Structure

#Files   #Stations   #Parameters

MERGE/SEPARATE Option

Path Name of Data File 1

Path Name of Location File 1

PathName of Data File 2

PathName of Location File 2

...

Name of Station 1

Name of Station 2

...

Name of Parameter 1      Station #

Name of Parameter 2      Station #

...


Some explanation of these various components should shed light upon the use of the *.mdi files. The first line simply states the number of RFC Point Data Files to be read, each containing a month of data, followed by the number of weather observation stations to be read and the total number of weather parameters to be read. Identifying the appropriate station names and the appropriate parameter names is done by inspecting the RFC Point Data File and locating the stations according to their proximity to the watershed of interest. Information about each station, including the latitude and longitude, is found in the RFC Point Location File. The MERGE or SEPARATE key word is important since it will specify whether or not the data from various stations will be merged into one tRIBS HydroMet Data File (*.mdf) or if the station data will be kept in separate files. This option is useful if the user has identified more than one station near to the watershed of interest that have complementary data (e.g. station 1 has data missing in station 2). The pathname lines are used to specify the location of the Data File and the Location Files that need to be downloaded from the Operational RFC Site. The name of the station lines correspond to the actual name given to each site within the RFC file. The proximity of the chosen stations should be ascertained by using the location of station and a watershed map within a GIS program. The name of the parameter lines include both the actual parameter name (e.g. TA, XC, TD) and the number of the station from which it will be extracted (if MERGE option used). Further details can be obtained from the tHydroMetConvert class source code. Note that the use of the hydrometeorological data processor is controlled in the tRIBS Model Input File through the keywords METDATAOPTION (= 0, inactive, = 1, point data, = 2, grid data) and CONVERTDATA (= 0, inactive, = 1, preprocess weather data).


7.0 Contacts and Further Reading

Contacts

Enrique R. Vivoni
School of Earth and Space Exploration
School of Sustainable Engineering and the Built Environment
Arizona State University
vivoni@asu.edu
http://vivoni.asu.edu


References

Deitel, H.M. and Deitel, P.J. 2001. C++ How to Program. Third Edition. Prentice Hall, Upper Saddle River, NJ.

Environmental Systems Research Institute. 1996. ArcView Spatial Analyst. Redlands, CA.

Environmental Systems Research Institute. 1996. Understanding GIS: The Arc/Info Method. Redlands, CA.

Garrote, L. and Bras, R.L. 1995. A distributed model for real-time flood forecasting using digital elevation models. Journal of Hydrology. 167(1-4): 279-306.

Garrote, L. and Bras, R.L. 1995. An integrated software environment for real-time use of a distributed hydrologic model. Journal of Hydrology. 167(1-4): 307-326.

Lippman, S.B. and Lajoie, J. 1998. C++ Primer. Third Edition. Addison-Wesley. Reading, MA.

Reed, S.M. and Maidment, D.R. 1999. Coordinate transformations for using NEXRAD data in GIS-based Hydrologic Modeling. Journal of Hydrologic Engineering. 4(2): 174-182.

Rybarczyk, S.M. 2000. Formulation and Testing of a Distributed Triangular Irregular Network Rainfall/Runoff Model. MS Thesis. Massachusetts Institute of Technology. Cambridge, MA.

Tucker, G.E., Gasparini, N.M., Bras, R.L. and Lancaster, S.T. 1999. A 3D Computer Simulation Model of Drainage Basin and Floodplain Evolution: Theory and Applications. Technical Report. Department of Civil and Environmental Engineering, Massachusetts Institute of Technology. Cambridge, MA.

Tucker, G.E., Gasparini, N.M., Bras, R.L. and Lancaster, S.T. 1999. Future Development and Applications of the CHILD Model. Technical Report. Department of Civil and Environmental Engineering, Massachusetts Institute of Technology. Cambridge, MA.

Tucker, G.E. 1999. CHILD User Guide. Version 2.0. Technical Report. Department of Civil and Environmental Engineering, Massachusetts Institute of Technology. Cambridge, MA.

Tucker, G.E., Lancaster, S.T., Gasparini, N.M., Bras, R.L and Rybarczyk, S.M. 2001. An object-oriented framework for distributed hydrologic and geomorphologic modeling using triangulated irregular networks. Computers and Geosciences. 27(8): 959-973.

Young, C.B., Bradley, A.A., Krajewksi, W.F., Kruger, A. and Morrissey, M.L. 2000. Evaluating NEAD Multisensor Precipitation Estimates for Operational Hydrologic Forecasting. Journal of Hydrometeorology. 1: 214-254.

Wang, J. and Bras, R.L. 1999. Ground heat flux estimates from surface soil temperature. Journal of Hydrology. 216: 214-226.