GLOBAL TROPOSPHERIC EXPERIMENT

Data Archive Format

GTE Project Office

  Mail Stop 483

  National Aeronautics and Space Administration

  Langley Research Center Hampton, VA 23681-2199

Data Archive Format

August, 2000

Prepared by
Dennis W. Owen
Revised by Ali A. Aknan¹ and A. Don Scott² In Partial Fulfillment of NAS1-19570
¹Science Applications International Corporation
²NASA Langley Research Center Chemistry & Dynamics Branch

GTE DATA ARCHIVE FORMAT

Table of Contents

I. GENERAL INSTRUCTIONS AND RATIONALE

The data format described herein is designed to provide a file structure that effectively utilizes computer storage media for the exchange of data for scientific analysis. Recognizing that the variety of GTE measurement techniques span a large dynamic data range, every attempt has been made to meet the needs of scientists that generate either large or small data sets. The GTE Data Archive Format is intended to satisfy both the data archive and data exchange requirements of the GTE field expeditions.

I.A. SUITABLE MEDIA

Files must be in ASCII. All data should be numeric, separated by commas. Each aircraft PI shall submit a minimum of one file per flight. Whenever possible, data shall be submitted to the GTE Data Archive via electronic transfer. Suitable media include File Transfer Protocol (FTP), electronic mail (E-mail), and IBM-compatible diskettes (3.5" High Density preferable). The file size should be compatible with the submitting media limitations. Therefore, if the ASCII file size is greater than 1.44 mb, it should either be compressed before being submitted on 3.5" disks, or it should be submitted via FTP or E-mail. If data are compressed using non-standard compression software, either the un-compressing programs must be included with the data, or the data should be in executable form (.EXE file extension). Large files can be most easily accommodated via electronic submissions directly into the GTE Archives (Refer to Section V. FTP Protocol for GTE Data Exchange). As mediums of data exchange are constantly being upgraded and amended, and as new mediums of exchange introduced, the GTE Data Archive Office will continue to upgrade and change its data exchange processes when feasible. Any medium of exchange differing from those mentioned in this document should be approved by the GTE Data Archive Office prior to data submittal.

A file containing header records in the GTE Data Archive format shall be submitted with each mission data set. The file shall describe the data submitted, how to locate and access it, and the data file structure. See Section I.B. Common File Structure for more information and guidance on constructing the file.

The requirement to submit files of header records to describe both the data and data access procedures applies also to hardcopy submittals..

I.B. COMMON FILE STRUCTURE

A GTE Archive file is composed of two sections: a HEADER SECTION, which contains all the information with which to process the file; and the DATA SECTION, which contains the data in the prescribed GTE Data Archive format. The file naming convention, header and data format descriptions are detailed in Section 2 of this document.

In order to facilitate the exchange of data among the GTE investigators and the scientific community at large, the GTE format requires that all datasets be referenced by time. Time data is composed of the Julian day of the year and the seconds of the day, both referenced to Greenwich Mean Time (GMT). When a reporting period extends past GMT midnight (86,400 seconds), increment the Julian day of year and reset the time to zero. See Section II.C Dataset Types for an explanation of the different time reporting options.

Aircraft PI's should submit a file for each aircraft mission. If no data are submitted to the archive for a particular mission, the PI shall in any case submit a file containing the Header section of the GTE Data Archive format. The PI shall use comment records to explain the reasons no data are provided for the mission. The requirement to submit files of header records to describe both the data and data access procedures applies also to hardcopy submittals.

II. HEADER RECORD FORMAT

This section contains a detailed description of the format for each header record. The header records should supply all information needed to read and interpret the data records. Even if the actual data are not included in the file, the header records should include the parameters as noted and information needed to identify and locate the data files.

II.A. Definition of Header Records

Each line of the header section is reserved for specific information. These headers will be scanned by computer programs; therefore, all data must be in the format as described in order to be correctly interpreted. The following sections define each line of the Header Record Format.

Line 1. Number of Lines in the Header (NH)

The first line in the header contains the number of lines in the header section (NH). The first line of data = NH + 1.

Line 2. File Name:

The second line in the header contains the name of the dataset file. The data file naming convention for the GTE is as follows:

PPTTTLXX.EXP where:

PP = 2-character code identifying PI. See Table-1 for appropriate code.

TTT = 3-character code identifying data set or instrument technique.

L = Location code: 'D' for DC-8 aircraft, 'P' for P3-B, 'E' for Electra aircraft. Codes for other locations will be provided by the GTE Project Office.

XX = 2-digit numeric mission descriptor . For a flight, XX = flight number; for ground-based data, this may be a sample number or day identifier.

EXP = Expedition Code. See Table-2 for appropriate code.

NOTE: For aircraft investigators, each landing constitutes a new flight. Flights are named by integer numbers only (i.e. there can not be a flight named 21A or 21.1). If there are several flights on a day, each flight will receive a separate numeric identifier.

Examples follow:

DU_SUD01.PWB = Drexel University sulfur data for DC-8 Flight 1, for the PEM West-B Expedition (Replace any unused code letters with an underline "_")

POM10D05.TRA = Project Navigational/Meteorological 10-second data for DC-8 Flight 5, for the TRACE-A Expedition

Line 3. Principal Investigator

Line 3 contains the PI Last Name, First Name, and Institution. Always separate items by commas.

Line 4. Species Measured / Technique Used.

Line 4 contains a brief summary of the species measured and the method employed for this sampling. For example, nonmethane hydrocarbons should be entered here rather than listing each species. Use only one line.

Line 5. Expedition Name

The Official name for this expedition. Please refer to Table-2 for Expedition Names and their abbreviations.

Line 6. Data Start Date, Date Last Revised (YY,MM,DD,YY,MM,DD)

Line 6 contains two dates. Report the start date for this dataset, followed by the date of last revision, both in the format YY,MM,DD

Line 7. Number for this Flight, or Sequential Dataset Number (NF)

Line 7 contains a unique number for this dataset (NF). For aircraft datasets, this number is the number for this flight. For ground-based datasets, this is usually a sequential number starting at "01" for the first dataset submitted.

Line 8. Number of Variables Reported in this Dataset (NV)

For most standard datasets, the number of variables remains constant for each line in the dataset (Dataset Types 1, 2, 4 and 6). In those cases, NV = number of variables for each dataset submitted. Several dataset types are defined which include a matrix of data whose dimensions may vary between dataset records. For these datasets, the matrix variable is considered as a single variable and is always the last variable reported in the list. The variable or variables immediately proceeding the dimensioned variable will contain the number of elements in the matrix. In these cases, NV = number of unique variables for each record in the dataset, with the matrix being considered as a single variable. Refer to Header Sample Descriptions 3 and 5 for a complete explanation and examples of this variable.

Line 9. Number of Comments (NC)

Line 9 contains the number of comment lines included in the header for this dataset. Comment lines should include any pertinent information needed to help the scientific community correctly interpret the dataset, such as accuracy, precision and limits of detection of the instrument (where applicable). Listing a point of contact is encouraged.

Both precision and accuracy contribute to total uncertainty. In general, precision refers to the random component of total uncertainty, while accuracy refers to any systematic errors. Precision can be statistically determined and is often referred to as "noise"; whereas, accuracy is often a more subjective judgement typically associated with potential errors in calibration standards or methods.

Where applicable, a lower and upper limit of detection for an instrument should be provided for each parameter measured.

Line 10. Dataset Type (DT)

The GTE Data Archive Format currently supports seven (7) Dataset Types, numbered from 0 to 6. The seven Dataset Types are:

Data Type = 0 : Non-standard reporting of time of samples.

Data Type = 1 : Standard reporting of time as the midpoint of a standard averaging period.

Data Type = 2 : Standard reporting of time as start, stop, and midpoint of a non-standard averaging period.

Data Type = 3 : Vertical Column Sample. Non-standard sampling using a variable number of sampling points in the sample.

Data Type = 4 : Vertical Column Sample. Standard submission for sonde data.

Data Type = 5 : Gridded Dataset. Submission standards for mapping products such as the AVHRR Fire Counts maps.

Data Type = 6 : Trajectory Dataset. Trajectory data follows a particular air parcel over a finite period of time and records values at regular intervals over the period.

Refer to Section II.C. Dataset Types for a complete description and examples of the seven dataset types.

Line 11. Data Averaging Period

Refer to Section III.A. Time Reference.

Line 12. Data Sampling Frequency (Hertz)

Enter the instrument sampling frequency, in hertz. Data recorded at 1 sample/second = 1 Hz; 5 samples/second = 5 Hz; 1 sample every 5 seconds = 0.2 Hz.; 1 sample / minute = 1/60 = 0.0167 Hz. Enter "0" here for instruments having non-standard sampling periods. For Data Type = 6, replace this variable with the number of Samples per Trajectory.

Lines 13 thru Line 13+NV-1 contain the definition of variables used in the dataset as described in section II.B.

II.B. DATA VARIABLE DEFINITION

Each variable is defined on a separate line in the Header. Each variable definition is composed of a minimum of eight (8) parameters, separated by commas. The eight required parameters are:

Variable Name, Units, ScaleFactor, Offset, Minimum, Maximum, Null Code, LOD Code

If Limits of Detection (LOD's) are used in the dataset, then an additional four parameters are added to the end of the above definition line:

Lower LOD Code, Lower LOD Value, Upper LOD Code, Upper LOD Value

Variable Definition in the Header:

Item 1. Variable Name: Name of Data Variable. (Time, Day, Chemical Species, etc..)

Item 2. Units: Units of Data Variable.

Item 3. ScaleFactor: Scale Factor (Gain) of Data Variable.

Item 4. Offset: Offset of Data Variable.

Item 5. Minimum: This is the Reported Minimum Value found for this variable in the dataset (excluding Null and LOD codes), not an absolute minimum value that could be experienced for this variable. For TIME, use the first sample time reported in the dataset. The actual Minimum Value (Engineering Units)is computed using the ScaleFactor and Offset given for the variable, such that :

Minimum Value (Engineering Units) = Reported Minimum Value * ScaleFactor + Offset

Item 6. Maximum: This is the Reported Maximum Value (Engineering Units) found for this variable in the dataset (excluding Null and LOD codes), not an absolute maximum value that could be experienced for this variable. For TIME, use the last sample time reported in the dataset. The actual Maximum Value (Engineering Units) is computed using the ScaleFactor and Offset given for the variable, such that :

Maximum Value (Engineering Units) = Reported Maximum Value * ScaleFactor + Offset

Item 7. Null Code: This code is used for missing or bad data. This code is composed of a series of negative nines (-9's) which will be outside the range of actual data or one digit larger when the actual Minimum Value is negative. No ScaleFactor and Offset are applied to this Code. The code reported here should be to the same number of significant digits as the actual archived Data Value.

NOTE: Scale factors and offsets are applied on ALL reported data, such that:

Data Value (Engineering Units) = ReportedData Value * ScaleFactor + Offset

This means that ScaleFactors and Offsets are first applied on the archived data to arrive at the true data value, in Engineering Units. It is preferable that data be submitted such that Scale Factors = 1 and Offsets = 0.

Example 1. Variable Name = Static Air Temp, Units = DegC, Scale Factor = 1.0, Offset = 0.0, Reported Maximum Value = 59.9, Reported Minimum Value = 8.5, LOD Code = 0 (see Item 8); therefore, variable definition:

Static Air Temp, DegC, 1.0, 0.0, 8.5, 59.9, -9.9, 0

NOTE: The Null Code is beyond the range of actual data.

Example 2. Variable Name = Static Air Temp, Units = DegC, Scale Factor = 1.0, Offset = 0.0, Reported Maximum Value = 59.9, Reported Minimum Value = -125.4, LOD Code = 0; therefore, variable definition:

Static Air Temp, DegC, 1.0, 0.0, -125.4, 59.9, -9999.9, 0

Example 3. Variable Name = Static Air Temp, Units = DegC, Scale Factor = 10.0, Offset = 0.0, Reported Maximum Value = 5.99, Reported Minimum Value =-12.54, LOD Code = 0; therefore, variable definition:

Static Air Temp, DegC, 10.0, 0.0, -12.54, 5.99, -9999.9, 0

NOTE: The Null Code is one digit larger than the Actual Data Minimum

(-12.54 *10.0 + 0.0 = -125.4).

Item 8. LOD Code : Acceptable values are 0, 1, or 2.

0 : There are no Limits of Detection given for this variable.

1 : The Limits of Detection for this variable are varying with time. Items 10 and 12 are pointers to variables in the dataset which contain the actual LOD Values for this variable. See Items 9-12 for further explanation of this code.

2 : The Limits of Detection for this Variable are constants. Items 10 and 12 contain the actual LOD Values for this variable.

Items 9-12 are used only when Limits of Detection are given (i.e., LOD Code = 1 or 2).

Item 9. Lower Limit of Detection Code (L_LOD Code) :

This code is used when Lower Limit of Detection for this variable is to be reported. This code is composed of a series of negative eights (-8's) which will be outside the range of actual data or one digit larger when the actual Minimum Value is negative. No ScaleFactor and Offset are applied to this Code. The code reported here should be to the same number of significant digits as the actual Reported Data Value.

Item 10 : Lower Limit of Detection Value (L_LOD Value)

If LOD Code = 1, L_LOD Value = Variable column number containing the actual L_LOD Values.

If LOD Code = 2, L_LOD Value = Actual Lower LOD Value.

Item 11 : Upper Limit of Detection Code (U_LOD Code) :

This code is used when Upper Limit of Detection for this variable is to be reported. This code is composed of a series of negative sevens (-7's) which will be outside the range of actual data or one digit larger when the actual Minimum Value is negative. No ScaleFactor and Offset are applied to this Code. The code reported here should be to the same number of significant digits as the actual Reported Data Value.

Item 12 : Upper Limit of Detection Value (U_LOD Value)

If LOD Code = 1, U_LOD Value = Variable column number containing the actual U_LOD Values.

If LOD Code = 2, U_LOD Value = Actual Upper LOD Value.

NOTE: Scale factors and offsets are applied on reported LOD Values, such that :

LOD Value (Engineering Units) = Reported LOD Value * ScaleFactor + Offset

Examples of LOD Codes:

LOD Code = 0

No LOD's for this variable.

LOD Code = 1

This code assumes the Limits of Detection for this flight were changing with time. Assume this is Var_3, and data reported has one significant digit, with Min = 2.1; Max = 155.8; Scale Factor = 1.0, and Offset = 0.0; the actual limits of detection values are stored in column 4 of this dataset. Therefore:

L_LOD Code = -8.8 (beyond the normal data range)

U_LOD Code = -7.7

L_LOD Value = 4. Var_4(t) contains the actual L_LOD Values when Var_3(t) = -8.8.

U_LOD Value = 4. Var_4(t) contains the actual U_LOD Values when the Var_3(t) = -7.7.

NOTE: when Var_3(t) contains real data, Var_4(t) should contain the Null Code (-9.9).

The variable definition in the Header:

Var_3's Name, Var_3's Units, 1.0, 0.0, 2.1, 155.8, -9.9, 1, -8.8, 4, -7.7, 4

Thus, if Var_3(t) contains L_LOD Code (-8.8), instrument has detected data below its lower limits of detection (L_LOD Value). Refer to Var_4(t) for actual L_LOD Value for this time period. If Var_3(t) contains U_LOD Code (-7.7), observed data are above the upper limits of the instrument (U_LOD Value). Refer to Var_4(t) for the actual U_LOD Value for this time period.

LOD Code = 2

This code assumes the Limits of Detection for this flight were constant. Assume this is Var_3, and data reported has one significant digit, with a Reported Min = 2.1; Max = 15.8; Scale Factor = 10.0, Offset = 0.0; Reported Lower limits of detection = 1.5; and Upper limits of detection = 20. Therefore,

L_LOD Code = -8.8 (beyond the normal data range)

U_LOD Code = -7.7

L_LOD Value = 1.5.

U_LOD Value = 20.

The variable definition in the Header:

Var_3's Name, Var_3's Units, 10.0, 0.0, 2.1, 15.8, -9.9, 2, -8.8, 1.5, -7.7, 20.0

Thus, if Var_3(t) contains L_LOD Code (-8.8), instrument has detected data below its L_LOD Value. This L_LOD Value (15 = 10 * 1.5 + 0) is defined in the Header for this variable. Likewise, if Var_3 contains U_LOD Code (-7.7), instrument has detected data above its U_LOD Value. This U_LOD Value (200 = 10 * 20 + 0) is defined in the header for this variable.

Lines 13 thru 13+NV-1 in the Header:

Line 13. Definition of the First Variable in the Dataset : Var_1

This variable must be the Julian Day of the Year (GMT) when the sample were taken. If the samples span two days, this is the start day of the samples. A minimum of eight parameters are necessary for this Variable Definition. They are:

Variable Name, Units, Scale, Offset, Minimum, Maximum, Null Value, LOD Code

Line 14. Definition of the Second Variable in the Dataset : Var_2

The second variable must be time in seconds, GMT. For Data Type 1, this is the median time of the sampling period. For all other Data Types, this is the Start Time of the sample. (The start time will be null (-9's) in the case of data type 5). Refer to Section II.C for further explanation.

Line 15 Definition of the Third Variable in the Dataset : Var_3

Refer to the Header Sample Descriptions (Figures 0-6) for any standard definitions for this record.

Line 13+NV-1: Definition of the last variable in the dataset, Var_NV

Line 13+NV: First line of Comments.

This line contains the first line of comments for this header. If NC = 0, then there are no comment lines in the dataset.

Line 13+NV+NC-1: Last line of Comments.

This is the last line of comments for this header.

Line 13+NV+NC: First line of Data.

This is the first line of data for this dataset. This location is the same as Number of Lines in the Header (NH)+1 (Header line 1 defines NH)

II.C. DATASET TYPES (DT)

Data reporting frequency is a function of instrument response, data processing, and the temporal variability of the measured quantity. Some investigators sample at 1Hz or faster, while others employ measurement techniques that require several minutes to obtain a sample, such as grab samples. In order to facilitate the intercomparison of data and merging of data sets for scientific studies, the GTE Data Archive format provides standard reporting capabilities for instruments as diverse as fast-response chemical measurements, grab samples, and processed fire counts mapping from satellites. The GTE Data Archive Format currently supports seven (7) Standard Dataset Types, numbered from 0 to 6. This value is reported on line10 of the Header Record. A description of these parameters follows.

Sample Description 0.(DT = 0) : Non-standard Dataset, Non-constant time increment. Time reported as the sampling time. Report "0" in the 12th header record for sampling frequency (see Variable Interval Time Reporting). This dataset type should be used by experimenters who take samples at irregular time intervals. The first two variables must be:

Var(1) : Julian Day of the Year (GMT)

Var(2) : Time (Seconds GMT) - Time of sample.

Refer to Header Sample Description 0 [FIGURE-0] for an example of this dataset type.

Sample Description 1.(DT = 1) : Standard Dataset, Constant time increment. Time reported as the time of sample or midpoint of the averaging period. Time between 2 consecutive records must equal to the averaging period. If data is reported as collected, the averaging period should be the same as the sampling frequency. For example, if data was collected and reported at 2 Hz, the averaging period should be set to 0.5 and the sampling frequency to 2 (See Constant Interval Time Reporting for a discussion of midpoint reporting.) Most instruments using a constant time interval between samples can utilize this dataset type. The first two variables must be:

Var(1) : Julian Day of the Year (GMT)

Var(2) : Time (Seconds GMT) - Time of sample or Midpoint of Averaging Period. See Constant Interval Time Format section.

Refer to Header Sample Description 1 [FIGURE-1] for an example of this dataset type.

Sample Description 2.(DT=2) : Standard Grab Sample, Non-standard time increment. The sampling frequency and/or averaging period are non-constant (see Variable Interval Time Reporting). For non-constant sampling frequency, report "0" in the 12th header record. This dataset type should be used by experimenters who take and report samples at non-constant sampling times and periods. When reporting intervals are irregular, it is necessary to report the sample start time, end time, and the midpoint time for each record. The first four variables must be:

Var(1) : Julian Day of the Year (GMT) of the Sample Midpoint

Var(2) : Sample Start Time (Seconds of the Day, GMT)

Var(3) : Sample Stop Time (Seconds of the Day, GMT)

Var(4) : Sample Midpoint (Seconds of the Day, GMT)

Refer to Header Sample Description 2 [FIGURE-2] for an example of this dataset type.

Sample Description 3.(DT = 3) : Vertical Profile Sample, with a variable number of points in the sample. Variable "nv" defines the number of variables, with the last variable being an array dimensioned Var(nv). For example, if nv = 8, then variable 8 contains the number to dimension the profile array variable. The first two variables must be:

Var(1) : Julian Day of the Year (GMT) of the Sample Start Time

Var(2) : Sample Start Time (Seconds of the Day, GMT)

The final two variables must be:

Var(nv-1) : Number of profile data values for this sample

Var(nv) : Profile array, dimensioned Var(nv-1)

Refer to Header Sample Description 3 [FIGURE-3] for an example of this dataset type.

Sample Description 4. (DT = 4) : Vertical Profile Sample, Standard Sonde Data. This dataset type follows the example of DT 1, except that time is not constant. The first two variables must be:

Var(1) : Julian Day of the Year (GMT) of this altitude

Var(2) : Time of this altitude (Seconds of the Day, GMT)

Refer to Header Sample Description 4 [FIGURE-4] for an example of this dataset type.

Sample Description 5.(DT = 5) : Standard Gridded Data, Gridded Map Data. This dataset type is constructed to enable investigators to submit satellite data to the Archive, for example, AVHRR Fire Count data maps. It is assumed that these datasets are geographically rectified to a given latitude and longitude at a given time. This data type requires the following variables:

Var(1) : Start Julian Day of the Year (GMT)

Var(2) : Start Time of the Scan (Seconds, GMT)

Var(3) : Stop Julian Day of the Year (GMT)

Var(4) : Stop Time of the Scan (Seconds, GMT)

Var(5) : Start Latitude of the scan, Degrees North = positive

Var(6) : Start Longitude of the scan, Degrees East = positive

Var(7) : Latitude Increment , Degrees North . Add the Latitude Increment to the Start Latitude to find the second row of the scan. If the Latitude Increment is positive, scan is going from south to north; negative is north to south.

Var(8) : Longitude Increment, Degrees East. Add the Longitude Increment to the Start Longitude to find the second column of the scan. If the Longitude Increment is positive, the scan is going from west to east; negative is east to west.

Var(9) : Number of Rows of Latitude (NRows)

Var(10) : Number of Columns of Longitude (NCols) :

Var(11) : Pixel Data (NRows, NCols). The data is gridded by Latitude (NRows) and Longitude (NCols) and is presented as scan lines of longitude, one data record for each Latitude Increment. A simple decode program flow for the data scans follows:

DIM PixelData(NRows,NCols)

FOR i = 1 to NRows

' read in a line of data for a constant Latitude

For j = 1 to NCols

INPUT filenumber, PixelData(i , j)

NEXT j

NEXT i

The dimensioned variable PixelData will now contain the entire matrix of data for this image. Geographically rectify the image using the Start Latitude and Start Longitude and incrementing each correctly. Refer to Header Sample Description 5 [FIGURE-5] for an example of this type of dataset.

Sample Description 6.(DT = 6) : Standard Trajectory Dataset. Trajectory data report samples from a particular air parcel over a finite period of time. Each trajectory in the dataset must contain the same number of data points, defined by Header Line 12. The first data line contains data from the trajectory end point, corresponding to a selected aircraft time and position. Each following line is the trajectory's position on the previous time step. Time steps prior to the start time are all normalized according to the Data Averaging Period defined in Header Line 11. Refer to Header Sample Description 6 [FIGURE-6] for an example of this type of dataset.

III. DATA RECORD FORMAT

The Data Record section begins on line NH+1 (one line after the header). For each record, data should be reported in the sequence as stated in the Header Record. Each reported value in the dataset utilizes the scale factor and offset for that variable so that

Reported DataValue * ScaleFactor + Offset = Engineering Units

Only numeric values are acceptable as data for the standard archive data types. Please contact the GTE Data Management Office if your data cannot meet this criteria. It is preferable that data be reported in engineering units such that Scale Factors = 1 and Offsets = 0. If data is missing, or is above or below the Limits of Detection (LOD), use the appropriate code as stated in the variable definition for that variable in the header. These special codes should be entered exactly as stated in the Variable Definition Section so that computer programs can correctly determine validity. For example, if the null value is defined as -9.99 for a variable in the Variable Definition Section, that value should be used in the data for the null value. Scale factors and offsets are NOT applied to any codes in the data.

Note that uncertainties (e.g., ) associated with a given measurement may be included in the archive as a variable.

III.A. TIME REFERENCE

All data should be referenced to day of the year (Julian Day) and Greenwich Mean Time (GMT seconds of the day). When a reporting period extends past GMT midnight (86,400 seconds), increment the Julian day of year and reset the time to zero. Please refer to Section II.C. Dataset Types for a complete list of required variables for each dataset.

For DT2 files where START, STOP, and MID times are required and when time extends past GMT midnight (i.e., STOP time is greater than 86400), report STOP, and MID times without any resetting for this particular record. Thus, STOP and/or MID times could be greater than 86400. Then, JDAY for the next record should be incremented by one and START, STOP, and MID times resetted.

III.A.1. CONSTANT INTERVAL TIME AVERAGING REPORTING

Report the Data Averaging Period in the 11th header record. For a 10-second reporting interval, report data at 5-second time ticks; i.e., 5, 15, 25,... GMT seconds. Thus, the data value reported at 15 seconds represents the average value in the interval equal to or greater than 10 seconds and less than 20 seconds.

For 60-second data (1-minute averages), the reporting times should be at 30-second time ticks; i.e., 30, 90, 150,... GMT seconds. Thus, the data value reported at 90 seconds represents the average value in the interval equal to or greater than 60 seconds and less than 120 seconds. Data reported in 60-second time intervals would be reported in the same format as for 10-second reporting, except the data reporting interval in header record 12 would be 60.

For other constant time intervals, time ticks of the data reporting interval should be consistent with the 10-sec or 60-sec format.

III.A.2 VARIABLE INTERVAL TIME REPORTING

Report "0" for the Data Averaging Period in the 11th header record when reporting intervals are irregular.

1.SAMPLE DATA FILES

FIGURE-0: Header Sample Description 0 Non-standard Dataset: Non-constant Time Increment

FIGURE-1: Header Sample Description 1 Standard Dataset; Time at Midpoint

FIGURE 2 : Header Sample Description 2 Standard Grab Sample : Start/Stop/Midpoint Time

Figure 3: Header Sample Description 3 Vertical Column Sample : Variable Number Sampling Points (DIAL Datasets, etc.)

Figure 4: Header Sample Description 4 Vertical Column Sample : Standard Sonde Data (Ozonesondes, Rawinsondes, etc.)

Figure 5: Header Sample Description 5 Gridded Dataset (Fires Gridded data)

Figure 6: Header Sample Description 6 Trajectory Dataset (Isentropic and Isobaric Trajectory Data)

V. FTP Protocol for GTE Data Exchange

DATA ARCHIVE MEMO: FTP File Transfer to/from the GTE Archives

The GTE Data Archive datasets are now located on ANONYMOUS FTP site at www-air.larc.nasa.gov

located at NASA Langley and accessible 24 hours a day. The GTE Archive can also be accessed through the GTE Web site at http://www-gte.larc.nasa.gov (Data Archive link). Type the quoted (" ") commands to login and access the various on-line files. Note that you can now submit your data files via FTP. Follow the instructions given below to login and transfer files to/from the GTE Archives. NOTE: The proprietary archives (those not yet released to the public) are "password" protected from being read by the public. The protected data is accessible to the science team only using FTP protocol. Contact us at the E-mail address listed below for more information on accessing the protected data.

LOGGING ON TO THE GTE ARCHIVE

1) Access via FTP the GTE Archives computer "www-air.larc.nasa.gov". If this name is not on your host table, address the computer using the IP address of 128.155.54.94

2) Login using "anonymous" as your name.

3) Enter your actual E-mail address as your password. Note: your E-mail address will be logged and used to distribute any updates on the data that has been accessed.

4) "cd pub" to change directories to the public directory. (UNIX is case sensitive - use lower case for all commands. Our GTE main directories are in all caps, although subdirectories may be in either.

LOCATING THE GTE ARCHIVE FILES YOU WISH TO TRANSFER TO YOUR COMPUTER

5) Change to the directory of the GTE Expedition archive files of interest. For example, "cd PEMWESTA" or "cd ABLE3A"

6) "ls" to list the files and/or sub-directories in this directory. NOTE: The GTE Archives have the following long directory structure:

ftp/pub/Expedition/Sub-category/Investigator.Institution/Species/Files

PLEASE NOTE: not all Expeditions have "Sub-categories" and most Investigators do not have a "Species" sub-directory.

7) Assuming you changed directories to PEMWESTA, you can now change to the subdirectory of interest. For example, "cd dc-8/heikes.uri" will put you in the DC-8 aircraft subdirectory, and then to the investigator heikes.uri subdirectory. You can now access files in that subdirectory. FTP only allows you to retrieve files in one subdirectory at a time, thus type "cd .." to return to the parent directory if you desire to view the subdirectory containing files of another investigator.

TRANSFER COPIES OF THE FILES TO YOUR COMPUTER

8) Select the local drive and directory on your machine to receive the data. Useful commands:

