1. Bob Kuligowski, NOAA/NESDIS/STAR
The GOES-R Rainfall Rate, Rainfall Potential, and Probability of Rainfall Algorithms
Bob Kuligowski, NOAA/NESDIS/STAR
Yaping Li, Zhihua Zhang, Richard Barnhill, I. M. Systems Group
5th International Precipitation Working Group (IPWG) Workshop
Hamburg, Germany, 12 October 2010

2. Outline Review of GOES-R Status and Capabilities
GOES-R Algorithm Working Group
Algorithm Descriptions and Examples
Rainfall Rate Algorithm
Rainfall Potential Algorithm
Probability of Rainfall Algorithm
Algorithm Validation
Status and Future Work
Summary

3. Review of GOES-R Status and Capabilities
Anticipated launch in late 2015
Advanced Baseline Imager (ABI)
Increase from 5 to 16 spectral bands
Improved spatial resolution (42 km IR; 10.5 km VIS)
Faster scanning (5-min full disk vs. 30 min)
GOES Lightning Mapper (GLM)
Detects total lightning, not just cloud-to-ground
Single-channel, near-IR optical detector
Spatial resolution of ~10 km
The launch of GOES-R, which will represent the next generation of NOAA’s geostationary weather satellites, is scheduled for late However, the launch will be followed by a long check-out period, so actual data will not be flowing from the satellite for at least another year after that.
The two instruments of interest for weather in general and precipitation in particular are the Advanced Baseline Imager and the GOES Lightning Mapper. The ABI will represent a significant improvement in the spectral, spatial, and temporal capabilities of the current-generation Imager, while the GLM will continuously monitor total lightning from geostationary orbit at roughly 10-km resolution.

4. GOES-R Algorithm Working Group (AWG)
Algorithm Teams (AT’s) working together to develop a prototype GOES-R ground processing system
Hydrology AT Products:
Rainfall Rate / QPE (current)
Probability of Rainfall (next 0-3 h)
Rainfall Potential (next 0-3 h)
Hydrology AT Members:
Bob Kuligowski (STAR/SMCD), Chair
Ralph Ferraro (STAR/CORP)
Kuo-Lin Hsu (UC-Irvine)
George Huffman (NASA-GSFC/SSAI)
Sheldon Kusselson (OSDPD/SSD/SAB)
Matthew Sapiano (UMCP/ESSIC)
The GOES-R Algorithm Working Group has been charged with developing a prototype ground processing system for GOES-R, and there are roughly 18 Algorithm Teams focused on different aspects of the Ground System development.
The Hydrology Algorithm Team is responsible for three products…
The Hydrology AT has members from government and academia, most of whom are in the audience.

5. Rainfall Rate Algorithm Description
IR algorithm calibrated in real time using MW rain rates
IR continuously available, but weaker relationship to rain rate
MW more strongly related to rain rate, but available ~every 3 h
Calibration by type and region
Three cloud types:
“Water cloud”: T7.34<T11.2 and T8.5-T11.2<-0.3
"Ice cloud": T7.34<T11.2 and T8.5-T11.2≥-0.3
"Cold-top convective cloud": T7.34≥T11.2
Four geographic regions: 60-30ºS, 30ºS-EQ, EQ-30ºN, 30-60ºN
Two retrieval steps:
Rain / no rain separation via discriminant analysis
Rain rate via multiple linear regression
Moving on to the algorithm descriptions, the Rainfall Rate algorithm will provide instantaneous rainfall rates at the IR pixel scale every 15 minutes.
The algorithm uses IR data as inputs but is calibrated against microwave rain rates in real time. This is an effort to capture the best of both instruments—the spatial and temporal resolution of the GOES IR and the accuracy of the polar-orbiting microwave.
To maximize the fit between the IR predictors and the MW rain rates, the data are subdivided into 12 classes by cloud type and latitude. The cloud types are in quotes because they are actually based on transitions in the relationship between the IR window brightness temperature and rainfall rate.
The retrieval of the rainfall rate is done in two steps that are calibrated separately: discriminant analysis is used to identify the best predictors and threshold values for identifying raining pixels, and multiple linear regression is used to identify the best predictors and regression coefficients for retrieving rainfall rates for the raining pixels.

