Notable quote, "Boy, was I optimistic."

Well, my point rainfall comparisons with Wunderground gages at times were a little less than hoped for. A search of the online literature of comparisons seem to suggest caution as do my less than stellar results. One more color of DBZ precision between 50 and 55 dbz wouldn't hurt.  Perhaps a basin averaged Nexrad N0R every 5 minutes will demonstrate a point is just a point and computed runoff will redeem Nexrad. Let’s find out.

I should point out that no experience with rainfall-runoff modeling is expected of new users of my methods. Hopefully anyone with  interest in this stuff can follow my steps in setting up and maintaining a Nexrad radar rainfall and runoff record in real-time.  The only things I can think of where experience is a big advantage is in calibration of runoff coefficients and routings. Everything else is pretty much a cook book. Remember there is a comment/question link at the bottom of each of my web pages if you have a question and suggestions are always welcome.

On the other hand... As an aside illistrative of modeling and modelers I can tell you a story about theory and untheory. I worked for a couple years with a guy at BOR who had worked for COE for many years who was a real fire brand. He would say monkies could do PMF studies (probable max flood) about once a week... usually on Mondays... to everyone's dismay. I always thought he was just a little off until I started this realtime runoff stuff myself. Boy was he right... Compared to these real world problems in real time, PMF's CAN be done by monkies. ;) Hey Tom!

And remember what someone said about models, "they are never right." But that does not mean they are not useful. If your model tells you anything, it will tell you what can go wrong always does. Watch and learn that right here.

A basin was selected within the Las Vegas, NV urban area for the USGS stream gage 094196781 Flamingo Wash at Nellis Blvd. The basin is mostly developed housing and yards with about 30% commercial and apartments I am guessing. Little undeveloped area remains within the basin boundary as I have selected it. The total basin area is 215 square miles but 3 quarters of it are undeveloped desert located on the back side of an intervening mountain. Contribution from the desert area only occurs with high intensity rainfall and is regulated by intervening runoff detention basins. I’ll deal with crossing that bridge when I have to. For now, only the 50.7 square mile urban area will be used.

Here are the steps required to set up GetRealtime.exe to automate retrieval of the Nexrad N0R radar average basin rainfall as described on the help page here but in the particulars of example as follows:

1)   Radar ID= ESX.

2)   Fire up GetMapArea's 'Google Map Lat/Long' menu item to determine latitidude and longitude for points in Las Vegas Valley. Now find 2 intersections of the highways located within Vegas Valley that are located roughly on a screen diagonal to enable determing both the X and Y scaling. 2 locations at about the same screen height would poorly determine the Y scaling so choose 2 points on a diagonal. As an example my two highway intersections have the long/lat locations -114.9820, 36.0395 and -115.2326, 36.2396.

3)   Fire up LatLongPixels.exe to convert the long/lat locations to radar image pixel locations:

Using GetMapArea.exe load a better map.  As an example I used the menu ‘Load/Save Map’ then ‘Big Google Maps’ and zoomed into Vegas Valley in the Terrain mode until both my scaling reference highway intersections were still visible.  Press Alt*PrtScr to capture the Google Map to the Windows clipboard and close the Big Google Maps window.  Select ‘Paste from Clipboard’ from the menu and the map image will be loaded.  Now set the scale by selecting ‘Set Scale’, click on the 2 highway intersections, and select ‘General Pixels’ on the menu and enter the 2 pixel locations. 

You can now start left click digitizing the basin boundary as pixels.  When finished right click and select 'End Area/Line' and then right click the data box and save it to file like this (add label is somewhere in here too):

Urbanized Flamingo Wash at Nellis Blvd X,Y Coordinates   (pix)

 280, 225

 279, 224

 277, 224

 276, 224

 274, 223

 269, 223

 267, 226

 267, 227

 260, 227

 260, 225

 249, 224

 249, 226

 250, 227

 252, 227

 253, 228

 254, 229

 254, 230

 254, 233

 255, 233

 268, 233

 269, 230

 274, 230

 276, 228

 277, 225

 280, 225

