![](media/image1.png){width="4.749305555555556in"
height="4.374305555555556in"}Draft

**Weather Scenario**

**Generator**

**User's Guide**

## 

Version 1.0

September, 2003

Prepared by

![](media/image2.png){width="4.145833333333333in"
height="0.2604166666666667in"}

For

**Human Information Processing Research Branch**

NASA Ames Research Center

Moffet Field, CA

Draft

**This page intentionally left blank**

**Table of Contents**

[1 Introduction 4](#introduction)

[2 Concept of Operations 4](#concept-of-operations)

[3 System Requirements 5](#system-requirements)

[4 Data Format 6](#data-format)

[4.1 Wx Data Archive 6](#wx-data-archive)

[4.2 Gridded Data 7](#gridded-data)

[4.3 Region Data 7](#region-data)

[5 Developing a Scenario 8](#developing-a-scenario)

[5.1 Starting the Scenario Generator
8](#starting-the-scenario-generator)

[5.2 Select Scenario Dates 9](#select-scenario-dates)

[5.2.1 Change Button 9](#change-button)

[5.2.2 Map Browse Button 9](#map-browse-button)

[5.2.3 Wx Search Button 10](#wx-search-button)

[5.2.4 Wx View Button 11](#wx-view-button)

[5.3 Select Products 12](#select-products)

[5.4 Select Product Settings 13](#select-product-settings)

[5.4.1 Bounding Box 13](#bounding-box)

[5.4.2 Resolution 14](#resolution)

[5.4.3 Scale Factors 16](#scale-factors)

[5.4.4 Translate/Rotate 16](#translaterotate)

[5.4.5 Weather Streams 17](#weather-streams)

[5.4.6 Update Rates 18](#update-rates)

[5.5 Generate 19](#generate)

[Appendix A - Weather Streams 22](#__RefHeading___Toc52869126)

[Appendix B -- Interim Support for Scenario Winds
23](#appendix-b-interim-support-for-scenario-winds)

[B.1.0 Introduction 23](#b.1.0-introduction)

[B.2.0 System Requirements 23](#b.2.0-system-requirements)

[B.3.0 Components 23](#b.3.0-components)

[B.4.0 Usage 24](#b.4.0-usage)

[B.5.0 Recommendations 26](#b.5.0-recommendations)

# Introduction

The Weather (Wx) Scenario Generator is one component of the weather data
delivery architecture illustrated in Figure 1.1. The Wx Scenario
Generator converts real-world weather data into *weather scenarios* that
are subsequently used by the Thor Wx server (a separate application).
This document described the configuration and use of the Wx Scenario
Generator only. The Wx Data Collection subsystem, the Thor Wx server,
and the byte-level format of the scenario files are described in
separate documents.

![](media/image3.jpeg){width="6.125694444444444in"
height="2.8131944444444446in"}

*Figure 1.1 -- Weather Delivery Architecture*

# Concept of Operations

This section describes the concept of operations for the Wx Scenario
Generator. The Scenario Generator is a stand-alone application that
reads Wx data from an archive, processes it into a standard format and
writes a *Wx Scenario file* for subsequent use by the Thor Wx Server.
The Scenario Generator provides a wizard-like GUI that allows the user
to specify the weather products to be included in the weather scenario,
and to set the clipping region, scaling, resolution, and other
parameters of the data.

A *weather scenario* is a collection of time-correlated weather data,
consisting of products such as winds, visibility, NEXRAD reflectivity
and so on. All the products in the scenario are time-correlated in that
the first record for each product represents the state of the product at
the same instant in time (this is the start of the scenario, referred to
herein as the first time step). Some products have different update
rates in the real-world. Wind data, for example, which comes from the
RUC model, is updated every hour, whereas NEXRAD reflectivity data is
updated every six minutes. The wx scenario includes a "manifest" file
called the *scenario descriptor file* that indicates which products are
included in the scenario and what update rates to use for each product.
As seen in Figure 2.1-1 a scenario will consist of the descriptor file
and one or more wx product files.

![](media/image4.png){width="5.749305555555556in"
height="3.5215277777777776in"}

*Figure 2.1-1 Wx Scenario Contents*

In the figure, files for three products are shown: NEXRAD, with a 6
minute update rate; Winds, with an hourly update rate; and Visibility,
also with an hourly update rate. The product files themselves do not
contain any rate information. The rate information is in the scenario
descriptor file--an ASCII XML file that may be easily edited to alter
the update rates for the products to suit simulation requirements. Note
that if the ratio of the update rates is varied (e.g. NEXRAD/ Winds =
10/1) the weather data will be out of sync.

The Scenario Generator reads data from an archive where it is deposited
by the Wx Collection subsystem (described in a separate document). The
generator formats the data into the correlated files and creates the
scenario descriptor file. It is the formatting of the data that is at
the heart of the generation process. During formatting, the data may be
converted from raster to vector, or may be scaled, translated or
rotated, depending on the weather product being formatted. Through the
scenario generator GUI, the user has a good deal of control over these
transforms as will be described in the following sections.

# System Requirements

The Wx Scenario Generator server runs as a Win32 MFC application. As it
is dynamically linked, it requires that the MFC library be installed on
the host on which it runs. The Wx Scenario Generator has been tested on
Windows 2000 and Windows XP. Generation can consume quite a few
resources; the following are the recommended minimums:

-   2 GHz CPU

-   1 GByte RAM

-   100 MByte disk space

-   DVD drive for reading Wx archives on DVD

-   Network connection for reading Wx archives on shared drive.

# Data Format

This section describes the data models involved in scenario generation.
This is primarily background material and may be useful in understanding
the later sections of this guide.

## Wx Data Archive

The weather data archive is the repository of raw weather data as
collected from the public internet sites of the National Weather
Service. This data is collected from multiple sites, since no one site
archives all the data of possible interest. As the data is retrieved
from the NOAA sites, it is stored in a hierarchical directory structure
that reflects and preserves the date and time of its creation. This
structure differs from the structure use on the NOAA sites and is
designed to facilitate time-and-date navigation by the Wx Scenario
Generator.

![](media/image5.png){width="2.438888888888889in"
height="4.043055555555555in"}

*Figure 4.1-1 Wx Archive Directory Structure*

Figure 4.1-1 illustrates the Wx Archive directory structure. The path:
"Wx Archive \\ 2003 \\ 0503 \\ CY.00" contains Wx data for 03-May-2003
at 12:00 AM (cycle 0). CY.01 contains data for the next cycle, one hour
later. Under each hour, there is a folder for type of Wx data. Data
products that have update cycle of less than an hour have subfolders
below the product folder. For example, the NEXRAD folder contains
subfolders for each six-minute sub-cycle (see Fig. 4.1-2), with each
subfolder having a subfolder for every NEXRAD site for which data was
collected.

![](media/image6.png){width="2.0854166666666667in"
height="2.354861111111111in"}

*Figure 4.1-2 Subfolders within the NEXRAD Folder*

The data files included in the Wx Archive folders are the weather
product files downloaded from the NWS portal. The files for different
products originate from different organizations and systems and so have
different, specialized formats. The Wx Scenario Generator contains
decoders for each file type. However, when a scenario is generated, all
product files are written in one of two standard formats: *Gridded* and
*Region*.

## Gridded Data

The Grid Record Format is used for products that can be represented by a
grid of points at a defined altitude level, such as wind, pressure and
temperature. Each point has an associated value. Gridded products are in
two parts. The first is a file containing a grid of latitude and
longitude values. This grid defines the geographic points at which the
values for the weather product are defined.

The second part of the gridded product consists of a set of values that
map to the points in the grid. The idea is that the grid need be sent or
read only once. As the weather is updated, the values mapped to the grid
points may change, but the values of the grid itself will not. The
record layout is described in detail in a separate document: *Thor Wx
File Format.doc*.

## Region Data

The Region Record Format (RRF) is used for products that can be
represented by a polygonal region in space (2-D, at a fixed altitude)
with an associated value. Examples are Pressure contours, Icing,
lightning and turbulence hazard areas, and NEXRAD precipitation areas.
Each record in a Region Record Formatted (RRF) file begins with two
long-words. The first contains the timestep number (0 to the last step
in the scenario); the second contains the length in bytes of the data
that follows in the record. The record consists of one or more polygons
with an associated value and altitude level, and optionally, some
associated text. The record layout is described in detail in a separate
document: *Thor Wx File Format.doc*.

# Developing a Scenario

The Weather Scenario Generator generates weather scenarios for the Thor
Weather Server. It accesses the Ames Weather Archives and allows the
user to specify the weather products and other parameters to be included
in the generated weather scenario. The generation process is
wizard-like, in that each step of the workflow is driven by a separate
dialog window; clicking the Next button on the window moves to the next
step in the generation process. Clicking the Back button moves to the
previous step. The Cancel button stops the generation and exits the
Scenario Generator application. The major steps in generating a weather
scenario are shown below in Figure 5-1.

![](media/image7.png){width="6.343055555555556in" height="1.0625in"}

*Figure 5-1 Steps in Generating Wx Scenario*

Each of these steps has an associated primary dialog window. Subordinate
dialog windows may be available from the primary window where needed to
facilitate data entry. The details of each step are covered in the
following sections.

## Starting the Scenario Generator

The Wx Scenario Generator is a Window\'s application that is typically
run by double clicking its associated icon (see Figure 5.1-1). The
start-up screen should appear (Fig. 5.1-2), giving the option of
canceling (ending the application), displaying help, or continuing to
Scenario Generation (the Next button).

![](media/image8.jpeg){width="0.3333333333333333in"
height="0.3333333333333333in"}

*Figure 5.1-1 Wx Scenario Generator Icon*

The "help" for the application is implemented as an HTML file that
covers much of the same material as in the following sections. Clicking
the *Help* button will open a browser loaded with the HTML file.
Hyperlinks in the file allow navigating from topic to topic.

![](media/image9.jpeg){width="3.65625in" height="2.8333333333333335in"}

*Figure 5.1-2 WxGenerator Start-up Dialog Window*

## Select Scenario Dates

![](media/image10.png){width="4.166666666666667in"
height="0.7083333333333334in"}Weather data in the Wx Archive is stored
in temporal order. Selection of the weather to be included in the
generated scenario is done by indicating the start date/time and the end
date/time for the scenario. The actual date and time are not carried
into the generated scenario; they are just a convenient method to index
the weather in the archive. The scenario is always played back as
"current" weather in the scenario.

Clicking the *Next* button on start up screen opens the \"Select Dates\"
dialog window (Fig. 5.2-1) which allows you to select the start and end
dates for the scenario. The dialog window provides some functions to aid
in locating interesting weather within the Wx Archive.

### Change Button

The *Change* button at the top of the window lets you change the weather
archive that the scenario generator uses as a source for its weather
data. The default archive is the one normally used, but may be changed
for special purposes, such as testing a new version of the software.

### Map Browse Button

The *Map Browse* button opens the Map Browsing dialog window. This
window displays a graphic weather map associated with the time and date
in the Scenario Start Time field. The map depicts predicted
precipitation at the indicated hour. The *Prev Hour* and *Next Hour*
buttons allow you to navigate back and forward an hour at a time within
the weather data archive. When interesting weather is found, you can use
the *Set as Start* or *Set as Stop* buttons to set the scenario start or
end time to the time of the map. Clicking the *OK* button will close the
window and retain your changes, while clicking *Cancel* will close the
window and discard your changes.

![](media/image11.jpeg){width="4.185416666666667in" height="3.01875in"}

*Figure 5.2-1 Select Scenario Dates Dialog Window*

### Wx Search Button

Clicking the *Wx Search* button opens the Weather Search dialog window.
This dialog allows you to search through the weather archive for
particular weather conditions.

![](media/image12.jpeg){width="5.040972222222222in"
height="3.986111111111111in"}

*Figure 5.2.3-1 Weather Search Window*

The search results will be the first found date and time where the
weather data in the archive matches the weather characteristics entered
on the search page. The *Set as Start* button can be used to set the
start time of the scenario to the time found by the search, or the *View
Wx Map* button can be used to bring up the weather map display and
navigate backwards and forwards through the weather data around the
search result time.

The Wx search uses METAR reports in the weather archive to locate
periods of specific weather at certain geographic locations. The search
parameters that can be entered are based on the fields in the METAR
report, which basically reflects observed weather conditions at the
surface around the reporting site--usually an airport. The fields on the
search page are:

-   *Search From* - the date/time to start searching from. The search
    will continue until a match is found, or the data archive is
    exhausted.

-   *Search Forward/Search Backward* - allows specifying whether to
    search forward or backward in time through the weather archive.

-   *Any All of* - with this setting you indicate whether you wish to
    find weather that matches all of your selected precipitation types,
    or that matches any of your selected types. That is, if you select
    rain and thunderstorms, selecting \"Any\" will find matches on rain,
    thunderstorms, and rain with thunderstorms. Selecting \"All\" will
    only find matches on rain with thunderstorms.

-   *Heavy* - this is a qualifier on the precipitation or obscuration
    level. If selected, you will get matches only if at least one of the
    precipitation or obscuration phenomenons is heavy.

-   *Freezing* - this is a qualifier on precipitation. Selecting this
    qualifier means that you will only get matches only if at least one
    of the selected precipitation types is freezing (i.e. freezing
    rain).

-   *Precipitation* - these are the weather phenomena that the archive
    will be searched for.

-   *Other* - these are other obscuration phenomena that the archive
    will be searched for.

-   *Reporting Site Locations* - you can select one or more reporting
    sites. You must select at least one. These are selected METAR sites,
    laid out in a rough grid across the continental U.S. Selecting a
    subset of the sites allows you to restrict your search to a broad
    geographical area.

### Wx View Button

Clicking the *Wx View* button opens the Wx View window (Fig. 5.2.4-1).
This window allows you to visualize the actual data held in the weather
archive. The check boxes allow you to select what to display on the map.
The *Prev Hour* and *Next Hour* buttons allow you to navigate back and
forward an hour at a time within the weather data archive. If data
corresponding to a checked box is found in the archive, it will be
displayed graphically on the map. If data has not been collected for the
requested period, a message will be displayed on the map. This
distinguishes between periods or which no data is available and periods
having no weather to display.

![](media/image13.jpeg){width="5.919444444444444in"
height="4.206944444444445in"}

*Figure 5.2.4-1 Weather View Dialog Window*

Checking the *airports* option will display a fixed set of airports for
use as reference points. The set of NEXRAD sites for which data is
available, if any, may be displayed by checking the *Nexrad Sites* box.
Both are displayed as icons. Double clicking an icon will open a small
dialog window providing information about the site or airport.

The *Set as Start* or *Set as Stop* buttons will set the scenario start
or end time to the time of the map. Clicking the *OK* button will close
the window and retain your changes, while clicking *Cancel* will close
the window and discard your changes.

## Select Products

![](media/image14.png){width="4.75in" height="0.8048611111111111in"}The
Select Products dialog window (Fig. 5.3-1) allows you to select the
weather products that will be included in the scenario.

![](media/image15.png){width="4.445833333333334in"
height="3.2527777777777778in"}

*Figure 5.3-1 Select Products Dialog Window*

Note that the Text and Radar products are observational and therefore do
not have a forecast component. The other weather products are model
outputs. Their Current, Actual and Forecast *weather stream* (see
Appendix A) can be independently specified.

The **Select All** button will select every item on the page. Only the
selected items will be included in the scenario.

## Select Product Settings

![](media/image16.png){width="4.916666666666667in"
height="0.8465277777777778in"}On the Product Settings dialog window,
there are a number of tabbed forms that allow you to enter various
parameters that affect the contents of the scenario.

### Bounding Box

The Bounding Box form (Fig. 5.4.1-1) allows you to limit the data
contained in the scenario files to weather within a roughly rectangular
region. By default, weather data for all of the continental U.S. is
included. You can specify a bounding box in one of three ways:

-   Enter the lat/long corners of the region directly into the
    appropriate field.

-   Select a region graphically from a map by clicking the **Pick from
    Map** button. This button will bring up a map window, on which you
    can select a region using the mouse. Clicking the **OK** button on
    the map window will result in the lat/long values for the corners
    selected on the map being entered into the fields in the bounding
    box form.

-   Click the **All CONUS** or **DFW Center Area** to select one of the
    pre-defined bounding boxes. The **All CONUS** button fills the
    bounding box fields with values that span the continental U.S. while
    the **DFW Center Area** button enters the values for a rectangle of
    about 1291 Km East-West by 790 Km North-South (or 802 by 491 miles),
    encompassing the coverage area for a set of seven NEXRAD sites
    centered around the Dallas-Fort Worth area.

![](media/image17.jpeg){width="3.6875in" height="2.8340277777777776in"}

*Figure 5.4.1-1 Bounding Box Dialog Window*

### Resolution

On the Resolution form (Fig. 5.4.2-1) you can select the relative
resolution for the two major classes of weather data. The main reason
for reducing the resolution is to make the scenario files (and
subsequently served weather messages) smaller.

#### Grid Resolution

Most of the weather products are outputs from a weather model and are
samples on a rectangular grid. The nominal grid resolution is 40Km
between samples. This corresponds to the High setting. If this level of
resolution is not required, the grid can be re-sampled at 80 or 120Km.
These correspond to the Medium and Low settings.

#### ![](media/image18.jpeg){width="3.84375in" height="3.0416666666666665in"} {#section-1 .unnumbered}

*Figure 5.4.2-1 Resolution Form*

#### Region Resolution

The radar products are represented as sets of edges, defining polygonal
regions. Some of the gridded products are converted to a region
representation as well. The resolution slider determines how accurately
the polygons represent the underlying grid data. At a setting of 1,
every point in the grid is used to compute the polygons. This could
result in a large number of small polygons. At higher settings, fewer
points are used, resulting in hopefully fewer and larger polygons. For
specular data (like NEXRAD) the larger polygons may actually be a more
accurate representation of the real weather than those generated at
ostensibly higher resolutions.

#### NEXRAD Forward Sampling

Forward Sampling is an option where data from future time steps is
incorporated into each NEXRAD time step. This is essentially a sliding
window where, for example, a time step t1 will consist of data from t1,
t2 and t3, or t1 = (t1, t2 t3). The next time step, t2 will be t2 = (t2,
t3, t4) and t3 = (t3, t4, t5), and so on. The idea is to use multiple
samples to make up for the sparseness of the NEXRAD data. The **Enable**
check box enables forward sampling when checked. The number of future
time steps to include with each time step is specified by entering a
value from 1 to 10 into the **Steps to look ahead** field.

#### Low-resolution NEXRAD

The low-resolution NEXRAD product is designed to reduce the number of
polygons while still providing an accurate representation of the NEXRAD
data. The parameters allow you to reduce the polygon count:

-   By specifying a lesser number of intensity levels (3 or 5). By
    default, NEXRAD has 15 intensity levels. When a lesser number is
    selected, the intensity regions are consolidated so that all
    intensities below a level and above the next-lower level are folded
    into the upper level.

-   By specifying a horizon in kilometers for how close two regions have
    to be before they are merged into a single region. Specifying a zero
    horizon means that the regions must actually intersect.

#### Storm Model Parameters

The Storm Model Parameters allow setting values that affect the way the
Scenario Generator models storm cells for the Storm Model Wx product.

-   Cell Max Radius sets the distance in miles from the storm cell
    center of the outermost intensity shell.

-   Cell Min Refl. Cutoff sets the minimum reflectivity value (0-15) for
    a cell to be included in the product. Cells with a maximum
    reflectivity below this cutoff are discarded.

-   Cell Smoothing is a factor (1-10) used to make the cells less
    concave. Cells only become concave when they are merged with
    adjacent cells.

The Merge Horizon setting also applies to the storm model.

### Scale Factors

The Scale Factors dialog is where you would adjust the parameters of the
data. The only currently supported parameter is the intensity. When
applied to NEXRAD, this allows scaling up the intensity of the
reflectivity.

![](media/image19.jpeg){width="3.8027777777777776in"
height="2.9791666666666665in"}

Figure 5.3.3-1 Scale Factors Form

### Translate/Rotate

The Translate/Rotate form (Fig. 5.4.4-1) allows the weather in the
scenario region to be shifted geographically.

![](media/image20.jpeg){width="3.872916666666667in" height="2.96875in"}

*Figure 5.4.4-1 Translation / Rotation Form*

You enter the latitude and longitude offset, in degrees, by which you
would like the scenario to be shifted, and the scenario will be shifted
by that amount. You may also enter a rotation angle, in degrees. The
scenario will be rotated clockwise by that amount. Scenario translation
is primarily effective when used with scenarios centered over the plain
states. Scenarios centered over mountain regions will lack low-altitude
weather data when shifted to mountain-less regions, because there will
be no measurements from sea-level to the altitude of the mountain peaks.

### Weather Streams

For forecast weather, a scenario may contain any of three parallel
streams of weather data: the current weather, the forecast weather and
the experienced or actual weather. This provides for simulations
involving forecast weather, and allows for actual weather (experienced
or out-the-window) to be separate from the current weather (measured or
last reported). See Appendix A for a detailed description of Weather
Streams.

The Weather Streams form (Fig. 5.4.5-1) allows selecting which outputs
from the weather model are to be used for each of the weather streams.

![](media/image21.jpeg){width="3.71875in" height="2.84375in"}

*Figure 5.4.5-1 Weather Streams Form*

Normally, the Forecast stream will be either the two-hour or the
three-hour forecast, depending on how much deviation from the current
and actual weather is desired. The current and actual weather will
usually be either the one-hour forecast or analysis output; which is
used for which largely being a matter of personal preference.

### Update Rates

The Update Rate form (Fig 5.4.6-1) allows changing the update rates of
the weather products. The update rate for a product is the rate at which
updates to the product become available or are published. The source for
the most of the weather products is the RUC model, so its update rate is
the update rate for all the products not otherwise listed on the form.

![](media/image22.png){width="4.082638888888889in"
height="3.217361111111111in"}

*Figure 5.4.6-1 Update Rate Form*

The default rates can be reset by clicking the Reset button. These rates
correspond to the actual rates at which the National Weather Service
produces updates. Because the scenario generator is accessing archived
data, different update rates can be simulated.

The playback rate indicates that the scenario as a whole should be run
at some multiple of its normal rate. The update rates of the products
relative to each other remain unchanged.

## Generate

![](media/image23.png){width="4.833333333333333in"
height="0.8333333333333334in"}The final step in the process is to
generate the scenario, resulting in the creation of a *scenario
descriptor file* and files for each of the weather products selected for
inclusion in the scenario.

The scenario must be given a name. The name should include no white
space characters, and be legal for use as a file name, because the
scenario name will be used as the file name for the scenario descriptor
file. A destination path may also be provided. This will be the location
to which all of the generated files will be written.

By default, the scenario files are written in the byte order used by the
native platform (Windows PC). This is the byte ordering required by the
Thor weather server. Checking the \"Write Files in Network Byte Order\"
checkbox will force the files to be written in the standard Network Byte
Order. This makes it easy for non-native system to know what, if any,
byte order conversion must be made to read the files. If the files are
to be read directly by a UNIX system, you might want to use network byte
order.

The three buttons at the bottom of the dialog (see Fig. 5.5-1) have the
following functions:

-   **Back** - of course, moves you to the previous screen.

-   **Exit** - exits the Wx Generator, but saves your inputs and
    settings so that they are available the next time you run the
    Generator.

-   **Cancel** - exits the Wx Generator and does not save your settings.

Settings are saved in an XML file written to the directory from which
the generator is run. They can be hand-edited if desired, or copied and
saved for archival purposes. The file name for the saved (and later,
read) settings file must be *WxGenSettings.xml.* This file is
automatically read, and the settings applied, when the Scenario
Generator starts.

.![](media/image24.jpeg){width="4.364583333333333in"
height="3.084722222222222in"}

*Figure 5.5-1 Generate Scenario Dialog Window*

Once the parameters are entered on the Generate window, the **Generate**
button may be clicked to begin the scenario generation. A Generation
Report window will be displayed (Fig 5.5-2) containing status
information as the generation proceeds. When the status window indicates
that the scenario generation is complete, the window may be closed. The
**Save** button on the status window will be enabled when generation is
complete; clicking the button will open a dialog window for saving the
status log to a file.

![](media/image25.jpeg){width="4.696527777777778in"
height="3.4965277777777777in"}

*Figure 5.5-2 Generation Log Window*

A generated scenario consists of a scenario descriptor file and a set of
product files. The scenario descriptor file is an XML file that contains
an entry for each of the product files in the scenario, and information
about how to serve the product data. The descriptor file will have a
name of the format: \<*scenario name*\>.xml. The data files will have
names of the format: \<*scenario name*\>\_\<*product name*\>.dat.

For example, if the name entered on the Scenario Name field was
"Wx18MARCY00_NBO" and a storm model product was included in the
scenario, the scenario descriptor file would be: Wx18MARCY00_NBO.xml and
the storm model data file would be: Wx18MARCY00_NBO_nxStormModel.dat.

A sample scenario descriptor file is shown below:

> \<?xml version=\'1.0\'?\>
>
> \<SCENARIO_DESCRIPTION\>
>
> \<SCENARIO_ID\>Wx23AUGCY02_NBO\</SCENARIO_ID\>
>
> \<PLAY_RATE\>5\</PLAY_RATE\>
>
> \<BYTE_ORDER\>NETWORK\</BYTE_ORDER\>
>
> \<PRODUCT\>
>
> \<PRODUCT_NAME\>NXSTORMMODEL\</PRODUCT_NAME\>
>
> \<UPDATE_DELAY\>60\</UPDATE_DELAY\>
>
> \<FILE_PATH\>C:\\Wx23AUGCY02_NBO_nxStormModel.dat\</FILE_PATH\>
>
> \<FILE_TYPE\>REGION\</FILE_TYPE\>
>
> \</PRODUCT\>
>
> \</SCENARIO_DESCRIPTION\>

In this file, the scenario Id is Wx23AUGCY02_NBO following a convention
where the Id is named for the date of the weather, with a tag (NBO)
indicating network byte ordering. The play rate is five, indicating that
the weather should be served at five times the normal rate. The byte
order is "NETWORK", indicating that the data files are in network byte
order; for Intel byte order the value would be "HOST".

The file contains a "PRODUCT" section for every weather product included
in the scenario. The example scenario contains one product:
NXSTORMMODEL. The file fields indicate that the product data is in file
C:\\Wx23AUGCY02_NBO_nxStormModel.dat, and that it is region data. The
records in the data file are snapshots of the data at different times.
The update delay field indicates the period in seconds between the
snapshots--in this case, 60 seconds. Note that with a play rate of 5,
the effective update rate for the data file is 12 seconds (60/5 = 12).

The scenario descriptor file is designed to be used by the Thor Weather
Server. XML was chosen for the file format because its human-readability
facilitates manual inspection or editing of the scenario.

[]{#__RefHeading___Toc52869126 .anchor}***Appendix A - Weather
Streams***

The Weather Scenario Generator builds scenarios containing weather data
in three separate and parallel weather streams: *forecast*, *actual* and
*current*. Each stream can potentially contain the same weather
products, representing some weather characteristic at some time. Only
the meaning of the data in the weather stream differs (see Table A-1).

Table A-1 Notional Wx Streams

  ----------- -----------------------------------------------------------
  **Wx        **Notional Meaning**
  Stream**    

  Forecast    The forecasted weather. This represents the Wx data that
              would be presented to a pilot or controller as a forecast.

  Current     The current weather. This represents the Wx data that would
              be presented to a pilot or controller as current
              conditions, based on last-taken measurements.

  Actual      The actual or experienced weather. This represents the
              weather that the pilot or controller would experience in
              the cockpit or by looking out the window.
  ----------- -----------------------------------------------------------

The Forecast, Current and Actual weather are expected to differ due to
Wx model inaccuracies and measurement time lags. The Wx streams are
called "streams" because the Wx data changes over time and--depending
upon the scenario--is periodically updated. Note that these are notional
data streams. The data that is actually available is one of the products
derived by the RUC model.

The RUC-20 model provides an Analysis (nowcast) and forecasts in 1-hour
increments out to 12 hours. The Wx Scenario Generator allows one of
these forecasts to be assigned to any (or all) of the notional Wx
streams. The assignments may represent, for the simulation, the amount
of error desired between the real weather and the forecast. For example:
assigning the 1-hour forecast to the Current stream and the 2-hour
forecast to the Forecast stream will have less error than assigning the
3-hour forecast to the Forecast stream. It is also possible to assign
the same forecast (say, 1-hour) to both the Current and Forecast streams
to simulate zero error.

## Appendix B -- Interim Support for Scenario Winds {#appendix-b-interim-support-for-scenario-winds .unnumbered}

###  {#section-2 .unnumbered}

### B.1.0 Introduction {#b.1.0-introduction .unnumbered}

### B.2.0 System Requirements {#b.2.0-system-requirements .unnumbered}

The following hardware is required for this system:

A Pentium-III or higher Windows XP workstation

A Sun workstation running Solaris 5 or higher

Network connections for both machines

The following software is needed:

An installation of Perl 5.2 or higher on the Solaris system

An installation of Active State Perl 5.6 on the Windows workstation

An working instance of the CTAS weather data processing daemon (WDPD)

An instance of an ARTCC-level adaptation data set for CTAS for the area
of interest

A working instance of the CDTI weather utility

software on the Windows workstation

The following data is needed:

A well-formed RUC GRiB data file for the period of interest

A wdpd_site_info file in the wthr_data directory of the adaptation set
modified for the source and destination directories for weather data,
and the latitude/longitude coordinates of the corners of the area of
interest. This must be a rectangular area inside the bounds of the RUC
model, which for practical purposes can be considered to cover CONUS.

### B.3.0 Components {#b.3.0-components .unnumbered}

#### B.3.1 Existing Windows-Based Components {#b.3.1-existing-windows-based-components .unnumbered}

The program BinToPCPlane.exe converts the information in a CTAS binary
wind file to a text based format that is useable by CDTI. This file is
based on the files used for input of weather by the PCPlane product.

#### B.3.2 Existing Sun-Based Components {#b.3.2-existing-sun-based-components .unnumbered}

The CTAS weather data processing daemon (wdpd) takes raw GRiB files and
extracts wind, temperature and pressure data for an area of interest.
The data is then processed into polynomial interpolation coefficients
and written out to a binary data file. This file is used by a number of
simulation tools for wind direction and magnitude inputs, including PAS
and CTAS.

#### B.3.3 Windows-Based Script Scripts {#b.3.3-windows-based-script-scripts .unnumbered}

A Perl script that wraps BinToPCPlane.exe so it can be used to execute
multiple instances of the program to process multiple files, and to
control the output and file names

#### B.3.4 Sun-Based Support Scripts {#b.3.4-sun-based-support-scripts .unnumbered}

The command line interface to the wdpd is complex and error prone. In
addition, the name of the output file is hard coded and not related to
the input file. Each time the program is used, it will overwrite the
output binary file. A perl script has been written to simplify this
process.

### B.4.0 Usage {#b.4.0-usage .unnumbered}

#### B.4.1 Setup {#b.4.1-setup .unnumbered}

##### B.4.1.1 CTAS software {#b.4.1.1-ctas-software .unnumbered}

A compiled version of the CTAS wdpd program must be available, and
reside in its typical place in the CTAS directory structure. This should
be:

\[top level dir\]/realtime_procs/wthr_data_proc_daemon

A working CTAS adaptation data set for the center of interest should
reside in its typical place it the CTAS hierarchy. This should be:

\[top level dir\]/adapatation/\[adaptation data set\]

A wdpd_site_info file must be under the CTAS adaptation directory for
the center of interest, in the directory:

\[top level dir\]/adapatation/\[adaptation data set\]/wthr_data

The wdpd_site_info file should be modified to reflect the directory
structure for the wdpd to use during it's processing. There are a great
number of data elements in the file, some of which are important
constant data, and some are settings for obsolete functions in the wdpd.
These must not be modified or the results of this process me be
undefined.

The following data items must be modified in the file. They are
key/value pairs, so the second value must be modified. The paths
themselves do not affect the running of the wdpd in its standalone mode,
but an existing directory must be specified for the program to execute.

**Wthr_aquisition_rendezvous_file** \[existing directory\]

**Cm_rendezvous_file** \[existing directory\]

**Wthr_bin_file_directory** \[an existing directory\]

If desired, the size of the rectangle representing the area of interest
can be changed. The values shown here are representative for extracting
an area that contains the ZFW ARTCC. It is the area most widely used for
the wdpd.

The only other area known to have been tested extensively is a rectangle
encompassing the ZDV ARTCC. Other areas may work, or there may be
unknown issues with the data or algorithms. The RUC data in the GRiB
data files covers an area roughly encompassing CONUS. If an area of
interest lies near the boundaries of CONUS, care should be taken.

If an area of interest that partially within and partially outside the
boundaries the RUC data, the data outside the boundary should degrade
smoothly and gradually to standard atmosphere values. If the entire
region of interest chosen lies outside of the RUC data set, the results
may be unpredictable. The only partially in/out areas known to have been
tested are areas extending off the Atlantic coast of South Florida, and
areas extending off the Pacific Coast of Southern California. The
results were useable, but fidelity was low.

It is also possible that unexpected behaviors may occur if the area of
interest is significantly larger or smaller than these values. The
ZDV-encompassing rectangle used was perhaps 20% larger than the ZFW
area. So there is very little experience with areas significantly
smaller than the ZFW area, or significantly larger than the ZDV area.

Finally there is no known data on comparisons between values extracted
from two overlapping areas of interest. In other words, the wind values
at two identical latitude longitude points that are part of two
different but overlapping data sets may diverge, and this divergence may
vary with the conditions in each data set.

The rule *caveat emptor* most definitely applies here.

With those caveats in mind, the following key/value pairs contain the
latitude and longitude of the southwest and northeast corners of the
area of interest. These values are given in degrees east longitude.

> **\# The following four lines define the site area: longitudes in deg.
> East**
>
> **GRIB_site_sw_lat 28.0**
>
> **GRIB_site_sw_lon -108.0**
>
> **GRIB_site_ne_lat 40.0**
>
> **GRIB_site_ne_lon -88**

There is another value in the file, **GRIB_site_lon_0**. This value has
to do with the coordinate system of the GRiB file itself, and should NOT
be modified.

##### B.4.1.2 Data {#b.4.1.2-data .unnumbered}

One or more GRiB formatted RUC data files are expected to have been
aquired. The current Wx Data Collection system acquires GRiB formatted
files containing the output of the RUC weather model from the National
Weather service, and is intended to be the primary source for the GRiB
files for the processing described here. However, the acquisition of the
data is completely decoupled from the processing described here.

This GRiB file must be placed in the same directory as the wdpd
executable and the wdpd_dag.pl Perl script.

#### B.4.2 Sun-Based Processing {#b.4.2-sun-based-processing .unnumbered}

The binary weather data file is created by running the perl script and
giving it the name of the RUC file:

**wdpd_dag.pl fh.0001_tl.press_gr.us40km**

The output of this process will be a file named:

**fh_0001_tl.press_gr_us40km.bin**

Notice that the "." in the filename have been translated to "\_" so that
Windows can make use of a well formed file extension. This file will be
in the same directory as the wdpd executable. This file can be used
as-is by CTAS and by processes that use CTAS-format binary wind data
files.

#### B.4.3 Windows-Based Processing {#b.4.3-windows-based-processing .unnumbered}

In order to process the binary file for use by CDTI, a copy of the
binary data file must be moved from the Sun system to the directory
containing the binary-file-to-PCPlane-conversion utility. Once the file
is in that directory, the following command is run from a DOS command
line

**BinToPCPLane \[binary wind file\] \[PCPlane-format output file\]**

This will convert the binary wind file to a PCPlane-format text file,
usable by programs that can ingest that format, notably CDTI.

### B.5.0 Recommendations {#b.5.0-recommendations .unnumbered}

This process is only intended as a near term work-around to allow all
users in a simulation scenario to use the same source for wind data. It
allows all CTAS-format file users and PCPlane format file users to base
their data on the same GRiB formatted file of RUC data. It is
recommended that all users implement the standard wind file formats
created by the Wx Scenario Generator so that this cumbersome process can
be eliminated.