6. Rainfall Rate Algorithm Description
8 predictors derived from 5 ABI bands
8 additional nonlinear predictors
Regressed against the MW rain rates in log-log space
T6.19
T8.5 - T7.34
S = (Tmin, K)
T T7.34
Tavg, Tmin, S
T8.5 - T11.2
T T6.19
T T12.3
The specific IR predictors are here, narrowed down from a the list of all possible combinations of those 5 bands by removing predictors that are selected by the algorithm less than 10% of the time. It might seem odd that T11.2 isn’t here, but that is superseded by the S variable that uses the local minimum value of T11.2.
Since the relationship between IR temperature and rainfall rate is known to be highly nonlinear, the algorithm also creates additional nonlinear predictors by regressing all of the original predictors against the MW rain rates in log-log space.

7. Rainfall Rate Algorithm Description
Initial SCaMPR rain rates strongly underestimate heavy rain
Adjust distribution
For each class and region, match the CDF of the SCaMPR rain rates against the CDF of the target MW rain rates
Create an interpolated LUT to modify the SCaMPR rain rate distribution
The initial rain rates showed a very strong systematic dry bias, so one more step was added to adjust the distribution of the rain rates. The retrieved and training MW rain rates are arranged in order from highest to lowest and used to create a lookup table that is used to make the distribution of the rain rates match that of the MW.

8. Rainfall Rate Algorithm Description
Apply most recent calibration in between new MW overpasses
Update calibration when new MW rain rates available
This flowchart is too detailed to go over here; the main point is that the algorithm runs in two different modes. If new microwave data are available, the algorithm updates its calibration as shown on the right. Otherwise, the previous calibration is used to retrieve rain rates from the current ABI imagery.
Retrieve rain rates from ABI data

9. Rainfall Rate Examples
Radar
These are a couple of examples that were retrieved from SEVIRI data, which was used as a proxy for the ABI in our development work.
Rainfall Rate

10. Rainfall Potential Algorithm Description
Identify features (clusters) in Rainfall Rate imagery
Filter rain rate image to reduce noise
Use cost minimization to organize pixels into clusters
Combine smaller clusters into larger ones
Determine motion vectors between features in consecutive images
For each cluster in current image, determine spatial offset that maximizes match with corresponding cluster in previous image
Objectively analyze the resulting spatial offsets for all clusters to create a spatially distributed motion field
Apply motion vectors to create rainfall nowcasts
In 15-minute increments…
Project each pixel forward in time based on motion vectors
Project motion vectors forward in time
Sum 15-min rain rate fields to get a 3-hour total
Next is the Rainfall Potential algorithm, which produces forecasts of rainfall accumulation for the next 3 hours from satellite data.
The algorithm uses the K-Means algorithm that was developed at the NOAA National Severe Storms Laboratory, and it is named after the clustering technique that it uses. The basic steps in the algorithm are as follows:
After first smoothing the image to reduce noise, the current Rainfall Rate image is organized into clusters of rainfall areas, and smaller clusters are combined into larger ones.
Once this is done, each of the clusters in the current image is overlaid on the previous image and shifted until the minimum error is achieved. This shift is then the basis of the motion vector for that particular cluster. The field of motion vectors for each cluster is then objectively analyzed to produce a spatially distributed motion vector field, and a Kalman filter is used to ensure consistency with previous motion fields.
These motion vector fields are then used to advect the current Rainfall Rate image forward in time by 15 minute, and then to advect the motion vector field itself forward in time by 15 minutes. This continues at 15-minute intervals out to 3 hours, and then the instantaneous rates are all aggregated to get the 3-hour total Rainfall Potential field.

11. Rainfall Potential Examples
Radar
This is just a couple of examples of the Rainfall Potential field which were derived from Rainfall Rate fields I showed earlier.
Rainfall Potential