Xmin 249, Ymin 223, Xmax 280, Ymax 233

Area1= 167 (pix^2), Perimeter= 78.2 (pix), Centroid= 264, 229

5)      With the basin Boundary pixel coordinate file we can now generate the Point file that GetRealtime.exe will use to determine which radar image pixels to average as being within the basin.  Fire up GetNexrad.exe, enter the file names and select ‘Create Basin Point File from Boundary File’:

Example of the generated Point file: (note there is no title line)

249,223,280,233

 0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,0,1,1,1,1,1,1,1,0,0,0,0,0 1,1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0,0,1,1,1,1,1,1,1,1,1,1,1,1,0 1,1,1,1,1,1,1,1,1,1,1,1,0,0,0,0,0,0,0,1,1,1,1,1,1,1,1,1,1,1,1,1 1,1,1,1,1,1,1,1,1,1,1,1,0,0,0,0,0,0,1,1,1,1,1,1,1,1,1,1,1,0,0,0 0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,0,0,0 0,0,0,0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,0,0,0 0,0,0,0,0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,0,0,0,0 0,0,0,0,0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,0,0,0,0,0 0,0,0,0,0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0 0,0,0,0,0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0 0,0,0,0,0,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,0,0,0,0,0,0,0,0,0,0,0,0

Factoid: A pixel on the ESX radar N0R image is 0.00886 x 0.00886 degrees of long and lat or about 0.5 miles wide x 0.6 miles high. The current WSR-88D scan resolution is 1 degree in azimuth (0.5 mile mid range) by 1 km (0.6 miles) in range.  Update:  The guys at Nexrad are now in the process of making a higher resolution radar image available (0.00532x0.00532 degrees, 0.37x0.37 mile, 1000x1000 pixel PNG image file) and hopefully by March, 2011 the Ridge II radar images will be operational, although in the newer graphic format of PNG instead of GIF.  Beta test versions of GetRealtime.exe and GetNexrad.exe will soon be made available as the NOAA Ridge II radar image test bed hopefully becomes more responsive to image requests.

With the Point file created we are all set to automate GetRealtime.exe radar downloads.

6)      Copy the Boundary and Point files to the GetRealtime.exe directory.  Fire up GetRealtime.exe and select ‘Select Station from List’ and edit in our radar station and ID like this:

7)      We now need to add the site to our HDB database.  Fire up GetAccess.exe and select the ‘DB Tables’ button and from the displayed list of tables select ‘rsite’, click the ‘Allow Edit’ box , then hit the ‘Go’ button to display and edit in the new site info like this:

The datatype_id for rainfall is 10, the parameter_code is N0R with a zero, and the station_id for retrieval is NEXRAD-ESX.  Note that I combine the site_id 210 with the datatype_id 10 to give the datatype_site_id 10210 entered here and used with the Boundary and Point file naming convention.

GetRealtime.exe is now setup to automate the retrieval of our Vegas Valley basin averaged rainfall.  The next step is to determine runoff coefficients for automated conversion of the rainfall to runoff.  Also, don't forget to redigitize the basin boundary in square mile scaling for runoff computation.  Actually, I have found it best to digitize the basin boundary using GetMapArea.exe first in square miles and save the boundary image, THEN reload the saved image and redigitize the basin boundary following its already shown boundary using the general pixel method.

Creating a Boundary Area and Point File with GetMapArea.exe video:

Digitize Map Area and Stream Length with GetMapArea.exe video:

The art of runoff coefficient estimation:  (if it fits, wear it) ;-)

1)      Wait for a runoff event to happen.  Could be awhile in the desert.  Bingo, we have our first recorded runoff event and we have downloaded the USGS gage flow data for Flamingo Wash using GetRealtime.exe  and stored it and also our Nexrad basin averaged rainfall and we’re set to go.

2)      Fire up GetAccess.exe and retrieve the Nexrad rainfall as ‘Unit’ values which were stored every 5 minutes.  We need to save these rainfall values to Excel or text file and then create a GetMapArea storm file by pasting the data into Notepad and saving to a stm file like this:

