Template:GUM6

 

6 - Precipitation

GSSHA User's Manual

Rainfall is always a required input. Rainfall may be input as spatially and temporally uniform, at a specified rate for a specified duration, for a single event, or rainfall may be input as spatially and temporally varying for any number of rainfall events. The second method requires a separate rainfall data input file.

6.1 Spatially and Temporally Uniform Precipitation

Spatially and temporally uniform rainfall is specified with project file cards. Place the PRECIP_UNIF card in the project file, and specify the rainfall rate (mm/hr) and duration (minutes) with the RAIN_INTENSITY and RAIN_DURATION cards, respectively. Since GSSHA normally determines the starting date and time of a simulation from the rainfall input file, this information must be provided in the project file using the START_DATE and START_TIME cards. For example, the following five lines entered in a project file specify a rainfall rate of 27 mm/h, for a duration of 60 minutes, starting on 12 June 1996 at 13:30. Note that the date/time format in GSSHA input is always year, month, day, hour, and minute.

PRECIP_UNIF
RAIN_INTENSITY		27
RAIN_DURATION		60
START_DATE	1996	6	12
START_TIME	13	30

The use of spatially- and temporally-uniform rainfall is mutually exclusive with continuous simulations using the LONG_TERM project file card. Do not specify both PRECIP_UNIF and LONG_TERM in the same project file.

6.2 Spatially and Temporally Varied Precipitation

Assignment of spatially and temporally varied rainfall requires the creation of a rainfall input file. Like the project file, the rainfall input file is card based. The precipitation input file can contain multiple “events’. The following rainfall cards, Table 9, are recognized by GSSHA, and valid for use only in the precipitation input file (not in the project file):

Card	Argument	Description
EVENT	“character string”	Denotes the beginning of a new event in the precipitation input file. The optional character string can be used to annotate the file. Card-REQUIRED, argument-OPTIONAL. Optional string MUST be in double quotes.
NRGAG	integer	Denotes the number of gages that recorded data for this event. The card and argument are REQUIRED for each EVENT.
NRPDS	integer	Denotes the number of periods of rain rate observations for this EVENT. The card and argument are REQUIRED for each EVENT.
COORD1       COORDNRGAG	real real “char string” “char string”	Denotes the UTM coordinates of the gage, in the format easting northing. Two optional strings, which must be in double quotes are provided to annotate the file. One COORD card is REQUIRED for each gage. The number of COORD cards in an EVENT must equal NRGAG.
GAGES1       GAGESNRPDS	date time val1,1..val1,NRGAG       date time valNRPDS,1..valNRPDS,NRGAG	Rain accumulations (mm) recorded at the end of the sampling period. The number of GAGES cards in each EVENT must equal NRPDS. Each GAGES card must have the date and time of the recording, and be followed by NRGAG real values of rain accumulation during that period.
RADAR1       RADARNRPDS	date time val1,1..val1,NRGAG       date time valNRPDS,1..valNRPDS,NRGAG	Rain rates (mm/h) recorded at the end of the sampling period. The number of RADAR cards in each EVENT must equal NRPDS. Each RADAR card must have the date and time of the recording. There are two radar formats that can be put here: a set (NRGAG in size) of values similar to a set of gage points of rain rate or a sequence of file names of Arc/Info ASCII grids of rainfall rates (one per time step). If a set of values is used, the NRGAG should be the number of points. If the file version is used, then NRGAG should equal -1 and no coordinate locations should be defined.
RATES1       RATESNRPDS	date time val1,1..val1,NRGAG       date time valNRPDS,1..valNRPDS,NRGAG	Rain rates (mm/h) recorded at the beginning of the sampling period. The number of RATES cards in each EVENT must equal NRPDS. Each RATES card must have the date and time of the recording, and be followed by NRGAG real values of rain rate.
ACCUM1       ACCUMNRPDS	date time val1,1..val1,NRGAG       date time valNRPDS,1..valNRPDS,NRGAG	Cumulative amount of rainfall (mm) recorded at the end of the sampling period. The number of ACCUM cards in each EVENT must equal NRPDS. Each ACCUM card must have the date and time of the recording, and be followed by NRGAG real values of cumulative rainfall. The values must increase monotonically for each gage.

