Permanent removal of the Partial Service Backup functionality.

Apr 10 2007

http://www-sdd.fsl.noaa.gov/~ramer/noaa/removePartialBackup/removePartialBackup.html


The original theory behind partial service backup was that if a given site became unable to issue warnings for its own CWA, neighboring sites would be assigned responsibility for issuing warnings for those parts of the disabled site's CWA which best fell under the coverage of their associated radar. As interoffice communications improved and it became easier to obtain radar products for non-associated radars, partial service backup was abandonded as a concept of operations. The current concept of operations for backing up warning operations has a single neighboring site taking responsibility for all of the disabled site's CWA.

This type of backup, which we refer to as full service backup, was actually available in warnGen long before partial service backup was. Even during the time when partial service backup was the preferred methodology for backing up warning operations, support for full service backup was maintained. This was mostly to account for a case where there was an outage at two adjacent offices, but also to account for situations where two offices that had backup responsibility for each other were separated by large distances, such as Miami having backup responsibility for San Juan.

Having to support both backup methodologies is what led to the current layout of the warnGen GUI as regards service backup. Here is a screen shot of that part of the current warnGen GUI that controls service backup:

At this point, a quick overview of how each type of backup methodology works will be useful. When one selects a different office in the full service backup menu, warnGen actually shuts down briefly and restarts pointing at the localization data set for that different office. When one selects a different office in the partial service backup menu, warnGen continues to use the exact same set of geographic tables and templates, but those geographic tables are used in such a way that only areas in the neigboring CWA can be described in the scratch products generated.

The design of these two backup methodologies means that using one or the other has certain repercussions. In order to use full backup, one must have localizations already built for those sites one wants to backup in this manner. In the old HP days when disk space in the /awips/fxa partitions was limited, this could be problematic, but this is no longer an issue. Because full backup uses a separate localization data set, it has the advantage of being able to use a set of customized templates specifically for the site being backed up. In order to use partial backup, all areas that one might want to issue for must be included in the single set of geographic tables for your default CWA. This means that the more areas one wants to be able to use partial backup for, the less spatial precision your geographic tables have. Here is a link to the OB8.1 version of the document warngenBackup.html, which contains information about configuring for full service backup.

In the warning by polygon era, which starts in OB8.1, it will be more important than ever that warnGen geographic tables be built with the designed degree of spatial precision. Warngen tables are designed to have better than 1km resolution, whereas continuing to use partial backup areas that include entire neighboring CWAs will result in geographic tables with less precision. We have seen isolated cases in the CONUS where a site's warnGen tables have only 3km resolution, although that is a worst case scenario. Last week we had occasion to get the localization data set from a site with a warnGen problem they wanted GSD to troubleshoot, and they still have two entire neighboring CWAs in their partial backup area. The resolution of their warnGen geographic tables was about 1.35 km.

Because of these issues concerning geographic precision, the partial service backup functionality is being permanently removed in OB8.2. It will be a strong recommendation that all sites make the transition to using only Full backup at the earliest possible time so that they are not having to deal with this at the same time they are dealing with the transition to warning by polygon.

Removing the partial service backup selector from the warnGen GUI will also give us the opportunity to reduce the footprint of the warnGen GUI. To this end, we submit this prototype of the warnGen GUI being proposed for OB8.2:

Note that the overall width of this proposed GUI is the same as the previous version, but the overall length is reduced by just over half an inch.

The changes needed to support this new GUI are entirely in the tcl file warnGen. If there was a desire to evaluate this menu at a site, or if a site wanted access to a GUI that had partial backup removed so that there would be no ambiguity for users, this file could be replaced at a site with very minimal risk.



We have prototyped two other "looks" for the top of the warnGen menu, as illustrated here. The first uses no frame for the Backup button:

The other uses the same style frame as the Track type and Edit boxes.

Although the discussion point may seem to be largely aesthetic, one may consider whether or not it is appropriate to have a box surrounding a single item, since one purpose of a box is to visually group items. Another role a box may serve is to highlight the importance or significance of its contents.