"drive x:" to change the local drive to "x:"

"lcd xxxxx" to change the local directory to "xxxxx"

"ldir" to get a directory listing of the local drive

"help" to get a complete listing of the FTP commands on your machine. Your actual commands may differ slightly from these.

9) The command "mget *.*" will get all files in the subdirectory.

10) "cd .." to transfer to the parent directory: return to (7) to repeat the process

SENDING FILES TO THE GTE ARCHIVE USING FTP

To submit data to the Archive, you must have access to the "password" protected FTP site. Again, please contact us at the E-mail address listed below for more information to access this protected site. Assuming you have successfully logged on to the FTP site:

11) Change directories to "incoming" (path = pub/incoming). Useful change directory commands include: "cd .." to change to the parent directory and "cd /" to change to the root directory.

12) Change to the appropriate subdirectory: "cd TRACEA" to send GTE TRACE-A files.

13) Create a subdirectory for your files if one does not already exist. Use your name and institution to name the subdirectory. For example, "mkdir bradshaw.git" will create a subdirectory for files from the John Bradshaw investigation team of Georgia Tech.

14) Use the commands of (8) to go to your local drive and directory where the files to be transferred are stored.

15) Transfer the files to the "incoming" directory with one of the following commands:

"put filename" To transfer one file from your machine to "incoming". You will be prompted to enter the foreign file name.