Table 9 – Types of rainfall inputs

The following information on developing rainfall input should also be noted:

• In a given EVENT, the rainfall data source type (GAGES, RADAR, RATES, ACCUM) may NOT change.
• The data source type may change from one EVENT to the next.
• The number and location of rain gages may change from one event to the next.
• If only one gage is present, rainfall interpolation is impossible. The location of the gage is irrelevant and the gage coordinates are ignored. Rainfall is applied uniformly in space. This provides a means to apply a temporal distribution of rain in a spatially uniform fashion. Such temporally varying, spatially uniform rainfall distributions are commonly used in flood frequency analysis, i.e. TP40.
• A separate line with its own time of recording is used to input each instance of rainfall, allowing varying temporal resolution rainfall data to be input. This feature is particularly useful when using radar-rainfall estimates, since the temporal resolution can vary considerably.
• Avoid using precipitation data with temporal resolution coarser than 1 hour.
• The finest temporal resolution of GSSHA rainfall input is 1 minute. Rainfall rates change on integer minutes. Seconds are not allowed in the time field.
• The COORD card must be followed by the easting and northing of the rain gage. Easting and northing must be in coordinates in the same frame of reference as the header of all ASCII GRASS input maps. If the gage and map coordinates are not in the same system, the gages will not be placed at the correct location in relation to the watershed.
• If used, the optional strings must be enclosed in double quotes “like this”
• Tabs or spaces are used to delimit the file. DO NOT USE COMMAS.
• To improve readability, line feeds are allowed in the data file.
• If radar rainfall files are used they should be in the same projection as the model, which should be a UTM projection.

The following is an example of a multiple-event precipitation input file using radar-rainfall estimates for the first event, rain gage data for the second event, and radar ascii text files for the third event. (unlikely but illustrative):

EVENT “Event of 30 June 1995- rainfall stops on July 1st”
NRPDS 5 
NRGAG 3
COORD 205150.0 4750212.0 "center of radar pixel #1" 
COORD 205045.0 4750104.0 "center of radar pixel #2" 
COORD 205320.0  4751173.0 "center of radar pixel #3" 
RADAR 1995 06  30  22  56  0.00  0.00  0.00 
RADAR 1995 06  30  23  18  10.75  2.25  5.80 
RADAR 1995 06  30  23  39  21.16  1.80  41.50 
RADAR 1995 06  30  23  57  12.13  20.90  20.70 
RADAR 1995 07  01  00  09  11.71  16.50  2.30 

EVENT "Event of 4 July 1995- new raingage network data" 
NRPDS  4 
NRGAG  4 
COORD 204555.0  4751268.0 "location of raingage #1" 
COORD 205642.0  4750491.0 "location of raingage #2" 
COORD 205921.0  4750330.0 "location of raingage #3" 
COORD 206170.0  4749611.0 "location of raingage #4" 
GAGES 1995 07  04  09  47  0.0  0.0  0.0  0.0 
GAGES 1995 07  04  10  01  38.0  2.0  0.0  0.0 
GAGES 1995 07  04  10  16  16.0  14.0  3.0  0.0 
GAGES 1995 07  04  10  35  19.0  20.0  16.0  8.0 

EVENT "Event of 6 July 1995- new radar data" 
NRPDS  8 
NRGAG  -1 
RADAR 1995 07  06  10  54  kzmx_07_06_10_54.asc
RADAR 1995 07  06  11  00  kzmx_07_06_11_00.asc
RADAR 1995 07  06  11  06  kzmx_07_06_11_06.asc
RADAR 1995 07  06  11  12  kzmx_07_06_11_12.asc
RADAR 1995 07  06  11  18  kzmx_07_06_11_18.asc
RADAR 1995 07  06  11  24  kzmx_07_06_11_24.asc
RADAR 1995 07  06  11  30  kzmx_07_06_11_30.asc
RADAR 1995 07  06  11  36  kzmx_07_06_11_36.asc

6.3 Interpolation Between Gages

