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.

***The following is pretty much outdated now. I now always digitize the basin boundary in Lat/Long using GetMapArea or even Google Earth can be used. Then use LatLongPixelsFromFile.exe to create the boundary file.***

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

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.

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:

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 averagedrainfall. 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:

Beginning July 3, 2011, the urbanized area was expanded to include the area west and south of the Beltway for a total basin area of 70.3 sqmi.  The subdivided areas are Area 2 (16.0 sqmi) above Flamingo Detention Basin, Area 3 (39.5 sqmi) below FDB to Maryland Pkwy, and Area 4 (14.8 sqmi) as Maryland Pkwy to Nellis Blvd. Subbasin 2 was Mod Puls routed through the Flamingo Detention Basin, and then channel Mod Puls routed to Maryland Parkwy and combined with Area 3... then channel Mod Puls routed to Nellis Blvd and combined with Area 4 for total runoff at Nellis Blvd.

GetRealtime_setup.txt:

NEXRAD-ESX; 30210; Runoff; Flamingo Wash Urban; 0; 1.5,0.25,0.20,5,70.3,0.4,0.04,0.5,1.5,0.2,3; P1

NEXRAD-ESX; 30209; Runoff; Flamingo abv FDB; 0; 0.25,0.30,0.25,45,16.0,0.4,0.04,0.5,1.5,0.2,3; P1

NEXRAD-ESX; 30212; Runoff; Flamingo abv M Pkwy; 0; 0.5,0.30,0.25,5,39.5,0.4,0.04,0.5,1.5,0.2,3; P1

NEXRAD-ESX; 30213; Runoff; Flamingo blw MPkwy; 0; 0.5,0.30,0.25,5,14.8,0.4,0.04,0.5,1.5,0.2,3; P1

ROUTE; 1214; Flow; Routed Flamingo Wash at Nellis, Blvd Nv

MyRoutingFile.txt:

Three subbasins on Flamingo Wash Las Vegas Valley

GET 4 30209 Upper West Flamingo #2 

ROUTE Modpul RatingFlamingoDetentionBasin.RAT  (2 or more here means cascading modpul routing)

ROUTE Modpul Flamingo.Rat  (0.01 to 1.99 here means adjust storage by value*storage)

GET 4 30212 Middle Flamingo #3 

COMBINE

ROUTE Modpul Flamingo.Rat     reuse same channel rating 

GET 4 30213 Lower Flamingo #4

COMBINE

END

MyDetentionModPul.txt:

Flamingo Detention Basin ModPul Rating (Elv, Flow cfs, Storage AcFt)

7   <<lines below to read tab seperated

0  0  0

5  300  25

10  700  100

15  900  300

20  1200  500

25  1350  1000

30  31500  1500

MyChannelModPul.txt:

Flamingo Channel ModPul 8 miles w=40' side 2:1 s=60'/mi n=.03

15  << lines below(stage, cfs, acft)

0  0  0

.2   14.5   7.84

.4   46.0   15.8

.6   90.7   24

.8   146.8  32.3

1   213.5   40.7

1.4   376   58.1

1.8   575   76.1

2   687   85.3

2.6   1074   114

3   1372   134

4   2255   186

5   3331   242

6   4601   303

6.4   5164   328

Now we are getting the essence of a recession going, not sure why the USGS gage is stuck in the mud at this party.

Ok,  Let's have just the facts of this matter:

The results below come from continuous rainfall runoff modeling in real-time so once the model parameters are set in the GetRealtime.exe setup the real-time results are on their own until/if parameters are changed (initial loss, costant loss, % impervious, recession ratio).  Only the initial loss is self adjusting.

Runoff Comparison Flamingo Wash:

No change to  runoff coefficients were made until 3-Jul-2011.

Note:  Radar hourly ratio adjustments are being added (green) beginning Aug 1, 2012.  The UN-subdivided basin uses the ratio of  3GageAvg/3RadarAvg.  The 3 subdivided basins began using the 3 seperate gage/radar ratios on Dec 13, 2012.  For tipping bucket comparisons, Svenson and Eastern use the McCarran gage ratio and the others use the other closer of the two ratios.  It only took me 3 years to figure out one must adjust the radar and it looks like it's really paying off!!!

Level 2 is the high resolution NEXRAD base reflectivity radar images that are downloaded using the NOAA Weather Toolkit for comparison with the real-time Level 3 N0R Ridge 1 product used here.  N0Q now has the same dBz resolution as Level 2 of 0.5 but spatial is like old N0R 0.6mi x 0.6 mi mid-mid range.

% Diff is the difference between the two totals of rainfall events.

MAE% is the mean absolute error as the average of the individual unsigned difference for each event.

Ongoing Averaged Rainfall Comparison:

Average distace to the ESX radar is 33 miles, average mid-beam base scan elevation is 5,000 ft.

I find it amazing that no matter how bad the 5-minute correlation is to tipping buckets or how far Nexrad missed the event total rainfall, in the end, Nexrad actually consistantly reports the actual seasonal accumulated rainfall for the basin.  Time after time.  How do they do that?

