Previous studies have demonstrated that rapid increases in total lightning activity (intracloud + cloud-to-ground) are often observed tens of minutes in advance of the occurrence of severe weather at the ground. These rapid increases in lightning activity have been termed “lightning jumps.” Herein, the authors document a positive correlation between lightning jumps and the manifestation of severe weather in thunderstorms occurring across the Tennessee Valley and Washington D.C. A total of 107 thunderstorms from the Tennessee Valley; Washington, D.C.; Dallas, Texas; and Houston, Texas, were examined in this study. Of the 107 thunderstorms, 69 thunderstorms fall into the category of nonsevere and 38 into the category of severe. From the dataset of 69 isolated nonsevere thunderstorms, an average, peak, 1-min flash rate of 10 flashes per minute was determined. A variety of severe thunderstorm types were examined for this study, including a mesoscale convective system, mesoscale convective vortex, tornadic outer rainbands of tropical remnants, supercells, and pulse severe thunderstorms. Of the 107 thunderstorms, 85 thunderstorms (47 nonsevere, 38 severe) were from the Tennessee Valley and Washington, D.C., and these 85 thunderstorms tested six lightning jump algorithm configurations (Gatlin, Gatlin 45, 2σ, 3σ, Threshold 10, and Threshold 8). Performance metrics for each algorithm were then calculated, yielding encouraging results from the limited sample of 85 thunderstorms. The 2σ lightning jump algorithm had a high probability of detection (POD; 87%), a modest false-alarm rate (FAR; 33%), and a solid Heidke skill score (0.75). These statistics exceed current NWS warning statistics with this dataset; however, this algorithm needs further testing because there is a large difference in sample sizes. A second and more simplistic lightning jump algorithm named the Threshold 8 lightning jump algorithm also shows promise, with a POD of 81% and a FAR of 41%. Average lead times to severe weather occurrence for these two algorithms were 23 min. The overall goal of this study is to advance the development of an operationally applicable jump algorithm that can be used with either total lightning observations made from the ground, or in the near future from space using the Geostationary Operational Environmental Satellite Series R (GOES-R) Geostationary Lightning Mapper.
Numerous studies have demonstrated the potential utility of total lightning data for use in decision support during severe weather situations (Goodman et al. 1988; MacGorman et al. 1989; Williams et al. 1989, 1999; Buechler et al. 2000; Goodman et al. 2005; Bridenstine et al. 2005; Wiens et al. 2005; Steiger et al. 2005, 2007; Gatlin 2006). These previous studies have found positive correlations between rapid increases in total lightning, also termed lightning jumps (Williams et al. 1999), and manifestations of severe weather at the surface. Not all severe weather is preceded by a lightning jump, nor do all storms that produce these rapid increases in lightning contain severe weather. Yet, despite occasional ambiguities, numerous concrete examples of increases in lightning several minutes prior to severe weather have been observed in thunderstorms across Alabama, Tennessee, Florida, Texas, Oklahoma, and Colorado. The observations are a manifestation of the physical links between cloud dynamics, microphysics, and thunderstorm electrification.
Thunderstorm electrification is currently thought to be dominated primarily by the noninductive charging process (NIC; Takahashi 1978; Saunders et al. 1991). More specifically, NIC involves charge transfer between ice crystals and graupel or hail particles in the presence of supercooled liquid water. The combination of a thunderstorm updraft and the earth’s gravitational force then provide the necessary cloud-scale separation of charge within the cloud, thus forming an electric field. As charge continually builds over time, the electric field reaches a breakdown magnitude, and lightning occurs. Collectively, numerous observational studies have presented evidence to support the dominance of NIC processes in thunderstorms.
Workman and Reynolds (1949) were some of the first to show that the amount of lightning produced by a thunderstorm is closely tied to updraft evolution and appearance of an ice phase. Vonnegut (1963), Williams (1985), and Boccippio (2002) demonstrated that a nonlinear relationship exists between storm depth and the amount of lightning a storm produces. Thus, thunderstorms having stronger updrafts (e.g., severe thunderstorms) have the potential to produce more lightning. Carey and Rutledge (1996, 2000), Petersen et al. (2005), and others provide strong evidence linking precipitation ice mass to lightning occurrence and amount, while Deierling (2006) linked the ice mass and updraft to lightning occurrence by demonstrating a correlation between the vertical flux of ice and the total flash rate. Given the strong correlation between the dynamics and microphysical evolution of the thunderstorms and lightning production, it seems reasonable to assume that lightning activity would provide some indication of storm severity.
Goodman et al. (1988) and Williams et al. (1989) correlated total lightning rates to the onset of wet microbursts in northern Alabama. MacGorman et al. (1989) also observed increases in total lightning in a tornadic thunderstorm near Binger, Oklahoma, in 1981. In the past decade, many studies continued to find similar findings. Williams et al. (1999) found increases in the total flash rate prior to severe weather in several thunderstorms in Florida. Goodman et al. (2005) demonstrated similar results for tornadic thunderstorms in south-central Tennessee, as well as for a damaging microburst case near Huntsville, Alabama, in August of 2002. Wiens et al. (2005) demonstrated that these increases in lightning also occur across the high plains, as observed during the Severe Thunderstorm Electrification and Precipitation Study (STEPS) field project in 2000 (Lang et al. 2004). Wiens et al. as well as Tessendorf et al. (2005, 2007) compared lightning rates to updrafts and graupel/hail volume using dual-Doppler analysis. Other noteworthy studies can be found from the Dallas total lightning network (e.g., Steiger et al. 2005; Wilson et al. 2006; Steiger et al. 2007). Gatlin (2006) and Gatlin and Goodman (2010) described numerous lightning jumps that occurred prior to the onset of severe thunderstorms in the Tennessee Valley, and these studies utilized the time rate of change of the total flash rate as a predictor for defining a jump in the total amount of lightning.
Gatlin (2006) provided the basic framework for an operational algorithm that could be used by a warning forecaster to assess a storm’s severity through the incorporation of total lightning data. In Gatlin’s framework, the time rate of change of the total flash rate, relative to a running background mean, provided the means to nowcast the occurrence of severe weather at the surface with a lead time as large as 25 min (Goodman et al. 2005). However, Gatlin’s analysis and framework were limited by 1) the lack of a broad spectrum of case study types, and 2) no assessment of total lightning behavior in ordinary nonsevere thunderstorms and of how nonsevere thunderstorms may affect the performance of an operational algorithm. The first limitation has significance because not all severe weather–producing storms are isolated. The second limitation is important because all thunderstorms will, by definition, exhibit at least one jump in lightning activity during their lifetime (i.e., prior to first lightning in the cumulus stage or latter impulsive changes associated with pulsing growth in the latter mature and dissipating stages; Byers and Braham 1949). These pulses in activity can conceivably lead to warning false alarms if lightning jump criteria are used for thunderstorms that are clearly below severe limits, thus creating a lack of confidence in the operational product.
The purpose of this study is to extend the Gatlin (2006) framework by investigating the link between total lightning and the occurrence of severe weather over a wide range of thunderstorm types. Based on the results, the aim is also to provide a new lightning jump methodology for improving lead times and forecaster confidence during the severe thunderstorm warning process, allowing for more timely and accurate warnings. Ultimately we plan to build on the method during continued development of an operational algorithm for use in the Geostationary Operational Environmental Satellite Series R (GOES-R) Lightning Mapper data stream (Goodman et al. 2006).
2. Data and methodology
Development of an operational algorithm for thunderstorm warnings using lightning data requires the following steps. First, severe and nonsevere thunderstorms must be identified and partitioned for different regions. Second, the lightning flash behavior for nonsevere thunderstorms must be quantified to understand trends that occur in “everyday” nonsevere thunderstorms. This step provides a “behavioral background” from which severe thunderstorms should stand out. Third, algorithms must be formulated and tested for the identified thunderstorm types. The algorithm providing the best “performance” can be further refined (if needed) to create an operational algorithm for real-time use.
a. Case selection
Thunderstorm cases were primarily chosen from two regions of the United States. One region is located in the Tennessee Valley, which comprises northern Alabama and south-central Tennessee. The second region is the Washington D.C. Metropolitan area. Both locations are covered by Doppler radar and very high frequency (VHF) total lightning mapping array (LMA) systems. The period of study was from 2002 to 2008 for severe thunderstorms, while nonsevere thunderstorms were limited only to the warm season during this period, defined as May–September. Nonsevere thunderstorms were defined as those thunderstorms having 1) a 35-dBZ reflectivity contour evident at 2 km for at least 30 min, 2) no report of severe weather, and 3) complete isolation from other convection. Tracking at the 2-km level will allow for the observance of the entire lifetime of the nonsevere thunderstorm. Severe thunderstorm cases were chosen based on present National Weather Service (NWS) criteria, which require the presence of 1) hail ≥1.9 cm, 2) wind ≥26 m s−1, and/or 3) the occurrence of a tornado. To study all severe thunderstorms and isolate the “core” feature, a 35-dBZ contour is tracked at the −15°C isotherm. This level is well within the temperature range needed for thunderstorm charging. The use of a 35-dBZ threshold provides a means to isolate the most vigorous updrafts and thunderstorm precipitation cores, especially in situations where severe convection is not isolated.
b. Severe weather reports
The locations, magnitudes, and timing of observed severe weather events were obtained from the National Oceanic and Atmospheric Administration (NOAA) National Climatic Data Center’s (NCDC) publication Storm Data. Unfortunately, there are several documented cases of errors in reporting times and magnitudes (e.g., Witt et al. 1998; Williams et al. 1999; Weiss et al. 2002; Trapp et al. 2006); however, this dataset is the most accurate in trying to determine what exactly occurred as a severe storm passed over a given location. Witt et al. (1998) observed that 38% of tornado report times were not within 5 min of the actual occurrence in 26 tornado days studied. According to Williams et al. (1999), only 10% of all storm data are likely to be accurate within 1 min of occurrence. Furthermore, another 15% fall within the 2–5-min range. An additional 50% of reports fall into the 6–10-min range. These inaccuracies in report time contribute to ambiguities in the determination of lead times between lightning jumps and severe weather. Williams et al. (1999) also noted that the more severe an event is, the more accurate the report time becomes. Weiss et al. (2002) and Trapp et al. (2006) show discontinuities in the number of wind reports and magnitudes between NWS offices. They also note that many of the wind reports over the past 10 yr are estimated and not measured winds, which then leads to discrete maxima in reports at wind speeds of 50, 55, 60, 65, and 70 kt. Despite these errors, the dataset provided by NCDC is still the most accessible and accurate in determining what exactly occurs during severe storm events. Additional care was taken to manually go through each report and assign viable reports to specific severe storms.
c. Total and cloud-to-ground lightning information
Total lightning flashes were observed using two very high frequency LMAs (Rison et al. 1999; Krehbiel et al. 2000; Wiens et al. 2005; Goodman et al. 2005) located in northern Alabama (Koshak et al. 2004) and in Washington, D.C. (Krehbiel 2008). To obtain the full three-dimensional view of a flash, as well as eliminate noise points within the LMA dataset, the VHF source points are combined using a clustering algorithm that combines data points in both space and time. For the North Alabama LMA, VHF sources that occur within 0.3 s and 0.5 radians of azimuth are clustered together as a first step in identifying a given “flash.” Sources must also be within a certain distance from one another, and this distance varies with range from the LMA center (McCaul et al. 2005). This clustering algorithm does not place an upper threshold on the temporal length of a flash; however, comparisons with other studies (e.g., Thomas et al. 2004) show good agreement in the number of flashes. The Washington, D.C., Lightning Mapping Array (DCLMA) uses a different clustering algorithm, which is found in the LMA display package named XLMA. However, XLMA combines VHF sources with similar space and time criteria (Thomas et al. 2004).
Herein we require each flash to be composed of a minimum of 10 VHF sources. Wiens et al. (2005) demonstrated that a minimum source threshold in LMA data will not affect the determination of the trend in total lightning, thus the 10-source minimum will not have an adverse effect in calculating the time rate of change in the flash rate. Thresholding at 10 VHF sources also eliminates noise points that the LMA might misclassify as sources and subsequently use for flash determination. Additionally, two range thresholds are set to see how distance from the LMA center affects lightning measurements and each of the lightning jump algorithms. The first range threshold is set at 150 km, and second range threshold is set at 100 km. These two range thresholds fall within the 160-km range threshold determined in Koshak et al. 2004, where spatial errors in source location approach a maximum of 50 m at that range.
Ground flashes are determined from the National Lightning Detection Network (NLDN), which comprises 113 sensors across the United States with a flash detection efficiency of 90%–93% (Cummins et al. 2006). The network occasionally misclassifies small positive in-cloud flashes as positive cloud-to-ground (CG) flashes; therefore, a +15-kA peak current threshold is applied to accurately estimate positive CG flash counts (Biagi et al. 2007). NLDN flashes are treated separately from the LMA flashes.
d. Radar data and thunderstorm tracking
Radar data are extensively used in this study for cell tracking, determining storm intensity, and comparing with lightning data. A thunderstorm’s areal extent plays a large role in determining the amounts of precipitation-sized ice and lightning produced. Larger thunderstorms tend to produce more lightning; therefore, radar data add to this study’s ability to compare thunderstorms of different sizes and discern why thunderstorms producing the same type of severe weather might have drastically different flash rates. The use of radar data helps in the investigation of the lightning history of each thunderstorm within this study.
Next Generation Weather Radar (NEXRAD) data were retrieved from NOAA’s NCDC in archived Level II format. These data were collected from five NWS Weather Surveillance Radar-1988 Doppler systems (WSR-88D; Crum and Alberty 1993) located at Hytop, Alabama (KHTX), Calera, Alabama (KBMX), Columbus Air Force Base, Mississippi (KGWX), Old Hickory, Tennessee (KOHX), and Sterling, Virginia (KLWX). The first four radars listed surround the North Alabama LMA, while the final radar listed is centered in the domain of the DCLMA. Radar data were transformed from their native Level II format using two different methods. Each method serves its own purpose for tracking as well as determining a storm’s intensity.
The first method of transformation is used for cell-tracking purposes. Level II reflectivity was transformed from polar coordinates (i.e., radar space) to a 2 km × 2 km × 1 km Cartesian grid using a 0.9° radius of influence in the “REORDER” software (Oye and Case 1995) developed by the National Center for Atmospheric Research. The grid size is 300 km × 300 km × 19 km with the origin centered over each individual radar. Reflectivity grids are then fed into the Thunderstorm Identification, Tracking and Nowcasting algorithm (TITAN; Dixon and Wiener 1993) and each storm that meets the desired temperature and height criteria is tracked.
The second method for transforming the radar data is similar to the first; however, there are some notable differences. The radar data were taken from their native Level II format to the network common data form (NETCDF) using the Warning Decision Support System-integrated information (WDSS-II) (Lakshmanan et al. 2006, 2007). Latitude, longitude, height grids of reflectivity, azimuthal shear, and vertically integrated liquid (VIL) were then created using grid spacing of 1 km × 1 km × 1 km on a grid size of 300 km × 425 km × 19 km for each data product. To have a common areal domain for all radars and the LMA, grids were centered on the National Space Science and Technology Center (NSSTC) for the northern Alabama cases and on the NWS forecast office in Sterling for the Washington, D.C., cases.
Storm-scale characteristics are then determined by combining the total lightning dataset with the radar datasets. Each thunderstorm identified by TITAN has a latitude center, longitude center, and major axis for each radar volume. This position information is then used to count total lightning flashes within the radius of influence using one-half of the major axis length. The radius of influence is also used to determine maximum values of reflectivity, azimuthal shear at 19 levels, as well as the maximum value of VIL for each thunderstorm. Time–height plots of reflectivity and azimuthal shear are then plotted along with the total lightning information and VIL values.
e. Jump algorithm approaches
Many methods can be used to predict storm severity based on total lightning trends in thunderstorms. In this study, six algorithm configurations are examined to determine which may be the best for a real-time operational lightning jump algorithm. Range dependence, warning length, and minimum flash thresholds are explored to maximize the utility of each algorithm.
1) Algorithm overview
There are three types of algorithms, each algorithm type having two variations. Each algorithm relies on the time rate of change of the total flash rate within a thunderstorm, also known as DFRDT. The first algorithm is based off the initial lightning jump algorithm presented in Gatlin (2006). This algorithm uses an averaged time rate of change and an averaged one-sigma standard deviation threshold to determine if a lightning jump has occurred. The two variations of the algorithm are only in the warning time length, where one version has a 30-min warning time to be consistent with Gatlin (2006), while the other has a 45-min warning time to be in line with typical NWS warning time lengths [T. Troutman, Warning Coordination Meteorologist (WCM), Weather Forecast Office (WFO) Huntsville, 2008, personal communication]. This algorithm does not use a flash rate threshold to try and eliminate jumps in total lightning associated with nonsevere convection. Gatlin and Goodman (2010) recently presented results from a newer two-sigma configuration for the Gatlin algorithm on the same 26 thunderstorms presented in Gatlin (2006).
The second algorithm explored is a two-step process termed the threshold algorithm. This algorithm uses a flash rate threshold of 10 flashes per minute and a second DFRDT threshold to determine abnormal total lightning behavior in a thunderstorm. The DFRDT used in this algorithm are not averaged over time like the Gatlin algorithms. The flash rate and DFRDT thresholds are based off of a sample of nonsevere thunderstorms, and both algorithms use a 45-min warning time. There are two variations of this algorithm, one called the Threshold 10 algorithm and the other the Threshold 8 algorithm, where the main difference is in the DFRDT value. The Threshold 10 algorithm uses a DFRDT value of 10 flashes per minute squared, whereas the Threshold 8 algorithm uses a DFRDT value of 8 flashes per minute squared.
The final set of algorithms is called the sigma algorithms. The first sigma algorithm is called the 2σ algorithm and the second is called the 3σ algorithm. Like the threshold algorithms both algorithms require a total flash rate of 10 flashes per minute before starting any jump calculations. The 2σ algorithm uses a jump threshold of twice the standard deviation of the previous 10 min of total lightning data, while the 3σ algorithm uses 3 times the standard deviation of the previous 10 min of data. The main differences between this and the Gatlin algorithms are 1) DFRDT values and jump thresholds are not averaged over a period of time, 2) they incorporate more of the previous flash behavior before determining whether or not a jump in total lightning activity is abnormal, and 3) they require a flash rate threshold to be met before the algorithm turns on and determines whether or not a jump has occurred. This flash rate threshold helps to eliminate typical nonsevere convection that will cause false alarms. An example of how the algorithms would function for each type of algorithm is presented in Fig. 1 for a severe storm case.
2) A summary of the Gatlin algorithm
FRt1(t) and FRt2(t) are the 1-min total lightning counts from a thunderstorm, and FRavg (flashes per minute) is the 1-min averaged flash rate that is calculated every 2 min. For example, if the 1-min flash rate at t1 equaled 50 flashes per minute and the 1-min flash rate at t2 equaled 60 flashes per minute, then the 1-min average flash rate over 2 min of data would be 55 flashes per minute. This quantity is calculated in 2-min intervals (e.g., 1202, 1204, and 1206 UTC). Next, a weighted moving average in flashes per minute is determined from the three most recent averaged periods (6 min) using
where FRavg(t1), FRavg(t2), and FRavg(t3) are computed as in (1). Once another time period is calculated, for example, , then the trend in the total flash rate at t4, DFRDT (flashes per minute squared), can be calculated using
A standard deviation in DFRDT is then calculated using the most recent three DFRDT values starting after the first 10 min of lightning data have been collected. The most recent standard deviation value is then averaged with the previous time step’s standard deviation value to obtain a new lightning jump threshold value. A trend is considered a jump once the DFRDT value exceeds the averaged one standard deviation value and ends when the DFRDT value falls below zero. This algorithm does not use a flash rate threshold to be activated, and thus is susceptible to small jumps associated with total lightning activity associated with ordinary convection.
3) Threshold algorithms
A simple technique explored in this study is termed the “threshold” method. The purpose of the threshold method is to differentiate between a storm that is severe and one that is nonsevere based on climatologically observed conditions. Some overlap between the two classifications of severity is expected; however, a simple method such as this one might provide useful information in real-time situations as the threshold algorithms are not computationally tasking.
This technique involves a two-step process for differentiating between severe and nonsevere thunderstorms. The first step for both threshold algorithms is based on the peak 1-min total flash rate (e.g., Williams et al. 1999), and the second step is based on the DFRDT value. The importance of the peak flash rate threshold is that it essentially turns the algorithm on, while the value of the second threshold DFRDT then determines if the lightning activity is associated with a severe or nonsevere thunderstorm. The peak 1-min flash rate threshold is based on a survey of 69 nonsevere thunderstorm cases observed in three different areas having total lightning networks. Forty-seven of these storms occurred in northern Alabama, while the remaining 22 occurred near Lightning Detection and Ranging (LDAR) networks around Houston and Dallas, Texas (Motley 2006). From these cases we diagnose the mean peak flash rate to be 10 flashes per minute (Fig. 2).
The second step, the DFRDT value, was also calculated using the difference in the 1-min average flash rate [Eq. (3)]. DFRDT thresholds were determined from the sample of nonsevere thunderstorms presented in Fig. 3. Thresholds were arbitrarily chosen at the 90th and 93rd percentile, which turned out to be 8 and 10 flashes per minute squared, respectively. As stated above, some overlap is expected between the severe–nonsevere partition, hence a 5%–10% false-alarm rate (FAR) for identification of a severe thunderstorm is already assumed. Currently, the FAR for severe thunderstorm and tornado warnings combined for the entire NWS is around 48% (Barnes et al. 2007); for tornadoes only, the FAR value is 76%. Two DFRDT thresholds were tested to evaluate the variability in probability of detection as a function of false alarm rate.
Relative to the 90%–93% levels discussed above, an algorithm referred to as the Threshold 10 algorithm is defined, and a lightning jump is triggered when the total flash rate equals or exceeds 10 flashes per minute and DFRDT values exceed 10 flashes per minute squared (for the 93% level). The second threshold algorithm, the Threshold 8 algorithm, uses the same 10 flashes per minute flash rate criteria; however, the DFRDT threshold criteria is set at 8 flashes per minute squared (90% level).
4) The sigma algorithms
The “sigma” algorithms (σ = standard deviation) we develop are a variant of the Gatlin algorithm; however, they involve less smoothing of the data and higher jump thresholding to lower false alarm rates. The 1-min flash rates are calculated as in Eq. (1), and similarly DFRDT values are computed from these 1-min averaged totals. A standard deviation calculation is based on the five most recent periods of time (i.e., the previous 10 min of total lightning), not including the period of interest. Next we consider a 2σ variation from the running mean behavior to identify abnormal lightning behavior. The 2σ was chosen on a trial and error basis to reduce the number of false alarms while still maintaining a high probability of detection. A 2σ deviation eliminates smaller jumps, while still allowing for the detection of significant increases in lightning behavior. Similarly, a 3σ lightning jump algorithm configuration was also developed for further testing.
Finally, a 10 min−1 flash rate threshold is applied to the 2σ and 3σ algorithms so that normal behavior associated with nonsevere thunderstorms, and nonsevere stages of severe thunderstorms, are not misclassified as severe. This threshold is based on the mean flash rate determined for nonsevere storms discussed in the previous section. For the sigma algorithms, a “jump” occurs once the value of DFRDT exceeds the 2σ or 3σ threshold, respectively. A jump ends once the DFRDT value is less than or equal to 0, unless two jumps are separated by 6 min or fewer. If two jumps are separated by 6 min or fewer (i.e., jump, no jump, and jump in consecutive periods) this is counted as one jump.
5) Warning length and verification
Once a lightning jump occurs, a severe warning is placed on the thunderstorm for 45 min. This 45-min period is the average warning time for severe thunderstorms provided by the NWS (T. Troutman, WCM, WFO Huntsville, 2008, personal communication). Additionally, to facilitate comparison with the results of Gatlin (2006), a separate warning time of 30 min is also tested. The algorithm using the 30-min warning time will be termed the “Gatlin algorithm,” while the algorithm using the 45-min warning time will be denoted as the “Gatlin 45” algorithm.
Verification of a severe warning will occur if severe weather is observed within the warning time period for the thunderstorm that triggered the lightning jump. Events that are reported within 6 min of each other are counted as one event. Multiple events can occur within the warning period, and each is counted as a hit if a warning has been issued. If severe weather occurs while two warnings are in effect, the verification of the severe warning is counted toward the earliest issued warning that is still in effect. Therefore, if another event does not occur after the first warning expires but before the second expires, the second warning is counted as a false alarm. Severe weather events that occur without the presence of a lightning jump warning are misses. Lightning jump warnings that do not verify with a severe weather event are false alarms, including secondary lightning jumps that extend initial lightning jump warning times.
To provide objective performance evaluation of the algorithms, contingency tables are created to analyze the success or failure of each algorithm. Probability of detection (POD), FAR, and critical success index (CSI) are calculated for each algorithm over the entire dataset of thunderstorms (Wilks 1995, 238–241). Heidke skill scores (HSS) are also calculated using a method by Doswell et al. (1990), which better accounts for rare events (like severe thunderstorms) to test the skill of each algorithm.
a. Nonsevere thunderstorms
Here nonsevere thunderstorms are examined to set the basic framework for formulation of the lightning jump algorithm. Additionally, each algorithm is tested against the nonsevere population to identify the number of false alarms a given nonsevere sample might produce.
Determination of what is “normal” lightning behavior for a thunderstorm must first be considered prior to implementing an algorithm that identifies a storm as severe. For example, the overall sample of 69 nonsevere thunderstorms from three different regimes (northern Alabama, Dallas, and Houston) yields an average peak flash rate for nonsevere storms of 10.06 flashes per minute. This information is used in the sigma and threshold algorithms to initialize the algorithms. Furthermore, examining the DFRDT characteristics of the nonsevere dataset reveals that the average peak DFRDT value is 4.74 flashes per minute squared. Using the northern Alabama cases, 90% of the nonsevere thunderstorms fall below a threshold of 8 flashes per minute squared, while 93% fall below a threshold of 10 flashes per minute squared, and these two thresholds are the second step in the threshold technique. Importantly the average peak flash rate was applied as a separate criterion for the 2σ, 3σ, and threshold algorithms for initialization. The DFRDT information is then used for creation of a second limit to determine whether or not a lightning jump occurs.
2) Testing of algorithms on nonsevere thunderstorms
The next step is to test the nonsevere dataset against each of the algorithms to understand potential false alarm rates for misidentification of nonsevere storms as severe. Table 1 shows the number of warnings that would be issued on the northern Alabama dataset for nonsevere thunderstorms using each lightning jump algorithm configuration. Leading the way in number of false alarms are the Gatlin methods with 101 false severe classifications. Several thunderstorms within the dataset had multiple false alarms, which is why there are more false alarms than nonsevere thunderstorms in this dataset. The 2σ algorithm produced significantly fewer false alarms for the nonsevere dataset (16), and the 3σ came in with slightly fewer with 10 false alarms. The Threshold 8 and Threshold 10 algorithms round out the bottom with seven and six false alarms, respectively.
There are several causes for false alarms within each algorithm. In the case of the Gatlin algorithm, it is highly sensitive to small variations in total lightning. Typically a thunderstorm exhibits a peak flash rate during its life cycle, and many times this peak flash rate is picked up by the Gatlin algorithm. There are also several cases in this study where there was a surge in total lightning, but zero severe weather was reported. This may be due in part to a lack of observations (i.e., the thunderstorm occurs in a remote part of the region) or the inexact nature of thunderstorms (i.e., one thing does not always lead to the observance of another). In many cases, especially with the more stringent algorithms (e.g., the sigma and threshold algorithms), a lightning jump did indicate time periods when the thunderstorm and associated updraft were strengthening.
b. Severe thunderstorms
1) Case examples
Each example below is to show the versatility (or lack thereof) for each algorithm when tested on different types of convection. There are a variety of examples presented here, each having their own challenge when developing an operational lightning jump algorithm.
4 April 2007, MCS
A large linear mesoscale convective system (MCS) moved into the Tennessee Valley from the northwest during the late evening hours. This system developed in the mid-Mississippi Valley during the early afternoon on 3 April and plowed southeastward ahead of a strong cold front. Severe weather hail and high winds were already ongoing as the complex entered the domain of study. Using the 35 dBZ at −15°C isolation technique, several thunderstorm cells are identified within the convective line (Fig. 4), which shows the utility of the isolation technique in complex convective situations.
One thunderstorm formed just to the north of the Alabama/Tennessee border in Pulaski and Giles County, Tennessee, at about 0245 UTC 4 April 2007 (Fig. 5, top left). This cell was located just ahead of the main MCS squall line that had produced severe hail and wind across central Tennessee in Fig. 4. Initially, total flash rates were only on the order of 10 min−1, and the maximum height of the 35-dBZ contour was consistently found between 10 and 11 km (Fig. 6). The MCS approached the area from the northwest and interacted with the developing storm between 0300 and 0310 UTC. At 0305 UTC the NWS office in Huntsville issued a severe thunderstorm warning ahead of this section of the MCS.
Coincident with the collision between the developing cell and convective line, the 35-dBZ height shot upward to 13 km around 0306 UTC. In response to the vertical growth and interaction with the bow echo, the total flash rate for the storm dramatically jumped from 23 flashes per minute at 0257 UTC to 87 flashes per minute at 0310 UTC (Fig. 6). During this period all six algorithms indicated a lightning jump had occurred with this thunderstorm. At the NWS WFO in Huntsville, the warning forecaster noted that the flash rate1 on the Advanced Weather Interactive Processing System (AWIPS) display was over 100 flashes per minute. Unfortunately with the current configuration of the lightning data at WFO Huntsville, it is difficult for the warning forecasters to “eyeball sources and formulate jumps in their head, while still maintaining their warning duties” [C. Darden, Science and Operations Officer (SOO), WFO Huntsville, 2009, personal communication].
Around 0325 UTC a small EF0 (EF denotes enhanced Fujita scale) tornado occurred near Taft, Tennessee. This tornado then moved across the Alabama/Tennessee state line and dissipated near the town of Hazel Green, Alabama at 0336 UTC. The report was not received by NWS Huntsville until 0340 UTC, which demonstrates the problematic nature of severe weather event report times. Around 0330 UTC, a 65-dBZ maximum in reflectivity formed at an altitude of 5 km and dipped down to the surface. At 0334 UTC the NWS upgraded the severe thunderstorm warning for this part of the MCS to a tornado warning. At 0335 UTC, several power poles were snapped off at the base near Maysville, Alabama, and at 0345 UTC 1.00-in. (2.54 cm) hail was reported in Flintville, Tennessee. Again, it is emphasized that on average the six lightning jumps triggered for this case occurred nearly 25 min in advance of the tornado touchdown, and over 30 min in advance of the destructive winds and hail across northern Madison County, Alabama, and southern Lincoln County, Tennessee. The lightning jump data in this case may have reinforced a severe warning decision if there were an operational lightning jump algorithm in place.
25 September 2005, tropical cyclone tornado
On 23 September 2005, Hurricane Rita made landfall along the southeast coast of Texas, near the Texas–Louisiana border. Rita produced significant damage along this stretch of the Gulf Coast before moving inland. By 25 September 2005, the remnants moved into central and northern Alabama, and the system’s outer bands produced several severe thunderstorms (Fig. 7). One such thunderstorm spawned two tornadoes near Double Springs, Alabama. The severe thunderstorm that spawned the tornadoes initially developed outside the maximum range set for this study (>150 km); however, by 1844 UTC the storm moved into the outer 150-km domain. Total flash rates for this storm were low at 1844 UTC (1–2 min−1). At 1848 UTC the Gatlin algorithm indicated a lightning jump with a slight increase in 1-min averaged flash activity, demonstrating that the Gatlin algorithms are sensitive to small changes in flash rate. The lightning flash rate at this point increased from 1 to 2 flashes per minute. From 1844 to 1915 UTC, the vertical extent of the thunderstorm remained constant, with the 35-dBZ height extending up to 8 km, and the 50-dBZ height remaining around 5 km. However, the rotational velocity of the storm increased in the lowest levels of the thunderstorm. Azimuthal shear values noticeably increased for the next 50 min, with values ranging from 4 × 10−3 to 6.5 × 10−3 s−1. This rotation was confined to the lowest 3 km of the storm. At 1904 UTC the Gatlin algorithm once again indicated a lightning jump with another small increase in the total flash rate. At this point none of the other algorithms had indicated a lightning jump because the total flash rate had not reached 10 flashes min−1.
Examining Fig. 8, around 1920 UTC a 55-dBZ core developed aloft near a height of 4 km. By 1930 UTC the core extended up to 5 km and the 35-dBZ echo top height reached up to the 9-km height. Increases in height shown in the time–height plot (Fig. 8) along with higher reflectivity values indicate that there were larger amounts of precipitation-sized ice aloft. In response to the vertical growth, the total flash rate increased from 1 flash per minute at 1922 UTC to 10 flashes per minute by 1926 UTC. Now four algorithms (Gatlin, Gatlin 45, 2σ, and 3σ) were triggered on by this potentially dangerous cell. At 1954 and 1957 UTC two tornado reports were relayed to the NWS in Birmingham, Alabama, and a tornado warning was issued.
For the this case, the Gatlin algorithms provided 12 min of lead time, while the 2σ and 3σ algorithms provided nearly 30 min of lead time. The sigma algorithms triggered because the 10 flashes per minute requirement was met, and the DFRDT value for the cell was above each of the sigma algorithms’ jump threshold at that time. The threshold algorithms do not provide any lead time because the DFRDT criteria were not met to trigger either threshold algorithm because of the lack of lightning.
For tropical situations, the threshold algorithms would need to have their criteria lowered for a lightning jump because of the lack of large amounts of precipitation-sized ice in a tropical system. In this case, the sigma algorithms were fortunate that the flash rate reached 10 flashes per minute. The relative dearth of lightning in some tropical situations could pose potential problems for some lightning jump algorithms; however, the lightning data coupled with the radar data and near-storm environmental conditions can add value to the warning decision process in tropical situations. For instance, the rotation within the storm was evident well in advance of the tornado (about 1 h). In this instance, there was an increase in the vertical extent of the thunderstorm and the total flash rate, indicating potential stretching of the updraft and rotation within the thunderstorm. In this specific case, the lightning jump algorithm would have added valuable information to the NWS radar operator for use in a real-time decision.
4 July 2007, Washington, D.C., supercell
For the second straight year the Washington, D.C., metropolitan area experienced severe weather on 4 July. Multiple isolated severe thunderstorms affected the area with wind and hail (Fig. 9). The particular thunderstorm examined here developed along the Maryland–Virginia border at 1822 UTC and is located nearly due north of Washington, D.C. (Fig. 9). The storm pushed its way across Loudoun County, Virginia, for the next hour, producing lightning rates of a few flashes per minute. Despite the relative lack of lightning, the thunderstorm developed a strong reflectivity with >50-dBZ core, but the core was confined to the lowest 3 km of the atmosphere (temperatures warmer than −10°C). By 1900 UTC the core reflectivity increased to >60 dBZ, and 35 dBZ extended upward to 6 km.
By 1934 UTC the 35-dBZ echo top height shot up to 9 km, and the thunderstorm was identified by the TITAN software. Even with the strong vertical growth of the thunderstorm, lightning flash rates increased only slightly to 6–10 per minute (Fig. 10). The strong reflectivity core >50 dBZ descended by 1951 UTC, and at 2000 UTC 0.75-in hail was reported at the surface. The Gatlin algorithms indicated a lightning jump on a subtle increase in total lightning at 1956 UTC. The remaining algorithms did not indicate a lightning jump because the flash rate remained below 10 flashes per minute.
Total lightning rates increased from 10 flashes per minute at 2008 UTC to values around 20 flashes per minute by 2010 UTC. This increase in flash rate occurred in conjunction with the development of another strong reflectivity core exceeding 65 dBZ just after 2010 UTC (Fig. 10). Large hail (0.75 and 0.88 in.) was once again reported between 2010 and 2015 UTC near Damascus, Maryland. Four of the algorithms (Gatlin, Gatlin 45, 2σ, and Threshold 8) indicated a jump in lightning around 2010 UTC; however, only the Gatlin algorithms provide any lead time for the report at 2010 UTC because a warning would have already been in effect for this storm. At 2025 UTC 2.00-in hail was reported in Laytonsville, Maryland, and at 2030 UTC a funnel cloud was spotted. The timing of reports was in conjunction with a noticeable descent of the latest reflectivity core from around 3 km to just above the surface. The Gatlin, Gatlin 45, 2σ, and Threshold 8 algorithms provided nearly 15 min of lead time on the larger 2.00-in. hail. The Threshold 10 and 3σ algorithms still did not recognize a lightning jump because the flash rate and change in flash rate for the storm remained below the lightning jump thresholds for the two algorithms.
Total lightning increased once again to 25 flashes per minute at 2030 UTC just prior to another increase in vertical growth of the 65-dBZ reflectivity core. The Gatlin, Gatlin 45, and 2σ algorithms once again indicated a lightning jump had occurred. The 3σ algorithm’s lightning jump threshold was now met, and the 3σ algorithm indicated a lightning jump as well. The Threshold 10 algorithm had yet to indicate a lightning jump for this storm because DFRDT trends in the total flash rate did not increase beyond 10 flashes per minute squared. At 2050 UTC, the newest reflectivity core began its descent to the surface. At the same time the total lightning flash rate increased from around 16 to 44 flashes per minute. Between 2050 and 2055 UTC wind damage and hail around 0.75 in. were reported in central Maryland, likely in conjunction with the descent of the reflectivity core. The increase in lightning during the period triggered both the Gatlin algorithms and the Threshold 8 algorithm beginning at 2050 UTC. The lightning activity with the thunderstorm steadily increased as the maximum reflectivity values >65 dBZ disappear (see Fig. 10). At 2104 and 2112 UTC two additional increases in lightning were observed, and the Gatlin algorithms as well as both Threshold algorithms indicated lightning jumps had occurred. The storm decayed as it approached the southern end of Baltimore County. The lightning rate peaked at 49 flashes per minute at 2112 UTC; however, the number of flashes remained steady around 40 flashes per minute through 2126 UTC. The CG flash rate peaked at 8 flashes per minute at 2110, 2118, and 2122 UTC, and all flashes were of the negative polarity. The core of the storm collapses and large hail and high winds were observed near Baltimore, Maryland, between 2130 and 2145 UTC. The Gatlin and Threshold algorithms provided nearly 30 min of warning on this severe weather; however, the 2σ and 3σ algorithms missed the severe weather associated with the demise of the storm.
19 June 2007, null case
On the morning of 19 June 2007, a mesoscale convective vortex (MCV) moved across northern Alabama (Fig. 11). Several convective cells (>35 dBZ) developed well to the east and northeast of the circulation center during the early–midmorning hours (1200–1400 UTC). These cells contained lightning; however, they remained below severe criteria, and were located far away in east-central Tennessee around the time of a reported tornado. Around 1400 UTC the MCV’s circulation center entered northwest Alabama, with a few convective cells located to the southeast of its center. These cells produced little if any lightning during this time, and the lack of lightning continued through the time of a tornado that occurred just after 1600 UTC. By 1530 UTC additional cells developed just to the east and southeast of the center, and began to rotate relative to the MCV center. At 1605 UTC a small EF0 tornado occurred with no warning in the small community of Trinity, Alabama, damaging a few homes and garages. WSR-88D from KGWX and KHTX were too far away to resolve the circulation; however, the University of Alabama in Huntsville (UAH)/NSSTC Advanced Radar for Meteorological and Operational Research (ARMOR; Petersen et al. 2007) located closest to the tornadic feature did detect the small circulation. The lack of lightning rendered the use of lightning jump algorithms moot. There is no time–height section presented for this thunderstorm because it only reaches the −15°C level for one volume period at 1549 UTC. This case is important though because it illustrates the inability of lightning data to provide warning utility in the event of shallow rotating features that can produce tornadoes.
c. Summary of algorithm performance
In this section we present a synthesis of statistical results for the entire dataset of thunderstorms studied. To assess the performance of each individual algorithm, POD, FAR, CSI, and HSS values are determined for each algorithm, broken down by range from the individual LMA center.
1) The Gatlin algorithms
Referring to Tables 2 and 3, the Gatlin and Gatlin 45 algorithms display a high POD (90% and 97%, respectively); however, their FAR is also high, with values of 50% and 49%, respectively, when only severe thunderstorms are considered within 150 km. As mentioned multiple times, the Gatlin algorithm is easily triggered by small changes in the total flash rate. When nonsevere thunderstorms are also considered in the sample set, the FARs for these two algorithms significantly increase to 66% and 64%. The CSI values just for the severe set are 47% and 50%; however, once again when the nonsevere thunderstorm dataset is added, the CSI drops by nearly one-third to 33% and 35%, respectively. HSS values hover around 0.50 (0.49 for Gatlin and 0.52 for Gatlin 45 at 150 km). When comparing the Gatlin algorithm with 30 min of warning time with values presented in Gatlin (2006), the POD is nearly 2% lower than Gatlin’s original results while CSI is nearly the same at ≈50% for severe thunderstorms only. Unfortunately, the noted high FAR values eclipse the high POD results, so this algorithm configuration would require improvements prior to being used operationally. Recently, Gatlin revised his algorithm to include a 2σ lightning jump threshold to replace the 1σ threshold in his original work. Results indicate that POD values are still very high (between 70% and 80%); however, only one nonsevere thunderstorm was considered in the entire study of 26 thunderstorms, and thus the FAR values are underrepresented (Gatlin and Goodman 2010).
2) The sigma algorithms
The statistics for the 2σ algorithm suggest that it shows promise for the detection of severe weather using lightning trend data (Table 4). From Table 4, the POD for this algorithm at ranges closer than 100 km is around 87%. The FAR for severe thunderstorms is an impressive 23%. If nonsevere thunderstorms are included, the FAR increases to a modest 33%, which is still much lower than the 48% FAR associated with NWS severe warnings in Barnes et al. (2007). It must be noted though that the sample size in this study is considerably smaller than that presented in Barnes et al. (2007). CSI is higher than the Gatlin algorithms at 69%, and only falls to 61% if the nonsevere dataset is included. HSS values are very high with a score of 0.76 for the entire dataset. If the range threshold is expanded 150 km for the entire dataset, the above values do not change markedly, indicating that a slight increase in range has little effect on this algorithm. Considering that a perfect HSS value is 1, the above metrics suggest that the 2σ method is a relatively robust algorithm.
The 3σ results are not as promising as the 2σ algorithm. From a comparison of Tables 4 and 5, the POD decreases, reaching a value of 50% and CSI near 41% within 100 km of the LMA center for the entire dataset. FAR is the lowest of the algorithms at 21% at 100 km or shorter, but this is of little help if the algorithm misses one-half of the severe weather events. The decrease in POD and FAR is expected as 3σ algorithm has a slightly higher jump threshold than the 2σ method. Looking once again at Table 5, little improvement is found as the domain is extended to 150 km, and the increase in POD may be due in part to an increase in the number of severe events. HSS values hover near a respectable 0.60, but the main issue with this algorithm is its lower POD.
3) The threshold algorithms
The threshold-based methods also show some promise for severe weather applications. Results presented in Tables 6 and 7 show that these simple threshold-based approaches yield POD values at 73% for the Threshold 10 method and 82% for the Threshold 8 method. FARs are manageable for both algorithms, as FARs are 36% and 41% when applied to the entire dataset at 100 km. As range increases, values of POD, FAR, and CSI increase slightly, and this once again may be attributed to the increase in the number of severe events. HSS values are in the mid–upper 0.60 range for both algorithms at either range (Tables 6 and 7), once again indicating promise for severe weather application.
4) Lead times
Average lead time results for each lightning jump algorithm are very promising. The algorithm that had the largest average lead time was the Gatlin 45 algorithm at 28 min. Next, the 2σ and Threshold 8 algorithms came in with 23 min of lead time on average, followed by the Threshold 10 (18 min), the Gatlin algorithm with 30-min warning time at 17 min, and finally the 3σ (12 min). Mean lead times for most algorithms were below the 50th percentile (Gatlin: 39th, Gatlin 45: 42nd, 2σ: 44th, Threshold 8: 44th percentile). Two algorithms had a mean that was equal to or above the 50th percentile. These were the Threshold 10 (50th) and the 3σ algorithm (60th). The main reason for the 3σ algorithm’s mean being above the 50th percentile was the high number of missed severe weather events using the 3σ configuration (i.e., 61 events with 0-min lead time). No attempt was made to partition lead times for each type of severe weather, as the lightning jump algorithm’s purpose is to detect all types of severe weather.
The use of total lightning data, especially through the filter of a lightning jump algorithm, may provide an expedient means to help forecasters understand what is physically happening in select thunderstorms (e.g., updraft strength and trends in updraft). Traditional methods for observing thunderstorms (e.g., radar, satellite) will certainly continue to be the “norm”; however, the incorporation of total lightning information and a lightning jump algorithm can be valuable for warning decisions on all types of thunderstorms (severe and nonsevere).
The lightning jump algorithms presented in this study demonstrated skill in their warning application on a variety of thunderstorm types. The 2σ jump algorithm performed best on the entire dataset of severe and nonsevere thunderstorms (POD = 87%, FAR = 33%, HSS = 0.75), and exceeded current NWS warning statistics. The FAR value of the 2σ algorithm was nearly 15% below that of the NWS national average presented in Barnes et al. (2007). Additionally, POD for the 2σ algorithm for the full thunderstorm dataset is right in line with the NWS average of 80%–90% (T. Troutman, WCM, WFO Huntsville, 2008, personal communication). The Threshold 8 algorithm also performed reasonably well despite its relatively simple configuration. The POD value was at the lower end of an acceptable POD for the NWS, however, the Threshold 8 algorithm’s FAR value was nearly 7% lower than the average FAR value presented in Barnes et al. (2007). Once again note that there is a considerable difference in each study’s sample size; therefore, these particular algorithms still need further evaluation, especially in meteorological regimes other than northern Alabama (e.g., more cases from the DCLMA, Florida, Colorado, and New Mexico). However, the testing described herein indicates the promise of an effective lightning jump algorithm for operational purposes.
Although the Gatlin 45 algorithm provided the largest lead time prior to the occurrence of severe weather at nearly 28 min, its high FAR is undesirable. If one could sacrifice 5 min of lead time, the 2σ algorithm and Threshold 8 algorithm still provide 23 min of lead time on average, with a much lower FAR. This is higher than the current average lead time for all severe weather for the NWS at 13 min. Again, our sample size is not as large as the NMS’s; however, an average lead time of tens of minutes in the first stages of lightning jump algorithm development indicates that there will be utility in an operational lightning jump algorithm.
Thunderstorm size clearly played a role in the amount of lightning produced. This was evident during the early stages of the 4 July 2007 thunderstorm near Washington D.C. For comparison, a 2.00-in. hail-producing supercell thunderstorm on 8 April 2006 from our dataset will be used. Using the TITAN software, a simple size comparison can be made between the two storms (not shown). The 8 April storm was 4–7 times the size of the 4 July storm just prior to the occurrence of 2.00-in. hail in each storm. As expected the total flash rates for each storm were dramatically different. The peak 1-min flash rate for the 4 July storm going back 30 min prior to the occurrence of 2.00-in. hail was 25 flashes per minute. Meanwhile, the peak 1-min flash rate for the 8 April supercell within 30 min prior to the onset of 2.00-in. hail was 104 flashes per minute. Thus, the size of a given thunderstorm is a significant determinant of the amount of lightning produced, and is a limiting factor for the application of any real-time lightning jump algorithm (especially for a flash rate threshold algorithm) for the detection of severe weather in storms such as the early stages of the 4 July 2007 case.
The representation of storm types in this study was broad, but the number of cases within the thunderstorm dataset needs to be increased. Increasing the sample dataset will allow for a more robust understanding of different thunderstorm types and their associated lightning characteristics, and enable a better determination of the most effective lightning jump threshold value for any of the above configurations. For example, with tropical remnant thunderstorms lightning production is limited; therefore, lower thresholds may be necessary to identify a severe storm in a tropical environment. Finally, statistical modeling is currently being developed to determine the point at which the number of cases studied are reasonable enough to represent a global population of thunderstorms (e.g., Carey et al. 2009).
As a preliminary to GOES-R Geostationary Lightning Mapper algorithm development, this study has developed and tested six lightning jump algorithm configurations for operational application. To set the framework for determining the definition or the identification of a severe storm using lightning trends, 69 nonsevere thunderstorms were studied to determine what normally occurs within ordinary convection. An average 1-min peak flash rate from the sample was found to be just above 10 flashes per minute, similar to what past studies have found in Florida (Livingston and Krider 1978). An average DFRDT rate for this same dataset is near 4.74 flashes per minute squared. Although this number is not used in any of the proposed algorithms, this may be a useful number in the future if a lower bound greater than zero needs to be applied to define the end of a jump. DFRDT rates at the 90% and 93% level of the nonsevere sampling distribution were found to be at 8 and 10 flashes per minute squared, respectively. The average peak flash rate information from this set of storms was used to define a lower limit for triggering the 2σ, 3σ, Threshold 8, and Threshold 10 algorithms. The nonsevere peak DFRDT rate information acts as a second level of security for the alarm to sound for the Threshold 8 and Threshold 10 algorithms.
Of the 69 nonsevere thunderstorms, all 47 northern Alabama cases were tested against each algorithm to see how many false severe classifications were identified in situations in which thunderstorms remained below severe limits. The Gatlin (2006) algorithms performed poorly, with 101 false alarms identified solely in the nonsevere thunderstorm database. This is due to the high sensitivity of the algorithm to small increases in total flash rate. The 2σ algorithm performed much better with 16 lightning jump false alarms, followed by the 3σ with 10, Threshold 8 with 7, and Threshold 10 with 6 false alarms. This information was then incorporated into the statistics after the severe sample was tested.
Severe thunderstorms were broken down by range to see if distance from the center of the LMA had any influence on lightning algorithms. At 100 km, 35 severe thunderstorms with a total of 93 severe weather events were tested against each algorithm. At a range of 150 km, 38 severe thunderstorms were tested with a total of 122 severe weather events. The severe dataset ranges in storm type from isolated supercells to tornadic cells in tropical storm remnants, and all types of severe weather are represented.
A total of six algorithm configurations were tested to determine an optimal configuration for a lightning jump algorithm. Of the six lightning jump algorithm configurations, the 2σ jump algorithm performed best on the full dataset of severe and nonsevere thunderstorms with POD values at 87%, FAR at 33%, CSI at 61%, and HSS at 0.75. The 2σ algorithm POD met the NWS desired requirements, and its FAR was 15% lower than the NWS average. Granted, the dataset presented here is much smaller than that presented in Barnes et al. (2007); therefore, more cases from a variety of meteorological regimes are required to examine the full potential of any lightning jump algorithm. The Threshold 8 algorithm may also provide a simple and effective algorithm configuration (POD ≈ 83%, FAR ≈ 41%). The worst performing algorithms were the Gatlin and 3σ algorithms. The Gatlin algorithms poor performance was primarily due to their high FAR (≈65%) because of the algorithm’s inclination to indicate lightning jumps on small increases in the total flash rate. The 3σ algorithm missed half of the reported severe weather events, which led to its low POD.
Overall, the use of lightning jump algorithms on many different types of thunderstorms demonstrates that the lightning jump algorithms have the potential to indicate storm severity regardless of environment. Specifically, there is a potential to track severe weather among different storm types confined in the GOES-R field of view. However, further testing of the lightning jump algorithms for other areas of the country and meteorological regimes should be conducted to confirm that similar results can be found using any of the lightning jump algorithms presented here, most specifically, the 2σ algorithm.
This work was funded by the GOES-R Risk Reduction effort under Space Act Agreement NA07AANEG0284. Larry Carey also gratefully acknowledges partial support for this research under an award from the NOAA NWS CSTAR program (NA08NWS4680034). Walt Petersen and Larry Carey acknowledge partial funding of this research via NOAA support of the UAH/NSSTC tornado and Hurricane Observations Research Center (THOR). The authors also acknowledge John Hall and Jeff Bailey for the North Alabama LMA and DCLMA data, as well as Eugene McCaul and Dennis Buechler for their contributions and help with the LMA datasets and Hugh Christian and William Koshak of NASA MSFC for their continued support and advice throughout this study. A special thanks is given to Pat Gatlin of ESSC for his technical support with the WDSS-II system and many conversations on lightning jump algorithm development. The authors also thank members of the National Weather Service WFO Huntsville for their insights into warning operations, specifically WCM Tim Troutman (now WCM of the NWS Morristown, Tennessee, WFO), SOO Chris Darden, and Meteorologist-in-Charge Mike Coyne.
Corresponding author address: Christopher J. Schultz, Department of Atmospheric Science, The National Space Science and Technology Center, The University of Alabama in Huntsville, 320 Sparkman Drive, Huntsville, AL 35805. Email: firstname.lastname@example.org
Real-time lightning data at WFO Huntsville do not represent individual flashes; however, they represent an LMA source density (i.e., sources per kilometer squared), and the value of the source density is referred to in flashes per minute for use by the warning forecaster.