The rainfall interpolation technique for spatially varied rainfall is specified with either the RAIN_INV_DIST or RAIN_THIESSEN project cards. No interpolation method can create information without creating uncertainty. All interpolation methods “estimate” the spatially varied field from point measurements, introducing uncertainty. The Thiessen polygon method is simply a nearest-neighbor approach, while the inverse distance squared method produces smooth fields based on the assumption that the influence of a measured value decreases with the distance from the point of measurement squared. The spatial variability of instantaneous rainfall is correlated at a scale of only several km at most. Use caution. It is not appropriate to use rain gage data at distances greater than the correlation length of the rainfall rate field. For example, the use of 15-minute rain gage data from a gage that is 30 km from the catchment is completely unrealistic, making calibration impossible. If you have no rain gages in the catchment separated by less distance than the correlation length of the rainfall field, you do not have enough data to calibrate GSSHA.

For example, Ogden and Julien (1993) calculated the correlation length of radar-estimated rainfall rates from multi-parameter observations of convective rainfall. Putting aside the discussion of the appropriateness of the correlation length as indicator of spatial structure due to the anisotropy and non-stationary of rainfall, the calculated correlation length was on the order of 2.5 km. This means that a rain gage network with inter-gage distances greater than this distance will not capture the true spatial variability of rainfall. There is also a chance that significant rainfall will be completely missed by such a network.

The U.S. National Weather Service network of WSR-88D next generation (NEXRAD) weather radars offer the potential of providing rainfall estimates in locations where there are no rain gages. There are numerous error sources that affect the conversion of radar observations into rainfall rate estimates. Discussions of radar errors are beyond the scope of this manual. NEXRAD precipitation estimates can be used in GSSHA, by formatting the data into a GSSHA precipitation file using the RADAR precipitation type card. When using NEXRAD rainfall estimates, GSSHA assigns a rain gauge at the center of each radar data pixel. When combined with Thiessen polygon rainfall interpolation, this reproduces the original radar pixels. The use of inverse-distance squared interpolation should not be used with radar data.

6.4 Interception

The interception of rainfall by the vegetation is modeled in GSSHA using the two parameter method published by Gray (1970). An initial quantity of rainfall (mm), entirely intercepted by foliage, is specified with the STORAGE_CAPACITY project card. The fraction of rainfall retained as intercepted water after satisfying the storage capacity is specified with the INTERCEPTION_COEFF card. These two cards are used to specify GRASS ASCII maps of the required parameters. Alternatively, both storage capacity and the interception coefficient may be assigned use the Mapping Table and an index map based on vegetation.

In GSSHA, the interception rate (i) is expressed as:

i(t)=r(t) while I < a

i(t)=b*r(t) while I > a

where:

• r (t) denotes rainfall intensity at time t,
• a is the storage capacity (mm),
• b is the interception coefficient (unitless, between 0.0 and 1.0),
• and I is the cumulative interception depth.

Storage capacity and interception values are usually inferred from vegetation or land cover. Values of storage capacity and interception coefficient values can be found in Gray (1970, section 4.6) or Bras (1990) p. 233.

To reflect the seasonal nature of interception in temperate regions, the storage capacity variable can be seasonally adjusted with the SEASONAL_RS card. This card is specified in the project file. If this card is specified, the storage capacity is varied based on the month. This option is only valid if LONG_TERM simulations are being conducted. If using this option, peak growing season values should be specified for the storage capacity. These values will be modified inversely with the canopy resistance values, as described in Section 9 Continuous Simulations. While this method has not been independently validated, it is based on the reasonable assumption that the storage capacity for interception is dependent on the available leaf area. Canopy resistance is the inverse of the leaf area index, thus storage capacity is inversely related to the canopy resistance. Factors were developed for two regions in the northern hemisphere, basically north and south, north is specified as latitudes above 37.0 degrees. The storage capacity is divided by the following factors for each month. The methods were employed in the calibration and validation of flow and sediment data in the Eau Galle Model (Downer, 2008) Eau Galle TN.

Month	South Factor	North Factor
1	4.0	4.0
2	4.0	4.0
3	4.0	4.0
4	2.5	4.0
5	1.0	3.0
6	1.0	2.0
7	1.0	1.0
8	1.0	1.0
9	1.0	1.0
10	2.5	2.5
11	4.0	4.0
12	4.0	4.0

Table - Seasonal storage capacity adjustment factors