In the next set of blog entries, you are going to hear a lot more opinion and ideas of where some of us in the National Weather Center (NWC) community in Norman think we can begin to exploit technology to improve the way the NWS delivers hazardous convective weather information to its customers.  It should be noted that these ideas are still in the process of being vetted across many disciplines:  meteorology, technology, social science, ergonomics, etc.  It has been a challenging process, namely because the resources to carry this out have been hard to come by.  But we have been able to exhibit some of these ideas to NWS forecasters via the NOAA Hazardous Weather Testbed (HWT) and a social science stakeholder workshop and gained their valuable feedback.  Our overarching goal is to improve the digital communication of hazard information to provide the best decision support services to the entire spectrum of users that the government serves.

So let’s continue by examining some of the shortcomings of the WarnGen function in AWIPS.  Bear in mind that these comments are not meant to disparage the excellent work that the developers have done, but to highlight how we can evolve into an improved and more robust system to deliver hazardous weather information.  Many of our concepts have been introduced at the first two Integration Hazard Information Systems (IHIS) workshops and are being considered by the GSD developers as the framework for the IHIS software is developed.

As you recall from earlier blog posts, WarnGen creates its default polygons thus:

1.  Forecaster drags a point or line to a location on the storm at the current time

2.  Forecaster steps the radar data back in time and drags the point or line to a location on the storm at some past time

3.  The distance and bearing between the two points/lines, along with the time difference of the two radar frames, is used to determine a motion vector for that storm.

4.  The forecaster selects a warning duration.

5.  The point/line is extrapolated to its calculated position based on the motion vector and warning duration.

6.  Around the initial point/line is drawn a 10 km buffer to represent the current threat area (20 km back side for point warnings).

7.  Around the extrapolated point/line is drawn a 15 km buffer to represent the forecast threat area (30 km front side for point warnings).

8.  The back corners of the current threat area are connected to the forward corners of the forecast threat area to create default polygon.  See here again, for a point-based polygon:

9.  This polygon can then be edited by adding, deleting, or modifying any of the vertices (the triangles in the above figure).

10.  The warning polygon is transmitted with accompanying text.

Here’s a list of some of the shortcomings to this process:

a.  If any of the vertices of the polygon are changed, the polygon is no longer coupled to the motion vector, duration, and the initial and projected threat location.

b.  There is no direct way to quantify motion uncertainty.  This must be done as a guess by manually editing the polygon vertices.

c.  There is no way to change the default choice for the initial or projected threat areas.  The same parameters (10km, 15km) are always used.

d.  Information about the intermediate threat area locations is not part of the warning.  The polygon represents only the swath of the threat swept out through the duration of the warning.

e.  If the storm changes its predicted evolution (motion vector, grows, shrinks, splits, etc), there is no way to adjust the polygon swaths without (in most cases) having to issue another polygon to account for the change.

Let me first address limitation (a).  Let’s take a look at a situation that we’ve observed a number of times with warnings, and is actually taught as a “best practice”.  A warning polygon is issued that covers two counties.  The downstream end of the polygon extends not too far into the next county.  The warning forecaster does not have enough confidence that the storm will remain severe into the end of that county, so the forecaster “clicks off that county” (this can be done within Warngen – counties can be removed or added at the click of a mouse.)  The warning is then transmitted.  See anything wrong here?

Let’s look at this in pictures.  Here’s the original warning polygon, with the county borders included.  Let’s assume that this warning is in effect for 60 minutes:

And here is the new warning polygon after County B has been “clicked off”:

I’ve left the background extrapolated threat point and area on the second figure.  Note that the warning polygon was edited and then transmitted.  An important step was omitted!  Assuming that storm moves exactly as extrapolated, where will that storm be in 60 minutes?  Located at the end point.  When will that warning polygon expire?  When the storm is located at the end point.  Is the storm inside the polygon?  No! The storm exited the polygon well before the polygon expired.  If the forecaster was relying on an alerting application (such as SevereClear) to announce that the warning was nearing expiration, the forecaster may get the alert well after the storm as already exited the polygon, and the storm becomes unwarned!  The storm escaped its cage and is on the loose!

Some warning forecasters will account for this issue before transmitting the polygon by reducing the duration of the warning.  But how is the new duration chosen?  How does the forecaster know exactly at what time the storm will be at the end of the shortened warning?  They really don’t, and they have take a guess.

How should the warning be adjusted for uncertainty of duration?  Not by editing the polygon, which should represent the accumulated swath of all the extrapolated positions of the threat area from the current time, through all intermediate positions, to the final position.  Instead, it should be done by adjusting the duration of the warning, thus affecting the final extrapolated position of the threat.  Here’s the same warning with a 40 minute duration (note that even though I slightly clipped the county, I don’t advocate this in the purest sense):

Yes, this can all be done carefully using WarnGen, but we have a better idea how the warnings swaths should be created.  This new idea will also address the other shortcomings, which I will describe next.

Greg Stumpf, CIMMS and NWS/MDL