10/11/2007 DISC: TX

[Sam Barricklow]

Two Storm Reports from yesterday are of note. Both were in the Lubbock region.

0035 275 4 SW HALFWAY HALE TX 3415 10200 (LUB)

2127 250 MAPLE BAILEY TX 3385 10290 (LUB)

Did anyone chase yesterday and observe these storms?

[David Drummond]

I wasn't able to get out, but I did catch this on radar that dropped the hail. It also blew out a patrol car's windows.

That first report near Halfway was actually on the evening of the 10th from this storm:

[Paul Knightley]

News on this hailstorm is given here (http://www.kcbd.com/Global/story.asp?S=7203213&nav=menu69_3), highlighting damage to crops.

[Martin North]

I was personally watching these storms on GRL3 last night. It was actually hinting at 4" hail over one rural area!

Storm SW of Odessa. I think it was exiting Crane Co at the time...in fact it was into Pecos Co.

Basically well away from any populous I think....

[David Drummond]

I was personally watching these storms on GRL3 last night. It was actually hinting at 4" hail over one rural area!

Storm SW of Odessa. I think it was exiting Crane Co at the time...

I have noticed throughout the year, that generally speaking, the actual hail ends up being about half of what the hail markers on GRL3 estimate. I am sure there is a reason for that, although I don't know enough about how it works to know what that reason is.

[Kiel Ortega]

I have noticed throughout that year, that generally speaking, the actual hail ends up being about half of what the hail markers on GRL3 estimate. I am sure there is a reason for that, although I don't know enough about how it works to know what that reason is.

If the Hail Detection Algorithm (HDA) that they use is exactly the HDA designed by Arthur Witt and others, it's biased to be high (since it's a warning tool...lead time...fairly logical). If you are getting the numbers from the cell identifications, those are biased really high (up around 14 mm!; though with storms with high reflectivities, IMO this bias goes up). The gridded identifications are a little less biased for single radar data, but still fairly high. Here's a paper (http://ams.confex.com/ams/pdfpapers/104885.pdf) I did evaluating the different hail algorithms.

[Martin North]

Yes, when it gets to 4" I generally assume there are Baseballs these days...

I have issues with the meso and TVS markers too at times.

Just switch off the markers and go for what you can see imo...

[David Drummond]

That was an interesting read Kiel. Thanks for expanding my knowledge on that.

[Martin North]

Yes, I had a good read at that too. Thanks...very interesting.

[Mike Gibson]

If the Hail Detection Algorithm (HDA) that they use is exactly the HDA designed by Arthur Witt and others, it's biased to be high (since it's a warning tool...lead time...fairly logical). If you are getting the numbers from the cell identifications, those are biased really high (up around 14 mm!; though with storms with high reflectivities, IMO this bias goes up). The gridded identifications are a little less biased for single radar data, but still fairly high. Here's a paper (http://ams.confex.com/ams/pdfpapers/104885.pdf) I did evaluating the different hail algorithms.
I'm confused by some of the results in the paper. It's not clear to me how the cell-based integration differs from the grid-based storm tilt integration (other than one is cell and the other is grid based). Isn't the grid-based storm tilt integration trying to integrate along a path that includes the higher reflectivities in a cell? If that's true then I don't understand the results in Table 1 for methods 8 and 10! Both methods are the same except for the tilted integration. Integrating along a higher reflectivity path should bias the results higher yet method 10 has a significantly lower bias than 8.

I would have expected method 10 to have a higher bias than method 8, similar to how the methods that use time-space correction have a higher bias. The time-space correction is similar to storm tilt integration in that it tries to "straighten up" the cell before integrating, which usually stacks the higher reflectivities vertically.

Can you explain tilted integration some more?

Thanks,
Mike

[Kiel Ortega]

