This is a slightly edited transcript of a presentation given at the Intermountain Advanced WSR-88D Users Workshop at the WSR-88D Operational Support Facility in Norman, OK, 20 August 1996.

Introduction

The main product from the network of WSR-88Ds which is used at the West Gulf River Forecast Center (WGRFC) in Fort Worth is the Hourly Digital Precipitation Array (HDP). While other products are received and examined at the PUP, such as the three precipitation products, the product that gets the most extensive use is the HDP. To most WSR-88D operators, the HDP is a "forgotten" product, since it is not displayable at the PUP. But the Precipitation Processing System (PPS) at each RPG generates the HDP once an hour at the top of each hour. After generation, it is sent at the same time and in the same fashion as the RCM. It is sent as a digital, binary file through the PUES line to AFOS for dissemination to the RFC.

In this presentation I will be discussing the program used at NWS RFCs called Stage III which accepts and displays the HDPs from all the sites within our area of responsibility. I will briefly explain how the output of Stage III is used at the RFC, and I will discuss the various problems we have with the precipitation estimates from the WSR-88Ds. I will also show examples of these problems from radars in or near the intermountain region.

HDP Processing at the WGRFC

Presently, WGRFC is receiving the HDP product from 18 different WSR-88Ds. In the near future, we will be receiving four additional HDPs from Department of Defense (DOD) radar sites. Once these HDPs arrive across AFOS, they are sent by an AFOS product translator into our local area network. After being stored in the proper directories, they are decoded for future use in the RFC software program called Stage III.

When the Stage III program is run, several things happen before one views the final output. First, the raw HDP data are drawn out of the database and are considered Stage I output. There is no adjustment to the WSR-88D precipitation estimates at this stage. Even in the future, when there will be a rain gauge bias adjustment factor in the RPG, it will not affect the HDP product. The Gage Data Support System (GDSS) bias adjustment will only affect the precipitation products displayed on the PUP. This will enable forecasters using the precipitation products at the PUP to see rainfall estimates with a bias adjustment in real-time. The reason the Stage III program will not use the GDSS is that it performs its own rain gauge bias adjustment factor based not only on the rain gauge data available during the current hour, but on rain gauge data available for that hour which is transmitted up to four hours later.

Second, Stage II is run. This is where the rain gauge bias adjustment factor is calculated, based on all available one-hour rain gauge reports which are received and defined in Stage II. As mentioned, not all rain gauge reports are available immediately, so Stage II is actually rerun for the previous four hours, while also running for the current hour. This computed adjustment bias reflects long term rain gauge/radar differences, and is designed to compensate for nonrepresentative Z-R relationships. Each hour, the previous hour's bias is modified using current gauge data and radar estimates for each radar site. The one-hour WSR-88D precipitation estimates are then increased, decreased, or left unchanged based on this bias, and the output becomes the Stage II adjusted radar field. Next, a rain gage-only analysis is derived for each site. This is a plot of the hourly rain gauge data available, and each gauge is given a 15 km radius of influence. If two or more gauges are within 15 km of each other, a weighting factor is used. The rain gage-only analysis is then blended together with the Stage II adjusted radar field to arrive at a multisensor field.

Last, Stage III is displayed. This is where the multisensor fields from all the radars are overlayed onto one map. In the locations where multisensor fields from more than one radar overlap, the outputs for each HRAP grid point which are overlaped are averaged together. This process is called mosaicking. The benefit of mosaicking is that if one radar is overestimating or underestimating the precipitation, it may be compensated for if that area of precipitation is also detected by a nearby radar that has a better estimate. Some examples of this is when one radar is affected by the bright band effect or hail contamination, while another nearby radar may not because its beam is sampling the precipitation at a different altitude. The final mosaic is what is displayed initially on Stage III, and an example is shown in Figure 1.

One of the main responsibilities of the Hydrometeorological Analysis and Support (HAS) forecasters at the RFC is to quality control all sources of precipitation information. At times, the precipitation estimates from the radars are incorrect. We must attempt to adjust Stage III for the inaccurate radar estimates. This can be achieved by adding pseudo-(rain)-gauges to that area. Rainfall estimates which we believe to be representative of the precipitation area are assigned to these pseudogauges. This is a difficult task. These estimates can be made by looking at the past history of the rain area compared to previous hourly rain gauge reports, cooperative observer rainfall reports, or estimates of rainfall based upon satellite data from NESDIS. Similarly, we sometimes receive rain gauge reports which we are confident are inaccurate. More times than not these will be reports from a previous time period that were inserted into the wrong time frame. Unfortunately, these bad rain gauge values either get plotted as rainfall, or set an incorrect rain gauge bias factor for one or more radar sites. In either case, the HAS forecaster must set the bad gauges to missing or zero and rerun Stage II to obtain a proper Stage III mosaic. Once it is determined that the Stage III mosaic is the best estimate of hourly rainfall that is achievable, the program creates binary files containing these estimates and are saved for future use. Other options exist to the HAS forecaster in Stage III to obtain the best possible representation of hourly precipitation across the WGRFC area of responsibility. These will not be covered here.

