An Explanation of the Hurricane Research Division
             Archive of Post-Season Processed Hurricane Data
                         Written by Ed Rahn

The primary data in this archive are held in files with the extension ".APF",
standing for "ASCII ProFile". Each such file is just what the name implies -
an ASCII file holding data that give a profile of the storm during one aircraft
pass. This is a single pass, either inward or outward, not a complete
penetration. The APF file contains 299 data lines (no header) with explanatory
text at the bottom of the file. Each line contains data for one radius. The
variables contained, reading from left to right, are time (in seconds relative
to a
zerotime, defined as 0000Z on the morning of a starting day, month and year)
aircraft latitude and longitude, ZP (height in meters of a standard pressure
surface), radial, tangential and vertical winds (in meters per sec.),
temperature and dewpoint (degrees Celcius) and liquid water content (grams
per kilogram). Vertical wind and liquid water are missing from data sets
taken by Air Force aircraft, since the data systems on board these aircraft
are unable to measure them.

All the data in the APF files are integers, with implied decimal points -
the position of the decimal point for each variable is given in the text at
the bottom of the file.

All these data are expressed as functions of distance from the storm center.
The original data are functions of time - one second data are the inputs to the
analysis, except for the special case of Air Force data, which will be
explained below. A track, in the form of beta splines, is fit to the storm 
motion, and the data are recomputed and averaged as functions of distance from
the (moving) storm center. Data are lumped into 300 "bins", which are actually
imaginary rings concentric to the storm center. The width of bins, and their
spacing, are controlled by the quantity DR, the half-width of a bin. The bins
are 1/2 DR apart, meaning that there is considerable overlap of bins, and a
single one second datum will be averaged into several bins, although with
variable weighting. If DR is 1.0 (kilometers) the total bin width is 2.0,
the nominal bin radius (from the storm center) increases by 0.5 km from one
bin to the next, the closest bin is 0.5 km from the center, and the farthest,
150 km. However, due to a miscalculation during the writing of the original
software, which for consistency we were forced to propagate through later
versions of the code, the outermost bin is always empty. For this reason,
the last bin is not included in any .APF file; that is why the real total
number of bins is the conspicuously non-round number of 299.

All data are weighted as they are placed in bins; the weighting decreases
linearly from 1.0 for a datum at exactly the nominal bin radius, to 0.0 at
exactly plus or minus DR. After all the data for a pass has been placed in
bins, the data in each bin is normalized: the sum of the data is divided by
the sum of the weighting factors.

The data we receive from the Air Force are ten-second averages. Interpolation
is performed to convert this into one-second data, which are then input into
the analysis as if they were one-second data originally.

The data held in all the APF files for a single storm are also held in a
single file with the extension ".RPFL" - standing for Real ProFiLe. The data
is in ASCII coded real numbers with explicit decimal points, with more
significant figures for most variables than the APF files. As a result, each
data line is 95 characters long. The APF files are more convenient to work
with, (only 80 characters per line maximim) but the RPFL files are more
accurate. Each data line in an RPFL file has the same variables in the same
order as an AFL file, except that the bin number is absent. The structure of
the file is as follows: The first 4 lines are headers giving data for the
whole storm; the storm name, starting data (the 3rd line holds the date as
integer month day and year at the start of the line, which is thus readable
by  a simple FORTRAN list-directed READ) and value of DR. Then for each
profile in the storm there are a blank line, 4 header lines giving information
for that profile, and 299 data lines. For a storm with N profiles the total
number of lines is 4 + (N * (1 + 4 + 299)).

There are other files associated with this archive, of which the index files
(with extensions of .IDX) are the most important. There is one IDX file for
each storm. Each IDX file contains in the first line the number of profiles
(ie., the number of .APF files), the number of flights, the value of DR for
the storm (there is always only ONE value of DR for a storm - when there is
not, the storm must be split into "logical" storms) and the starting day in
integer month, day and year. Succeeding lines hold data on each flight: the
flight ID, the global pass numbers of the first and last passes for that
flight, and the standard pressure for the flight. There is a final line
holding the storm name as used in this archive, which always includes the
year in two digit form. For example, Hurricane Zachary of 1992 is designated
ZACHARY92. Since the archive begins with 1977, we can continue with two
digits to designate the year until 2077, at which time we will have to go to
four digits, for example AARON2077. Stay tuned for this :-)

There is also one .NDX file for each storm. It is like the .IDX file
except that there is one line of data per profile, rather than one per flight.
The IDX file is pretty much necessary to use the archive, and the .NDX file,
while not indispensible, contains some very useful summary information.

There is only one starting date for an entire storm - meaning all the times
in seconds in all APF, RPFL, TRK and POS files for a storm are all relative to
the same zero time. There is no hard and fast rule determining the starting
date  - it is simply whatever is convenient for the processing, and is not
necessarily the starting date assigned by the National Hurricane Center.

A flight ID contains the date of the flight; the next character is an
alphabetic character designating the aircraft (H for NOAA42, I for NOAA43 and
U for any Air Force aircraft) and there is a final numeral to indicate which
flight during that day this flight is, if the aircraft (or any aircraft for
the Air Force) flew more than once during that day. Thus, if a flight is the
fourth for the Air Force on Feb. 29, 1992, the flight ID will be 920229U4.
However, there is a slight complication here - if there is a change in altitude
during the flight, the flight may have to be split into two (or very rarely,
three) logical flights, which can add one more character at the end; thus the
flight ID can be up to 9 characters long.

One or more track files (files holding spline coefficients, with the extension
of ".TRK" at the end) are necessary for the processing of data. The spline
coefficients describe the motion of the storm center - this is necessary
information to place data in bins, since the bins move with the storm. The
spline coefficients are necessary if users of this archive wish to translate
the winds (which are storm-relative) into Earth-relative winds. The simplest
case is that in which there is one global track file which was used to process
all flights in a storm - i.e., one track file that covers the entire period
during which aircraft were flying the storm.

For the convenience of users of this archive, there are also files with the
extension ".POS". A POS file holds a list of positions and velocities for the
storm center; each POS file is calculated using the spline coefficients from
the TRK file with the corresponding name. All TRK files are calculated by
fitting splines to a set of centers and as a matter of good form, the center
file from which each TRK file was generated is included in the archive.

In summary: In the simplest case, for each storm there will be one CTR file
holding all the centers used for final processing, one TRK file generated
from this file, one POS file generated using the TRK file, and one IDX file
that contains information useful for interpreting the data. These files will
have names identical except for the extensions.

Life however, is not always simple. For some storms in which flights were at
different altitudes, there is more than one track; for example, one track for
processing of flights at 700mb and another for flights at 850mb. Other storms
have been divided into two or more logical flights, with separate CTR, TRK,
POS and IDX files for each. In several cases, especially those of the earlier
storms, due to misunderstandings, disk crashes, or whatever, some files have
not been preserved. Some TRK files, and a few CTR files, are re-creations of the
originals, which have been lost. In such cases, there is explanatory text at
the end of the files. For a storm in which the simplest case does not apply,
there is a README.ASCII file in the individual storm subdirectory, explaining
the circumstances.

By the way, since there is explanatory text at the end of APF, TRK and CTR
files, a program reading one of these cannot simply read until the end-of-file
is detected, it must know where the end of the data is. An APF file has 299
data lines; the structure of the following text is fixed - consult any APF
file if you need to know what it is. A CTR file has data lines until -9999.90
appears as an end-of-data marker. The zerotime appears in the fourth line
after this, in integer month, day and year. The structure of the TRK file is
variable. There is one line at the beginning holding the number of splines,
the start and end times (seconds relative to the zerotime) and the time
interval per spline. There are at least two lines for the latitude
coefficients, and two lines for the longitude coefficients; if the spline
number is 11 to 15, there are three lines each, if the spline number is 16 to
20 (20 is the maximum allowed) there are four lines each. The explanatory
text has the same format as for CTR files; the zerotime is held in the
fourth line after the end of the data.

Some of the storm subdirectories have further subdirectories called .MISC.
These hold data used during processing, but which are of absolutely no use
to you. Ignore them. There is a subdirectory (directly below the one you are
now in) called .CODE which has FORTRAN code that may be of use to you in
working with the data in this archive. The file reading subroutines at least
may be of interest, and we will have graphical routines to display the
data available in the not too distant future. If you have questions about the
code or the data in the archive, send them to Ed Rahn (rahn@aoml.noaa.gov)
We have tried to check this archive for errors as thoroughly as possible,
but if you notice any that have slipped by us, we would appreciate hearing
from you.

There are also graphical radar composites in existence for many of the storms
in this archive, but they are not included in it as of this time. A great deal
of work needs to be done to translate these into a standard graphical format.
We hope to have them available here in the near future.

At the moment, all the files in the entire archive are ASCII.

                         Acknowledgements

The project of post-season analysis of storms is the brainchild of Dr. Hugh
E. Willoughby, who has supervised the project during its entire lifetime. The
early software development was done by Hugh Willoughby, Marcy Chelmow and
Jeanne Clos. William Patrick Barry made later additions to the software, and
Ed Rahn has done most of the software development since the late Eighties.
The track fitting is done using beta splines developed by Dr. Katsuyuki V.
Ooyama.

For the first few years Hugh Willoughby did the actual data processing. Ed
Rahn took over this in early 1987, and has processed several of the storms
dating from before that time.