Flamingo Wash Urban Basin Nexrad N0R rainfall

57        0.083333

7/20/2009 21:05          0.00032

7/20/2009 21:10          0.00051

7/20/2009 21:15          0.00089

7/20/2009 21:20          0.00757

7/20/2009 21:25          0.0216

7/20/2009 21:30          0.03123

7/20/2009 21:35          0.01603

7/20/2009 21:40          0.01242

7/20/2009 21:45          0.01027

7/20/2009 21:50          0.00969

7/20/2009 21:55          0.01418

7/20/2009 22:00          0.01434

7/20/2009 22:05          0.01121…etc.

Download full storm file here.

 This was cut from Excel and so is Tab delimited.  See the GetMapArea help for other formats.  The 2^nd title line shows there will be 57 data lines to read and they have a time step of 0.083333 hours or 5 minutes.  The date/time is not actually used by GetMapArea so it is assumed the data is at a regular 5 minute interval.

Note:  GetMapArea.exe can now read rainfall directly from the GetAccess.exe HDB database so creation of the storm file is no longer needed. Simply select 'HDB Database' from the storm arrangement list.

3)      We now have our storm file.  We need a hydrograph to visualize and get its peak flow cfs and the event volume acre-feet.  This we do using GetAccess.exe.  Retrieve the USGS Flamingo Wash flow ‘Unit’ values.  Save as Excel and you have your graph at 15 minute intervals and peak flow cfs.  To determine event volume average the 15 minute values.  Take the average cfs value and multiply it by 1.9835 then multiply it by the number of hours in the event divided by 24.  For a 6 hour event that averaged 50 cfs, the volume would be 50*1.9835*6/24 or 25 acre-feet.  Knowing the peak flow and volume we now have something to shoot for.

4) Fire up GetMapArea.exe and select ‘Runoff Hydrograph’.  Select Triangle Unit Graph for the dimensionless graph as used by GetRealtime.exe.

The deceptively simple SCS triangle unit graph has the following dimensions:

Timetopeak = (lag + udur / 2) / udur ...as time steps

Timeofrecession = 1.67 * Timetopeak ...as time steps

Qpeak = 484 * area * excess / lag ...as cfs

Select 'Storm File' and play with the coefficients until you get the right peak flow and volume as displayed on the window caption and the hydrograph looks similar to the USGS recorded hydrograph in Excel.  Note that the Lag is usually easily determined from the peak rainfall to peak runoff on the USGS hydrograph… USUALLY, what could go wrong?!!  See first comparison.

Note: For SCS Curve Number equivelants try 0.2 constant loss and vary the intial loss.

5)      After playing around for an hour or so we now have our basin runoff coefficients required by GetRealtime.exe to automate computation of runoff.  Here is the Getrealtime.exe setup showing the coefficients above:

The shift1 cell contains our runoff coefficients separated by commas as Lag, Initial Loss, Constant Loss, Percent Impervious, and Basin Area.  Our HDB database needs the ‘rsite’ table setup for storing the computed runoff as shown above in the rainfall setup.  If you ever need to change coefficients and rerun the runoff computations it’s as simple as changing the coefficients and rerunning, either by number of past days or using the ‘Historical’ button on the GetRealtime.exe interface for just that time period.

Likewise, version 2.0.1 can also compute runoff using Station_ID= COMPUTE-Unit like this:

COMPUTE-Unit; 30210; Runoff; Flamingo Wash Urban Runoff N0r; 0; 0.5,0.15,0.1,5,50.7; P1

The database table RSITE would have the Parameter_Code= 10210 and Station_Id= COMPUTE.