It appears that runoff computation just exaserpates the radar rainfall errors.  Perhaps I should take the average of tipping buckets rainfall and recalibrate the runoff coefficients to get back in the ball park. My initial calibration did not even look at the tipping bucket rainfall. Boy, was I optimistic.  But basins without rain gauges do not allow for the luxary of calibration from rain gauges. And I thought this would all be so easy.  As noted at the beginning the experts suggested "A search of the online literature of comparisons seem to suggest caution."  Boy was that an under statement.  The average of the tipping buckets for the calibration storm of July 20, 2009 was 0.16 inches versus the N0R of .31 inches.

An attempt was made to convert the tipping bucket records for July 20, 2009 to 5-minute steps and then averaged for the basin. This met with nothing resembling the runoff record for that day.  Correlation of the 5-minute record with a single tipping bucket was also futile.  At least the radar found rainfall in the basin that the tipping buckets missed so that's good.  

A simple correction of the radar N0R rainfall record by the average TipB/N0R ratio resulted in the following improvements. No changes to the original runoff coefficients were made. Hopefuly summer rainfall will redeem this winter's Nexrad radar rainfall record or Nexrad rainfall will simply be a waste of time out here... beyond the hundredth meridian.

Something I have failed to point out is the EARLY WARNING that Nexrad radar can provide in the absense of rain gages and should be noted here. Also radar lets you see it comming.  Although a 0.5 hour lag time is not much early warning it is better than waiting for the USGS to report the peak up to an hour later. The data below for the runoff comparison below seems to show the USGS clock has fixed itself (see initial calibration above):

Two Weahter Underground Rain Gage and NWS McCarran Airport Locations used for hourly gage/radar ratios used to adjust radar:

(Tip: never use an airport rain gage unless you know exactly what you are doing!... ok maybe I do now.)

Check out another of my Nexrad real-time runoff comparisons for Central Valley California at my web page RunoffComparisonsBigCrCA.aspx. and in Arizona RunoffAZ.aspx ...they get better at the end.

Also as a way to evaluate the NEXRAD rainfall 5-minute record and put the blame where it belongs, runoff for hypothedical 1 square mile basins are now computed for both the tipping bucket and Nexrad rainfall record at some of the point rainfall comparison sites here. This elimanates any actual basin characteristcs and shows the effect of only the difference in rainfall records on a hypothetical runoff sequence.

Part 2

Radar Rainfall Adjustment

(A continuation with just the adjusted radar)

GetRealtime's hourly gage/radar ratioing method was used to add the much needed hourly adjustments. Three Wunderground gages were used for ratios. For the full basin average runoff, the ratioing was Avg3Gages/Avg3Radars.  You could use the sums instead of averages but the sums do not compare graphically as nice and looses some connotation.  And should a Wundergage fail, the averages could still give a good ratio but the totals would not. For the 3 subdivided basins each subbasin average radar rainfall was based on the single nearest Wundergage ratio. The adjusted radar at the Clark County tipping buckets was computed both ways for comparison, 3G/3R and neaerest 1G/1R.  These hourly ratios are applied to 5-minute rainfall computed from N0Q radar reflectivity using the standard NWS Convective Z-R year around.

It may have taken me over 3 years but I think my adjusted Nexrad radar rainfall is now ready for the big time. I think my future example studies should try to look at ratioing methods... like how far away from a basin can a good Wundergage be?... so I will try to do that here.

Three Wunder Gage locations and 8 Clark County Tipping Buckets:

Event average rainfall at the gage points based on  both 3G/3R ratioing and nearest 1G/1R ratioing:

Cumulative basin 50.7 sqmi average versus 8 tipping bucket average based on 3G/3R ratioing:

Computed peak runoff versus USGS peak flow; is using single closest Wundergage ratio better?:

Hourly Gage/Radar ratios:

GetRealtime_setup.txt:

**get the 3 Wundergages rainfall

KNVLASVE71; 10229; Rainfall; Russel at Rainbow LV, NV

 KNVLASVE25; 10230; Rainfall; Nellis at Flamingo LV, NV

KLAS; 10234; Rainfall; McCarran Airpot, NV

**get the radar 5-minute rainfall at the 3 Wundergages

NEXRAD-ESX; -10229; Rainfall; Russel at Rainbow LV, NV; 0

NEXRAD-ESX; -10234; Rainfall; McCarran Airpot, NV; 0

NEXRAD-ESX; -10230; Rainfall; Nellis at Flamingo LV, NV; 0

**compute the hourly average for the 3 Wundergage locations

COMPUTE-hour; 10231; Rainfall; Avg of Rainbow,Nellis,Klas Gages; 0; 0; (P1+P2+P3)/N

COMPUTE-hour -10231; Rainfall; Avg of Rainbow,Nellis,Klas Radars; 0; 0; (P1+P2+P3)/N

**Compute the hourly ratio 3GageAvg/3RadarAvg

COMPUTE-hour; 31231; Ratio; Ratio of Avg of Rainbow, Nellis, KLAS LV, NV; 0; 0.0,0.25,3; P1/P2

 **get the average basin radar 5-minute rainfall