Hydrologic effects of radar precipitation estimates

Once several hours of Stage III output have been saved, the files are used to create Mean Areal Precipitation (MAP) values for each of the 562 river sub-basins within WGRFC's area of responsibility. This is done by running a program called MAPX. Each grid point in our area is defined to a river sub-basin. All precipitation values for all grid points in a basin are averaged together to arrive at a MAP for each basin. These calculations are made for each hour that Stage III was saved. Finally, after the MAPs are calculated, the output is sent for use by the NWS River Forecast System which is run on Hewlett-Packard scientific workstations at WGRFC. These MAPs are used as the input into the Sacramento Soil Moisture Accounting model for the purpose of calculating runoff. It is these values of runoff, combined with water from other sources, which are used to make river flow forecasts.

The precipitation estimates from the WSR-88D can have a direct impact upon the amount of runoff generated by our river forecast model. It is in the best interest of the RFC to produce the best possible precipitation estimates. In the past, only rain gauges were used to calculate MAPs. If, for example, heavy rainfall from a particular thunderstorm should happen to miss the network of rain gauges, there could be an underestimation of the amount of runoff generated from that storm. With the advent of radar-derived precipitation estimates, the rain gauges are supplemented so that all heavy rainfall events, as well as lesser rains, may be accounted for.

Problems with radar precipitation estimates

Just as there are problems associated with rain gauge observations, radar precipitation estimates are not perfect, and sometimes they are not even close. Next I would like to discuss some of the problems with the radar-derived precipitation estimates that we deal with, and show a few examples on how they are adjusted by HAS forecasters using the Stage III software.

One of the more difficult things a HAS forecaster must decide is whether a particular WSR-88D is overestimating, underestimating or correctly estimating the precipitation. An understanding of meteorological conditions, and how they may affect radar estimates, is a must. The height of the freezing level or the possible presence of hail are good examples. For the sake of time, I will not show examples of hail or bright band contamination. Hopefully, you have seen examples of this either through the WSR-88D course or at your field sites. When we sense that unrealistic precipitation estimates are being displayed on Stage III, we rely very heavily on the available rain gauges to support our feelings. We also rely on other sources, such as satellite precipitation estimates from NESDIS, to help confirm the inaccurate radar estimates. Another problem we deal with is whether it really is precipitating at all where and when the radar says it is. I am going to show you two case studies as examples of this.

In Figure 2, which estimates on this Stage III display represent actual rainfall, and which are some sort of false estimate? This was the decision we faced at 1000 UTC 1 August 1996. At first glance you would be tempted to say it's all rainfall, but if we look at each individual radar site, many clues are apparent as to what may be real and what is not. Figure 3 shows the precipitation display for the Amarillo radar. The Stage I and Stage II radar estimates are almost identical in this case. But if you look at the gage-only field you see that the rainfall on Stage I and II is real, as several rain gauges received rainfall. However, one additional gage is reporting rain that is not confirmed by radar. When one compares the Stage II adjusted radar field with the gage-only field, it is apparent that the gauge in the center of the Texas panhandle is in error. It shows up on the multisensor field in addition to the radar precipitation estimates from Stage II. In this case, that rain gauge value was from a previous hour, so the Stage II adjusted radar was used for the mosaic on Stage III rather than the multisensor field.

Figure 4 shows the precipitation estimates from the Midland, Texas, radar. What may not have been so obvious looking at the big picture becomes quite obvious when you look at the individual site. This radar precipitation estimate has been generated from anomalous propagation (AP). There are several ways to confirm this. One is the blank gage-only field. None of the rain gauges under the Midland radar umbrella received rainfall for this hour. Another way is to call up a nearby radar which covers the same part of west Texas and southeast New Mexico. In this case we called up the radar in Lubbock, Texas, and there were no widespread radar precipitation estimates from that area. To our surprise, however, the Lubbock radar did show a few isolated showers which were masked by the AP on the Midland radar. A third clue is to look at the estimated rainfall amounts. Up to three inches of rain in one hour are estimated over West Texas, which is a rare occurance.

