The primary data in this archive are held in files with the extension ".APF.TXT". APF stands for "ASCII ProFile". Each such file is an ASCII file holding data for a given profile of the storm during one aircraft pass. 'Pass' here refers to either an inward or outward radius, not a complete pass through the storm center.
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, 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 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, and the bin extends 2.0 km on each side of the nominal bin radius. 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*2. 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.
Starting with the 1996 season, there is a new type of file, with extension ".APF2.TXT", that is strictly parallel to the APF file. We archive 4 new variables: radar altitude, pressure altitude, storm latitude and storm longitude. A given APF2 file is strictly parallel to the APF file with the same short name (i.e., the same name exclusive of the extension). Thus, necessarily, there is the same number of APF2 files as APF files, for a given storm. You can simply ignore the APF2 files if you do not use these variables.
These same 4 variables, in the same order, are placed at the right-hand end of each line in the RPFL file; if you are not interested in using these, you don't need to change your software, because a FORTRAN free-format READ statement will ignore them.
The data held in all the APF files for a single storm are also
held in a single file with the extension ".RPFL.TXT" - 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 APF 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
There are other files associated with this archive, of which the index files (with extensions of ".IDX.TXT") 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 day, month 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.
One or more track files (files holding spline coefficients, with the extension of ".TRK.TXT" 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.TXT". 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.
These are azimuthally-averaged files instead of individual pressure profiles. There are labels at the top of each ".PCMP.TXT" file. Data are tabulated (in almost all cases) at half-km intervals, starting from 0.5 km (i.e. not at zero). There are a few cases (Arthur of where the radial interval is 1 km. Data represent "pup" tent averages in bins that extended 1 km on either side of the tabulated radius.
The first three columns represent the geopotential height of standard pressure surface. The first column is the bin-mean height itself, the second is the standard deviation of observations from the bin average, and the third is the number of observations in the bin.
The fourth through tenth bins represent the winds. Columns four and five are the radial component of the wind (positive outward) and its bin standard deviation. Columns six and seven are the tangential component of the wind (positive cyclonic) and its bin standard deviation. Columns eight and nine are the total wind speed and its standard deviation. Column ten is the number of wind observations in each bin. Columns eleven and twelve were designed to hold the aircraft radar altitude, but they are disused.
There are always 299 rows of data. If DR is 0.5 km the radii range from 0.5 to 149.5 km. If DR is 1 km they range from 1 km to 299 km. Missing data are indicated with no-data flags -99.9 or -9.9, depending upon the data format.
At the bottom is a list of meta data, which is self explanatory for the most part. One key item is DR in the third row of metadata. It specifies the size of the averaging window and hence the interval at which the data are tabulated. If DR = 1, radii are 0.5 1.0 1.5 ... 149.0 149.5 km. If DR = 2, radii are 1.0, 2.0 3.0 ... 298 299 km. Arthur of 1984 is an example of the latter averaging interval.
Note that there is exactly ONE zerotime for an entire storm, and 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.
The only exceptions to this are the local IDX, CTR, and TRK files, which are placed in the MISC subdirectory and so are out of sight and irrelevant to you.
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.
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.
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.TXT 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.
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.
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 on the FTP site 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 Bill Barry.
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.
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. Since Ed's death, no more pass data has been processed awaiting the assignment of someone to this task.