"mput *.*" To transfer all files in your host directory and keep same names.

"mput gt*.* To transfer all files beginning with "gt" in your host directory.

16) Log off the system. "quit"

17) Contact the GTE Data Manager (use E-mail if possible) and describe the action you have taken. Provide a list of files transferred and the directory path on the FTP site that was used:

GTE Data Manager
email: gte+archive@larc.nasa.gov
phone: (757)864-4838
fax: (757)864-5841

*** END OF INFO ON FTP TRANSFER ***

GTEScan Software

All GTE data files must comply with GTE Format standards. PIs are encouraged to run GTEScan on their files prior to submitting them to the GTE Archive.

Download:

Download GTEScan.exe and GTEScan.hlp to your hard drive from the "password" protected FTP site. GTEScan runs in Win32 environment (Win95/98/NT/2000).

Usage:

This version scans GTE formatted files for data type 0, 1, 2, 3, and 4 -- it verifies data files as follows:

1) File Header for compliance with the GTE Format 2) Time Logic and continuity 3) Min Max checking 4) LOD Logic

Simply run GTEScan, select Open (1 or multi files)..., and program takes over. If no major errors found, GTEScan finds the actual Mins, Maxs; the correct codes for missing data and LODs; and by default, re-generates the file(s) to a directory "...\Output.gte\".

Help:

See "Topics" under Help menu item.

TABLE 1. Principal Investigator Codes

TABLE 2. GTE Expedition Codes