Figure 5 shows the rainfall estimates from the El Paso, Texas, radar. This one is tougher, because even though the gage-only field is blank, there are very few rain gauges under the El Paso radar umbrella. In addition, earlier in the morning the El Paso radar detected real radar estimates of rainfall from thunderstorms. Again in this case, however, this rainfall estimate is from AP. The way this was determined is that El Paso's AP pattern generates the same appearance when it is present, and Figure 5 shows this appearance. So experience led us to switch from the multisensor field to the gage-only field for the Stage III mosaic.

Figure 6 shows the precipitation estimates from Albuquerque, New Mexico, for the same hour. The only sure way to confirm that this was an erroneous rainfall estimate from AP was to look closely at the current satellite image. Satellite imagery is at times the only way we can tell if a radar is estimating rainfall in a location where it is really occurring. Using surface weather observations is helpful, but there may not be an observing site close to where the radar is estimating precipitation. The infrared satellite image for this case (Figure 7) confirms a clear sky over southern New Mexico, and the gage-only field was used for the Stage III mosaic from the Albuquerque radar. If you go back and look at Figure 1 again, this was the final Stage III mosaic which was used for this hour, showing the removal of all inaccurate radar precipitation estimates.

The next case may be more obvious, but it illustrates a false precipitation estimate for reasons other than just AP. Look at eastern Utah and western Colorado in Figure 8. On this Stage III display from 1300 UTC 6 August 1996, what is real and what is not? Taking a look at the individual radar sites again helps us determine if the rainfall estimates are realistic. Figure 9 shows the Grand Junction, Colorado, radar. In this case the first thing one should ask is "How realistic is a three to four inch rain in one hour, especially over eastern Utah?" The problem is compounded when you look at the gage-only field. There was at least one gauge which received some rainfall. In the multisensor field, the rain gauge report was combined with the Stage II adjusted radar to show a fairly solid area of convection. Additionally, rainfall estimates from an apparent sunrise spike (large radar reflectivities returned from electromagnetic energy from the sun) are shown. In this case, the precipitation estimates from the radar are all false and the rain gauge value came from a malfunctioning gauge.

Figure 10 is the infrared satellite image from this hour, and the sky was clear over eastern Utah and western Colorado. The rain gauge value in this case was set to zero, and Stage II was rerun. Then, for the Grand Junction radar, we switched from the multisensor field to the gage-only field for the Stage III mosaic. The final Stage III display (not shown) eliminated all the "precipitation" shown in Figure 8 in the area of concern.

The false precipitation estimates from this case may have occurred for several reasons. It could have been from improper clutter suppression regions, an improper bypass map, or an inaccurate default notch width map (Chrisman et al., 1995). Or, it could have been a result of superrefraction of the radar beam. The WSR-88D tries to correct for AP using the tilt test. The tilt test checks for continuity between the two lowest elevation scans. If the reflectivity field is reduced substantially from the 0.5° to the 1.5° scan, the returns are assumed to be AP and the 0.5° scan is discarded (Sampson, 1995). If the false returns remain strong at the 1.5° scan, the returns are assumed to be real and the PPS algorithm continues with its estimation. Also, the MXPCT, the Maximum Area Percent Reduction in the PPS, was recently changed from 50% to 75% (OSF Software Notes, 1996). By allowing up to 75% echo reduction from the 0.5° to the 1.5° scan, it decreased the number of times that the tilt test will discard the lowest tilt. This change reduced the problem of underestimation of precipitation from low-topped convection or stratiform events, however, it also allowed unsuppressed AP to contaminate the HDP products more frequently.

Conclusions

Overall, great progress has been made in precipitation estimates, largely due to the advent of the WSR-88D Precipitation Processing System and the Stage III program. These improved estimates will enable the river forecast centers to do a better job in carrying out its mission of river and flood forecasting. And even though we established that the radar precipitation estimates are not perfect, we look forward to the planned improvements which will be made to the PPS in future WSR-88D software builds.

References

Chrisman, J., D. Rinderknecht, and R. Hamilton.: WSR-88D Clutter Suppression and Its Impact on Meteorological Data Interpretation. WSR-88D OSF/OTB, Norman OK. January 1995.

Sampson, G.: Factors Affecting Radar Precipitation Estimates. WRH-SSD, Salt Lake City, UT. Technical Attachment 95-20. 29 August 1995.

"WSR-88D Software Note 6 - Summary of PPS Changes." Class Notes, OSF/OTB, Norman, OK. February 1996.