We are now all set to automatically retrieve radar rainfall and USGS flows for comparison so let's getr' done.... except you might want to consider how often you want to run GetRealtime retrievals.  Unless you're an obsessive-compulsive radar freak like me, you can just wait for an event to occur and then retrieve the past 4 hours of radar and take it from there.  You can then set GetRealtime.exe to get the radar every 5 minutes and watch the fun using GetGraphs.exe.  Or if you'ld rather be doing something else then set GetRealtime to retrieve the Nexrad rainfall every 4 hours and check in every few days to see what's up.  Setting the retrieval interval to less than 15 minutes will only retrieve the current radar gif. With storm activity I find 15 minutes (or greater) seems to work well for me and assures not missing a radar gif and eases demand on any other sources such as Wunderground on your retrieval list.

If you have subdivided your basin into sub basins then you can use GetGraphs.exe to route and combine sub basin runoff for display using Modpul or Tatum's travel time in real-time as the runoff is being downloaded and HDB updated every 5-minutes.   Better yet, you can now use GetRealtime to do the complex routings and save them in the Access HDB database for viewing.  (see GetRealtime Help here)

For basins having significant indirect runoff and need better definition of the recession then you may optionally add 2 additional coefficients to describe the recession in addition to first Tp/Tr ratio as described on GetRealtime's help page.   Video example Estimating Triangular Unit Graph Coefficients with GetMapArea

Example of Estimating Basin Lag Time (if no USGS gage or has a broken clock):

One method of calculating basin lag time for ungaged basins as used by the USBR as adapted from COE as adapted from Snyder is:

 Lag Time = C*(L*Lca/S^0.5)^0.33.

Where:

C=26*K where K=Manning’s roughness for longest stream course.

L=length of longest stream course in miles.

Lca=length of stream course below basin centroid in miles.

S=slope of longest stream course in feet per mile.

Based on observed urban runoff events the USBR as found C to vary from 0.34 to 0.88.  So based on the lower limit for C of 0.34 we can estimate a likely lower limit to our Vegas Valley basin lag time of 0.88 hours:

So much for the 0.5 hour lag time I used to get things to fit.  I will stick with 0.5 hours for now until I have more information on each storms centering over the basin.  Something that could also be changed when using the Triangle Unit Graph method is using a different Recession to Rising ratio that can be entered on the left of GetMapArea as shown above.  I did not change from the standard SCS 1.67 ratio but this may help the hydrograph shape somewhat.  If you want GetRealtime.exe to use a different ratio, then just add it to the coefficients after the basin area in Shift1.  Here are some different ratios to try:

Hydrograph peaking factors and recession limb ratios (Wanielista, et al. 1997)

Runoff Comparison Flamingo Wash 7/20/2009:

Lag Time = 0.5 hours

Basin Area = 50.7 mi^2

Loss0 = 0.15 inches

Loss = 0.10 in/hr

%Impervious = 5

Well right off the bat the USGS cant figure out what time it is.  It also turns out this gage is very erratic in data availability so hopefully the USGS will fix their clock.  I just can’t catch a break in this radar comparison stuff. ;-)

None the less, the peak and volume comparisons are good.

 Flamingo Wash Urban Area Averaged Rainfall and Runoff

The next event will test the runoff assumptions for fitting different storms.

After further review...

The peak at the USGS gage Flamingo Wash at Nellis Blvd was recorded at 12:15 am and arrived at the USGS gage Flamingo at Confluence 0.96 miles downstream at 12:45 am for a velocity of 3 feet/second which seems ok for 400 cfs in a cobble and gravel channel. It appears the USGS clocks are probably ok. My apologies to the USGS. Now what??? 

My background comes from computing Probable Maximum Floods for basins like Hoover Dam so any assistance here is welcome.  On the other hand my methods here have improved early warning by 2 hours!!! ;-)  Easily worth the price of admission.  Who can compete with these results!

(Since no one has offered any comments, I will offer this... the answer to my time anomally lies in sub-dividing the basin into areas of excess rainfall and routing... but the runoff volume will remain about the same and the hydrograph routing will fix the time of arrival at the gage. So no fix is actually needed. As you were... All is well... I hope!)

Clark County maintains a network of precip gages through out the county of which these are located on the Flamingo Wash stream course and are listed here at the indicated mile to help define the storm distribution and verify radar reported rainfall: