Overview

The Thor Weather Scenario Server (named after Thor, the Norse god of thunder) is a data server that is part of an overall weather-data delivery architecture. This architecture was developed at Ames to provide simulated, realistic weather data to cockpit and ground display systems to facilitate research regarding the presentation and use of weather information.

Future work on the Thor project includes expanding the offerings of the type of weather products that can be included in a weather scenario. Additionally, a 3D interactive weather scenario editor is planned that will allow a researcher to tailor and even synthesize weather conditions to suite a particular experiment scenario.

Click on following links to jump to sections of this document:

• Weather Data Collection Subsystem
• Weather Scenario Generator
• Model Product
• Model Inputs
• Cell Merging
• Conclusion/References
• Thor Weather Scenario Server
• Weather Related Link
• Document Downloads

Weather Data Collection Subsystem
The Data Collection Subsystem is an automated service that gathers weather data from National Weather Service public Internet portals. The data includes outputs from the Rapid Update Cycle (RUC) atmospheric model and Level III products derived from NEXRAD weather radar. Weather data for periods of time-ranging from an hour to several days-when the conditions are of research interest, are captured and stored in a weather archive. Because of the large volume of data, the archives are periodically moved to DVDs.

<< Return to Top

Scenario Generator Interface
click for larger image (81.7 Kb)

NEXRAD base reflectivity in a 3-D projection click for larger image (58.2 Kb)

The Weather Scenario Generator processes the weather data in the archive to produce a weather scenario. It is a stand-alone application that provides tools for searching the archive for particular weather conditions, visualizing the weather, and performing some simple transforms on the weather. The transforms include region clipping, and geographic translation and rotation. The primary job of the scenario generator is to convert the weather data from its native format (each product, RUC, NEXRAD, etc., has a different storage format) into a common, easily processed format, referencable in latitude, longitude and altitude for utilization by Ames' advanced 3D displays. For example: NEXRAD data, a collection of range/value pairs along an azimuth, is converted to a set of polygons, each representing the region of value at a particular flight level. Once the data is converted, it is written to disk as a set of files comprising the weather scenario. Complete documentation is available to allow any application to read the weather scenario files directly, or they can accept weather data through use of the Thor Weather Server.

The Model Product
The Storm Model Weather Product is a set of two-dimensional polygons, where each polygon has an assigned altitude, intensity value and object Id. A polygon represents a 2D slice, at a particular altitude, through a 3D region where the precipitation is of a particular intensity. Each 3D region is assigned an object Id; all the polygons representing the region will have the same intensity value and object Id (see Figure 1).

Figure 1 - Polygon Slices of a 3D Region.

The polygons in aggregate represent samples of a storm cell. The intensity value corresponds to the strength of the radar return from the precipitation in the air in the region. For the Storm Model product, the storm cell regions are not defined by sampling because the radar coverage is too sparse; rather the cell locations and structure (derived by algorithmic processing of the radar data) is extracted from the NEXRAD product files and used to model the storm cells. The product's polygons are generated from the modeled cells

<< Return to Top

Model Inputs
Each storm cell is a simple model based on an idealized conceptualization of a typical supercell thunderstorm. Figure 2 illustrates a thunderstorm with considerable overhang, surrounded by the signature anvil cloud. In the figure, the numbers assigned to the banded regions are typical radar reflectivity values. This is the kind of cell that would be detected by the NEXRAD radar and be a data point in the NEXRAD product files. The NEXRAD product files are inputs into the cell modeling process as shown in Figure 3.

Figure 2 - Vertical Cross Section of Typical Supercell (source: [1])

The NEXRAD Storm Structure File (Product 62) identifies each storm cell detected by the radar at a particular site. It contains the location of the cell center (in Az/Range from the radar), the height of the cell base, the height of the cell top, and the highest point of maximum reflectivity. It also contains the values for vertically integrated liquid (VIL) and the maximum reflectivity (in dBz)-only the later is currently used in the modeling.

Figure 3 - Modeling Inputs

The NEXRAD Storm Track Information File (Product 58) contains the speed and direction of cell movement, and is correlated with the Storm Structure file by cell Id. The Storm Track file also contains predicted cell positions for one hour in fifteen minute increments, but these are currently not used.

Table 1 summarizes the information utilized from the NEXRAD product files. This information is used to construct simplified models of the storm cells, which are then used to generate the Storm Model Product polygons. Figure 5 illustrates the simplified model used to generate the product polygons. Only the precipitation regions are modeled; the clouds associated with the storm cells are not necessarily detected by radar and not modeled at this time.

Presently, no attempt is made to model the lifecycle stage of the cells. Figure 4 illustrates the typical stages for a convective cell. We are modeling cells after they have been detected by NEXRAD and flagged as storms-probably from the late Cumulus states through the Mature and possibly into the early dissipating stage.

Figure 4 - Storm Lifecycle Stages (source: [3])

For the purposes of the Storm Model Product, each cell consists of up to three concentric "shells", where each shell encapsulates a region of storm intensity. NEXRAD reflectivity values as measured may range from 0 to 75dBz. Most end-user applications map the dBz value to an integer value for intensity, usually from 0 to 15. For this model, the intensity values are further "bucketized" into severe, moderate and light. Table 2 lists the intensity buckets and the values to which they are mapped.

Figure 5 -Vertical Cross Section of Modeled Cells

