Fill and Sign the Weekly Progress Report Welcome to Ms Sanchez Form

THE AVIATION FORECAST PREPARATION SYSTEM OF THE NATIONAL WEATHER SERVICE Matthew R. Peroutka and Mark G. Oberfield Meteorological Development Laboratory Office of Science and Technology National Weather Service, NOAA Silver Spring, Maryland Michael Graf Meteorological Services Division Office of Climate, Water, and Weather Services National Weather Service, NOAA Silver Spring, Maryland George Trojan and Bailing Li Science Applications International Corporation Beltsville, Maryland 1. INTRODUCTION Forecasters at National Weather Service (NWS) Weather Forecast Offices (WFO) prepare and maintain a set of weather forecasts specifically designed for aviation users. NWS (2004a) describes a forecast product named the Terminal Aerodrome Forecast (TAF) and NWS (2004b) describes a related product named Transcribed Weather Broadcast (TWEB). Preparing TAF and TWEB products and monitoring their verification constitutes a major portion of a forecaster’s responsibilities at a WFO. For years, computer software has played an important role helping forecasters prepare and monitor TAF and TWEB forecasts. The Aviation Forecast Preparation System (AvnFPS) is the current computer application used by NWS forecasters for this important task. 2. TAFs and TWEBs NWS (2004a) describes a TAF as consisting “of the expected meteorological conditions significant to aviation at an airport (terminal) for a specified time period.” TAFs prepared by NWS forecasters follow a modified version of the World Meteorological Organization’s (WMO) Manual on Codes (WMO 2001). WFO forecasters are responsible for comparing TAFs to observed weather and issuing amended forecasts if “conditions meeting amendment criteria are imminent or have occurred and those conditions will, in the forecaster’s estimation, persist (30 minutes or longer), or new guidance/information indicates future conditions are expected to be in a different category than origi- nally forecast” (NWS 2004a). The process of monitoring observations, comparing them to the current forecast, and judging whether an amended forecast is needed is frequently called a “metwatch.” NWS (2004b) describes a TWEB as describing specific information on sustained surface winds…visibility, weather and obscuration to vision, sky conditions… mountain obscurement, and nonconvective low-level wind shear along a route” or near an airport “during a 12-hour period.” WFO forecasters monitor and amend TWEB forecasts much like they monitor and amend TAFs. 3. Computer Programs, TAFs, and TWEBs Paper and pencil were used for many years to help forecasters perform their aviation metwatch. The earliest computer systems used at NWS WFOs were able to supplement this system. A number of applications were developed that compared observations and forecasts and sent a text alert to the forecaster when discrepancies developed. Other applications performed a Quality Control (QC) check on forecasts before they were transmitted or managed a transmission queue. Late in the 1990s, computer software was introduced into WFOs that combined a number of these capabilities into a single application. Two of these applications were RAVE (Eme and Spriggs, private communication) and Aviation Workstation (Machala, private communication). RAVE was hosted on a personal computer and introduced a “traffic light” concept that allowed forecasters to quickly assess the status of their forecasts. The traffic light was a colored circle, one for each TAF site. A green circle indicated that observations and forecasts agreed well for that site. A yellow circle indicated some problems, and a red circle indicated serious problems. Additional colors provided additional information. RAVE also included an editor to help forecasters compose TAFs as well as a verification feature. Machala’s Aviation Workstation was implemented on the NWS’ Advanced Weather Interactive Processing System (AWIPS; Seguin 2002). It displayed forecast and observational data in a tabular format that allowed a forecaster to readily compare them. Color coding highlighted areas where forecasts and observations did not agree. Aviation Workstation included a TAF/TWEB editor as well as a forecast quality control feature. Early in the 2000s, Kirkwood and Hotz (2002) introduced the AWIPS Aviation Workstation (AAW). AAW adopted RAVE’s traffic light monitoring technique, and included several useful features including editing, quality control, and guidance display. AvnFPS began its development in earnest late in 2002 with the intent of integrating many of the useful features found in previous aviation software into an application that was part of the AWIPS operational baseline. Since that time, the application has evolved through three major releases. This paper describes version 3.0 of AvnFPS. 4. Forecast Monitoring Figure 1 shows the AvnFPS interface for forecast monitoring. Across the top of the Graphic User Interface (GUI) are three buttons that can be used to launch TAF and TWEB editors as well as configure AvnFPS to monitor forecasts from a different WFO (Backup). The next row shows the status of various background processes that support AvnFPS. Most of the GUI is dedicated to monitoring TAFs, observations, and various guidance sources. The left column of buttons lists the location identifiers of the stations for which TAFs are being monitored. Timestamps indicate the valid times of the most recently processed TAFs and observations. Four sections of color-coded indicators follow. The buttons labeled “Editor Shortcuts” allow forecasters to quickly begin an editing session to amend, correct, or issue a routinely delayed TAF. The indicators in the section labeled “METAR” compare the most recent set of observations with the current TAF. Table 1 provides a key for the contractions used in all four sections. Col- ors are used to indicate potential problems. Like traffic signals, green, yellow, and red suggest increasing problem severity. Orange and purple indicate additional levels of severity. Table 1: Monitoring Codes Code Meaning tpo If current forecast includes a forecast of intermittent (TEMPO) or probabilistic (PROB30) conditions, tracks whether those conditions have been observed during the past 2 h. wnd Wind direction and speed vsb Visibility wx Weather cig Ceiling ts Thunderstorm sky Sky cover The indicators in the section labeled “persistence 4hr” compare the forecast for 4 h beyond the current time with the current observation. The indicators in the section labeled “ltg” compare the TAF forecast with a 0-3h lightning nowcast. This nowcast is derived from radar observations, satellite cloud top temperatures, and a forecast 700 mb wind vector. Kitzmiller, et al. (1998) describe the statistical techniques used to generate this product. The indicators in the section labeled “grid” compare the forecast with data extracted from grids generated by the Interactive Forecast Preparation System (IFPS; Ruth et al. 1998; Peroutka et al. 1998). IFPS grids are not generally used to generate aviation forecasts. For consistency’s sake, data from the IFPS grids should agree with data in the TAFs at some nominal level. The rules used to compare TAFs with observations and guidance are controlled, in large part, by the local WFO. These alerting rules can be different among TAF sites, allowing WFOs to support variations in runway alignments and operational procedures at the airports they serve. For each alerting rule, the WFO can configure threshold settings, a severity level (which, in turn, determines alert colors in the GUI), and a message that will be displayed to the forecaster. AvnFPS is delivered with a set of rules that support all the amendment criteria required by NWS policy. The rules that compare observations and forecasts are generally more straightforward than rules that compare forecasts with the lightning nowcast or IFPS grids. 5. Forecast Preparation The editing interfaces of AvnFPS are designed to give forecasters ready access to observations and guidance as they prepare their forecasts. An emphasis is placed on presenting these data in ways that will contribute the most to the forecast generation process. Figure 2 shows the TAF Editor, configured to prepare a TAF for station KIAD The text of the TAF can be edited in the upper portion of the GUI, while a set of observations is displayed in the lower portion of the GUI. Figure 2 shows the METAR observations in their original, coded form. Figure 3 shows the METARs reformatted in a way that makes them easier to compare to each other. Notice how background shading is used to convey flight category information. The TAF editor allows forecasters to use cut and paste tools to copy text between the observation and forecast sections of the GUI as well as among multiple instances of the GUI. The tab in the lower section of the TAF Editor shows observations from multiple locations. The rest of the tabs will be addressed below under “Guidance Display.” 6. Forecast Quality Control Near the top of the TAF Editor GUI in Figures 2 and 3 is a button labeled “QC.” This button activates the AvnFPS’ QC routine. The QC function validates the syntactic correctness of all TAFs in the editor. If the QC routines identify any issues, the TAF text in question is highlighted. The forecaster can point to any of the highlighted text and receive a description of the problem. Figure 4 contains a portion of the TAF Editor display that shows two problems. The first problem is an inappropriate cloud base value and the second show misuse of the code FG. 7. Guidance Display AvnFPS attempts to make relevant objective forecast guidance available to the forecaster while TAFs are being generated. Four of the tabs shown in the lower portion of the TAF Editor in Figures 2 and 3 provide the forecaster with numerical guidance. Two of the tabs, labeled “AVNMOS” and “NGM-MOS” provide statistical forecasts generated from Model Output Statistics (MOS) (Glahn and Lowry 1972). The third tab provides numerical guidance taken from the Eta model. The fourth tab includes forecast data taken from IFPS grids. Guidance data can be displayed in the AvnFPS TAF Editor in two ways, tabular and formatted. The tabular format shows the guidance arranged in rows and columns with little interpretation. The formatted display attempts to render the guidance in a format that is ready to “cut and paste” into a TAF forecast. Figures 5 and 6 show AVN MOS guidance in these two formats. The software that generates the formatted displays generally adds a considerable amount of information. These routines must infer specific cloud heights from categorical forecasts, so they can create TAF-ready statements about precipitation and obstructions to vision. 8. Local Tools Near the center of the AvnFPS TAF Editor GUI is a menu labeled “Tools.” The Tools Menu allows forecasters to use a number of editing tools which are then applied to all forecasts in the TAF Editor. These tools are implemented in a scripting language (Python) which allows WFOs to modify existing tools and/or create new tools. Four tools are provided with AvnFPS. “AdjustTimes” modifies each TAF by removing periods that are older than the current system time and adjusting issue and valid times. “CopyForecasts” lets the forecaster use an interactive menu to copy forecast data from one TAF to another. “UseMetarForPrevailing” updates the earliest hours of each TAF with data taken from the relevant observations. “WestFlow” is an example of more sophisticated tools that could be built. It generates forecasts for multiple TAFs, based on two human-generated TAFs. Adjustments are made to account for timing and station elevation. 9. Support for TWEB Many of the features that AvnFPS provides for the generation of TAFs are also provided to support the generation of TWEBs. Figure 7 shows the AvnFPS TWEB Editor. Like the TAF Editor, the upper portion of the GUI provides an editing interface for one or more TWEBs. The lower portion of the interface allows the forecaster to display relevant supporting data, such as TAFs and observations. A TWEB Quality Control feature can validate the syntactic correctness of all TWEBs in the editor. 10. Implementation a. AvnFPS is implemented with a flexible, distributed processing model. This takes advantage of the distributed design of the AWIPS platform. Processes that capture data for AvnFPS can be located on hosts where these data are readily available. Moreover, as AWIPS evolves and various data ingest processes are rehosted, AvnFPS can readily adapt. Interprocess communications are implemented using Python Remote Objects (PYRO; de Jong 2004). PYRO uses a reserved range of Internet Protocol (IP) addresses as its data transport layer. Figure 8 illustrates the processes that support AvnFPS and many of the data flows. AvnFPS is designed to ingest data from multiple sources. The AWIPS Text Database supplies TAF, TWEB, and observations. Lightning guidance must be queried from netCDF files that contain gridded data. MOS guidance comes from netCDF files that are organized by station. In the current AWIPS configuration, these data reside on different hosts. For illustration, Figure 8 shows two data feeds on two hosts. AvnFPS can be readily configured to support more hosts or fewer hosts. A key element in the implementation of AvnFPS is the Name Server process. The Name Server maintains information on all other AvnFPS processes. All other processes are directed to the Name Server to determine the configuration of the rest of the modules of AvnFPS. Thus, an instance of the AvnFPS GUI running on a workstation needs only to be configured to communicate with the Name Server. After contacting the Name Server, the GUI process will obtain the information needed to contact any other processes it needs to contact. This implementation is flexible enough to support a GUI process running outside the WFO Local Area Network (LAN). When data arrive, an instance of the Data Ingest Server captures the data, performs whatever decoding is needed, and stores the data in a format that is readily readable by the Data Request Server. The Data Request Servers respond to requests from any active GUIs. The event server buffers data arrival events and provides notification to the GUI. The Transmission Server manages the details of transmitting TAFs and TWEBs on communications circuits, including delayed transmission. LLWS is a major peril to aviation operations. Wind profile data can be retrieved from the NOAA Profiler Network (Beran and Wilfong; 1998) as well as WSR-88D radar information. Software has been developed for AvnFPS that can process wind profile data looking for indications of LLWS, and compare the observations to the current forecast, alerting the forecaster as necessary. 11. Future Plans MDL continues to improve AvnFPS. Below are some areas that are under development. b. Monitor Low-level Wind Shear (LLWS) Climate-based Quality Control The QC techniques described above validate the syntax of the text forecasts. No attempt is made, however, to assess the meteorological content. Algorithms under development can assess the climatological frequency of the weather element combinations found in the TAF. To support this capability, observational data for 1259 US stations were amassed. These data included all hourly and “special” observations since 1973. Aviation-relevant weather elements were extracted from these observations and stored in a format that would support rapid access. When a forecaster invokes Climatological QC, AvnFPS categorizes each group of weather elements found in the TAF. These combinations of categories, along with the time of day and the time of year are then compared with all the observations that are available for that station. If the combination forecast has a low climatological frequency, subsets of weather elements are compared in an attempt to identify an “outlier.” Equation 1 shows the basic mathematical expressions used to flag unlikely combinations of weather elements. P(C P(V P(O P(P P(W | | | | | V O P W C ∩ ∩ ∩ ∩ ∩ O P W C V ∩ ∩ ∩ ∩ ∩ P W C V O ∩ ∩ ∩ ∩ ∩ W) C) V) O) P)