Evolution of GFESuite Text Products : Policy and Project Overview

The staff of the Forecast Systems Laboratory (FSL), working closely with National Weather Service (NWS) field forecast offices, develops the grid-editing component of the Interactive Forecast Preparation System (IFPS). This component called the Graphical Forecast Editor Suite (GFESuite) allows forecasters to define a weather forecast in gridded digital form. Once defined, the majority of NWS products are then derived from this digital forecast database.

Textual forecasts are among the most widely known products of the National Weather Service. With the advent of digital forecasting it is possible to produce these products automatically, allowing forecasters to focus on meteorology rather than typing, and giving consistency to the products. There is an established set of text formatters included in the IFPS system. The FSL development team is developing an alternative set of text formatters which produce standard text products directly from the digital forecast database.

The GFESuite text formatters are being developed within the Rapid Prototype Process (RPP), which delivers software in a rapid fashion and incorporates forecaster feedback to quickly improve the system. This section examines the phased development of the formatters and how the feedback process works in each development phase.

Exploration Phase

The GFESuite text formatter infrastructure was introduced by FSL as a prototype at the National Weather Service Modernized Product Workshop in September of 1998. The infrastructure was written using C++ and Python, which made it easy to extend and customize. During the next four years, field forecasters explored the capabilities of the infrastructure to develop text products. During this Exploration Phase, the infrastructure was enhanced to meet field needs. The system was also kept backward-compatible as new functionality was added.

By July of 2002, many local offices were successfully running GFESuite formatters. However, the nature of this Exploration Phase led to multiple versions of products, and support for these local versions became a challenge. At this time, OS&T developed the Local Formatter Infusion Plan which tasked the NWS, in concert with FSL, to develop a core set of GFESuite text formatters as an alternative approach to the established IFPS text product generation providing potential risk reduction for the September 2003 IOC. By providing a core set of standardized local formatters, the number of versions in the field will be minimized while still allowing local customization. A Local Text Formatter Team was formed consisting of forecasters representing all regions and the FSL development team.

Consolidation Phase

With the adoption of this plan, we entered a new phase of local formatter development, a Consolidation Phase. Instead of creating multiple versions of products, we are consolidating and integrating the products that were developed during the Exploration Phase. The infrastructure is being enhanced and transformed to better meet the needs of the local products. Backward compatibility during this phase is not desirable since it requires 25-50% of the time available for local formatter development. Even if time permitted, we would not want to maintain old code; we want a system that is easy to understand and maintain and not cluttered with older versions.

Thus, we created a new set of infrastructure modules to replace the older ones from the Exploration Phase. The older modules will continue to be included in the GFESuite until the new products are mature so that existing versions of products will still run. This will ease the transition to the new products.

In October 2002, an initial set of new products was released for testing and field feedback. The products were of varying maturity levels. In general, products in a tabular format had higher levels of maturity than the narrative-type products, which are more complex. As the field becomes comfortable with each product, they may choose to use them operationally.

Feedback Process in the Exploration Phase

How does this all-important feedback process work? First, let's look at the feedback process used during the Exploration phase. A site would create or install a product and set up local customizations. When a bug or desired enhancement was identified, the focal point would make modifications writing new methods and code to override the existing ones. The focal point used an electronic bulletin board, called the "listserver", for help with trouble-shooting from FSL or from other forecasters. This resulted in a solution for each site. The local sites were satisfied, and FSL enhanced the infrastructure to meet their needs. However, this process resulted in multiple solutions to the same problem, and the solutions were not available to all.

Feedback Process in the Consolidation Phase

In the Consolidation phase, we are integrating the existing versions of products, and the infrastructure is changing dramatically. If we used the same feedback process as we did for the Exploration phase, a new release containing a changing infrastructure would cause the modified new products to break. Depending on how much development had been done, it could take days to weeks to recover. If the product team and FSL continued to provide support for local sites making modifications to the code, the effort toward new products would be reduced by 25-50%. In the end, each site would have a different solution to the same problem, and the enhancements may not be available to all in the standard product.

The feedback process in the Consolidation Phase works differently, as follows: A site installs the new product and makes local customizations according to established "customization points" documented for that product. When a bug or desired enhancement is identified, instead of modifying the code at the local site, the focal point submits a report to the listserver. The GFESuite Local Formatter team responds to the problem or request. Often, due to the flexible nature of Python, an interim solution can be given to the site. This solution would then be available to all AND can be integrated back into the standard product and infrastructure. As a result, the individual sites are satisfied and the Local Formatter Team has spent time on new product development. There is one solution to the same problem, which makes the products easier to understand and maintain.

Using this feedback process, which minimizes local versions, a new release is less likely to break the products. If there are infrastructure changes that will effect products, they can be identified. The time to adapt the products would be more on the order of hours rather than days or weeks. In this scenario, progress on the new products has been increased and the feedback process has served the purpose of developing mature products for the benefit of all. During the Consolidation Phase, there might be some cases where the field offices are asked to settle for less functionality in the short term in order to help build fully featured and maintainable products in the long term.

Conclusion

The target date for operational GFESuite Local Text Formatters is June 2003. The goal is to have a set of fully featured and customizable products. At this time, the infrastructure will be stable and mature. As a result of supporting the needs of a diverse set of core products, the revised infrastructure will contain excellent tools for field forecasters to begin a new Exploration Phase, creating Modernized Products, the original goal and intention of the GFESuite text formatters.