The starting point for the modeling process is the value of the maximum reflectivity in the storm cell. The innermost shell is given the intensity value to which this reflectivity is mapped. The surrounding shells are each assigned an intensity value that is a percentage of the inner shell's value. Any shells that have values that fall below the minimum threshold (4) are dropped. This means that not all cells may have three shells.

The maximum diameter of the each shell (cell width) is determined by computing an offset from the cell location point. This offset is a heuristic derived by taking a fixed percentage of the distance from the maximum reflectivity height to the cell top height-the assumption being that the width of a storm bears some relationships to its height. For the outermost shell the percentage is 100% so that the top of the shell corresponds with the top of the storm cell. The offset for each of the other shells is a proportionally lesser percentage. The bottom for each shell is similarly computed from the difference between the cell base height and the maximum reflectivity height. Table 3 gives the offsets for each of the three shells computed for the Storm Model Product.

The shape of a shell is initially modeled by computing a sphere with the shell top height as its diameter. The equator of the sphere is set to ground level. At each of the predefined flight levels (2 Kft to 60 Kft in 2 Kft increments), the circle that intersects the sphere defines the polygon boundary.

Most storm cells that last longer than 10 minutes will develop a tilt. Otherwise, the downdraft from the precipitation will interfere with the uplift that is feeding the storm and cause the cell to dissipate (see Figure 6). To model this tilt, a tilt-magnitude parameter is used to progressively offset the center of the polygons computed in the upper half of the range between the storm cell bottom and storm cell top. The current tilt setting is .02 degrees and is used for both latitude and longitude.

Figure 6 - Supercell Airflow (source: [2])

The downdraft from a storm cell can disturb the air, triggering the development of a new cell, whether or not the first cell dissipates. Figure 7 illustrates a cell with a defined tilt and an adjacent cell developing at its edge.

As storm cells dissipate and develop, the storm system moves in the direction of cell formation. The direction of movement may not be correlated with the wind direction. For this model, the storm track heading for a storm cell is assumed to be indicative of the leading edge of the cell. The offsets for shell tilt are calculated so that the tilt is in the direction of the storm track. No use is made of storm speed at this time. Figure 8 illustrates how the storm heading and the tilt magnitude are used to define the tilt for the top half of the cell models.

Figure 7 - Two Storm Cells (source: [2])

Figure 8 - Cell Tilt Computation

<< Return to Top

Cell Merging
Shells of the modeled cells may intersect shells of adjacent cells. When this happens, the intersecting shells are merged. The shells may in fact intersect at only one or two altitude levels, however all the polygons from all altitude levels are assigned the Object Id of one (arbitrarily chosen) of the shells and are thereafter treated as a single object.

Generally, due to the implicit separation of the storm centers, only the outermost shells will intersect with adjacent cells. This is consistent with observed NEXRAD data, where large, irregular regions of low intensity surround kernels of high intensity reflections.

Conclusion
Basically the model is one of idealized thunder storm cells based on storm structure and track data from two NEXRAD level III products. The model uses some heuristics, describe herein, to arrive at a plausible model of the weather that could produce the NEXRAD products. As the RUC data comes on-line it may prove useful in improving the future fidelity of the model.

[1] NWS Louisville, Structure and Dynamics of Supercell Thunderstorms, http://www.crh.noaa.gov/lmk/soo/docu/supercell.htm
[2] Pani, Eric A., Thunderstorm Structure and Evolution, PowerPoint Presentation, University of Louisiana at Monroe
[3] Wolfson, Marilyn, Terminal Transitional En Route Convective Weather Forecast, MIT Lincoln Laboratory Presentation, 26-May-2000

<< Return to Top

Thor Weather Scenario Server
The Thor Weather Server has the job of delivering the weather data in a weather scenario to any and all users of the data. Thor is message-based and listens at a well-known port for client connections. Client applications send a "subscribe" message to Thor, indicating interest in a particular weather product: wind, NEXRAD, visibility, etc. Thor acts as a sequencer: the weather data in a scenario is time-correlated, but may have differing update rates. For example, winds change every hour, whereas NEXRAD data changes every six minutes (nominally). When Thor receives a message to start the scenario, it starts keeping track of the weather products in the current scenario. When a weather product has an update (for NEXRAD, for example, at time zero and then every six minutes thereafter), Thor sends a notification message to each subscriber on that product. Upon receipt of the notification, a client may send a request for the data to Thor. Thor will send the weather data to the client in a reply message. A client may use Thor as a full data server, as merely a sequencer, or not at all, depending on its requirements. Documents describing the Thor server and its message catalog are available for download on this site.

Together, the Data Collection Subsystem, the Weather Scenario Generator and the Thor Weather Scenario Server constitute a complete architecture for delivering real-world, time-varying weather to flight deck, ground ATC, and other applications, in support of research into the integration of weather and traffic information.

Weather Related Links

• NEXRAD Radar Maps
• Aviation Weather Center
• National Center for Supercomputing Applications (NCSA)
  

<< Return to Top

<< Return to Top

Home | Activities | Implementations | Publications | Downloads | Contact Us | Site Map

Responsible officials: Walter Johnson & Vernol Battiste
Curator: Arik-Quang V. Dao

NASA Ames Research Center, Moffett Field, CA 94035-1000

NASA privacy policy

Section 508 compliance