NEXRAD-ESX; -10210; Rainfall; Flamingo Wash Urban Nexrad N0Q; 0

**Compute the adjusted basin average radar 5-minute rainfall

COMPUTE-unit; 11210; Rainfall; Flamingo Wash Full Developed Basin Adj N0Q; 0; -1, 0.25, .01, 0.50; P1*P2

Note that the GetAccess table 'rsite' entry for each setup line above is not shown so see Help web page.  Also getting the radar rainfall requires radar point file.

Radar Adjustment Error versus Distance

The graphs below will attempt to show if distance from the adjusting Wunderage will have an affect on the adjusted radar error. I would assume the closer to the Wunder gage the better but I hope this will prove not to be the case. The idea for G/R hourly adjustment is that you are hoping every radar pixel in your area of interest has a perfect distribution so by knowing the error at just one pixel, you can perfectly correct them all. We shall see. The tipoff that this will probably not be the case is that the G/R adjustment must be done hourly, meaning conditions are constantly changing.  But remember, radar is better at area averages than at any particular point so although these point errors look horrendus, averaging the 3 points for error would look much better.

For each storm event, the % error as 100*Abs(R-G)/G of the adjusted radar storm total at each County Tipping Bucket is plotted against its distance to the Wundergage used to adjust it. The Gage/Radar hourly adjustment factor is the single G/R ratio at the Wundergage (not 3gage avg). The 3 trend lines are the linear regressions for error vs distance for each of the correcting Wundergages.

Ideally, a horizontal trend line near zero % error would be ideal and would demonstrate radar images have perfect knowlege of the rainfall distribution, it just does not know the actual error bias.

Here's a thought experiment: Do you think puting 4 rain gages in the 1 km adjustment radar pixel would improve the adjustment? Ha! You would likely just get 4 rain gages saying the same thing.  How about 4 closest radar pixels to 1 gage??? This I have looked at and does not seem to help but hurts (see below).  If you got better ideas, please let me know.

Adjusted radar hourly error by storm event:

4-Pixel versus 1-Pixel Adjustment

To find out what would work better for adjusting radar, multiple radar pixels nearest the Wundergage or the single pixel containing the Wundergage, the following 3 graphs show the comparisons at 3 county tipping buckets. Looks like hands down, 1 single pixel is by far better. The radar pixels are 1km x 1km. Does this imply that Level 2's 0.25km pixel would work even better? Or how about adjusting the 4km x 4km NWS precip products, should they have 16 gages inside the pixel to adjust them???  The G/R adjustments below were for the closest Wundergage to each tipping bucket, Russel WG vs Torrey, Nellis WG vs Nellis, and McCarran Airport WG vs Swenson.  Note that Airport Wunder Gages are a last resort to use for hourly values because they do not report rainfall at the top of the hour.  In this case, McCarran reports at hh:56 each hour and GetRealtime uses that as the end for summing to hourly values.

The Radar Adjustment Wizard Values:

The Las Vegas ESX radar is only 34 miles from the Flamingo Basin centroid but usually way overestimates rainfall (reflectivity) as seen by the hourly ratios graph above.  From the Ratio Wizard above you will see that the 'Default Ratio When Gage Missing' is 0.25.  What is up with that???  The 'Gage Minimum for Hourly Ratios' is set to zero.  This means any value greater than zero for the average of the 3 Wunrgages will have ratio computed.  If the value of 3 Wundergage average is zero, the defualut 0.25 ratio will be used.  (If 0.01 was entered then anytime the Wundergage average was zero, then the basin radar would be zeroed out and is not what we want here.  Normally I would not go below 0.02" so I must have had a good reason here.)  The 'Minimum Usuable Ratio' is 0.12 or half the default ratio. The 'Maximum Usable Ratio' is 3. The 'Incremental Rain Cap' is 0.50 inches in 5 minutes or 6 in/hr rainfall rate. I'm not sure if this cap should be much higher or just what it should be. 6 in/hr is above the hail cap at about 5 in/hr and the 100yr 5-min rainfall from NOAA Atlas-14 is 0.5" for LV Valley. Just something you may wish to consider raising back east and in tropical conditions or even lowering for large basins.

Some runoff comparisons using 3G/3R adjusted radar N0Q rainfall with Initial Loss method (not CN):

Radar image for July 19, 2013. This should have had the end of the world sirens blowing in Las Vegas if were not for the fact that the ESX radar is 400% out of wack.  The unadjusted peak flow would have been 22,000 cfs versus the radar adjusted and  measured 3,000 cfs at the USGS stream gage.

While waiting for the paint to dry in real-time desert rainfall, check out another of my ongoing radar adjustment studies in Charlotte, NC go here.  My Charlotte study takes a closer look at continuous runoff modeling affects for different adjustment stratigies.  All my other ongoing studies also use adjusted real-time radar rainfall and snowmelt.

Important Note:  Nothing on this page is intended as interpretation of any legal authority such as water rights and supply. This page is intended solely as a demonstration of techniques in flood potential monitoring. The reader assumes all risk for any damages whatsoever in connection with the access, use, quality, or performance of the supplied data just so you know.