(Visit FSL's Web page http://www.fsl.noaa.gov/ for more on the lab.)
This discussion will focus on three areas within FSL's NWS/AWIPS work: the AWIPS forecaster workstation, LDAD (Local Data Acquisition and Dissemination), and LAPS (Local Analysis and Prediction System).
In general, data are made available to forecasters from three sources: central, local, and WSR-88D. PRC is responsible for passing data from the NWS Telecommunications Gateway (NWSTG) and NESDIS through the Network Control Facility by satellite broadcast to the field offices. Once received, FSL software routes, decodes, and stores data, making them available for viewing by forecasters. A connection to the local WSR-88D (or, at some offices, to more than one 88D) is provided, allowing the forecaster workstation to assume the role of the NEXRAD PUP (Principal User Processor). Local data are managed by an LDAD server, which provides for both receipt and dissemination of information.
FSL's history includes 15 years of developing and testing functional prototypes of advanced weather systems for NWS forecasters, with the goal of demonstrating capabilities and reducing the risks associated with NWS modernization plans. For the last ten years, FSL-built workstations have supported forecast operations at the Denver NWS Forecast Office. The current effort, known as WFO-Advanced, was built using AWIPS-compatible hardware (Hewlett-Packard/UNIX) and software, and has been used as the primary in-office system at the Denver office since May 1996. In August 1996, NWS management decided that FSL's software would be incorporated into AWIPS, as shown in Fig. 1, as the data management and display system for all NWS field offices.
FSL's experience in forecaster workstation development has led to the development of this design driver: The average time needed to display a typical composite, integrated product from `intention' to `available.' This includes menu manipulation, internal communications, data access, and rendering. Characteristics of the system resulting from this principle and years of testing include
Some display examples are included here. (Click in any example to open a full-screen version in another window. The size of the full-screen version is shown in the caption.)
The first illustration (Figure 2) shows the display layout, including a main display pane and four small monitor panes. The pull-down menus, accessible in the menu bar at the top, and the controls on the control bar below the menu bar, allow the user to display data in the large pane. With a single click of the mouse, the contents of any of the monitor panes can be swapped with those in the main pane. Information in all panes can be animated, zoomed, and panned, and all displays automatically update when new datasets arrive. (Please note that this and the other illustrations are from Build 3 of AWIPS. For Build 4, the user interface has been rewritten, but the basic layout is little changed.)
Figure 2. WFO-Advanced display example (vis/radar/METAR). (1.2MB JPEG)
Data integration is also illustrated in Fig. 2, where the main pane shows visible data from GOES (at full resolution) combined with radar data from the KFTG (Denver) WSR-88D, and both overlaid with a METAR plot. Two map backgrounds are displayed - one with state borders, and another with METAR station IDs. Other backgrounds may be added at the user's discretion.
Progressive disclosure, not illustrated here, is effected through rendering of the data with every zoom and pan operation. As the user zooms in on the display, all datasets (satellite, radar, METAR obs, and maps) are re-rendered. For satellite and radar, any decimation necessary to fit the data into the available pixels in an unzoomed state does not carry over into a zoomed-in display; the highest resolution available is used in every display. Likewise, additional METAR obs will appear, as will their IDs on the map. Plus, county lines automatically are displayed when the area covered is appropriately small.
Figure 3 shows how gridded information can be rendered as contour graphics or in image form. (Vector fields can be rendered as barbs, arrows, or streamlines.) A set of interactive baselines is also displayed, which the user can manipulate to select a cross-section axis. Similar controls are available to select points for soundings or time series. In Figure 4, a cross section along line I-I' in Fig. 3 has been displayed. Users have full access to gridded data, and can display any of dozens of grid parameters with just a few mouse clicks. A capability is also available to perform mathematical operations on grids, to produce virtually any desired field.
Figure 3. WFO-Advanced display example (grid image). (1.3MB JPEG)
Figure 4. WFO-Advanced display example (cross section). (1.2MB JPEG)
Also illustrated in Figures 3 and 4 is a popular feature. The third monitor pane is showing a four-panel radar display from the KFTG 88D. Users can display four tilts of the radar (or four different radar parameters, or satellite images, etc.) to get a quick look at the vertical structure of a storm. A ganged cursor lets them orient features, and also will read out the digital value in each panel.
Figure 5 shows how the system is designed to be localized to any forecast office. This particular case is from the Jarrell, Texas tornado of 27 May 1997.
Figure 5. WFO-Advanced display example (localization). (116kB GIF)
For more information on the WFO-Advanced workstation the reader is referred to these URLs:
LDAD is being developed by FSL under a separate agreement with the NWS. An initial capability has been tested at the Denver office since late 1997; AWIPS Build 4, being installed in the field in spring/summer 1998, includes an LDAD component.
LDAD data integration requirements include:
A standardized, comma-delimited ASCII data format has been developed for many of these data sources. Where possible, data are retrieved from base stations rather than individual sensors.
Dissemination requirements include:
The LDAD connection to AWIPS and outside data sources and users is illustrated in Figure 6. As shown, the LDAD servers and interfaces are separated from the AWIPS network by a firewall system, thus protecting AWIPS from intrusion, malicious or inadvertent. (A couple of notes on Figure 6: "FM" means fax modem; DTMF is a device to convert telephone tones to ASCII for remote data entry; Emergency Management officials will be Class II users, with dedicated modems.)
Figure 6. LDAD schematic
More information on LDAD can be found at URL http://ls1-fslc.fsl.noaa.gov/. This site includes Java-based access to LDAD-type data (at this writing, including displays of NWS text and LAPS analyses only).
The initial QC component of LDAD is built around work already done at FSL as part of the mesoscale analysis and modeling effort. This QC function includes
The initial implementation for AWIPS Build 4
LAPS is designed to accept a very large range of datasets. For first-guess fields, it can use grids from NCEP's RUC, Eta, or Aviation models, or from the Navy NOGAPS model. It uses data from WSR-88D radars, and can read GOES and TIROS satellite data in many different formats. It uses surface observations from ASOS, and it is quite straightforward to add data from local mesonets. Data from wind profilers, automated ACARS (aircraft) temperatures and winds, manual pilot reports of cloud layers, and surface-based radiometers have all been used to add accuracy and detail to the LAPS analyses. In the generic AWIPS configuration, it uses the SBN/NOAAPORT data feed for initialization grids from RUC, METAR surface observations, profiler winds, and three channels of GOES data (visible, window IR, and water vapor).
The LAPS software is available from the FSL/LAPS Web site (http://laps.fsl.noaa.gov/), free of charge. It is well-documented, and runs well on modest computers. Typically, independent users are interested in incorporating local mesonet data in their own implementations. This is a simple matter of providing LAPS with an ASCII-formatted data file, as specified in the LAPS README file. In the AWIPS application, the LDAD subsystem supplies access to local datasets such as mesonets and perhaps profilers.
LAPS analyses are ideally suited for initializing mesoscale forecast models such as CSU RAMS, PSU/NCAR MM5, and OU/CAPS ARPS. Work is under way at FSL to provide mesoscale modeling capabilities in future releases of AWIPS software. FSL has been running these models, initialized by LAPS and bounded by NCEP models, on a daily basis for several years, and a pilot operational implementation is now running on FSL's AWIPS testbed, with grids to be disseminated to the Denver WFO beginning in mid 1998.