WarnGen limits the user to only one default choice for the initial or projected threat areas.  The same parameters (10km, 15km) are always used.  Of course, the meteorologist can actually change these areas by manually editing the default polygon points.  The back end of the warning can be edited to conform to the shape of the current threat area.  The front end of the warning can also be edited to conform to the projected future shape of the warning area.  But recall that once you start to edit the points in the polygon, you have now decoupled the motion vector and duration from the warning.  In fact, the point position and motion vector happen to be transmitted in the warning text.  When the forward portions of the warning are changed without adjusting the motion vector and/or duration of the warning, it becomes possible for a sophisticated user to project the current position based on the motion vector and discover that the forecast future position may not even lie within the warning polygon swath.  Confusion could reign!

What about the placement of the point or line?  Where should these go?  Let’s just look at the point placement, the “Drag Me To Storm” position.

This point is used to represent the “storm”.  But does this get placed at the centroid of the storm (option 1)?  Or is it placed on the leading edge of the storm along the centroid motion vector (option 2)?  Or the most forward portion of the echo (option 3)?  Or elsewhere?  This point is used to project the future location of the threat at the end of the warning, and also to compute the “pathcast” information.  But if the point doesn’t actually represent the full spatial extent of the threat, wouldn’t the resulting polygons and pathcasts be incorrect?  For example, if using the centroid of the storm, the severe weather might commence before reaching the centroid of the storm, and the polygons and pathcasts would be lag in time.

So let’s say for example we track using the storm centroid.  Without editing the default polygon, you can see that a portion of the storm threat might be missed using the default box sizes.  One could manually edit the polygon, but this would be done entirely qualitatively.  How could this be done quantitatively?

In either case, the storm hazard isn’t a point, but it is a two-dimensional area.  In a way, WarnGen provides a 2D threat area, but it is a perfect square 20 km on each side.  No storm actually has those dimensions.  It therefore makes more sense that we should be defining 2D threat areas, and projecting 2D threat areas at future positions, like so (assuming the orange contour represents the spatial extent of the severe weather in this storm):

In addition, the future threat area defaults to a set expansion rate (exactly 150% its original size), and there is no direct way for the forecaster to quantify how much the threat area will expand, or how the projected area should be modulated to account for motion uncertainty or storm evolution.

We’ll show you one method in which we can address these shortcomings of WarnGen next, a proposed method for creating the short-fused convective hazard grids that does a better job at quantifying and directly coupling current and projected threat areas, motion, and motion uncertainty.  In addition, this new warning generation methodology can provide intermediate threat area locations within the entire swath of the warning, plus one other major benefit:  Threats-In-Motion (TIM), to be described very soon in this blog.

This is the first step in a proposed new hazard information delivery methodology that we feel will naturally dovetail toward the future “Warn-On-Forecast” paradigm of using numerical ensemble guidance to predict storm evolution beyond simple detection and extrapolation of threats.

Greg Stumpf, CIMMS and NWS/MDL