Table of Contents 
Previous Chapter
Figure2.3 summarizes the history of system development in PROFS and FSL. It is evident that every aspect of the system has "evolved" over the 16 years. Before discussing the general design principles that came out of this extended evolution, a brief discussion of the evolution of each of the major system components is helpful. Refer to Figure2.3 for the following discussion:
Figure2.3 (click to see a larger version)
System - The first system at PROFS was a McIDAS on loan from Wisconsin's Space Science and Engineering Center. Another available system was the AFOS system of the National Weather Service. These systems were the starting point for design of the RT81 System. This had a command line interface, like McIDAS and AFOS, and included all types of data - such as radar that was not available on McIDAS; of course, the AFOS had no image data. The "RT" in the title refers to real time, with the approach being that the system was tested by bringing in NWS forecasters in the Fall of 1981 to use it, and make suggestions for improvement. The results of the RT81 test were used to completely design a new system for use in the Summer of 1982, designated RT82. This system was the first one that included a graphical user interface, which was built using the VAX/VMS architecture developed by Digital Equipment Corporation. The VAX/VMS systems were the primary development platform for PROFS/FSL through the late 1980s. A much more sophisticated system was built in 1983, which was oriented toward the ability to improve severe weather warning capability. Experience with this system showed that the need to issue convective weather warnings is a "design driver" for NWS weather information systems, a subject that will be discussed in Section 2.5. By 1986, a much more effective method of evolving the weather information systems was in place - a system called DARE was installed and operating at the Denver Weather Service Forecast Office. By being in operations, the system was used continuously, with the associated advantage of continuous feedback to evolve improvements. Furthermore, the tests were not contrived to be close to operations - it was the actual operational environment toward which we were designing. DARE, including a significant upgrade in 1990, was in operation at Denver and Norman for many years, and is only now being decommissioned at Denver with the coming of WFO-Advanced. During 1987, work commenced on a PC-based system. This system was built with a UNIX operating system and used a special graphic board that plugged into the AT bus. The system helped FSL developers learn how to use UNIX effectively to get the performance needed for weather systems.
Interface - It became very obvious in the RT81 test that a key to weather information systems was development of a user interface that allowed the large and diverse variety of products and capabilities to be easily accessible. A command line may have worked for systems with limited products (McIDAS) or limited data types (AFOS), but a much more sophisticated approach was needed when diversity and complexity of products increased. The RT82 system had a separate display, equipped with a light pen, which was dedicated to the menu of products. A touch screen was used in RT83. Light pens and touch screens are limited in capability because the technology requires a comparatively large amount of screen space for each selectable item; later systems have used the now-common mouse/pointer mechanism. The RT85 system had a single high resolution dedicated menu screen that drove two display screens. This configuration, while an improvement over the touch screens, generated confusion and difficulty because of having to always be cognizant of which display would be affected by an interaction. It was determined that having the menus right on the display screen was preferable; this was accomplished in the development of DARE, which proved to be a great improvement over RT85. Tear-away menus allowed forecasters to configure the system and its menus to their preference and to tailor the menus to the particular situation they were facing. DARE had different menus for each scale, and floating menus for applications such as cross sections, interactive skew-T, warning generation, etc. The complexity of the menus became an issue, with orphan tear-always, and menus which were unrelated to the product which was displayed. For example, an interactive cross section generator could still hang around after the related cross section had been replaced by (say) a skew-T. Because of all these experiences, the FX Advanced menu was designed to be generally oriented to a single screen and unified through scales. Thus, whether one is on a very large scale, such as the hemispheric, or a small scale, such as the state scale, a single menu handles all access. If a product is unavailable, it is simply dimmed. In summary, the result of the experience was that menus have to tree rapidly and easily to a very large product set, but must be available at high level in simple form, and act unambiguously on the main display. WFO-Advanced does this. Although the reaction of many people to such a requirement is that this is obvious, most meteorological systems extant today grossly violate the rules of menu simplicity and directness.
Display - A salient feature of weather is that it is dynamic. Thus, it is not surprising that weather forecasters are always pushing for more and better motion capabilities. They want animations that load fast, have high resolution, and run long enough to see the phenomena of interest, which can range over time scales from minutes to weeks. A product, such as an infrared image of North America, can be derived from several megabytes of data which is transmitted from a geostationary satellite. The display problem is to convert that data to a stream of images on the screen. With the computer technology of the 1980s and 1990s, doing this to the satisfaction of the users is difficult.
It was once stated that it was fortuitous that PROFS was able to find dedicated hardware that allowed easy and fast animation of high resolution images, and that such capability was not easy in a UNIX/X environment. This view reverses what actually happens in the design process. In the early 1980s, starting with the requirement, it was very difficult to see how the display requirements could be met. PROFS pioneered the use of the Ramtek frame buffer, with its size, pixel-replicate zoom, and rapid display list processing, to meet the requirement. PROFS engineers worked closely with Ramtek to improve their system designs to meet the weather information processing needs.
One of the first things to do in the design of a meteorological system is to start with the available hardware and software, and analyze the factors which will allow access, load speed, and animation which will meet requirements. In the case of WFO-Advanced, much of the database, including imagery and grids, is located on the database processor. Thus, the first access must bring the data over the network to the local memory. In the memory, it is stored in its database form; a pixmap suitable for X window display is created from the memory-resident data. The pixmap is typically not a one-to-one load from storage format. Rather, there will be operations to convert the existing file form to the appropriate scale, zoom, etc. Thus, the loading of (say) an image consists of many steps: determine where the disk file is, bring it over the network, access it in memory with a program that converts it to the pixmap appropriate for display, etc. In the design of FX Advanced, each of these steps was optimized and redesigned and optimized again in order to meet the performance requirements. We are continually looking for better and faster ways to perform these crucial operations.
As seen in Figure2.3, the original imagery (in the early 1980s) was presented as four- frame loops, with a resolution of 512 by 512 pixels. The depth of the frame buffers was typically 8 bits. During much of the 1980s, performance was achieved by specialized frame buffers, in which the entire animation sequence was stored (in DRAM) and operated on (e.g. pixel-replicate zoom). When forecasters were given a choice of how many frames to use in their animations, they would choose the longest animation that could be loaded in a "reasonable" amount of time. Thus, on DARE 1, they could load up to a 32- frame loop, but rarely did, because it would take minutes to load. The time one is willing to wait varies with individual, but it is typically tens of seconds. Thus, in the RT82 and RT83 systems, it took about 30 seconds to load a four-frame loop, and that was the typical usage. In RT85 and DARE 1, an 8-frame loop could be loaded in about 30 seconds, and that was the most common usage. DARE 2 allowed faster loads, partly due to an image disk, and partly due to other optimizations. The result were that more forecasters used longer (e.g. 16- and 32-frame) loops, although they sometimes chose shorter loops for a variety of reasons. The FX Advanced currently loads a 900 by 900-pixel image at about 0.8 seconds per frame on a cold hit (i.e. when the product is not available in RAM or disk cache), which means that a forecaster willing to wait 30 seconds might reasonably load a 24-frame loop. Recent experience in Denver and Boulder has shown that the users are using 16 to 24 frame loops fairly commonly.
Hardware - The growth in the capability of hardware, such as processors and memory, is a well known but nevertheless amazing story during the last 16 years. PROFS started with a PDP 11 in the RT81 system, progressed to a VAX 750 in RT82, and stayed pace with the evolution of the DEC VAX series of processors during the 1980s. The PC 386 with an Omnicomp graphics board was used in the PC workstation. Hewlett Packard equipment, with the HCRX-24 graphics card, is being used in the FX Advanced. The most interesting thing to say about the hardware evolution of the PROFS/FSL systems is that large increases in raw computing power translates into relatively small increases of functional capability.
Operating System - The operating system used in the VAX systems was VMS. Starting with the PC workstation, FSL has used UNIX operating systems.
Grid Data - The early PROFS systems adapted from both AFOS and McIDAS. AFOS used predefined vector graphics, while McIDAS used grids to generate products "on the fly." During the early 1980s, PROFS used predefined vector graphics for a number of reasons, including performance (particularly load speed) and the availability of AFOS data in vector format. The use of grids is more flexible, both in the products that can be created, and how they can be tailored for use. For example, the use of 60 gpm contours on 500 mb charts is quite standard; for many years the fax products and then the AFOS products of NWS used these contours. Thus, when zooming into small spatial domains with data in vector format, the contours often disappear from the screen because the space between contours is wider than the geographic domain. With grids, we have the option of contouring on the fly, allowing the density of contours to increase as the user zooms in. In the DARE system, an application called "Grid to Graph" was used to generate a selection matrix for grid products. The system was limited in product selection, and cumbersome in that it often generated a large matrix of selectable products. The product was listed on the left side, with a "green time" (the time of the latest available product) for each prediction time listed along the abscissa of the selection matrix. The "Volume Browser" of FX Advanced represents a significant improvement because it simply shows an inventory of the prediction times. It is more organized in its call sequence. Furthermore, a new capability, called the "Product Maker" allows the user to use mathematical operations on one or more grids to generate fields of from 0 to 4 dimensions (x, y, z, t). A simple example of the use of the Product Maker would be to calculate the difference field between the relative humidities from two different models. It is clear that such operations require the availability of grids rather than vector graphics.
Data Base - It is clear from Figure2.3 that the history of the data base sizes has tracked the similar growth in disk storage available for a fixed cost. In real dollars, the cost of a 60 MB disk in 1980 is similar to the cost of 12 GB of disk storage in 1996. One use for the increasing disk space is to make more model grids available. The model grids require more space than vector graphics, and the models themselves have increased fairly rapidly in resolution, resulting in big increases in storage requirements. This trend will continue; a single run of a national 10 km resolution meteorological model will generate about 10 GB of data (which of course could be compressed). Such models are now being tested at NCEP and FSL, and may be available operationally as soon as 2000.
A second increase in data storage that occurred was in the resolution of imagery (mainly satellite and radar) and the length of animations of these. As discussed above, in the early 1980s, a four-frame loop of 256 by 256 or 512 by 512 images has been replaced by typical loops being 900 by 900 pixels, with typical sequence lengths of 12 to 24.
As shown in Figure2.4, a system typically starts as a collection of software or subsystems that do parts of the job. These are chosen to test high risk areas, and to learn more about critical design questions. FSL demonstrated a limited system of this type at the American Meteorological Society meeting in January 1993. An intense effort which began in early 1994 culminated in a "working" system near the end of 1994. This was a development system including the major subsystems. The development systems were redesigned, improved, and rebuilt on an aggressive 2- month cycle during FY95. The purpose of this phase is to force an accommodation between the major subsystems. For example, the major processes like the executive ("fxa"), the database, the graphics controller ("IGC"), the interprocess communications, and the applications can be designed at a high level, and developed somewhat independently. The aggressive build and rebuild cycle of the development phase allows a natural global optimization of the system, in which each system is progressively modified to fit better in the environment created by the other subsystems. This approach often results in improvements which would not have been possible if the system had been designed in detail at the beginning and built as if from a blueprint.
The Experimental System for WFO-Advanced came into being in Fall of 1995 when it was tested extensively by bringing National Weather Service forecasters to FSL. The tests are documented in An Overview of Evaluation Results from the WFO-Advanced Real-time Forecast Exercise: RT95 by Roberts et al., 1996.
Between the development phase and experimental phase, FSL requires meeting of an Experimental Alpha Documentation Standard (essentially, in-line documentation), and similarly, the transition from Experimental System to Demonstration System requires meeting a more rigorous Experimental Beta Documentation Standard (adding more external documentation).
The Demonstration System was implemented at the National Weather Service Forecast Office in Denver in June of 1996.
PRIMARY DESIGN DRIVER FOR WEATHER INFORMATION SYSTEMS
AVERAGE TIME NEEDED TO DISPLAY A TYPICAL COMPOSITE, INTEGRATED PRODUCT - FROM `INTENTION' TO `AVAILABLE'
**********************************************************************
A discussion of why this principle is so important as a design driver is given in Design Considerations of Operational Meteorological Systems: A Perspective Based Upon the PROFS Experience, by A. E. MacDonald, 1985. In that paper, particular importance was attached to speed of use as it related to the convective weather warning process. However, the principle stated above has been found applicable to all weather office operations in PROFS and FSL experience.
A few comments about the principle are necessary. First, the time needed between intention and available includes the Graphical User Interface (GUI) interaction. It was learned early in the PROFS workstation developments that there are many products for which the GUI access takes a very long time. For example, the forecaster wants a 300 mb vorticity chart; where in a complicated menu structure can it be found? The forecaster tries working down into the display tree of a particular model and discovers that there is no analysis, only 12, 24 and 36 hour progs. Trying another model, the vorticity analysis may be there for 500 mb, but not 300 mb. Complicated and difficult menus generate user confusion, and make their jobs much more difficult. In addition, the system may require a great deal of interaction, where the user specifies such things as display time, display mode, number of products in time sequence, etc. before the product is displayed. All these can result in the user being unable to rapidly tell the system the product which is desired. WFO-Advanced uses extensive and user-tested defaults to make minimal product specification the norm, while allowing extensive tailoring if needed.
Of course, once the product is selected (and specified), the system must display it. This is often a very complex process; for example, a 300 mb vorticity chart in WFO-Advanced is made from a grid, requiring data access through the network to two different fields (u and v component of the wind) stored on the database machine's disk, computations, contouring, and special display operations, all occurring on the fly before the product comes up. Furthermore, it is possible to call, in a single mouse click, upwards of 100 products (e.g. family graphics for a model run).
In short, there is much that happens between `intention' and `display.' Although things which typically show up in requirements, such as the speed of image loads, are quite important, other aspects, such as menu confusion and excessive specification demands (which are harder to cast as requirements), affect the usability of the system at a fundamental level.
It is important (at least conceptually) to define a metric which can be used to determine how well a weather information system meets the principle stated above. One characteristic of operational weather information systems is that some products are used extensively tens or hundreds of times in a shift while others are used very rarely. (The fact that a product is used rarely should not be construed as a measure of its importance; when a dangerous ice storm threatens, the forecaster is likely to be looking at low level temperature and moisture products that would ordinarily be of little interest.) A measure of the speed of a weather information system should take into account the frequency of use and measure the display latency for an "average" product call. Figure2.5 shows an example of how this could be done. First, the products are tabulated and placed in a histogram of usage based on actual logs. Then, a representative set of products (e.g. 100) is selected at random. Next, a typical user of the system (not the most adept, but rather the most representative) is timed in calling up the 100 products. The lower the time needed, the more suitable the system is for operational use. We believe that the WFO-Advanced performs very well on a test of this type.
It is worthwhile to discuss briefly why the speed of display is so crucial in operational weather information systems. A good place to start is to observe how the forecasters use the system. A good way to distinguish weather office use from other computer users is to plot typical usage on a two axis display, as shown in Figure2.6. The ordinate in this chart represents "Product Complexity", while the abscissa represents the "Display/Manipulation Ratio." Product complexity includes such things as the resolution of the images, the need to integrate different types of data (e.g. satellite images and model graphics), the use of motion, availability of domains or scales for display, etc. It is asserted that weather displays are extremely complex, as complex as any within the field of computer information systems. Although there are systems such as AFPS being developed for graphical forecast generation, the aspect of weather office usage which dominates is the study of the product displays. Thus, a forecaster trying to get ready for a possible severe convective storm will be looking at many products atmospheric stability, low-level helicity, the ever important doppler radar imagery, etc. This may go on for hours, with the culmination being a graphical specification of the warning area which occurs on a time scale of minutes. In current weather offices, the products are often generated on a word processor, which is the opposite of the weather information display aspect discussed in this section. Specifically, a word processor file is often quite small (a few kilobytes) and is usually manipulation-dominated (e.g. typing).
Referring to Figure2.6, it is clear that weather information systems are quite different from other computer information systems. The experienced weather forecaster likes to look at a number of complex products and to rapidly assimilate the information available from them. A CAD/CAM system may be complex, but is generally the object of extensive manipulation. Geographic Information Systems have a lot in common with weather information systems, but the ground is static in comparison with the dynamism of the atmosphere. This atmospheric dynamism makes motion and other complexity necessary.
It is noteworthy that weather researchers do not typically use weather information with the rapid display needs typical of an operational weather office. Researchers are more likely to spend a long time on a product, studying it and analyzing complex features. Thus, the weather research community has often chosen flexibility over speed in the systems it has developed (e.g. McIDAS and GEMPAK).
Figure2.7 presents an abstract representation of a data base. In the Figure, the model data are shown in one area of the database, and the radar in another. A forecaster looking at a 500 mb height field prog valid at 12 hours is often going to want the 24, 36, 48 etc. prediction fields for the same product in sequence. The GUI in FX Advanced allows a single click to call the complete prognosis sequence. Further, since forecasters typically look at entire model runs, the Volume Browser and Family Graphics parts of the GUI make multiple product calls very easy. In this case, FX Advanced takes advantage of usage coherence to make GUI selection faster and easier. Another type of coherence is in the buffering of the products. FX Advanced brings a grid of data for a model field from the database into the local memory of the computer being used to display a product. The grid in memory is operated on to generate a pixmap which is used by X from main memory to generate the display. A gridded field is already available in main memory when a user request is generated; it displays much faster than if the system must go through the network to the database. It is faster still if the pixmap for the requested product is already in main memory. Like the cache model of computing memory, the FX is made faster by a hierarchy of product caching that is related to typical usage.
Another way that FX Advanced is speedy is the way the data are accessed from the disk. As shown in Figure2.8, information concerning the location of the product on the disk is kept in the display machine's main memory. There is a data structure related to the CDL (descriptive text) files used by netCDF which has information about the grids, such as products available (inventory) and file names.Thus, a single access over the network is often all that is necessary to move a set of grids or other products from disk to main memory. This is made possible for grids by organizing the data in large files. As shown in Figure2.8, a file for the Aviation 211 grid for a particular time (19/00Z) is organized with the pressure and theta levels varying most rapidly, the fields (u component of wind, v component of wind, temperature, etc.) varying next most rapidly, and the prediction times as the third level. A particular product or set of products is called with speed and simplicity by taking advantage of use coherence (i.e. only one file access gets the whole model run which is often used as a whole).
Table of Contents 
Next Chapter