I'm confused by some of the results in the paper. It's not clear to me how the cell-based integration differs from the grid-based storm tilt integration (other than one is cell and the other is grid based). Isn't the grid-based storm tilt integration trying to integrate along a path that includes the higher reflectivities in a cell? If that's true then I don't understand the results in Table 1 for methods 8 and 10! Both methods are the same except for the tilted integration. Integrating along a higher reflectivity path should bias the results higher yet method 10 has a significantly lower bias than 8.

I would have expected method 10 to have a higher bias than method 8, similar to how the methods that use time-space correction have a higher bias. The time-space correction is similar to storm tilt integration in that it tries to "straighten up" the cell before integrating, which usually stacks the higher reflectivities vertically.

Can you explain tilted integration some more?

Thanks,
Mike

The tilted integration was applied to each grid point and not done for at one spot. What we did (as long as I remember right, this was a couple years ago :D) was first take the SCIT detections to fit a line (though we did 2, a W-E and N-S due to being able to actually calculate it). That's where any involvement on the cell-based detections stopped. We took the slope of the line and then ran a Barnes OBAN on it...so basically, we had a nice Gaussian field of "storm tilt" splatted wherever we had storms. Then when we went in to calculate MESH from the reflectivity grids we just put in our slope, went up that line and used whatever reflectivity values we intersected. The difference compared to the cell-based is that the maximum value of reflectivity in a segment would be used in the SHI (which gives MESH and POSH) calculation for the cell-based method.

The reason I think for the almost against logic of the the biases of methods 8 and 10 are we think that too often when integrating along the tilt, we would exit the storm--leading to lower MESH. The tilted fields of MESH were funny looking. They weren't very smooth or have a nice continuity when "swathing" them out (imagine you had a nice, smooth streamline field with tumors). The tilt method was chosen because at the time, with the way we were processing the cases, dilating the fields was eating too much of our resources.

The big thing I should mention is this was accomplished using Storm Data. It's too coarse to really score these types of algorithms. Using some data from SHAVE (http://ams.confex.com/ams/pdfpapers/115436.pdf) (SHAVE data (http://ewp.nssl.noaa.gov/projects/shave07/data/archive.php)) I found (unpublished findings) that there are statistically different answers when looking at bias and RMSE when using verification data at resolutions like SHAVE's compared to using verification data at resolutions like Storm Data's.

[Nick Bender]

Very informative paper Mike; you mentioning bootstrapping brought back memories of college when we used a program called 'Weka' to build forecasting models.

Question - which method does GRLEVEL3 use? - I'm assuming it's single radar of some sort, whether it's cell-based or grid-extracted I do not know.

[Mike Gibson]

Thanks for the explanation. In the MEHS product in GR2Analyst, I integrate along a line tilted by the storm motion vector. I bilinearly sample each sweep-line intersection point. I've seen very good results and some bad ones. It seems (all anecdotal evidence) that the best results occur when the MEHS value for a cell pulses or changes rapidly from volume to volume. The bad results (large overestimates) occur when there's persistently high MEHS values for a cell -or- when the cells are moving slowly.

Totally agree with you on the importance of better quality ground reports (SHAVE). In fact, it's amazing to me that Stumpf, et al were able to come up with an algorithm that produces reasonable results (MEHS) based on the spotty and unreliable storm reports database.

One thing that bothers me with the MEHS algorithm. We're trying to find the maximum expected hail size. Why use an integral? Wouldn't it be more appropriate to find the maximum reflectivity aloft, manipulate the value based on temp/height/etc., then get a size from that? It seems like an integral would give you a probability of hail but not the potential size.

Mike

[Mike Gibson]

Very informative paper Mike;
Kiel Ortega wrote the paper, I just make pretty pictures out of their hard work :)

Question - which method does GRLEVEL3 use? - I'm assuming it's single radar of some sort, whether it's cell-based or grid-extracted I do not know.
GRLevel3 displays the Hail Index data from the nexrad. That's the cell-based, single radar MEHS (method 1 in the paper).

Mike

[David Drummond]

I for one appreciate YOUR hard work that went in to making the pretty pictures. I can remember even back in 2000 thinking how I would love some software out on the road that would do exactly what GRL3 does.