12. Probability of Rainfall Algorithm Description
Inputs
Rainfall Potential algorithm output (3-h total)
Intermediate (every 15 min) rainfall nowcasts from the Rainfall Potential algorithm.
Calibrated using conditional probability tables
Rainfall Potential ≥1 mm: total number of raining 15-min periods
Rainfall Potential <1 mm: distance to nearest raining pixel
Calibrated against the Rainfall Rate product
Eliminate uncertainties associated with Rainfall Rate errors;
Allow much more spatially widespread calibration (ground truth is generally available over Western Europe only)
The final algorithm is the probability of at least 1 mm of rainfall at each pixel during the next 3 hours. This algorithm uses the Rainfall Potential algorithm as its source of input—specifically, both the 3-hour total rainfall forecast and the intermediate rain rate forecasts that are created every 15 minutes.
The calibration is done by computing conditional probabilities based on the predictors; i.e., for a given predictor value, what is the conditional probability of rainfall? The resulting conditional probabilities are then simply applied to independent data. The current version of the algorithm is quite simple, in that it considers the total number of 15-min periods (out of 12) where rain was predicted as the probability condition; for pixels with no rain predicted, the distance to the nearest pixel with rain predicted is the condition for the probability of rainfall. I won’t go into much more detail on this because we’re in the process of recalibrating the algorithm with a larger set of predictors.
It should be noted that this algorithm has been calibrated using the Rainfall Rate product rather than a “ground truth” dataset for observation data. There are two reasons for this: one is that the errors in the Rainfall Rate products might cause the conditional probabilities to tend too low, but the more important one is that there is too little ground validation data at 3-h time resolution or less that is available over the SEVIRI coverage area to ensure a robust calibration. The SEVIRI radar data are the only widely available ground truth data set at those time scales and it covers only Western Europe.

13. Probability of Rainfall Examples
Radar
These are just examples of the Probability of Rainfall product which were derived from the Rainfall Potential fields I showed earlier.
Probability of Rainfall

14. Validation: Truth Data
Time scales ≤3 h, so must validate against radar
Validation datasets in SEVIRI region:
Tropical Rainfall Measuring Mission (TRMM) Precipitation Radar for Rainfall Rate
Nimrod radar data from the British Atmospheric Data Centre (BADC) for all 3 algorithms
Validation is a significant challenge for these algorithms because we need instantaneous rain rates to validate the Rainfall Rate product and rainfall accumulations of 3 hours to validate the Rainfall Potential and Probability of Rainfall products. Hourly gauges are very difficult to come by, so we have had to rely primarily on radar for validation.
The two datasets we have used so far are TRMM precipitation radar—which we can use only for Rainfall Rate—and Nimrod radar data over Western Europe that we have been able to use for all 3 algorithms. We have tried a few other sources of data without much success; if you have any suggestions for ground validation data I would definitely like to talk to you! 14 14

15. Rainfall Rate “Fuzzy” Validation
Pixel-by-pixel comparisons difficult
Instantaneous rain rate varies too much at small scales
Neighborhood comparison
Compare to most similar nearby value (Ebert 2008)
Better indication of usefulness
Not needed for 3-h Rainfall Potential / Probability
Before I go on to the validation results I would like to point out that we did not do a pixel-by pixel validation for the Rainfall Rate algorithm. At the 5-km resolution of the validation data, most statistics are severely punished for relatively spall spatial displacements of rainfall and can yield very poor results even when a comparison of the two images looks quite good, such as the example here. In response, we did a neighborhood comparison that compared each Rainfall Rate pixel to the ground validation pixel within 10 km that had the most similar value—a technique that has been suggested by Beth Ebert and other authors for fine-scale rainfall validation.
We didn’t do this for the other two algorithms because 3-hour accumulations are much less spatially variable than instantaneous rates. 15 15 15 15

16. Rainfall Rate Validation
This scatterplot comparing the Rainfall Rate product with TRMM using the fuzzy validation shows a pretty good comparison between the two, though the SCaMPR algorithm is actually biased on the high side now.
Comparison with collocated TRMM PR for 6-9 January, April, July, and October 2005 and all of January 2008. 16 16

17. Rainfall Rate Validation
This slide helps to explain the validation statistics that I’m going to show in a little bit. The performance requirements for these algorithms are accuracy and precision. Accuracy is just the bias—the difference between the means of the retrievals and ground observations.
Precision is a little more complicated—it’s supposed to represent one standard deviation of error—that is, 68% of the errors would be lower than that value if the errors were normally distributed. Of course, rainfall rates and their errors aren’t normally distributed, but that’s the definition I was given to work with, so there you have it.
To make things even more complicated, general rainfall rate validation statistics aren’t very useful because they are dominated by the relatively small errors associated with light rain—the heavier rain rates that are of greater hydrologic interest aren’t very well represented. So I was asked to compute the accuracy and precision of for rainfall rates of 10 mm/h.
The results of all this are shown in the plots above. The plot on the left is the cumulative distribution function of the absolute errors in Rainfall Rate (using the fuzzy verification) when using the TRMM PR . From this plot we can see that the 68th percentile of error is at roughly 8.9 mm/h. On the right is the same plot when using Nimrod over Western Europe as the ground validation data, and there we see that the 68th percentile of error is much higher—around 9.7 mm/h. The main reason for this difference is probably that IR algorithms perform best for convective rainfall and perform poorly for stratiform rainfall, and the TRMM coverage area is mainly convective rainfall whereas stratiform rainfall is more common over Western Europe.
CDF of (absolute) errors of Rainfall Rate pixels with rates of mm/h vs. TRMM PR for 51 days: 6-9 January, April, July, and October 2005.
CDF of (absolute) errors of Rainfall Rate pixels with rates of mm/h vs. NIMROD radar data for 34 days: 6-9 April, July, and October 2005. 17 17

18. Rainfall Potential Validation
On to Rainfall Potential; this is a scatterplot comparing the data with the collocated Nimrod radar over Western Europe. We did not use fuzzy verification for this plot.
Comparison with collocated Nimrod radar for 6-9 April, July, and October 2005. 18 18

19. Probability of Rainfall Validation
Finally, here is a reliability diagram for the Probability of Rainfall product when comparing to the occurrence of rainfall in the Nimrod radar data. Note that the algorithm overforecasts for low PoP’s and overforecasts for high PoP’s, which is not good; however, the recalibration of the algorithm should yield better results.
Reliability diagram of Probability of Rainfall vs. Nimrod radar data for 5-9 April, July, and October 2005. 19 19

20. Validation Summary vs. Spec
Validation versus TRMM PR for 51 days of data: 6-9 January, April, July, and October 2005 and all of January 2008:
Rainfall Rate (mm/h)
Requirement
vs. TRMM radar
Accuracy
Precision
6.0
9.0
4.9
8.9
Rainfall Rate (mm/h)
Requirement
vs. NIMROD
Accuracy
Precision
6.0
9.0
8.6
9.7
Validation against Nimrod for 6-9 April, July, and October 2005:
Finally, here are the accuracy and precision values for each algorithm compared to spec. As you can see, the Rainfall Rate algorithm meets spec for TRMM but not for Nimrod; the Rainfall Potential algorithm meets spec; and the Probability of Rainfall meets spec for accuracy but not for precision.
The Rainfall Rate requirement has been modified to apply only to convective rainfall because of the difficulty in depicting stratiform rainfall accurately, so the Nimrod statistics do not count against spec.
As mentioned before, the Probability of Rainfall algorithm is currently being recalibrated and should meet spec by the final delivery.
Rainfall Potential (mm/3h)
Requirement
Evaluation
Accuracy
Precision
5.0
2.4
3.1
Probability of Rainfall (%)
Requirement
Evaluation
Accuracy
Precision 25 40 71 20 20

21. Status and Future Work Rainfall Rate: Rainfall Potential:
Delivered “final” algorithm to System Prime 30 Sep 2011
Validation against an additional 4 months of data ongoing
Developing real-time and “deep-dive” validation tools for further evaluation and potential improvement
“Maintenance” delivery 30 September 2012 that incorporates feedback from “deep-dive” validation
Rainfall Potential:
Optimizing parameters; “final” internal delivery May 2011
Final algorithm delivery to System Prime by 30 Sep 2011
Probability of Rainfall:
Continuing to recalibrate; “final” internal delivery May 2011
Finally, a few words on the current algorithm status and on what happens next.
The “final” Rainfall Rate algorithm has been delivered, but that word is in quotes because we will get to submit some minor modifications a year from now; in the meantime, we’ll be doing some detailed validation against a larger data set to identify potential areas for improving the algorithm for the maintenance delivery.
The Rainfall Potential algorithm parameters are being optimized even though we already meet spec; we’re looking to deliver the final version internally in May 2011 and to the System Prime contractor at the end of next September.
We are continuing to recalibrate the Probability of Rainfall algorithm with additional predictors, and it is on the same schedule as the Rainfall Potential algorithm.

22. Summary Three rainfall-related algorithms for GOES-R: Performance:
Rainfall Rate
Rainfall Potential (0-3 h)
Probability of Rainfall (0-3 h)
Performance:
Rainfall Rate and Rainfall Potential meet GOES-R spec
Probability of Rainfall partially meets spec and is being recalibrated
Future Work:
Rainfall Rate has been finalized and is in the validation stage
Rainfall Potential and Probability of Rainfall are still being modified; final delivery September 2011

23. Questions? Bob.Kuligowski@noaa.gov