ADDENDUM

USER'S GUIDE FOR THE

AERMOD METEOROLOGICAL PREPROCESSOR

(AERMET)

(EPA-454/B-03-002, November 2004)

U.S. ENVIRONMENTAL PROTECTION AGENCY

Office of Air Quality Planning and Standards

Air Quality Assessment Division

Research Triangle Park, North Carolina 27711

June 2015
ii

PREFACE

This document provides updated user instructions for the AERMOD meteorological 

preprocessor program, AERMET, including modifications introduced with version 06341 and 

later. This addendum supplements and updates the information contained in the current 

AERMET User’s Guide (EPA, 2004).
iii

CONTENTS

1.0 INTRODUCTION...............................................................................................................1

1.1 OVERVIEW OF AERMET REVISIONS......................................................................1

2.0 USER INSTRUCTIONS ...................................................................................................12

2.1 STATION ELEVATIONS ............................................................................................12

2.2 UPPER AIR SOUNDING SELECTION......................................................................14

2.2.1 Adjusting the Default Sounding Window..................................................................16

2.2.2 Option to Select Sounding Based on Sunrise.............................................................17

2.3 PROCESSING OF ASOS DATA..................................................................................18

2.3.1 Use of 1-minute ASOS Wind Data............................................................................19

2.3.2 Threshold Wind Speed for 1-minute ASOS Winds....................................................21

2.3.3 Adjustment to Truncated ASOS Wind Speeds...........................................................22

2.3.4 Identifying ASOS Observations................................................................................23

2.3.5 Validation of NWS Surface Format by Active Date Range .......................................25

2.3.6 Validation of WBAN Between Stage 1 Control File and NWS Surface Data File......26

2.3.7 ASOS Cloud Cover from SCRAM and SAMSON Set to Missing .............................26

2.4 DEFINING THE ONSITE FILE STRUCTURE – READ AND FORMAT ...............27

2.5 SPECIFYING ONSITE MEASUREMENT HEIGHTS ..............................................32

2.6 SECONDARY SITE SURFACE CHARACTERISTICS ............................................33

2.7 REVISED SURFACE FILE FORMAT TO SUPPORT AERMOD DEPOSITION 

ALGORITHMS ............................................................................................................36

2.8 BETA OPTION FOR ADJUSTING USTAR UNDER LOW WIND/STABLE 

CONDITIONS...............................................................................................................37

2.9 SUBSTITUTIONS FOR MISSING CLOUD COVER AND TEMPERATURE ........38

3.0 REFERENCES..................................................................................................................41

APPENDIX A. FUNCTIONAL KEYWORD/PARAMETER REFERENCE.................. A-1

APPENDIX B. VARIABLE NAMES AND DEFAULT QA VALUES ..............................B-1

APPENDIX C. DATA FILE FORMATS........................................................................... C-1

APPENDIX D. FUNCTIONAL KEYWORD/PARAMETER REFERENCE.................. D-1
1

1.0 INTRODUCTION

This document provides user instructions for revisions to the AERMOD meteorological 

preprocessor program, AERMET. The discussion provided here supplements and updates the 

information contained in the current AERMET User’s Guide (EPA, 2004), and it is assumed that 

the reader is already familiar with the contents of that document. Note that portions of the 

current AERMET User’s Guide are no longer valid or applicable. This Addendum includes a 

complete updated reference of AERMET keywords and parameters in Appendix A.

1.1 OVERVIEW OF AERMET REVISIONS

Several sets of AERMET revisions are included in this Addendum:

1. The first set of revisions, introduced with version 06341 of AERMET, includes 

modifications to address several problems associated with extraction and processing 

of National Weather Service (NWS), Federal Aviation Administration (FAA), or 

other airport data in the Integrated Surface Hourly Data (a.k.a., ISHD, ISH, ISD, 

TD-3505) format; inclusion of an optional station elevation parameter on the 

LOCATION keyword for the UPPERAIR, SURFACE, ONSITE, and METPREP 

pathways; and modifications to use a single executable file, AERMET.EXE, to 

perform all three stages of processing, replacing the STAGE1N2.EXE and 

STAGE3.EXE files (additional information is provided in Model Change Bulletin 

(MCB) #1 provided on the SCRAM AERMET webpage); and

2. The second set of revisions, introduced with version 11059 of AERMET (additional 

information is provided in Model Change Bulletin (MCB) #2 provided on the 

SCRAM AERMET webpage), includes:

a. further enhancements to the use of user-specified station elevations for surface 

stations to substitute for missing station pressure; 

b. enhancements to increase the maximum record length for the runstream input 

file from 80 to 132 characters, increase the maximum field length for 

filenames from 48 to 96, and allow use of double quotes (“) as field delimiters 

for filenames to support filenames with embedded spaces; 

c. enhancements to the selection of upper air sounding to support applications of 

AERMOD beyond the U.S., and including an option to select the most 

appropriate sounding based on local sunrise; 
2

d. enhancement to allow the use of hourly averaged winds derived from 1-

minute ASOS wind data (TD-6405); 

e. adjustment of ASOS-based wind speeds (including winds derived from 1-

minute ASOS data) to account for reported ASOS wind speeds being 

truncated (rather than rounded) to whole knots; 

f. enhancements to the error handling and reporting related to processing 

ONSITE data, including an option to use ‘FREE’ format to read the data and 

the option to specify missing data codes and upper/lower bounds for ONSITE 

data as REAL variables; 

g. an option/requirement to specify a secondary set of surface characteristics for 

use when NWS winds are substituted for missing on-site winds; and

h. enhancements to utilize on-site precipitation and relative humidity data, if 

available.

3. The third set of revisions, introduced with version 12345 of AERMET (additional 

information is provided in Model Change Bulletin (MCB) #3 provided on the 

SCRAM AERMET webpage), includes:

a. Modified subroutine DOCLDS to correct for errors that result when blank 

spaces occur between the cloud cover and ceiling height fields for HUSWO 

surface data. Also modified DOCLDS to no longer accept invalid ASOS cloud 

cover codes for HUSWO surface data. These bug fixes should not affect 

results for HUSWO surface data that were extracted from the HUSWO CD, 

but could affect results significantly for applications using surface data that 

were reformatted to the HUSWO format from another data format;

b. Modified subroutine CBLHT to correct an error in the calculation of the 

convective mixing height. Previous versions of AERMET may have 

underestimated convective mixing heights, and in turn the convective velocity 

scale (w*), due to this error. The magnitude of the errors would tend to be 

larger for cases where the vertical temperature profile based on the upper air 

sounding was based on fewer sounding levels. However, due to the 

widespread nature of these convective mixing height errors, AERMOD 

modeling results are likely to be affected to some degree by this AERMET 

bug fix in most cases. The magnitude and direction of changes in AERMOD 

model results due to this convective mixing height bug fix will vary 

depending on the resolution of the upper air data and the characteristics of the 

sources and terrain included in the AERMOD model application;

c. Modified subroutines CBLHT, MPPBL, MPMET, and SETUP to check for 

ONSITE mixing heights (OSMIX) in the determination of data completeness, 

and adjusted warning messages to account for possible presence of both 

ONSITE mixing heights and UPPERAIR data;

d. Added a new THRESH_1MIN keyword to Stage 3 processing. This optional 

keyword allows the user to specify a threshold wind speed below which winds 
3

reported in the 1-minute ASOS data processed through AERMINUTE, if in 

use, are considered calm. There is no default value; however, a warning 

message will be generated if the user-specified threshold is greater than 0.5 

m/s, and a fatal error message will be generated if the user-specified threshold 

is less than zero or greater than 1.0;

e. Incorporated a new "BETA" option to adjust u* (ustar) for low wind speed 

stable conditions, based on Qian and Venkatram (2011). The new option is 

selected by including the METHOD STABLEBL ADJ_U* keyword on the 

METPREP pathway in the Stage 3 input file. The ADJ_U* "BETA" option is 

considered to be a non-Default option and is therefore subject to the 

alternative model provisions in Section 3.2 of Appendix W (40 CFR Part 51). 

Users should coordinate with the appropriate reviewing authority regarding 

the procedures and requirements for approval of this BETA option for 

regulatory modeling applications. Use of this option also requires the user to 

include the BETA option on the CO MODELOPT keyword in the AERMOD 

input file;

f. The value used to adjust ASOS wind speeds to account for bias due to wind 

speeds being truncated to whole knots was modified to include three 

significant digits (from 0.26 m/s to 0.257 m/s, based on 0.5 kt). This 

modification avoids potential for mischaracterization of calm vs. non-calm 

due to precision issues associated with the truncation adjustment under the 

new THRESH_1MIN option; and

g. Modified subroutine GETFSL to issue a non-fatal warning instead of a fatal 

error message when the UA station ID specified on the UA LOCATION 

keyword does not match the UA station ID in the data file. This change will 

accommodate substitutions for missing UA soundings using data from other 

representative UA stations, and will document when such substitutions were 

made in the Stage 1 report file. Since all convective hours will be missing on 

days when the UA sounding is missing, this will allow users to minimize the 

number of missing hours in the AERMET-processed surface file due to 

missing UA soundings, while maintaining a record of when such substitutions 

were made and identifying which alternative sites were used.

4. The fourth set of revisions, introduced with version 13350 of AERMET (additional 

information is provided in Model Change Bulletin (MCB) #4 provided on the 

SCRAM AERMET webpage), includes:

a. Modified subroutine UCALST to incorporate AECOM's recommended 

corrections to theta-star under the ADJ_U* Beta option;

b. Modified subroutine MPMET to correct assignment of time-zone adjustment 

(ZONE) to be based on the upper air time-zone (UALST) for cases where 

both upper-air data and ONSITE mixing heights are available;
4

c. Modified subroutine SBLHT to correct the coefficient for the mechanical

mixing height from 2300 to 2400 based on the original Venkatram reference 

(BLM, 2009);

d. Modified subroutine MPPBL to correct the initialization of the NO_SKY 

variable for missing on-site cloud cover to use the OSTSKY(2) value based on 

the missing data code input by the user, instead of a value of 99. This error 

could have resulted in on-site cloud cover being flagged as missing 

inappropriately in previous versions;

e. Modified subroutine O3NEXT to remove the conversion of delta-T values to 

lapse rate values (delta-T/delta-z) before calling subroutine REALQA, which 

compares the value to upper and lower bounds based on delta-T values. This

could have resulted in a large number of spurious QA warnings for delta-T 

values out-of-range;

f. Modified subroutine RDISHD to correct the processing of ASOS cloud cover 

data based on the GA1-GA6 codes to avoid inadvertently assigning a missing 

code to the ASKY variable. Also modified subroutine RDISHD to move the 

check for hour 0 (zero) later in the processing in order to avoid using a 

"special" ISHD observation that occurs on the hour instead of a "non-special" 

observation that occurs earlier;

g. Modified subroutine MPFIN to include additional error checking and 

reporting regarding the completeness of the surface characteristics arrays. 

Errors in processing user- specified surface characteristics (i.e., not generated 

by AERSURFACE) may have occurred in previous versions;

h. Modified several subroutines to allow the use of on-site mixing heights only 

(OSMIX), without requiring upper air data. In these cases, the LOCATION 

keyword on the METPREP pathway should be used to specify the time zone 

adjustment from local time to GMT, since the time zone specified on the 

ONSITE pathway is likely to be for local time. Otherwise, AERMET would 

assume GMT as local time and results would be incorrect (unless local time 

actually was GMT);

i. Modified subroutine MPPBL to correct the error message associated with 

missing station pressure (FORMAT 1022) which was also used for missing 

sky cover data. A new FORMAT statement (1021) was added for use with 

missing station pressure. Also removed several FORMAT statements in 

MPPBL that were not used.

j. Modified subroutine BULKRI to incorporate a modified Bulk Richardson 

Number approach under the ADJ_U* Beta option, based on Luhar and Rayner 

(2009). As with the ADJ_U* Beta option incorporated in UCALST for 

applications which do not employ the BULKRN option, this method is 

considered a non-DFAULT option requiring approval as an alternative model 

for use in regulatory applications.

k. Modified subroutines MPPBL, SUBST, VRCARD, and MPTEST to include 

substitutions for missing cloud cover data and/or missing ambient temperature 

by interpolating across 1 or 2-hour gaps in the input data. New subroutines 
5

(GETCCVR and GETTEMP) were also created to facilitate this enhancement. 

The default option is for AERMET to apply the substitution for both missing 

cloud cover and temperature, unless the user has specified both SURFACE 

and ONSITE data. New options have been added to the METHOD keyword 

on Stage 3 that allow the user to disable the cloud cover and/or temperature 

substitution(s) in cases where only SURFACE or ONSITE data are available, 

or to activate the options in cases where both SURFACE and ONSITE data 

are available. Subroutines MPMET and MPOUT were also modified to 

include appropriate flags in the surface output file indicating when these 

options have been utilized.

5. The fifth set of revisions, introduced with version 14136 of AERMET (additional 

information is provided in Model Change Bulletin (MCB) #5 provided on the 

SCRAM AERMET webpage), includes:

a. Modified subroutines SUBST and MPPBL to correct potential issues 

associated with the options introduced in version 13350 to substitute for 

missing cloud cover (CCVR) and/or temperature (TEMP) by linear 

interpolation across 1 or 2-hour gaps. This included an error that may have 

resulted in substituted CCVR values larger than 10 based on in and which 

may have resulted in NaN (“not a number”) for some calculated variables; 

Issues with CCVR substitutions may also have occurred for applications using 

ONSITE meteorological data only, with ONSITE net radiation (NRAD) or 

with solar radiation (INSO) and delta-T (DT01) data using the Bulk 

Richardson Number (BULKRN) option. In these cases AERMET calculates 

equivalent cloud cover values that are included in the surface output file, but 

no substitutions for missing values should be included; 

b. Modified subroutine SUBST to remove the initialization of the GOT_OSTMP 

logical variable to .FALSE. for the current hour. The GOT_OSTMP variable 

is assigned a value in subroutine GETTEMP prior to the call to subroutine 

SUBST. This error may have affected calculations of station pressure and 

relative humidity for applications with ONSITE data, including relative 

humidity values greater than 100 for applications with both SURFACE and 

ONSITE data;

c. Modified subroutine GETTEMP to reinitialize the LTZMAX4T variable to 

.TRUE. within the hour loop, indicating that the maximum height for ONSITE 

temperature had not been reached yet. The ONSITE temperature may have 

been incorrectly interpreted as being missing in version 13350 for some cases;

d. Modified subroutines GETTEMP and SUBST to ensure that substitutions for 

missing ONSITE temperature data are only based on values from the same 

measurement level if multiple levels of temperature are available.

e. Modified subroutine MPPBL to address issues associated with the selection of 

the appropriate upper air sounding time. This includes use the INT function 

instead of NINT when assigning ‘MyZone’ to determine the reference 

sounding time based on the longitude of the location for the default option. 

Subroutine MPPBL was also modified to use an integer variable 
6

(ICHRND_UASRISE) instead of a real variable (CHRND_UASRISE) for 

assigning the ‘START_WINDOW’ when the UASELECT SUNRISE option 

is used.

f. Modified subroutines FLOPEN and WRTCRD to use STATUS='REPLACE' 

instead of STATUS='SCRATCH' when opening the DEV70 and DEV75 

"temporary" files to store the header records in the ".IQA", ".OQA", and 

MERGE data files that contain information for reprocessing of input options 

during subsequent stages of AERMET processing. This modification 

addresses issues that were encountered where AERMET was not able to 

locate the 'SCRATCH' files when applying a 64-bit version of AERMET.

g. Modified subroutines SUMHF and SUNDAT to eliminate integer/real mixedmode calculations in summing the hourly heat fluxes, and in calculating 

sunrise/sunset times and solar elevation angles.

h. Modified subroutine BULKRI to include the THSTAR adjustment for low 

solar elevation angles under the original BULKRN method and for the nonDefault/BETA ADJ_U* option associated with the BULKRN option. 

Subroutine BULKRI was also modified to avoid an array subscript out-ofbounds error in cases where the iterative approach does not converge within 

the specified loop limits.

i. Modified subroutine MPFIN to include additional error handling and 

reporting associated with processing of surface characteristics

j. Modified subroutines VRCARD, SUBST, MPPBL, and MPOUT to allow 

users to disable substitutions for missing CCVR and/or TEMP data that are 

based on persistence for hours 23 and 24. Additional flags have been added to 

the surface output file to identify when this option is applicable. These 

changes also allow users to specify either the NO_SUB or NOTSUB keyword 

to disable TEMP substitutions.

k. Subroutine OSDTCD was modified to include logical variables to identify the 

availability of ONSITE data for ambient temperature, solar 

radiation/insolation, cloud cover, net radiation, delta-T, and/or mixing heights. 

Several other subroutines were modified, including MPPBL, MPMET, 

MPFIN, and MPTEST to track whether substitutions for missing temperature 

and/or cloud cover should be implemented by default, based on whether only 

ONSITE data or only SURFACE data are available for a given parameter. 

Cloud cover and temperature substitutions were not implemented by default in 

v13350 if both SURFACE and ONSITE data were available, irrespective of 

whether the substituted parameter was included in both SURFACE and 

ONSITE data inputs. Version 14134 will apply CCVR and/or TEMP 

substitutions by default if the parameter is only included in the SURFACE or 

ONSITE data. However, the user options to disable substitutions are still 

available.

l. Modified subroutines MPPBL, SUBST, and EQ_CCVR to address potential 

issues with the use of ONSITE solar radiation and delta-T data in lieu of cloud 

cover (utilizing the delta-T based Bulk Richardson Number (BULKRN) 
7

method for stable conditions) or if delta-T/BULKRN is being applied with 

ONSITE or NWS cloud cover. These modifications were focused especially 

on the transition from nighttime stable conditions (controlled by deltaT/BULKRN) and daytime convective conditions (controlled by solar radiation 

data). The BULKRN/delta-T method will be used if valid delta-T and 

ONSITE wind data are available and if the delta-T lapse rate is stable, or if the 

cloud cover or insolation data is missing, or if the cloud cover is an 

"equivalent" cloud cover derived from solar radiation data when the solar 

elevation angle is less than the critical elevation angle for convective 

conditions. The critical solar elevation angle was also modified to use an 

average of the previous 24-hours of temperature data (with at least 75% data 

capture), instead of a default value of 288 K, for hours when the temperature 

is missing. An assumption of 5/10 cloud cover is also used in the calculation 

of critical solar elevation angle for hours when cloud cover is missing. Since 

the model will not compute concentrations for these hours due to missing 

temperature and/or cloud cover the effect of these changes on modeled 

concentrations is likely to be minimal. Furthermore, this approach should 

provide a reasonable estimate of early morning heat fluxes, and treating these 

hours as missing in terms of heat flux could result in the entire convective 

portion of the day being missing

m. Subroutine EQ_CCVR was modified to account for cases when the clear sky 

insolation value, QRNOT, is less than or equal to 0. The equivalent CCVR is 

set to 0 in these cases.

n. Modified subroutines MPMET, MPFIN, MPOUT, and AERSURF to track 

and report the use of MMIF-generated inputs, in the form of pseudo-ONSITE 

data alone (including "ONSITE" mixing heights) or as pseudo-ONSITE and 

UPPERAIR data. The use of MMIF-generated inputs is gleaned from 

information in the AERSURF input file of surface characteristics if it is used 

in Stage 3. The use of MMIF data is flagged in the header record of the 

surface file and by the use of the 'MMIF-OS' flag instead of the hourly NADOS, ADJ-SFC, etc., flags associated with ONSITE and/or SURFACE data.

Subroutines MPMET, MPFIN, and MPOUT were also modified to track and 

report the use of the Bulk Richardson Number (BULKRN) option based on 

delta-T measurements, in lieu of cloud cover, for stable conditions. For 

applications using the BULKRN option, the header record of the surface file 

will include the 'BULKRN' flag. An additional 'MMIF' flag will be included 

if the BULKRN option is associated with use of MMIF data

o. Modified subroutine GET620 to allow the user to specify a standard 5-digit 

WBAN, instead of an 8-digit number with 3 leading 0's, for processing upper 

air data in the 6201 format. Checks have also been included to identify issues 

that may occur when users specify the 6201VB (TD-6201 variable-length 

block) format for upper air data.

p. Modified subroutine GETFSL to read the WMO number from upper air data 

in the FSL format, in addition to reading the WBAN, and assign the WMO 
8

number to the BUF08(1) variable if WBAN = '99999' to support non-US 

applications.

q. Modified subroutines SETUP, MPPROC, OSCARD, MRCARD, WRTCRD, 

and HEADER to allow re-processing of the XDATES information from the 

MERGE file header records. This information is included in the Stage 3 

report, unless the user has specified XDATES in the Stage 3 input file. Also 

modified subroutine MERGE to use a consistent form for reporting the extract 

dates in the report files across all three stages. Subroutine CHROND was 

modified to fully support 4-digit years and subroutine XDTCRD was modified 

to use 4-digit years for extract dates in the report files instead of 2-digit years.

6. The sixth set of revisions, introduced with version 15181 of AERMET (see Model 

Change Bulletin (MCB) #6 provided on the SCRAM AERMET webpage), 

includes:

a. Modified subroutines UCALST and MPPBL to incorporate a constant value 

of THSTAR of 0.08, full inclusion of the displacement height, and a modified 

formulation for Monin-Obukhov length for the ADJ_U* option based on Qian 

and Venkatram (BLM, v138, 2011). Subroutine UCALST was also modified 

to adjust USTAR for wind speeds below the “critical” wind speed.

b. Modified subroutine BULKRI to correct the calculation of CDN to use 

ZREF(IHR)/Z0(IHR) instead of Z2/Z0(IHR). Subroutine BULKRI was also 

modified to use BETAM = 0.5 for the ADJ_U* option instead of 0.47.

c. Modified subroutine BULKRI to incorporate additional refinements to the 

ADJ_U* Beta option in conjunction with the Bulk Richardson Number 

(BULKRN) option, based on Luhar and Raynor (BLM, v132, 2009), including

a more refined method for calculating THSTAR, and extending its 

applicability for very stable/low wind conditions.

d. Modified subroutine MERGE to include the year in the Stage 2 table of Daily 

Output Statistics.

e. Subroutine GET620 was modified to issue a message if the UALOC in the 

upper data file does not match UALOC specified on the LOCATION 

keyword. This allows users to track when data from alternative representative 

upper air stations are used in conjunction with the UPPERAER tool.

AERMET is designed to be run as a three-stage process (see Figure 1-1 of the AERMET 

User’s Guide) and to operate on three basic types of data – NWS, FAA or other hourly surface 

observations, NWS twice-daily upper air soundings, and data collected from an on-site 

measurement program such as from an instrumented tower. The first stage of AERMET 

processing extracts (retrieves) data from the raw data files and assesses data quality. The second 

stage combines (merges) the available UPPERAIR, SURFACE, and ONSITE data for 24-hour 

periods and writes these data to an intermediate file. The third and final stage reads the merged 
9

data file, develops the necessary boundary layer parameters for dispersion calculations by 

AERMOD, and outputs AERMOD-ready meteorological data files.

Note that many references are made in the AERMET User’s Guide and Addendum to 

‘NWS’ surface data, which should be interpreted generically as any source of hourly surface 

weather observations, typically but not exclusively from airports. Also, AERMET defines the 

ONSITE pathway for inputting hourly surface observations taken from an on-site, or site-specific 

meteorological tower. The Guideline on Air Quality Models (Appendix W to 40 CFR Part 51) 

was modified in April 2003 to use the term ‘site-specific’ in place of ‘on-site,’ recognizing that 

collection of surface meteorological data on the property of a facility does not guarantee that 

such data are representative for purposes of dispersion modeling, while data collected ‘off-site’ 

are not automatically precluded from being considered representative. As a result, the terms ‘onsite’ and ‘site-specific’ are used interchangeably in the AERMET User’s Guide and Addendum. 

The AERMET program was revised, beginning with version 06341, to use a single 

executable file, AERMET.EXE, to perform all three stages of processing, replacing the 

STAGE1N2.EXE and STAGE3.EXE executable files used in earlier versions of AERMET. The 

AERMET program is designed to read a hardcoded input filename of ‘AERMET.INP’ for all 

three stages, and the program is run by entering ‘AERMET’ at a ‘DOS’ command prompt, or by 

double-clicking the AERMET.EXE file from a folder view. Note that the change to a single 

AERMET executable only affects the number of executables; AERMET, as currently 

configured, can still only perform one stage of processing at a time. 

The AERMET.INP file is a text file containing the instructions for processing (a.k.a., the 

command input file); this file must be located in the same directory as the AERMET executable. 

Note that all AERMET output filenames are user-specified. As currently configured, AERMET 

can only handle one processing stage at a time. Therefore, in a typical application the command 

line would be entered three times, once for stage 1 processing (extraction and quality assurance 

(QA)), a second time for stage 2 processing (merge), and a third time for stage 3 processing (met 

preparation). Since stage 1 processing is designed to support QA of raw input data, stage 1 may 
10

involve some iteration if data problems are encountered. Prior to running AERMET one should 

review the instructions in the command input file and, as necessary, replace them with 

instructions appropriate to the particular application and stage of processing. A batch file to 

facilitate the procedure of running AERMET for the three processing stages follows:

The revisions to AERMET introduced with version 06341 to address several problems 

associated with extraction and processing of National Weather Service airport data in the 

Integrated Surface Hourly Data (a.k.a., ISHD, ISH, ISD, TD-3505) format included:

• corrections to the procedure for selecting which record to process for hours with 

multiple records;

• corrections to code for processing of sky cover fields;

@ ECHO OFF

rem RUNAERMET filename

rem This is a DOS utility program for use in running the meteorological

rem preprocessor, AERMET. The program is run from the DOS prompt using

rem the following syntax:

rem where: RUNAERMET is entered 'as is' and

rem filename is the name of the input file

 :START

 IF '%1' == '' GOTO END

 IF EXIST %1 GOTO COPY

 ECHO Error locating input file

 GOTO STOP

 :COPY

 COPY %1 AERMET.INP

 ECHO Proceed with processing

 PAUSE

 AERMET

 GOTO STOP

 :END

ECHO ..

ECHO ..

ECHO AERMET is run from the DOS prompt using the following syntax

ECHO ..

ECHO RUNAERMET filename

ECHO ..

ECHO where: RUNAERMET is entered 'as is'

ECHO filename is the name of the input file

ECHO ..

ECHO ..

 

 
11

• addition of code for identifying "variable" winds, introduced on July 1, 1996, with 

adoption of the METAR reporting standard, with valid wind speed but missing wind 

direction (formerly flagged as calms);

• code for initializing the "additional" character variable to avoid data fields from 

previous hours being used; and

• code for handling mixed-format ISHD data files with full and condensed archival 

formats (note that ‘condensed’ format refers to ISHD data without the location and 

elevation fields on each record, which is not the same as the ‘abbreviated’ format for 

ISHD data, which is not supported by AERMET).

Some of the QA defaults presented in the current AERMET User’s Guide (EPA, 2004) 

have been revised to maintain consistency with the current AERMET code, including upper and 

lower bounds and missing indicators. These revisions are reflected in modified tables from the 

AERMET User’s Guide provided below in Appendix B.

Additional details regarding these and other revisions to the AERMET code are presented 

in the AERMET MCB#1 and MCB#2, and through comments embedded in the Fortran source 

code. Given the scope of code changes associated with the update dated 11059 (MCB#2), an 

annotated list of changes in the source code has not been developed.
12

2.0 USER INSTRUCTIONS

This section documents revisions to the user instructions associated with modifications to 

the AERMET program, including changes introduced with version 06341 and later.

2.1 STATION ELEVATIONS

Beginning with version 06341, AERMET allowed the option to specify station elevation 

above mean sea-level (MSL) as the last field on the LOCATION keyword in the UPPERAIR, 

SURFACE, and ONSITE pathways in the Stage 1 control file, and the METPREP pathway in the 

Stage 3 control file. However, this optional station elevation was only used under version 06341 

when processing ISHD data on the SURFACE pathway and all other occurrences of userspecified station elevations were ignored. Beginning with version 11059, AERMET was revised 

to make full use of user-specified station elevations for the SURFACE and ONSITE pathways to 

estimate station pressure if station pressure is missing, but to no longer allow station elevation on 

the UPPERAIR pathway. The LOCATION keyword has also been removed from the 

METPREP pathway beginning with version 11059. AERMET will issue a warning message if 

the elevation field is included on the UPPERAIR LOCATION keyword, but the user-specified 

elevation will be ignored and processing will continue. AERMET will also issue a warning 

message and ignore all inputs on the LOCATION keyword if specified on the METPREP 

pathway. 

The handling of station elevation within AERMET, beginning with version 11059, is 

summarized below:

1. A non-fatal warning message will occur if the station elevation is encountered on 

the LOCATION keyword on the UPPERAIR (Stage 1) pathway, or if the 

LOCATION keyword is included on the METPREP (Stage 3) pathway, but the 

inputs will be ignored and processing will continue.

2. The station elevation is allowed as an optional argument on the LOCATION 

keyword for the SURFACE and ONSITE pathways in Stage 1.
13

3. If the station elevation is included in the raw SURFACE input file to Stage 1 (ISHD 

or SAMSON formats), then the elevation from the data file is used; otherwise the 

user-specified station elevation is used, if available.

4. If the station elevation is not specified on the SURFACE pathway and is not in the 

raw surface data input file for Stage 1, then 0 meters (sea-level) is used for the 

SURFACE station elevation.

5. If the station elevation is not specified on the ONSITE pathway in Stage 1, then 0 

meters (sea-level) is used for the ONSITE station elevation.

Station elevation is used within Stage 3 of AERMET processing in the substitution for 

missing station pressure. While station elevation is currently an optional parameter on the 

LOCATION keyword under the SURFACE and ONSITE pathways, users are encouraged to 

include station elevation since it may improve the representativeness of the station pressure used 

by AERMET if station pressure is missing. The following hierarchy is used for determining 

station pressure, depending on the availability of ONSITE and/or SURFACE station pressure, 

sea-level pressure and station elevation, depending on the source of ambient temperature data:

1. If ONSITE temperature data is used, then:

a. Use ONSITE station pressure, if available;

b. Adjust ONSITE sea-level pressure to ONSITE station elevation, if provided on 

the LOCATION keyword in the ONSITE pathway;

c. Adjust NWS/FAA station pressure to ONSITE station elevation, if station 

elevation is available for both the SURFACE and ONSITE data;

d. Adjust NWS/FAA sea-level pressure to ONSITE station elevation, if ONSITE 

station elevation is provided;

e. Use NWS/FAA station pressure, if available, without adjustment;

f. Adjust NWS/FAA sea-level pressure to SURFACE station elevation, if 

available;

g. Estimate station pressure based on standard atmosphere using ONSITE station 

elevation, if available;

h. Estimate station pressure based on standard atmosphere using SURFACE 

station elevation, if available;

i. Assign ONSITE sea-level pressure to station pressure if no ONSITE station 

elevation is available; 
14

j. Assign SURFACE sea-level pressure to station pressure if no SURFACE 

station elevation is available; or

k. Assign standard sea-level pressure of 1013.25 mb to station pressure.

2. If SURFACE temperature data is used, then:

a. Use SURFACE station pressure, if available;

b. Adjust SURFACE sea-level pressure to SURFACE station elevation, if 

provided on the LOCATION keyword in the SURFACE pathway or in the 

SURFACE data file;

c. Adjust ONSITE station pressure to SURFACE station elevation, if station 

elevation is available for both the SURFACE and ONSITE data;

d. Adjust ONSITE sea-level pressure to SURFACE station elevation, if 

SURFACE station elevation is provided;

e. Use ONSITE station pressure, if available, without adjustment;

f. Adjust ONSITE sea-level pressure to ONSITE station elevation, if available;

g. Estimate station pressure based on standard atmosphere using SURFACE 

station elevation, if available;

h. Estimate station pressure based on standard atmosphere using ONSITE station 

elevation, if available;

i. Assign SURFACE sea-level pressure to station pressure if no SURFACE 

station elevation is available; 

j. Assign ONSITE sea-level pressure to station pressure if no ONSITE station 

elevation is available; or

k. Assign standard sea-level pressure of 1013.25 mb to station pressure.

2.2 UPPER AIR SOUNDING SELECTION

The AERMET meteorological preprocessor was originally developed to work with NWS 

upper air sounding data available in the United States and North America. Since that time, 

AERMET has been increasingly applied in areas outside North America. If observed ONSITE 

mixing heights are not available, AERMET requires a morning sounding to compute the hourly 

convective mixing heights for AERMOD. The preferred sounding time is prior to sunrise, before 

the convective mixed layer begins to develop. In North America, this generally means the 1200 

GMT sounding (also referred to as the 12Z sounding). In other parts of the world this means the 

0000 GMT (or 00Z) sounding. Originally, AERMET was designed to automatically select the 
15

12Z sounding, consistent with the primary focus of the AERMOD model development to support 

modeling applications within the U.S. Since the reported upper air observation time is known to 

vary slightly, AERMET also defined a default “sounding window” of ±1 hour, i.e., AERMET 

accepted the 11Z, 12z, or 13Z sounding. Beginning with version 11059, AERMET has been 

enhanced to select an upper air sounding that is more appropriate for the location where 

AERMET is being applied.

The world is divided into 24 time zones, but most zones do not follow a straight northsouth line of longitude (see Figure 2-1). As a result, the time zone adjustment parameter on the 

LOCATION keyword is not a reliable indicator for selecting the appropriate sounding time. 

Beginning with version 11059, the default approach in AERMET has been enhanced to search 

for an appropriate sounding for all locations based on the longitude entered on the LOCATION 

keyword under the UPPERAIR pathway for Stage 1 processing, and computes a ‘pseudo’ time 

zone based on this longitude. The longitude is divided by 15 with the result rounded to the 

nearest integer. For example, 156.76° West yields a time zone of -10 (in keeping with the 

standard convention that west longitudes are negative). It is worth noting that in Alaska, the time 

zone is -9 for the entire state but the state actually spans pseudo-zones -9, -10, and -11 based on 

longitude. This is not an uncommon occurrence. 

Table 2-1 shows which default sounding AERMET will use based on the longitudedependent ‘pseudo’ time zone (note that time zones -12 and +12 refer to the same zone). The 

values shown in the table are also shown across the top of Figure 2-1. A sounding time of -12 

indicates the use of the 1200 GMT (12Z) sounding from the previous day and is primarily used 

in the Far East, southeast Asia, Australia, and New Zealand.
16

Figure 2-1. Time Zone Boundaries (with preferred sounding time across top)

 Table 2-1. Sounding Selection by Time Zone

Time Zone -12 -11 -10 -9 -8 -7 -6 -5 -4 -3 -2 -1 0

Sounding -12 12 12 12 12 12 12 12 12 00 00 00 00

Time Zone 1 2 3 4 5 6 7 8 9 10 11 12 --

Sounding 00 00 00 00 00 00 00 -12 -12 -12 -12 -12 --

2.2.1 Adjusting the Default Sounding Window

By default, AERMET uses a 1-hour window before and after the preferred sounding time 

as the search window to locate a sounding to use. Beginning with version 11059, the user can 

expand (or contract) this window by using the optional UAWINDOW keyword under the 

METPREP pathway in Stage 3. The syntax of the UAWINDOW keyword is as follows:
17

Syntax: UAWINDOW window_begin window_end

Type: Optional, Non-repeatable

where window_begin represents the beginning of the sounding window and window_end

represents the end of the sounding window, entered as the number of hours relative to the 

preferred sounding time (whether it be 12Z or 00Z). A negative number indicates the number of 

hours before the reference sounding, and a positive number indicates the number of hours after 

the sounding. The default sounding window would be input as: UAWINDOW -1 +1 (note that 

the plus sign in not required). The sounding window does not have to be symmetric about the 

sounding time. For example if the user wants to search more hours before the sounding time and 

fewer after, the following could be used: UAWINDOW -5 +2. To force AERMET to accept 

only soundings corresponding to the reference sounding time, the use would input: 

UAWINDOW 0 0. If multiple soundings are available within the upper air sounding window, 

AERMET will select the sounding closest in time to the reference sounding, with a preference 

for soundings prior to and including the reference sounding time. For example, if UAWINDOW 

-5 +2 is specified, and soundings are available for 9Z, 12Z, and 15Z, AERMET would select the 

12Z sounding. However, if soundings were available for 9Z and 13Z, AERMET would select 

the 9Z sounding.

2.2.2 Option to Select Sounding Based on Sunrise

By default, AERMET uses the 12Z/00Z sounding criterion described above to locate a

sounding for its computations. Beginning with version 11059, AERMET has been enhanced to 

include an optional method to search for the morning sounding based on the local time of sunrise

at the UPPERAIR station location. Rather than looking for a 00Z or 12Z sounding, AERMET 

searches for the sounding nearest to sunrise. By default, AERMET attempts to find a sounding 

within 6 hours before sunrise, and if that search fails, it searches up to 2 hours after sunrise

(equivalent to UAWINDOW -6 +2). As with the sounding window for the default selection in 

Section 2.2.1, priority is given to soundings prior to and including sunrise, such that a sounding 

that is 4 hours before sunrise is preferred, and selected, over a sounding that is 1 hour after 
18

sunrise.

To invoke this search, a new option for the METHOD keyword under the METPREP 

pathway in Stage 3 has been defined: UASELECT. The syntax of the new UASELECT option is 

as follows:

Syntax: METHOD UASELECT SUNRIS(E)

Type: Optional, Non-repeatable

The ‘E’ on ‘SUNRISE’ is optional and can be omitted. As with the 12Z/00Z sounding search, 

the user can expand or contract the search window for the SUNRIS option (-6 to +2 hours by 

default) using the UAWINDOW keyword. The syntax for the UAWINDOW keyword is the 

same in both cases:

Syntax: UAWINDOW window_begin window_end

Type: Optional, Non-repeatable

where window_begin represents the beginning of the sounding window and window_end

represents the end of the sounding window, entered as the number of hours relative to sunrise to 

conduct the search. For purposes of applying the sounding window, sunrise is defined as the 

beginning of the hour during which the sun rises. For example, if sunrise is calculated to occur 

at 06:45 local time, AERMET will define sunrise as 0600 and preference will be given to a 

sounding at 0600 vs. a sounding at 0700. 

2.3 PROCESSING OF ASOS DATA

Beginning with version 11059, several modifications have been made to AERMET 

related to the processing of surface observations from Automated Surface Observing Systems 

(ASOS) used to collect weather measurements at airports located with the U. S. The U.S.

National Weather Service (NWS) and Federal Aviation Administration (FAA) began an effort in 

1992 to replace the traditional observer-based system for collecting and reporting weather data 
19

with an automated system. As of 2010, there were over 900 ASOS stations located at airports 

across the U.S. The transition from the observer-based system to an automated system has 

presented both challenges and opportunities in relation of the use of such data to support 

dispersion modeling applications (EPA, 1997). This section describes several modifications to 

AERMET to address some of these challenges, as well as to take advantage of the opportunities, 

and the most significant changes are related to processing of ASOS wind data.

2.3.1 Use of 1-minute ASOS Wind Data

In addition to the standard archives of surface observations based on ASOS, the National 

Climatic Data Center (NCDC) began routinely archiving 1-minute ASOS wind data (TD-6405), 

beginning with data for January 2000 for first-order NWS ASOS stations, and beginning with 

data for March 2005 for all other ASOS stations. The 1-minute ASOS wind data files include 

the 2-minute average wind speed and direction reported every minute, i.e., the files consist of 60 

overlapping 2-minute averages for an hour. By contrast, the standard archives of surface 

observations based on ASOS include a single 2-minute average wind speed, usually reported 

within 10 minutes before the hour. The values included in the 1-minute ASOS wind data files 

are reported to the nearest degree for wind direction and whole knots for wind speed. More 

importantly, whereas the standard ASOS archives report any wind speed below 3 knots as 0 

knots to represent a calm, consistent with the METAR standard adopted in July 1996, the 

1-minute ASOS wind data files include values for 1 knot and 2 knots.

The use of hourly-averaged wind speed and direction provides a more appropriate input 

for the AERMOD dispersion model than a single 2-minute average. Utilizing wind data for the 

full hour will typically result in a more complete data set since many hours classified as calm or 

variable (with a non-missing wind speed up to 6 knots, but missing wind direction) based on a 

single 2-minute average will be filled in with hourly averages derived from the 1-min ASOS

wind data. Furthermore, the use of hourly averaged wind direction, derived from 2-minute 

averages reported to the nearest degree, eliminates the need to randomize wind directions as 

done for the standard observations which are reported to the nearest 10 degrees.
20

Beginning with version 11059, AERMET has been updated to accept hourly averages of 

wind speed and wind direction derived from 1-minute ASOS wind observations available from 

NCDC at ftp://ftp.ncdc.noaa.gov/pub/data/asos-onemin/. The hourly-averaged wind speed and 

wind direction files input to AERMET should be generated using EPA’s 1-minute ASOS wind 

data processor, AERMINUTE (EPA, 2010). Hourly-averaged wind speed and direction data 

derived from 1-minute ASOS wind data files using AERMINUTE will be referenced below as 

“1-minute ASOS wind data.”

The 1-minute ASOS wind data are read by AERMET during the Stage 2 merge 

processing. AERMET is instructed to include these data in the merged output by adding the 

ASOS1MIN keyword followed by the filename of the 1-minute ASOS wind data file on the 

SURFACE pathway in the Stage 2 control file using the following format:

ASOS1MIN file_name

When provided, 1-minute ASOS wind data can be used to substitute for missing ONSITE wind 

data or replace wind data from standard NWS or FAA SURFACE data formats when ONSITE

data are not included. To substitute for missing on-site winds or replace standard SURFACE 

winds, the secondary keyword REFLEVEL must be specified with the SUBNWS parameter as a 

METHOD on the METPREP pathway in the Stage 3 control file. 

When SUBNWS is specified, AERMET uses the following hierarchy, based on data 

availability for each hour, to select the wind data used to calculate boundary layer scaling 

parameters, and ultimately written to the surface file (SFC) generated during Stage 3 processing:

1. ONSITE winds,

2. 1-min ASOS winds; then 

3. standard SURFACE winds. 
21

Neither NWS nor 1-min ASOS wind data will be used to substitute for missing onsite wind data 

if the ‘REFLEVEL SUBNWS’ option under the METHOD keyword is omitted from the Stage 3 

control file.

Wind speeds from 1-minute ASOS wind data files are extracted and merged during Stage 

2 processing. AERMET checks the observation date for consistency with the ASOS commission 

date, and if the 1-minute ASOS wind date precede the commission date the reference wind speed 

and direction are set to missing and an error message is generated (see Section 2.3.3 for more 

details).

2.3.2 Threshold Wind Speed for 1-minute ASOS Winds

Beginning in 2003, NWS began replacing the traditional cup and vane wind instruments 

at ASOS stations with more sensitive sonic anemometers (NOAA, 2003). Unlike the standard 

cup anemometer, which has a nominal starting threshold of about 2 knots, sonic anemometers 

have virtually no starting threshold. As a result, the hourly-averaged winds processed through 

AERMINUTE based on sonic data will not include any calm hours (defined as wind speeds 

below the starting threshold of the anemometer). Since the minimum acceptable wind speed 

threshold for site-specific meteorological monitoring is 0.5 m/s under current EPA guidance 

(EPA, 2000), to avoid imposing a more stringent requirement on data derived from 1-minute 

ASOS data than would be required for a site-specific monitoring program, beginning with 

version 12345 of AERMET user’s may specify a threshold wind speed for winds derived from 1-

minute ASOS data. 

Beginning with version 12345, a new THRESH_1MIN keyword is available in Stage 3 

for the user to specify a threshold wind speed for the 1-minute data. This threshold value only 

applies to the hourly averaged winds derived from 1-minute data and does not apply to the 

standard hourly NWS weather observations. The new THRESH_1MIN keyword uses the 

following syntax:
22

Syntax: THRESH_1MIN threshold_speed

Type: Optional, Non-repeatable

where threshold_speed is the threshold wind speed in m/s. If the user specifies a threshold speed 

greater than 0.5 m/s, a warning is issued by AERMET. If a threshold wind speed greater than 

1.0 m/s is specified, AERMET considers this a fatal error, will issue an error message and will 

not process data through Stage 3. The Stage 3 report file documents whether the 

THRESH_1MIN option has been used, and also specifies the number of calm winds identified 

based on the specified threshold value.

2.3.3 Adjustment to Truncated ASOS Wind Speeds

Beginning with version 11059, AERMET has been modified to add 1⁄2 knot (0.26 m/s) to 

all ASOS-based wind speeds in order to compensate for the bias introduced due to the wind 

speeds being truncated, rather than rounded, to whole knots (NOAA, 2008). There are two 

sources of ASOS wind data that can be input to AERMET: 1) NWS data in one of the standard 

NWS surface data formats; and 2) hourly-averaged wind speed and direction derived from 

1-minute ASOS wind data files generated with AERMINUTE (EPA, 2010). 

The 1⁄2 knot ASOS wind speed adjustment is applied, by default, during Stage 3 

processing to wind speeds substituted from 1-minute ASOS wind data as well as those 

substituted from standard NWS/FAA surface data determined to be ASOS winds based on the 

ASOS commission date. The user can override the default truncation adjustment by adding the 

ASOS_ADJ method and NO_ADJ keyword to the Stage 3 METPREP pathway using the 

following format:

METHOD ASOS_ADJ NO_ADJ
23

In order to document the source of the wind data in the Stage 3 SFC file output by 

AERMET, and identify whether the wind speed was adjusted, a two-part code is appended to the 

end of each record. The first part of the code indicates whether the wind speed was or was not 

adjusted with either “ADJ” or “NAD,” respectively. The source of the wind data for each record 

is encoded as either “OS”, “SFC”, or “A1” to indicate the use of ONSITE, SURFACE, or 

1-minute ASOS winds, respectively. The two parts of the code are separated by a hyphen, and if 

no wind data are available for a particular hour, the second part of the code is blank.

2.3.4 Identifying ASOS Observations

In order to implement the ASOS wind speed adjustment described in Section 2.3.2, 

AERMET must determine whether surface wind observations are ASOS or not. Wind data in the 

standard NWS surface formats read by AERMET are identified as ASOS based on the published 

commission date of the ASOS equipment for the Weather-Bureau-Army-Navy (WBAN) number

reported in either the header of the NWS surface file or the first observation, or the 3- or 4-

character station call letters included in the observations, depending on the format input to 

AERMET. A table of commission dates was added to AERMET to support the determination of

whether an observation was measured by ASOS instrumentation. As each observation is 

extracted from the NWS surface file during Stage 1 processing, the observation date and time are 

temporarily converted to LST and the 1-24 hour convention, then the converted date is compared 

to the ASOS commission date. Those records for which the observation date falls on or after the 

ASOS commission date are identified as ASOS by appending an “A” to the extracted record in 

the Stage 1 surface extraction and surface QA files. If a commission date is not found or the 

observation occurred before the commission date, the record is tagged with an “N” to indicate it 

is not an ASOS observation. For those formats that report hours using the 00-23 hour 

convention, the 00 hour becomes hour 24 on the previous day. Thus, data reported for hour 00 

on the ASOS commission date, after the date and time is converted, will not be recognized as an 

ASOS hour.
24

For those NWS surface formats that include a data field to indicate that measurements 

were made with ASOS instrumentation (HUSWO, TD-3280, and in some cases ISHD), a 

validation is performed on each record to check the consistency between the ASOS flag in the 

raw data file with the ASOS flag set by AERMET based on the commission date. If the ASOS 

flag in the raw data file indicates an ASOS observation, the record in the extracted file will be 

appended with an “A” to indicate an ASOS observation, but a warning will be included in the 

Stage 1 message file if the station is not found on the ASOS commission list, or if the station is 

found but the data period precedes the commission date contained within AERMET. 

To address cases where an ASOS station is not included in the ASOS commission list in 

AERMET but the station is known to be an ASOS site, AERMET includes an optional parameter 

on the DATA keyword under the SURFACE pathway allowing the user to specify that the data 

are ASOS. Note that this optional ‘ASOS’ parameter is only allowed for surface data in the 

ISHD format, and should only be used if the station is known to be ASOS, but is not included in 

the ASOS commission list within AERMET (see Table A-6 for a description of the DATA 

keyword format).

The ASOS commission date and the count of extracted ASOS records are reported in the 

Stage 1 message file. Similarly, the surface records are marked with either an “A” or an “N”, as 

appropriate, in the Stage 2 merge file to facilitate the ASOS wind speed truncation adjustment 

applied in Stage 3. Since 1-minute ASOS wind data are presumed to be ASOS by definition, the 

ASOS flag is not included on the 1-minute ASOS wind data in the merge file.

NOTE: Beginning with version 11059, Stage 2 processing requires the presence of 

the ASOS flag appended to each surface record in the Stage 1 surface extraction and QA 

files. Similarly, Stage 3 processing requires the presence of the ASOS flag appended to 

applicable records in the Stage 2 merge file. If the ASOS flag is omitted from either of 

these files, a fatal error is issued and processing is aborted. Therefore, version 11059 of 
25

AERMET, or later, will not process surface extraction or merge files generated with an 

earlier version of AERMET. 

2.3.5 Validation of NWS Surface Format by Active Date Range

Validations were incorporated in AERMET, beginning with version 11059, to check for 

consistency between the date of the observation in the NWS surface file and the range of dates 

for which the NWS format is considered to be active and valid. A file that contains data outside 

the format’s valid date range is assumed to have been reformatted from some other data format 

and its use in AERMET may result in inconsistencies with data processed for the same station 

and dates input in their native format. Use of reformatted data files in AERMET is discouraged, 

and AERMET results based on processing reformatted data should be used with caution. 

The date consistency check is performed for each hour of data extracted from the NWS 

surface file, until an observation is found that is outside the valid date range. Once an 

observation is encountered that is outside the valid date range, a variable is set to indicate the 

data was likely reformatted, and a warning is issued in the Stage 1 message file when the data 

extraction is complete. Table 1 lists the active dates for each of the NWS surface formats read 

by AERMET as currently implemented in AERMET. Note that ISHD and TD-3280 are 

currently active formats and the validation is not performed against either of those formats.

Table 2-2. Format Active Dates

NWS Surface Format Start Date End Date

CD-144 --- 12/31/1995

HUSWO 1/1/1990 12/31/1995

ISHD --- ---

SAMSON 1/1/1961 12/31/1990

SCRAM 1/1/1984 12/31/1992

TD-3280 --- ---
26

2.3.6 Validation of WBAN Between Stage 1 Control File and NWS Surface Data File

Another validation was incorporated into AERMET, beginning with version 11059, to 

ensure consistency in the WBAN number specified by the user on the LOCATION card in the 

Stage 1 SURFACE pathway and the NWS surface data file. The WBAN number from the 

control file is compared to the WBAN number stored on the header record of the NWS surface 

file (SAMSON) or the WBAN number recorded for the first observation for those formats 

without a header record that repeat the WBAN number on each observation record (CD-144, 

HUSWO, SCRAM, and TD-3280). When the WBAN number from the control file is found to 

be different from that recorded in the NWS surface file, a fatal error is issued and processing is 

aborted. This validation is performed for all NWS surface formats read by AERMET with the 

exception of the ISHD format since ISHD includes many stations located within the U.S. and 

internationally for which a WBAN number has not be assigned.

For those formats in which the WBAN number is repeated on each observation record, an 

additional validation is performed to check for internal consistency across all observation records 

in the surface file. If a mismatch is encountered, a fatal error is issued and processing is aborted. 

Note: This check for internal consistency is performed for the ISHD format as well as the other 

applicable formats; however, since the WBAN number is not consistently included in ISHD files 

a fatal error will only be issued and processing aborted if a mismatch occurs between two nonmissing (i.e., not ‘99999’) WBAN numbers. For the ISHD format, the validation is applied to 

the 5-digit ID stored in positions 11-15 on each record. The first non-missing (not ‘99999’) 

WBAN number encountered is stored and used to compare against each subsequent record.

2.3.7 ASOS Cloud Cover from SCRAM and SAMSON Set to Missing

Due to the difficulties that arise when attempting to reformat cloud cover information 

collected with ASOS instrumentation to the SAMSON and SCRAM formats, there are concerns 

over the validity of the representation of ASOS clouds in these older pre-ASOS formats. For this 
27

reason, AERMET was modified (beginning with version 11059) to set opaque and total cloud 

cover to missing for observations extracted from SAMSON and SCRAM formats for which the 

observation date falls on or after the ASOS commission date. For each hour this condition is 

encountered, opaque and total cloud cover are set to missing and warning (up to 24) or 

informational messages are issued in the Stage 1 message file. Note that this also applies to 

SCRAM-formatted data available on the EPA SCRAM website for a few stations that were 

commissioned as ASOS during the last four months of 1992, the last year of data archived in the 

SCRAM format.

2.4 DEFINING THE ONSITE FILE STRUCTURE – READ AND FORMAT

One of the more difficult challenges for many users attempting to run the AERMET 

meteorological processor is to specify the inputs necessary to read and process site-specific, or 

ONSITE, meteorological data. Since the AERMOD dispersion model was designed to utilize a 

wide range of site-specific meteorological variables, including wind, temperature and turbulence 

data from a multi-level tower and/or SODAR, it is not practical to specify a standard format for 

site-specific data being input to AERMET. Also, since AERMET was written using the Fortran 

programming language, part of the challenge may be for users to understand some of the basic 

rules and concepts for reading data based on the Fortran language. This section describes the 

process for defining ONSITE meteorological inputs for AERMET, including enhancements 

introduced with version 11059 of AERMET that may simplify this process, and also provide 

better error handling and reporting if problems are encountered.

The key to reading site-specific meteorological data correctly in AERMET is to define 

what data variables are present and specify the format for reading the data. This task is 

accomplished with two related keywords on the ONSITE pathway: 1) the READ keyword, 

which defines the list and order of variables present on a data record; and 2) the FORMAT 

keyword, which defines the format of the data on each record. As noted above, these two 

statements together operate much like reading or writing data in a Fortran program. The syntax 
28

and type of these two keywords are as follows:

Syntax: READ record_index osname1 osname2 ... osnamen

Type: Mandatory (Stage 1 ONSITE pathway), Repeatable, Reprocessed

Syntax: FORMAT record_index Fortran_format

Type: Mandatory (Stage 1 ONSITE pathway), Repeatable, Reprocessed

Each READ keyword is paired with a corresponding FORMAT keyword through the 

record_index field. This index refers to one “record” of data for an observation period, although 

the READ can span multiple records within the data file. The indices are numbered sequentially 

beginning with 1. There can be up to 50 variables on any one data record and up to 50 “records” 

(or READs) per observation period. There is no fixed limit on the record length for each 

physical record within the data file; however some of the error handling and reporting performed 

by AERMET for ONSITE data is limited to the first 500 characters of a given data record. 

The osname1, osname2, ... osnamen fields on the READ keyword are the variable names 

for the variables included in the ONSITE data file for a particular data record, in the order in 

which they are to be read. The variable names available for ONSITE data are described in Table 

B-3a for “scalar” (single-level) variables and Table B-3b for “vector” (multi-level) variables. 

The Fortran_format field on the FORMAT keyword is normally the Fortran format statement 

that will be used to read the data from the corresponding READ keyword. However, beginning 

with version 11059, user’s can specify ‘FREE’ (without quotes and not case-sensitive) for the 

Fortran_format to indicate that the variables for a particular data record should be read as freeformatted data, in accordance with Fortran language standards. Free-formatted, also called listdirected data, are read as a list of values which are separated by at least one blank space or by a 

comma. The user has the option to specify FREE format for some data records, while specifying 

the Fortran FORMAT explicitly for other data records. The FREE format option may simplify 
29

the process of specifying the READ and FORMAT inputs for some users, but still requires an 

understanding of some basic rules to ensure that the data are input properly to AERMET.

The structure and format of the site-specific data is reasonably flexible, but subject to the 

following restrictions:

(1) The data for one observation period can be spread across several records (up to 

50), but the records for one data period must be contiguous;

(2) The same variables must appear for all observation periods, even if the values for 

those variables are missing for certain hours;

(3) The ONSITE data file must be an ASCII text file and it must be in a form that can 

be read using Fortran FORMAT statements or as FREE format;

(4) The date and time information for each observation must be on the first record of 

the period; these may occur in any order within the first record, and are read as 

INTEGER format (Fortran ‘I’ format or FREE format);

(5) The (non-date) data variables on the READ keywords must be a subset of those 

listed in Appendix B, Tables B-3a and B-3b, and are read as REAL format 

(Fortran ‘F’ or ‘E’ format or as FREE format);

(6) Using an ‘F’ or ‘E’ (REAL) Fortran format specifier to read a date/time variable 

will cause an AERMET runtime error; and using an ‘I’ (INTEGER) format 

specifier to read a data variable will also cause an AERMET runtime error.

When specifying the multi-level variables, such as wind or temperature observations

from an instrumented tower, the variable name is composed of a two-character prefix that 

identifies the atmospheric quantity and a two-character (numeric) suffix that identifies the level. 

For example, height, temperature and wind speed from the first level would appear as HT01, 

TT01 and WS01 on the READ keyword, as HT02, TT02 and WS02 for the second level, and so 

on. The same variables do not have to appear for each level of data. For example, winds may 

appear at three levels but temperature only at two levels. However, multi-level data must be 

entered in ascending height order. More details regarding options and requirements for 
30

specifying measurement heights for ONSITE data processed through AERMET are provided in 

Section 2.5.

Unless FREE format is specified for a particular READ, the Fortran_format on the 

corresponding FORMAT keyword is a character string that AERMET uses directly within the 

program to read the data. Hence, the string must comply with all the rules of Fortran for creating 

a format statement. The format must begin with an open parenthesis and end with a closing 

parenthesis. Any book on the Fortran programming language can provide guidance on 

constructing a format statement, but here are some important points to remember:

• The Fortran I format specifier for integer constants consists of ‘I’ followed by the 

width of the data field, such that a format of ‘I4’ will read a 4-character data string as 

an integer number;

• A read error will be generated if a non-numeric character (other than a leading ‘+’ or 

‘-‘), including a decimal (‘.’), occurs within the date field being read with an I format;

• The Fortran F format specifier for real constants consists of ‘F’ followed by the width 

of the field and number of places after the decimal point (Fw.d), such that a format of 

‘F5.2’ will read a 5-character data string, including the decimal, as a real number, 

with 2 places after the decimal point;

• Data being read as real constants using the ‘F’ format specifier are not required to 

include decimal places within the data string; however, users must be aware of the 

rules for assigning values using the F edit descriptor in such cases:

o If the data string includes a decimal place, then the value assigned to the REAL 

variable will reflect the number of decimal places specified; e.g., reading the 

string ’10.23’ as F5.2, F5.1, or F5.0 will all assign the value 10.23 to the variable.

o However, if the data string does not include a decimal point the number of 

decimal places assigned will be based on the F format specifier, such that reading 

the string ‘b1023’ (where ‘b’ represents a blank) as F5.2, F5.1, or F5.0 will assign 

the values 10.23, 102.3, and 1023. to the variable, respectively.

• Data being read as REAL constants using the ‘FREE’ format option will reflect the 

values as specified in the data file, such that a string of ‘10.23’ will be assigned a 

value of 10.23, whereas a string of ‘1023’ will be assigned a value of 1023;

• Reading date variables as INTEGER constants using the ‘FREE’ format option will 

not result in a read error if a decimal (‘.’) occurs within the data field being read, but 

any data after the decimal point will be ignored, such that a data field of ‘4.8’ will be 
31

read as an INTEGER value of 4. However, any other non-numeric character in the 

data field (other than a leading ‘+’ or ‘-‘) will result in a Fortran read error. 

The fourth bullet above related to the number of decimal places reflected in the data 

highlights one of the more significant problems that could arise with reading ONSITE data in 

AERMET, since the value assigned to the variable may not be the value intended by the user. 

This situation may arise if the ONSITE data file has been generated by exporting data from a 

spreadsheet program. In such cases the data values for a particular parameter may have a 

varying number of decimal places, including values with no decimal places for some records, 

since the spreadsheet program may output a fixed number of significant digits. While this issue 

could occur with any ONSITE data variables, it may be more likely for parameters that vary over 

a large range, such as solar radiation data. Given the potential problems that could arise if the 

data values being read by AERMET may not match the values intended, users are strongly 

encouraged to review the QAOUT file for the ONSITE data to ensure that the data have been 

read properly by AERMET. The QA audit statistics on values exceeding the upper and lower 

bounds for a given parameter may also highlight potential problems with the data. For cases 

when the “raw” ONSITE data include a variable number of decimal places, using the ‘FREE’ 

format option or using ‘Fw.0’ as the Fortran format specifier may avoid the issue described 

above.

Beginning with version 11059, AERMET performs additional checks related to the 

processing of ONSITE data which may help the user to identify and avoid potential problems. 

One such check compares the number of decimals included in the data string for ONSITE data 

with the number of REAL variables being read. Warning messages are generated if the number 

of decimals found is less than the number of REAL variables, and if the number of decimals 

changes from one data record to another. Another issue that may arise with processing ONSITE 

data is that the missing data code used within the data file does not match the default missing 

code used by AERMET (shown in Table B-3). AERMET will process the “missing” value as 

valid data in such cases, which may produce errors or anomalous results. The user can specify 

missing indicators that differ from the default using the RANGE keyword on the ONSITE 
32

pathway, and the QA audit statistics on values exceeding the upper and lower bounds may also 

highlight if such a problem exists. In addition, AERMET will issue warning messages, which 

are included in the REPORT files, for cases when the upper and lower bounds are exceeded by 

an amount larger than one half the range defined by UPPER-LOWER, which may flag this issue 

in some cases. 

Not all of the variables present in the site-specific data file need to be read. Any 

superfluous data can easily be skipped over using the X, T and / edit descriptors in the Fortran 

FORMAT specifier. However, the ‘FREE’ format option does not allow for skipping values 

within the data record and assigns values to the variables based on the order of variables within 

the data file. Also, users should note that:

Λ the same format used to read the original site-specific data file is also used to write 

the QA output (QAOUT) file.

If some variables or entire lines of data are skipped, then the QA output file will contain 

corresponding blank fields and/or blank lines.

Once the variables and formats have been defined, the user does not need to specify them 

for any subsequent AERMET runs (e.g., for Stage 3 processing) as long as the information 

remains in the header records of the QAOUT file generated in Stage 1 and the MERGE file 

generated in Stage 2. AERMET reprocesses these records as needed whenever the data are used 

in subsequent processing stages, saving the user the time required to setup that portion of a 

runstream file and avoiding introducing errors on these two keywords.

2.5 SPECIFYING ONSITE MEASUREMENT HEIGHTS

AERMET provides two options for specifying the measurement heights for the multilevel profile data input through the ONSITE pathway. One option is to explicitly specify the 

measurement heights within the input data file, using the ‘HTnn’ variable on the READ 
33

keyword, where ‘HT’ refers to the height variable and ‘nn’ refers to the level at which the 

observation was taken, beginning with ‘01’ for the first (lowest) level, ’02 for the next lowest 

level, up to the highest level (see Table B-3). With this option the ‘HTnn’ variables would need 

to be included for each observation period within the data file. While AERMET allows the 

measurement heights to vary from one observation to the next with the ‘HTnn’ option (which is 

normally not the case), the number of levels must be the same for each data period, and the 

heights must be defined in increasing order from lowest height (HT01) to the highest height. 

Under this option, if measurement heights are found to decrease with height or be duplicated, all 

multi-level data for that observation period will be set as missing.

The OSHEIHGTS keyword on the ONSITE pathway provides an alternative approach for 

specifying measurement heights for multi-level profile data. The syntax and type for the 

OSHEIGHTS keyword are as follows:

Syntax: OSHEIGHTS height1 height2 ... heightn

Type: Optional if height information is provided in the data; otherwise 

mandatory (Stage 1), Repeatable, Reprocessed

The height1, height2, ... heightn variables are the measurement heights in meters, ordered from 

lowest to highest. If the OSHEIGHTS keyword is specified and the ‘HTnn’ variables are also 

defined on the READ keywords, AERMET will use the heights based on the OSHEIGHTS 

keyword to override the height variables that may be present in the data file. For example, if the 

heights in the data file are 10.0, 50.0 and 100.0 meters, but the user knows that the heights are 

really 9.0, 50.0 and 100.0 meters, rather than modify the data file, the OSHEIGHTS keyword can 

be used to rectify the problem.

2.6 SECONDARY SITE SURFACE CHARACTERISTICS

AERMET has been revised, beginning with version 11059, to require two sets of surface 

characteristics (primary and secondary) in the METPREP pathway of the Stage 3 control file 
34

when the SUBNWS option is specified and both ONSITE and SURFACE data are provided

(including 1-minute ASOS wind data). If either ONSITE data or SURFACE data are omitted, 

only a single (primary) set of surface characteristics is required. In addition, AERMET includes 

optional keywords, AERSURF and AERSURF2 under the METPREP pathway, which can be 

used to specify separate external files which contain the necessary AERMET keyword inputs to 

specify surface characteristics for the primary and secondary site, respectively. These keywords 

facilitate the use of surface characteristics based on the AERSURFACE tool (EPA, 2008), 

without the requiring the user to copy-and-paste the results into the AERMET input file. The 

syntax of the new AERSURF and AERSURF2 keywords is as follows:

Syntax: AERSURF primary_surfchar_filename

AERSURF2 secondary_surfchar_filename

Type: Optional, Non-repeatable

where primary_surfchar_filename and secondary_surfchar_filename refer to the names of the 

files containing the surface characteristics for the primary and secondary sites, respectively.

The primary set of surface characteristics, which include the temporal frequency

(monthly, seasonal, or annual), number of sectors, and the values for albedo, Bowen ratio, and 

effective roughness length, should be specified in the Stage 3 control file in the same manner as 

in previous versions of AERMET using the existing keywords FREQ_SECT, SECTOR, and 

SITE_CHAR, respectively. To include a secondary set of surface characteristics in the Stage 3 

control file, the user specifies the temporal frequency, number of sectors, and the site 

characteristics (albedo, Bowen ratio, and effective surface roughness length) in a similar manner 

to the primary set using the new keywords FREQ_SECT2, SECTOR2, and SITE_CHAR2. 

These should be added to the METPREP pathway immediately after the primary set of 

characteristics which are defined with the original set of keywords (FREQ_SECT, SECTOR, and 

SITE_CHAR). The following shows the format for adding a secondary set of surface 

characteristics to the METPREP pathway:
35

** Primary Surface Characteristics

 FREQ_SECT frequency number_of_sectors

 SECTOR sector_index beginning_direction ending_direction

 SITE_CHAR frequency_index sector_index albedo Bowen roughness

** Secondary Surface Characteristics

 FREQ_SECT2 frequency number_of_sectors

 SECTOR2 sector_index beginning_direction ending_direction

 SITE_CHAR2 frequency_index sector_index albedo Bowen roughness

Note that surface characteristics included in an AERSURF file are interpreted by AERMET to be 

for the primary surface observation site, and setup errors will occur if keywords for the 

secondary surface characteristics site (FREQ_SECT2, SECTOR2, or SITE_CHAR2) are 

encountered. On the other hand, data included in the AERSURF2 file are interpreted by 

AERMET to be for the secondary site, and will be processed as if the FREQ_SECT2, 

SECTOR2, and SITE_CHAR2 keywords were used, even if the primary site keywords are 

specified. This allows for the use of an AERSURFACE output file for the AERSURF2 keyword 

without requiring the user to edit the AERSURFACE file to modify the keywords.

The primary set of characteristics will be applied for those hours in which the onsite data 

are used when onsite data are provided. Likewise, the primary characteristics will be applied to 

the NWS surface data if onsite data are omitted from the application and only one set of surface 

characteristics is required. If both onsite data and NWS surface data (including 1-minute ASOS) 

are provided, along with the SUBNWS option to allow substitution of NWS surface data for 

missing ONSITE wind and temperature data, the primary surface characteristics will be applied 

to the onsite data for those hours in which onsite wind data are used, and the effective surface 

roughness from the secondary set will be applied for those hours in which wind data from the 

NWS surface file or 1-minute ASOS wind data file are substituted for missing or calm onsite 

data. Note: The albedo and Bowen ratio from the primary set of surface characteristics are 

always applied regardless of whether ONSITE or SURFACE data are used for a given 

hour. The albedo and Bowen ratio from the secondary set are not used at this time, but 

values must be included to maintain consistency in the formats for reading the data.
36

2.7 REVISED SURFACE FILE FORMAT TO SUPPORT AERMOD DEPOSITION 

ALGORITHMS

Beginning with version 06341, the AERMET program includes additional meteorological 

parameters in the surface file that are needed to support application of the deposition algorithms 

in AERMOD. The additional variables include the precipitation code, precipitation rate, relative 

humidity, surface pressure, and cloud cover. These additional variables are automatically 

included after the standard variables for each hour, and do not require any additional user input. 

The precipitation data needed for wet deposition calculations in AERMOD can be obtained from 

ONSITE data, or from SURFACE data in the SAMSON, HUSWO or ISHD (TD-3505) formats 

currently supported by AERMET (EPA, 2004). A description of the revised surface file format 

is provided below:

The AERMET Surface File

Header record:

READ( ) latitude, longitude, UA identifier, SF identifier, OS identifier, Version date

FORMAT (2(2X,A8), 8X,' UA_ID: ',A8, ' SF_ID: ',A8, ' OS_ID: ',A8, T85, 'VERSION:', 

A6 )

where latitude = latitude specified in Stage 1 for primary surface station

longitude = longitude specified in Stage 1 for primary surface station

UA identifier = station identifier for upper air data; usually the WBAN 

number used to extract the data from an archive data set

SF identifier = station identifier for hourly surface observations; usually 

the WBAN number used in extracting the data

OS identifier = site-specific identifier

Version date = AERMET version date; this date also appears in the 

banner on each page of the summary reports

Note that the ‘ ??_ID: ’ fields in the FORMAT statement above include two 

spaces before the 2-character pathway ID and one space after the colon.
37

Data records:

READ( ) year, month, day, j_day, hour, H, u* , w* , VPTG, Zic, Zim, L, zo , Bo , r, Ws

, Wd , zref , temp, ztemp, ipcode, pamt, rh, pres, ccvr, WSADJ

FORMAT (3(I2,1X), I3,1X, I2,1X, F6.1,1X, 3(F6.3,1X), 2(F5.0,1X), 

F8.1,1X, F7.4,1X, 2(F6.2,1X), F7.2,1X, F5.0, 3(1X,F6.1), 1X,I5, 

1X,F6.2, 2(1X, F6.0), 1X, I5, 1X, A7)

where j_day = Julian day

H = sensible heat flux (W/m2)

u* = surface friction velocity (m/s)

w* = convective velocity scale (m/s)

VPTG = vertical potential temperature gradient above Zic (K/m)

Zic = height of convectively-generated boundary layer (m)

Zim = height of mechanically-generated boundary layer (m)

L = Monin-Obukhov length (m)

z0 = surface roughness length (m)

B0 = Bowen ratio

r = Albedo

Ws = reference wind speed (m/s)

Wd = reference wind direction (degrees)

zref = reference height for wind (m)

temp = reference temperature (K)

ztemp = reference height for temperature (m)

ipcode = precipitation type code (0=none, 11=liquid, 22=frozen, 

99=missing)

pamt = precipitation amount (mm/hr)

rh = relative humidity (percent)

pres = station pressure (mb)

ccvr = cloud cover (tenths)

WSADJ = wind speed adjustment and data source flag

2.8 BETA OPTION FOR ADJUSTING USTAR UNDER LOW WIND/STABLE 

CONDITIONS

Beginning with version 12345, the AERMET program includes a non-Default BETA 
38

option in Stage 3 processing to adjust the surface friction velocity (u* or ustar) for low wind 

speed stable conditions, based on Qian and Venkatram (2011). The option is selected by 

including the METHOD STABLEBL ADJ_U* keyword on the METPREP pathway in the Stage 

3 input file. In addition, beginning with version 13350, AERMET has incorporated a new 

ADJ_U* option for applications that utilize the Bulk Richardson Number (BULKRN) option for 

estimating the stable boundary layer u* using low-level temperature difference (delta-T) data 

based on Luhar and Rayner (2009)). The syntax of the ADJ_U* BETA option is as follows:

Syntax: METHOD STABLEBL ADJ_U*

Type: Optional, Non-repeatable

The ADJ_U* "BETA" option is considered to be a non-Default option and is therefore 

subject to the alternative model provisions in Section 3.2 of Appendix W (40 CFR Part 51). 

Users should coordinate with the appropriate reviewing authority regarding the procedures and 

requirements for approval of this BETA option for regulatory modeling applications. Although 

AERMET does not include a regulatory default switch, use of this option also requires the user 

to include the BETA option on the CO MODELOPT keyword in the AERMOD input file.

2.9 SUBSTITUTIONS FOR MISSING CLOUD COVER AND TEMPERATURE

Beginning with version 13350, the AERMET program includes substitutions for missing 

cloud cover and temperature data based on linear interpolation across gaps of 1 or 2 hours. 

Linear interpolation across short gaps is a reasonable approach for these variables since ambient 

temperatures tend to follow a diurnal cycle and do not vary significantly from hour to hour, and 

AERMOD is relatively insensitive to hourly fluctuations in cloud cover, especially during 

convective hours since the heat flux is integrated across the day. Furthermore, gaps of 1 or 2 

hours for these parameters near the early morning transition to a convective boundary layer may 

result in all convective hours for that day being missing. 

The cloud cover and temperature substitutions are applied by default, unless the 

application involves both NWS and ONSITE surface data. However, beginning with version 
39

14134, substitutions will be applied by default if the parameter is only available for one type of 

data (NWS or ONSITE). For example, for cases with ONSITE data that includes temperature 

data but no cloud cover data, the cloud cover substitutions will be applied to the NWS data by 

default, but the temperature substitutions will not be applied unless the user specifies the TEMP 

SUB_TT option on the METHOD keyword in Stage 3. Options have also been incorporated in 

AERMET during Stage 3 that allow users to disable cloud cover and/or temperature 

substitutions, irrespective of the type(s) of data being processed. These Stage 3 options also 

allow users to activate these substitutions for cases with both NWS and ONSITE data; however 

this could result in substitutions based on interpolation between NWS and ONSITE values on 

either side of the gap. 

As noted above, the substitutions are based on linear interpolation across gaps of 1 to 2 

hours. Interpolations are only made based on non-interpolated values on both sides of the data 

gap. In addition, beginning with version 14134 substitutions for missing ONSITE temperature 

data are only applied for values from the same measurement level, if multi-level temperature 

data are available. Valid data available for hours 23 and 24 of the previous day are used to 

substitute for missing data for hours 1 and 2. However, since AERMET has not been modified 

to read ahead to extract data for the next day, substitutions for missing data for hour 24 (and hour 

23 if hour 24 is also missing) are based on persistence. 

The options for users to disable or activate the cloud cover (CCVR) and temperature 

(TEMP) substitutions are included under the METHOD keyword in Stage 3. Beginning with 

version 14134, AERMET also allows users to disable interpolations for hours 23 and 24 that are 

based on persistence for CCVR, TEMP or both. The syntax of these options is as follows:
40

Syntax: METHOD CCVR SUB_CC (activates CCVR substitutions)

 or

METHOD CCVR NO_SUB (disables CCVR substitutions)

 or

METHOD CCVR NOPERS (disables CCVR substitutions for

hours 23 and 24 that are based on 

persistence)

---------------------------------------------------------------------------------

METHOD TEMP SUB_TT (activates TEMP substitutions)

 or

METHOD TEMP NOTSUB (disables TEMP substitutions)

 or

METHOD TEMP NOPERS (disables TEMP substitutions for

hours 23 and 24 that are based on 

persistence)

Type: Optional, Non-repeatable (for a given option of CCVR of TEMP)
41

3.0 REFERENCES

EPA, 1997: Analysis of the Affect of ASOS-Derived Meteorological Data on Refined 

Modeling. EPA-454/R-97-014. U.S. Environmental Protection Agency, Research 

Triangle Park, North Carolina 27711.

EPA, 2000. Meteorological Monitoring Guidance for Regulatory Modeling Applications. EPA454/R-99-005. Office of Air Quality Planning & Standards, Research Triangle Park, NC. 

(PB 2001-103606)

EPA, 2004: User=s Guide for the AERMOD Meteorological Preprocessor (AERMET). EPA454/B-03-002. U.S. Environmental Protection Agency, Research Triangle Park, North 

Carolina 27711. 

EPA, 2008: AERSURFACE User’s Guide. EPA-454/B-08-001. U.S. Environmental Protection 

Agency, Research Triangle Park, North Carolina 27711. 

EPA, 2010: AERMINUTE User=s Instructions. EPA-Draft. U.S. Environmental Protection 

Agency, Research Triangle Park, North Carolina 27711. 

Luhar, A.K., and K. N. Rayner, 2009: “Methods to Estimate Surface Fluxes of Momentum and 

Heat from Routine Weather Observations for Dispersion Applications under Stable 

Stratification”, Boundary-Layer Meteorology, 132, 437–454.

NOAA, 2003: ASOS Product Improvement Implementation Plan (Addendum III) For Ice Free 

Wind. National Oceanic and Atmospheric Administration, National Weather Service, 

Silver Spring, Maryland 20910. 

http://www.nws.noaa.gov/ops2/Surface/documents/IFW030515A.pdf

NOAA, 2008: Cup & Vane Wind Data Processing Within ASOS. National Oceanic and 

Atmospheric Administration, National Weather Service, Silver Spring, Maryland 20910.

http://www.nws.noaa.gov/ops2/Surface/documents/IFWS_BelfordWS_comparison.pdf

Qian, W., and A. Venkatram, 2011: "Performance of Steady-State Dispersion Models Under 

Low Wind-Speed Conditions", Boundary Layer Meteorology, 138, 475-491.

Venkatram, A., 1980: Estimating the Monin-Obukhov length in the stable boundary layer for 

dispersion calculations. Bound.Layer Meteor., 19, 481-485.
A-1

APPENDIX A. FUNCTIONAL KEYWORD/PARAMETER REFERENCE

This appendix provides a functional reference for the keywords and parameters used 

by the input runstream files for AERMET. The keywords are organized by functional 

pathway and within each pathway the order of the keywords is alphabetical, excluding the 

keyword that identifies the start of a pathway. The pathways used by AERMET are as 

follows, including the applicable AERMET processing stages and the in the order in which 

they appear in the tables that follow:

JOB - for specifying overall JOB control options (all stages);

UPPERAIR - for processing NWS UPPER AIR data (Stages 1 and 2);

SURFACE - for processing NWS hourly SURFACE data (Stages 1 and 2);

ONSITE - for processing ONSITE meteorological data (Stages 1 and 2);

MERGE - to MERGE the three data types into one file, including

1-minute ASOS wind data, if available (Stage 2);

METPREP - for METeorological data PREParation for use in a dispersion

Model (Stage 3).

Two types of tables are provided for each pathway. The first table lists all of the 

keywords for that pathway, identifies each keyword as to its type (either mandatory or 

optional, either repeatable or non-repeatable, and if it is reprocessed), and provides a brief 

description of the function of the keyword. The second type of table, which may take up 

more than one page, describes each parameter in detail.

The following conventions are used in these tables. The parameter names are intended 

to be descriptive of the input variable being represented. Square brackets around a parameter 

indicate that the parameter is optional for that keyword. The default that is used when an 

optional parameter is left blank is explained in the discussion for that parameter.

Beginning with version 11059, the maximum record length for the AERMET 

runstream input file has been increased from 80 to 132 characters. Another important 

enhancement introduced with version 11059 of AERMET, which applies across all pathways, 

is that the maximum field length for filenames has been increased from 48 to 96 and the use 
A-2

of double quotes (“) as field delimiters for filenames is allowed to support filenames with 

embedded spaces
A-3

TABLE A-1

DESCRIPTION OF JOB PATHWAY KEYWORDS

Keyword Type Description

JOB Optional, 

Non-repeatable

Start of JOB pathway. This statement is optional if the statements 

associated with this block appear first in the input control file.

CHK_SYNTAX Optional, NonrepeatableFlag indicating that only the syntax of the input statements should be 

checked for errors, i.e., no data are processed.

MESSAGES Mandatory, NonrepeatableIdentifies the warning/error messages file.

REPORT Optional, NonrepeatableIdentifies the general report file.

TABLE A-2

DESCRIPTION OF KEYWORD PARAMETERS FOR THE JOB PATHWAY

Keyword Parameters

CHK_SYNTAX <none>

MESSAGES message_filename

 where: message_filename The name of the file where all source-code-generated messages are 

written

REPORT summary_filename

 where: summary_filename The name of the file where AERMET writes a summary of all

preprocessor activity for the current run
A-4

TABLE A-3

DESCRIPTION OF UPPERAIR KEYWORDS

Keyword Type Description

UPPERAIR Mandatory,

Non-repeatable

Start of UPPERAIR pathway.

AUDIT Optional, Repeatable Identify variables to be audited. These are in addition to any 

automatically audited variables.

DATA Mandatory, Non-repeatable, 

Reprocessed

File name of raw upper air data.

EXTRACT Mandatory, Non-repeatable File name of extracted upper air data.

LOCATION Mandatory, Non-repeatable,

Reprocessed

Site ID and location information. Required only for extraction 

processing.

MODIFY Optional, Non-repeatable,

Reprocessed

Flag indicating corrections should be made to the sounding data 

when extracted. See '5 for a discussion of these corrections

NO_MISSING Optional, Repeatable Identifies those variables to QA and summarize the messages 

only; detailed message identifying the violation and date is 

suppressed

QAOUT Mandatory, Non-repeatable File name of upper air data for quality assessed output/ merge 

input

RANGE Optional, Repeatable,

Reprocessed

Set new upper and lower bounds and missing values for QA of 

the variable listed.

XDATES Mandatory, Non-repeatable Inclusive dates identifying the period of time to extract from the 

archive data file.
A-5

TABLE A-4

DESCRIPTION OF KEYWORD PARAMETERS FOR THE UPPERAIR PATHWAY

Keyword Parameter(s)

AUDIT uaname1 ... uanameN

where: uaname1 ... uanameN Name(s) of variables that are to be tracked and reported during quality 

assessment (as defined in Table B-1 of Appendix B).

DATA archive_filename file_format 

 where: archive_filename

file_format

The name of the file containing the archive of upper air data

Archive file format; valid parameters are:

6201FB (TD-6201 fixed-length blocks)

 or

6201VB (TD-6201 variable-length blocks)

 or

FSL for data retrieved from National Climatic Data Center 

(NCDC) web site. Also available on the ‘Radiosonde Data of 

North America’ CD-ROM.

NOTE: The blocking factor and data type (ASCII or EBCDIC) 

parameters are no longer supported by AERMET, beginning with 

version 11059. The default values for these parameters are 1 for 

blocking factor and ASCII for data type. AERMET will issue a 

warning message if these parameters are included in on the DATA 

keyword.

EXTRACT extracted_data_filename

where: extracted_data_ 

filename

Name of the output file for data extracted from an archive data file and 

the name of the input file for upper air data QA
A-6

TABLE A-4, continued

DESCRIPTION OF KEYWORD PARAMETERS FOR THE UPPERAIR PATHWAY

Keyword Parameter(s)

LOCATION site_id lat(long) long(lat) [tadjust] 

 where: site_id

lat(long)

long(lat)

[tadjust]

Site identifier for which data are to be processed.

Station latitude (or longitude) in decimal degrees with the suffix N for 

sites north of the equator, S for sites south of the equator (or W for sites 

west of Greenwich, E for sites east of Greenwich).

Station longitude (or latitude) in decimal degrees with the suffix W for 

sites west of Greenwich, E for sites east of Greenwich (or N for sites 

north of the equator, S for sites south of the equator).

An integer used to convert the time reported in the database to local 

Standard time. For standard upper-air data reported in Greenwich 

Mean Time (GMT), the value is the same as the time zone for the 

station (e.g., a value of 5 for the Eastern time zone). 

NOTE: Beginning with version 11059, the optional station elevation 

parameter is no longer supported on the UPPERAIR pathway.

MODIFY <none>

NO_MISSING uaname1 . . . uanameN

 where: uaname1 . . . 

 . . . uanameN

Suppresses missing data messages for the upper air variables specified, 

as defined in Appendix B; the number of times the variable is missing 

is not tallied

QAOUT qa_output_filename

where: qa_output_ filename Name of the output file from the QA/input to merge data
A-7

TABLE A-4, continued

DESCRIPTION OF KEYWORD PARAMETERS FOR THE UPPERAIR PATHWAY

Keyword Parameter(s)

RANGE uaname lower_bound <[=] upper_bound missing_indicator

where: uaname

lower_bound

<[=]

upper_bound

missing_indicator

Variable name, as defined in Table B-1

Minimum value of the valid range of values for uaname

Exclude (<) or include (<=) the lower and upper bounds (the endpoints) in 

the QA

Maximum value of the valid range of values for uaname

Value to indicate the value is missing

XDATES YB/MB/DB [TO] YE/ME/DE

YB/MB/DB

[TO]

YE/ME/DE

Beginning year, month and day to extract; the slash (/) between each part 

of the date field is required; there can be no blanks in this parameter

Optional; used to make this record more readable

Ending year, month and day to extract; the slash (/) between each part of 

the date field is required; there can be no blanks in this parameter
A-8

TABLE A-5

DESCRIPTION OF SURFACE PATHWAY KEYWORDS

Keyword Type Description

SURFACE Mandatory, Non-repeatable Start of SURFACE pathway.

ASOS1MIN Optional, Non-repeatable File name for 1-minute ASOS wind data to be merged in Stage 2

AUDIT Optional, Repeatable Identify variables to be audited. These are in addition to any 

automatically audited variable.

DATA Mandatory, Non-repeatable, 

Reprocessed

Input file name of raw surface data.

EXTRACT Mandatory, Non-repeatable File name of extracted surface data.

LOCATION Mandatory, Non-repeatable,

Reprocessed

Site ID and location information.

NO_MISSING Optional, Repeatable Identifies those variables to QA and summarize the messages 

only; detailed message identifying the violation and date is 

suppressed.

QAOUT Mandatory, Non-repeatable File name for hourly surface data for quality assessed 

output/merge input.

RANGE Optional, Repeatable,

Reprocessed

Set new upper and lower bounds and missing values for QA of 

the variable listed.

XDATES Mandatory, Non-repeatable Inclusive dates identifying the period of time to extract from the 

archive data file.
A-9

TABLE A-6

DESCRIPTION OF KEYWORD PARAMETERS FOR THE SURFACE PATHWAY

Keyword Parameter(s)

ASOS1MIN asos1min_filename

where: asos1min_filename Filename for hourly-averaged wind speed and direction derived from 

1-minute ASOS wind data (TD-6405), to be merged in Stage 2

AUDIT sfname1 ... sfnameN

 where: sfname1 ...

 ... sfnameN

Name(s) of variables that are to be tracked and reported during quality 

assessment (as defined in Table B-2 of Appendix B).

DATA archive_filename file_format [ASOS]

 where: archive_filename

file_format

[ASOS]

The name of the file containing the archive of hourly surface observations

Archive file format; valid parameters are:

CD144

 or

SCRAM

 or

SAMSON (data retrieved from SAMSON CD-ROM)

 or

3280VB and 3280FB

 or

HUSWO (data retrieved from HUSWO CD-ROM; 

assumes metric units)

 or

ISHD (data in the full archival TD-3505 format)

Optional parameter to indicate that ISHD data are from an Automated 

Surface Observing System (ASOS) site. This parameter is only allowed with 

the ISHD file format, and instructs AERMET to apply the wind speed 

truncation adjustment to all hours (see Section 2.3.2). Beginning with version 

11059, AERMET includes a table of ASOS commission dates, which is used 

to identify whether surface data input to AERMET are from an ASOS site. 

The optional ‘ASOS’ parameter for ISHD data should only be used if the 

data are known to be from an ASOS site which is not included in the ASOS 

station list within AERMET.

NOTE: The blocking factor and data type (ASCII or EBCDIC) parameters 

are no longer supported by AERMET, beginning with version 11059. The 

default values for these parameters are 1 for blocking factor and ASCII for 

data type. AERMET will issue a warning message if these parameters are 

included on the DATA keyword.
A-10

TABLE A-6, continued

DESCRIPTION OF KEYWORD PARAMETERS FOR THE SURFACE PATHWAY

Keyword Parameter(s)

EXTRACT extracted_data_filename

 where: extracted_data_

 filename

Name of the output file for data extracted from an archive data file

LOCATION site_id lat(long) long(lat) [tadjust] [elevation]

 where: site_id

lat(long)

long(lat)

[tadjust]

[elevation]

Site identifier for which data are to be processed.

Station latitude (or longitude) in decimal degrees with the suffix N for 

sites north of the equator, S for sites south of the equator (or W for sites 

west of Greenwich, E for sites east of Greenwich).

Station longitude (or latitude) in decimal degrees with the suffix W for 

sites west of Greenwich, E for sites east of Greenwich (or N for sites 

north of the equator, S for sites south of the equator).

An integer used to convert the time reported in the database to local 

Standard time. For most surface databases, the value is 0. For TD-3505 

(ISHD) data, which is reported in GMT, the value is the same as the time 

zone for the station (e.g., a value of 5 for the Eastern time zone).

Station elevation (m above sea-level); default of 0m if omitted.

NO_MISSING sfname1 . . . sfnameN

 where: sfname1 . . . 

 . . . sfnameN

Suppresses missing data messages for the surface variables specified, as 

defined in Appendix B; the number of times the variable is missing is 

not tallied

QAOUT qa_output_filename

where: qa_output_filename Name of the output file from the QA/input to merge data

RANGE sfname lower_bound <[=] upper_bound missing_indicator

where: sfname

lower_bound

<[=]

upper_bound

missing_indicator

Variable name, as defined in Table B-2

Minimum value of the valid range of values for sfname

Exclude (<) or include (<=) the lower and upper bounds in the QA

Maximum value of the valid range of values for sfname

Value to use to indicate the observed variable is missing
A-11

TABLE A-6, continued

DESCRIPTION OF KEYWORD PARAMETERS FOR THE SURFACE PATHWAY

Keyword Parameter(s)

XDATES YB/MB/DB [TO] YE/ME/DE

where: YB/MB/DB

[TO]

YE/ME/DE

Beginning year, month and day to extract; the slash (/) between each 

part of the date field is required; there can be no blanks in this parameter

Optional; used to make this record more readable

Ending year, month and day to extract; the slash (/) between each part of 

the date field is required; there can be no blanks in this parameter
A-12

TABLE A-7

DESCRIPTION OF ONSITE PATHWAY KEYWORDS

Keyword Type Description

ONSITE Mandatory, Non-repeatable Start of ONSITE pathway.

AUDIT Optional, Repeatable Identify variables to be audited. These variables are in addition 

to any automatically audited variables.

DATA Mandatory, Non-repeatable, 

Reprocessed

Input file name of site-specific data.

DELTA_TEMP Optional, Repeatable,

Reprocessed

Define heights (meters) for temperature differences.

FORMAT Mandatory, Repeatable,

Reprocessed

FORTRAN format for reading one site-specific data record.

LOCATION Mandatory, Non-repeatable,

Reprocessed

Site ID and location information.

NO_MISSING Optional, Repeatable Identifies those variables to QA and summarize the messages 

only; detailed message identifying the violation and date is 

suppressed.

OBS/HOUR Optional*, Non-repeatable Number of observations each hour. 

 *Mandatory only if the observations are more frequent than 

 once per hour.

OSHEIGHTS Optional*, Repeatable,

Reprocessed

Define heights of the site-specific measurements.

 *Mandatory if the heights are not defined in the data file.
A-13

Table A-7, continued

DESCRIPTION OF ONSITE PATHWAY KEYWORDS

Keyword Type Description

QAOUT Mandatory, Non-repeatable File name of site-specific data for quality assessment 

output/merge input

RANGE Optional, Repeatable,

Reprocessed

Set new upper and lower bounds and missing values for QA of 

the variable listed.

READ Mandatory, Repeatable,

Reprocessed

Defines the name and order of variables as they appear in the 

site-specific DATA file.

THRESHOLD Mandatory, Non-repeatable,

Reprocessed

Sets the minimum wind speed (meters/second) below which 

the wind is treated as calm.

XDATES Optional, Non-repeatable Inclusive dates for data processing.
A-14

TABLE A-8

DESCRIPTION OF KEYWORD PARAMETERS FOR THE ONSITE PATHWAY

Keyword Parameter(s)

AUDIT osname1 . . . osnameN

where: osname1 . . .

 . . . osnameN

Name(s) of variables, as defined in Table B-3 of Appendix B, that are to 

be tracked during the quality assessment

DATA Filename

 where: Filename The name of the file containing the ONSITE data

DELTA_TEMP index lower_height upper_height

 where: index

lower_height

upper_height

Index for the ith temperature difference measurement

Lower measurement height for the ith temperature difference

Upper measurement height for the ith temperature difference

FORMAT record_index Fortran_format

where: record_index

Fortran_format

Specifies the record # in the ONSITE data to which the Fortran format 

refers; linked to record_index on corresponding READ keyword

The Fortran format used to read the ONSITE data record:

May be defined using a Fortran format specifier or as free-formatted 

(also called list-directed) data using the optional ‘FREE’ parameter 

(without quotes and not case-sensitive). The Fortran format specifier 

must include open and close parentheses and must fit within the 

record length of the runstream image (up to 132 characters including 

keyword and record index), and may include embedded spaces.

Note that date variables are read as INTEGER format (Fortran ‘I’ 

format) and all other data variables are read as REAL format 

(Fortran ‘F’ or ‘E’ format). Using an ‘F’ or ‘E’ format specifier to 

read date variables or ‘I’ format specifier to read other data variables 

will cause an AERMET runtime error. See Section 2.4 for a more 

detailed discussion of the READ and FORMAT keywords.
A-15

TABLE A-8, continued

DESCRIPTION OF KEYWORD PARAMETERS FOR THE ONSITE PATHWAY

Keyword Parameter(s)

LOCATION site_id lat(long) long(lat) [tadjust] [elevation]

 where: site_id

lat(long)

long(lat)

[tadjust]

[elevation]

Site identifier for which data are to be processed.

Station latitude (or longitude) in decimal degrees with the suffix N for sites 

north of the equator, S for sites south of the equator (or W for sites west of 

Greenwich, E for sites east of Greenwich).

Station longitude (or latitude) in decimal degrees with the suffix W for sites 

west of Greenwich, E for sites east of Greenwich (or N for sites north of the 

equator, S for sites south of the equator).

An integer used to convert the time reported in the database to local 

Standard time. For most onsite databases, the value is 0. 

Station elevation (m above sea-level); default of 0m if omitted.

NO_MISSING osname1 . . . osnameN

where: osname1 . . .

 osnameN

Suppresses missing data messages for the ONSITE variables specified, as 

defined in Appendix B; the number of time the variable is missing is not 

tallied

OBS/HOUR n_obs

 where: n_obs Number of time periods per hour the ONSITE data are reported; for 

example if the data are recorded every 15 minutes, then n_obs = 4. 

Maximum value is 12, corresponding with 5-minute averages.

If OBS/HOUR is not specified, AERMET will assume 1 observation per 

hour.

OSHEIGHTS height1 ... heightN

 where: height1 . . .

 heightN

Heights of the ONSITE data measurements; can be used to specify heights 

if they are not included in the data file. Must be in ascending order from 

lowest to highest height. If the OSHEIGHTS keyword is specified and 

heights are also defined in the data file, the OSHEIGHTS input will be used 

and values in the data file (HT01, HT02, etc.) will be ignored.

See Section 2.5 for a more detailed discussion about specifying 

measurement heights.
A-16

TABLE A-8, continued

DESCRIPTION OF KEYWORD PARAMETERS FOR THE ONSITE PATHWAY

Keyword Parameter(s)

QAOUT qa_output_filename

 where: qa_output_

 filename

File name of the quality assessment output/merge input.

RANGE osname lower_bound <[=] upper_bound missing_indicator

where: osname

lower_bound

<[=]

upper_bound

missing_indicator

Variable name, as defined in Table B-3.

Minimum value of the valid range of values for osname.

Determines whether to include (<=) or exclude (<) the lower and upper 

bounds in the range of acceptable values Exclude (<) or include (<=) the 

lower and upper bounds (the endpoints) in the QA. 

Maximum value of the valid range of values for osname.

Value to use to indicate the value is missing.

NOTE: Beginning with version 11059, AERMET allows the use of 

REAL values for lower_bound, upper_bound, and missing_indicator.

READ record_index osname1 . . . osnameN

where: record_index

osname1 ...

 osnameN

Links the list of variables named on this keyword statement to a Fortran 

format defined on a FORMAT keyword statement. While the 

corresponding Fortran format specifier must fit within a single record in 

the runstream input file (up to 132 characters total per record), multiple 

READ keywords can be used to list variables for a single read by 

repeating the same record_index.

Specifies the list and order of variables in the ONSITE data file that are 

to be read. See Appendix B for ONSITE variable names.

See Section 2.4 for a more detailed discussion of the READ and 

FORMAT keywords.
A-17

TABLE A-8, continued

DESCRIPTION OF KEYWORD PARAMETERS FOR THE ONSITE PATHWAY

Keyword Parameter(s)

THRESHOLD threshold_wind_speed

where: threshold_

 wind_speed

Minimum valid wind speed for the ONSITE measurements; cannot 

exceed 1.0 ms-1

XDATES YB/MB/DB [TO] YE/ME/DE

where: YB/MB/DB

[TO]

YE/ME/DE

Beginning year, month and day to QA; the slash (/) between each part of 

the date field is required; there can be no blanks in this parameter.

Optional; used to make this record more readable.

Ending year, month and day to QA; the slash (/) between each part of the 

date field is required; there can be no blanks in this parameter.
A-18

TABLE A-9

DESCRIPTION OF MERGE PATHWAY KEYWORDS

Keyword Type Description and Usage

MERGE Mandatory, Non-repeatable Start of MERGE pathway.

OUTPUT Mandatory, Non-repeatable File identifier for merged data.

XDATES Optional, Non-repeatable Inclusive dates for data processing. If omitted, the earliest date 

found in the data is used as the beginning date and the ending date 

is 367 days later. However, AERMET can MERGE multi-year 

data files if the XDATES keyword is specified.

TABLE A-10

DESCRIPTION OF KEYWORD PARAMETERS FOR THE MERGE PATHWAY

Keyword Parameter(s)

OUTPUT merged_data_filename

where: merged_data_filename Name of the output file from STAGE 2.

XDATES YB/MB/DB [TO] YE/ME/DE

where: YB/MB/DB

[TO]

YE/ME/DE

Beginning year, month and day to merge; the slash (/) between 

each part of the date field is required; there can be no blanks in 

this parameter.

Optional; used to make this record more readable.

Ending year, month and day to merge; the slash (/) between each 

part of the date field is required; there can be no blanks in this 

parameter.
A-19

TABLE A-11

DESCRIPTION OF METPREP PATHWAY KEYWORDS

Keyword Type Description and Usage

METPREP Mandatory, Non-repeatable Start of METPREP pathway.

AERSURF Optional, Non-repeatable Specify file name for primary surface characteristics, such as 

output file from AERSURFACE; contains FREQ_SECT, 

SECTOR, and SITE_CHAR keyword inputs.

AERSURF2 Optional, Non-repeatable Specify file name for secondary surface characteristics, such as 

output file from AERSURFACE; inputs in the AERSURF2 file 

are interpreted as secondary site characteristics, and may contain 

FREQ_SECT2, SECTOR2, and SITE_CHAR2 keyword inputs, 

or FREQ_SECT, SECTOR, and SITE_CHAR keywords. This 

allows users to include data from an AERSURFACE output file 

as secondary site characteristics without having to edit the file to 

change the keywords.

DATA Mandatory, Repeatable Input filename of merged data.

FREQ_SECT Mandatory, Repeatable,

Reprocessed

Number of surface characteristics by wind direction sector and 

time period for the primary location. Must precede SECTOR 

and SITE_CHAR statements, and also must precede secondary 

site keywords, if provided.

FREQ_SECT2 Conditional

*

, Repeatable,

Reprocessed

Number of surface characteristics by wind direction sector and 

time period for the secondary location. *

Must be specified if both ONSITE and NWS winds are 

included, and must precede SECTOR2 and SITE_CHAR2

statements.

LOCATION If UPPERAIR data are 

available (with or without 

ONSITE mixing heights):

OBSOLETE

Beginning with AERMET 

version 13350, if ONSITE 

mixing heights are used 

without UPPERAIR data:

Mandatory, Non-repeatable

The LOCATION keyword under the METPREP pathway in 

Stage 3 is no longer used by AERMET, unless ONSITE mixing 

heights are used without any UPPERAIR data. 

For applications with UPPERAIR data, sunrise for CBL height 

calculations is based on the primary surface station location in 

Stage 1; either the ONSITE pathway, if available, or the 

SURFACE pathway. A warning message will be generated in 

these cases if the LOCATION keyword is included under the 

METPREP pathway, and the METPREP inputs will be ignored.

For applications with only ONSITE mixing heights, without 

UPPERAIR data, the LOCATION keyword under the 

METPREP should be used to specify the conversion from GMT

to LST.

METHOD Conditional*,

Repeatable

Specify processing methodology used for a particular variable. * whether or not this keyword is mandatory depends on the

 processing to be performed and the types of data included in

 the merged database
A-20

TABLE A-11, continued

DESCRIPTION OF METPREP PATHWAY KEYWORDS

Keyword Type Description and Usage

MODEL Optional, Non-repeatable Name of model for which data are processed. Default: 

AERMOD

NWS_HGT Conditional

*

, Non-repeatable NWS instrument height, in meters, for the specified variable. 

* Mandatory if METHOD REFLEVEL SUBNWS is specified

SECTOR Mandatory, Repeatable,

Reprocessed

Defines a wind direction sector in degrees for the primary

location. See also FREQ_SECT and SITE_CHAR.

SECTOR2 Conditional**, Repeatable,

Reprocessed

Defines a wind direction sector in degrees for the secondary

location. See also FREQ_SECT2 and SITE_CHAR2.

SITE_CHAR Mandatory, Repeatable,

Reprocessed

Define the direction-dependent surface characteristics of albedo, 

Bowen ratio, and surface roughness length (meters) for the 

primary location. See also FREQ_SECT and SECTOR.

SITE_CHAR2 Conditional**, Repeatable,

Reprocessed

Define the direction-dependent surface characteristics of albedo, 

Bowen ratio, and surface roughness length (meters) for the 

secondary location. See also FREQ_SECT2 and SECTOR2.

THRESH_1MIN Optional, Non-repeatable Option to specify a wind speed threshold for winds derived from 

1-minute ASOS wind data processed through AERMINUTE.

UAWINDOW Optional, Non-repeatable Specifies the time window to use for selecting upper air 

sounding.

XDATES Optional, Non-repeatable Inclusive dates for data processing.

** Surface characteristics for the secondary site (SECTOR2 and SITE_CHAR2) are required for applications with 

ONSITE data and with the REFLEVEL SUBNWS option under the METHOD keyword to substitute for 

missing ONSITE wind data.
A-21

TABLE A-12

DESCRIPTION OF KEYWORD PARAMETERS FOR THE METPREP PATHWAY

Keyword Parameter(s)

AERSURF

AERSURF2

primary_surfchar_filenam (for primary surface data location)

secondary_surfchar_filenam (for optional secondary surface data location)

 where: primary_surfchar_f

ilenam

secondary_surfchar

_filenam

The name of the file containing the surface characteristic inputs for the 

primary surface data location (FREQ_SECT, SECTOR, and SITE_CHAR 

keywords)

The name of the file containing the surface characteristic inputs for the 

secondary surface data location (FREQ_SECT2, SECTOR2, and 

SITE_CHAR2 keywords)

DATA merged_data_filename

 where: merged_data_

 _filename

The name of the file containing the merged NWS and, if any, site-specific 

data 

FREQ_SECT

FREQ_SECT2

frequency number_of_sectors (for primary surface data location)

frequency number_of_sectors (for optional secondary surface data location)

where: frequency

number_of_

 sectors

Specifies how often the surface characteristics change; valid parameters 

are:

MONTHLY - every calendar month

SEASONAL - where the seasons are defined as:

Spring = March, April, May

Summer = June, July, August

Autumn = September, October, November

Winter = December, January, February

ANNUAL - constant for the entire year

Specifies the number of wind direction sectors by which the surface 

characteristics vary
A-22

TABLE A-12, continued

DESCRIPTION OF KEYWORD PARAMETERS FOR THE METPREP PATHWAY

Keyword Parameter(s)

LOCATION site_id lat(long) long(lat) [tadjust] [elevation]

where: site_id

lat(long)

long(lat)

[tadjust]

[elevation]

Site identifier for which data are to be processed.

Station latitude (or longitude) in decimal degrees with the suffix N for

sites north of the equator, S for sites south of the equator (or W for

sites west of Greenwich, E for sites east of Greenwich).

Station longitude (or latitude) in decimal degrees with the suffix W for

sites west of Greenwich, E for sites east of Greenwich (or N for sites

north of the equator, S for sites south of the equator).

An integer used to convert the time reported in the database to local

Standard time. For standard upper-air data reported in Greenwich

Mean Time (GMT), the value is the same as the time zone for the

station (e.g., a value of 5 for the Eastern time zone).

Station elevation (m above sea-level); default of 100m if omitted.

Note: The optional station elevation on the UPPERAIR pathway is

currently not used by AERMET.

NOTE: The LOCATION keyword under the METPREP pathway is obsolete 

for applications that include UPPERAIR data, and inputs will be ignored; 

however, applications that use only ONSITE mixing heights, without 

UPPERAIR data, should still use the LOCATION keyword under the 

METPREP pathway to specify the conversion from GMT to LST.
A-23

METHOD atmos_variable option

where: atmos_variable

option

Identifies the variable that will be processed:

UASELECT – selecting upper air sounding.

WIND_DIR – processing of NWS wind directions.

REFLEVEL – substitution of NWS data 

STABLEBL – specify option for SBL processing 

ASOS_ADJ – adjustment of ASOS wind speeds for truncation

CCVR – option to substitute for missing cloud cover

TEMP – option to substitute for missing temperature

Processing options:

For UASELECT, valid parameters are:

SUNRIS(E) – select upper air sounding based on local sunrise

For WIND_DIR (not applicable to 1-min ASOS data), valid parameters are:

NORAND – leave NWS wind directions to the nearest 10o (default)

 or RANDOM – randomize NWS wind directions.

For REFLEVEL, valid parameters are:

SUBNWS – allows substitution of NWS data for missing ONSITE 

wind and/or temp data (other parameters automatically substituted); 

NOTE: this option must be used if no ONSITE data are provided.

For STABLEBL, valid parameters are:

BULKRN – Bulk Richardson Number - This option requires onsite 

measurements of temperature difference.

ADJ_U* – Non-Default/BETA option to adjust U* (surface friction 

velocity) for low wind/stable conditions. For applications without the 

BULKRN option, the ADJ_U* option is based on Qian and 

Venkatram (2011). For applications with the BULKRN option, the 

ADJ_U* option is based on Luhar and Rayner (2009).

For ASOS_ADJ, valid parameters are:

NO_ADJ – do not adjust ASOS wind speeds for truncation.

For CCVR, valid parameters are:

SUB_CC – select option to substitute for missing cloud cover

NO_SUB – disable option to substitute for missing cloud cover

NOPERS – disable subs for hrs 23 and 24 based on persistence

For TEMP, valid parameters are:

SUB_TT – select option to substitute for missing temperature

NOTSUB – disable option to substitute for missing temperature

 (NO_SUB can also be used for TEMP)

NOPERS – disable subs for hrs 23 and 24 based on persistence

NOTE: The CCVR and TEMP substitutions are used by default, unless the 

application involves both NWS and ONSITE surface data, or only ONSITE 

data with NRAD or with INSO data and the BULKRN option. Substitutions 

can be disabled, and can also be activated for cases with both NWS and 

ONSITE data by specifying the appropriate parameters. Substitutions are 

based on linear interpolation across gaps of 1 to 2 hours, unless the missing 

data are for hours 23 or 24, where persistence is assumed. Interpolations are 

only made based on non-interpolated values on both sides of the data gap.
A-24

TABLE A-12, continued

DESCRIPTION OF KEYWORD PARAMETERS FOR THE METPREP PATHWAY

Keyword Parameter(s)

MODEL model_name

where: model_name Name of the dispersion model which uses the output files generated 

by AERMET. Allowable names are:

AERMOD

NWS_HGT variable_name instrument_height

where: variable_name

instrument_height

Weather variable that requires an instrument height to be defined; 

valid names are:

WIND (to specify anemometer height)

Height of the instrument above ground, in meters.

OUTPUT parameter_filename

where: parameter_

 filename

Name of the output file from STAGE 3, with one record per hour

PROFILE profile_filename

where: profile_name Name of the output file containing multi-level onsite data, or single 

level wind and temperature data from NWS site

SECTOR

SECTOR2

sector_index beginning_direction ending_direction (for primary data location)

sector_index beginning_direction ending_direction (for optional secondary data location)

where: sector_index

beginning_

 direction

ending_direction

Index that links a specific set of site characteristics to a specific wind 

sector.

Specifies the beginning wind direction of the sector, and is considered 

a part of this sector.

Specifies the ending wind direction of the sector, and is NOT 

considered a part of the sector

NOTE: The end of one sector must be the same as the beginning of 

the next sector.
A-25

TABLE A-12, continued

DESCRIPTION OF KEYWORD PARAMETERS FOR THE METPREP PATHWAY

Keyword Parameter(s)

SITE_CHAR

SITE_CHAR2

frequency_index sector_index albedo Bowen roughness (for primary data location)

frequency_index sector_index albedo Bowen roughness (for secondary data location)

 where: frequency_index

sector_index

albedo

Bowen

roughness

Index of the time period for which the surface characteristics apply;

 for ANNUAL on FREQ_SECT keyword, valid values:

1 (for the entire year)

 for MONTHLY on FREQ_SECT keyword, valid values: 

1 ... 12 (corresponding to each month of the year)

 for SEASONAL on FREQ_SECT keyword, valid values:

1 = Winter = December, January, February

2 = Spring = March, April, May

3 = Summer = June, July, August

4 = Autumn = September, October, November

Sector corresponding to direction from which the wind is blowing.

Albedo for the frequency index and sector index specified.

Bowen ratio for the frequency index and sector index specified.

Surface roughness for the frequency index and sector index 

specified.

THRESH_1MIN threshold_speed 

where: threshold_speed Threshold wind speed in m/s for wind speeds derived from 1-minute 

ASOS wind data processed through the AERMINUTE program. 

If the user specifies a threshold speed greater than 0.5 m/s, a 

warning is issued by AERMET. If a threshold wind speed 

greater than 1.0 m/s is specified, AERMET considers this a fatal 

error, will issue an error message and will not process data 

through Stage 3. 

UAWINDOW window_begin window_end 

where: window_begin

window_end 

Beginning of the sounding window, entered as the number of hours 

relative to the preferred sounding time (12Z, 00Z or -12Z for the 

default selection; or local sunrise for the UASELECT SUNRIS 

option)

Ending of the sounding window entered as the number of hours 

relative to the preferred sounding time 

NOTE: A negative number indicates the number of hours before the 

reference sounding (or sunrise), and a positive number indicates 

the number of hours after the sounding (or sunrise)

XDATES YB/MB/DB [TO] YE/ME/DE
A-26

where: YB/MB/DB

[TO]

YE/ME/DE

Beginning year, month and day to process; a slash (/) between each 

part of the date field is required; with no blanks

Optional; used to make this record more readable

Ending year, month and day to process; a slash (/) between each part 

of the date field is required; with no blanks
B-1

APPENDIX B. VARIABLE NAMES AND DEFAULT QA VALUES

This appendix lists the variable names for each type of data and provides a short 

description of and the units for each variable, and gives the default bounds and missing value 

codes. This information is presented in the tables (Tables B-1, B-2, B-3a, and B-3b) that 

follow, with each table divided into the following fields:

Variable Name

This is the four-character name that can be used on RANGE, AUDIT, and READ 

statements. An asterisk (*) indicates that the variable is automatically included in the 

QA for the path and need not be specified on an AUDIT record in the control file.

Description and Units

A brief description of each variable and the units follow the name. For UPPERAIR and 

SURFACE, real variables are stored as integers, in which case the units include a 

multiplier, such as *10 or *100, in order to maintain additional significant digits. For 

example, if the units are °C*10, then 1.5 °C is stored and referenced as 15.

Type of Check

The type of check determines whether to include (<=) or exclude (<) the lower and 

upper bounds in the range of acceptable values, and can be changed on a RANGE 

statement for specific variables.

Missing Value Code

The missing value code is the value that AERMET interprets to mean that a value is not 

present. It is also the value written/stored by AERMET when the variable is not present 

or cannot be calculated.

Bounds

The last two fields are the lower and upper bounds that determine the interval of 

acceptable values. The value of the variable is accepted if it lies within this interval, 

where the endpoints are either included or excluded according to the Type of Check. 

Note that the multiplier, if present, must also be applied to these values.
B-2

TABLE B-1

VARIABLE AND QA DEFAULTS FOR THE UPPERAIR VARIABLES

Variable 

Name Description Units Type*

Missing 

Indicator

Lower 

Bound

Upper 

Bound

UAPR Atmospheric pressure millibars*10 < 99999 5000 10999

UAHT Height above ground meters <= 99999 0 5000

UATT Dry bulb temperature oC*10 < 9990 350 +350

UATD Dew point temperature oC*10 < 9990 350 +350

UAWD Wind direction degrees from north <= 999 0 360

UAWS Wind speed meters/second *10 < 9990 0 500

UASS Wind speed shear (m/s)/(100 meters) <= 9999 0 5

UADS Wind direction shear degrees/(100 meters) <= 9999 0 90

UALR Temperature lapse rate oC/(100 meters) <= 9999 2 5

UADD Dew point deviation oC/(100 meters) <= 9999 0 2

* Type determines whether to include (<=) or exclude (<) the lower and upper bounds in 

the range of acceptable values, and can be changed on a RANGE statement.
B-3

TABLE B-2

VARIABLE AND QA DEFAULTS FOR THE SURFACE VARIABLES

Variable 

Name Description Units Type

Missing 

Indicator

Lower 

Bound

Upper 

Bound

PRCP Precipitation amount millimeters*100 <= -9 0 25400

SLVP† Sea level pressure millibars*10 < 99999 9000 10999

PRES Station pressure millibars*10 < 99999 9000 10999

CLHT Ceiling height kilometers*10 <= 999 0 300

TSKC Total//opaque sky cover tenths//tenths <= 9999 0 1010

ALC1a Sky cond//height, level 1 code//hundredths ft <= 09999 0 07300

ALC2a Sky cond//height, level 2 code//hundredths ft <= 09999 0 07300

ALC3a Sky cond//height, level 3 code//hundredths ft <= 09999 0 07300

ALC4b Sky cond//height, level 4 code//hundredths ft <= 09999 0 07850

ALC5b Sky cond//height, level 5 code//hundredths ft <= 09999 0 07850

ALC6b Sky cond//height, level 6 code//hundredths ft <= 09999 0 07850

PWVC Present weather (vicinity) <= 9999 0 9800

PWTH Precipitation type <= 9999 0 9800

ASKYc ASOS Sky condition tenths <= 99 0 10

ACHTd ASOS Ceiling kilometers*10 <= 999 0 888

HZVS Horizontal visibility kilometers*10 <= 99999 0 1640

TMPD* Dry bulb temperature oC*10 < 999 -300 360

TMPW Wet bulb temperature oC*10 < 999 -650 350

DPTP Dew-point temperature oC*10 < 999 -650 350

RHUM Relative humidity whole percent <= 999 0 100

WDIR* Wind direction tens of degrees <= 999 0 36

WSPD* Wind speed meters/second*10 <= 999 0 500

* Automatically included in audit report. † A value < 800 in CD144 files is converted to SLVP/10.0 + 1000.0

// The two variables have been combined to form one variable; the missing value flags, as 

well as the upper and lower bounds have also been concatenated.

a ASOS sky condition (code table) and height (hundredths of feet) for levels 1-3 b ASOS sky condition (code table) and height (hundredths of feet) for levels 4-6

(for augmented sites) c ASOS sky condition (tenths), derived from layer data.

d ASOS ceiling (kilometers *10), derived from layer data.
B-4

TABLE B-3a

VARIABLE AND QA DEFAULTS FOR THE ONSITE (SITE-SPECIFIC)

SINGLE-VALUE AND DATE/TIME VARIABLES

Variable 

Name Description Units Type*

Missing 

Indicator

Lower 

Bound

Upper 

Bound

HFLX Surface heat flux watts/square meter < -999 -100 800

USTR Surface friction velocity meters/second < -9 0 2

MHGT Mixing height meters < 9999 0 4000

ZOHT Surface roughness length meters < 999 0 2

SAMT Snow amount centimeters <= 999 0 250

PAMT Precipitation amount centimeters <= 999 0 25

INSO Insolation watts/square meter <= 9999 0 1250

NRAD Net radiation watts/square meter < 999 -100 800

DT01 Temperature diff.(U - L)1 °C < 9 -2 5

DT02 Temperature diff.(U - L)1 °C < 9 -2 5

DT03 Temperature diff.(U - L)1 °C < 9 -2 5

US01 User's scalar #1 user's units < 999 0 100

US02 User's scalar #2 user's units < 999 0 100

US03 User's scalar #3 user's units < 999 0 100

PRCP Precipitation millimeters*100 <= -9 0 25400

SLVP Sea level pressure millibars*10 < 99999 9000 10999

PRES Station pressure millibars*10 < 99999 9000 10999

CLHT Ceiling height kilometers*10 <= 999 0 300

TSKC Sky cover (total or opaque) tenths <= 99 0 10

OSDY Day <= -9 1 31

OSMO Month <= -9 1 12

OSYR Year <= -9 0 99

OSHR Hour <= -9 0 24

OSMN Minutes <= -9 0 60

1(U - L) indicates (upper level) - (lower level).

* Type determines whether to include (<=) or exclude (<) the lower and upper bounds in 

the range of acceptable values, and can be changed on a RANGE statement.

Note: Shaded parameters are not currently used in AERMET.
B-5

TABLE B-3b

VARIABLE AND QA DEFAULTS FOR THE ONSITE (SITE-SPECIFIC)

MULTI-LEVEL VARIABLES

Variable 

Name Description Units Type

Missing 

Indicator

Lower 

Bound

Upper 

Bound

HTnn Height meters < 9999 0 4000

SAnn Std. dev. horizontal wind degrees < 99 0 35

SEnn Std. dev. vertical wind degrees < 99 0 25

SVnn Std. dev. v-comp. of wind meters/second < 99 0 3

SWnn Std. dev. w-comp. of wind meters/second < 99 0 3

SUnn Std. dev. u-comp. of wind meters/second < 99 0 3

TTnn* Temperature °C < 99 -30 40

WDnn* Wind direction degrees from north <= 999 0 360

WSnn* Wind speed meters/second <= 99 0 50

VVnn Vertical wind component meters/second < 999 0 5

DPnn Dew-point temperature °C < 99 -65 35

RHnn Relative humidity whole percent <= 999 0 100

V1nn User's vector #1 user's units < 999 0 100

V2nn User's vector #2 user's units < 999 0 100

V3nn User's vector #3 user's units < 999 0 100

‘nn’ in variables HT to V3 refers to the level at which the observation was taken; 

e.g., TT01 is the temperature at the first level and WS02 is wind speed at 

the second level.

*Automatically included in audit report.

Note: Shaded parameters are not currently used in AERMET.
C-1

APPENDIX C. DATA FILE FORMATS

This appendix describes the format of the data files created by AERMET. This includes 

the EXTRACT and QA files of NWS upper air and surface data, the merged file, and the 

OUTPUT and PROFILE files that will be input to AERMOD. It does not describe the QA file 

for site-specific data since this file is written with the same user-specified format used to read 

the original site-specific file.

The format of the files is given in terms of the FORTRAN READ statements that must 

be used to input the data for each observation. Variable names shown in capital letters 

correspond to those given in Appendix B. Variable names shown in lower case italics are 

"local" variables that do not correspond to any in Appendix B.

C.1 UPPER AIR SOUNDINGS

Each upper air sounding in both the EXTRACT and QA files is composed of two parts: 

(1) an identifying header record consisting of the year, month, day, hour, and the number of 

sounding levels; and (2) a sounding record composed of pressure, height above ground level, 

temperature, dew-point temperature, wind speed, and wind direction, which is repeated for each 

level.

Upper air header record:

READ( ) year, month, day, hour, # levels

FORMAT (1X, 4I2, I5) 

where hour is expressed in local standard time (LST) and # levels is the number of levels in this 

sounding. If no soundings were extracted or there are no levels to the data, then # levels is 

zero.
C-2

Upper air sounding level data (if # levels > 0), repeated # levels times.

READ( ) UAPR, UAHT, UATT, UATD, UAWD, UAWS

FORMAT (6(1X,I6))

where UAPR = atmospheric pressure (millibars), multiplied by 10

UAHT = height above ground level (meters)

UATT = dry bulb temperature (°C), multiplied by 10

UAWD = wind direction (degrees from north)

UAWS = wind speed (meters/second), multiplied by 10

All values on the upper air pathway are written as integers. Several of the values were multiplied 

by 10, as noted above, to retain one significant digit after the decimal point prior to rounding the 

result to the nearest whole number. The values are divided by 10 prior to any usage in Stage 3.

C.2 SURFACE OBSERVATIONS

Each hourly surface observation in both the EXTRACT and QA files is written as two 

records. As with the upper air data, all values are reported as integers with several variables 

multiplied by 10 or 100 to retain significant digits. Several of the variables are two variables 

combined and stored as one integer value. These are recognized by the // in the variable name 

and units below.

The first record of a surface observation is written as follows:

READ( ) year, month, day, hour, PRCP, SLVP, PRES, CLHT, TSKC,

C2C3, CLC1, CLC2, CLC3, CLC4

FORMAT (1X, 4I2, 4(1X,I5), 6(1X,I5.5))

where hour = hour in LST
C-3

PRCP = precipitation amount (millimeters), multiplied by 1000

SLVP = sea level pressure (millibars), multiplied by 10

PRES = station pressure (millibars), multiplied by 10

CLHT = cloud ceiling height (kilometers), multiplied by 10

TSKC = sky cover, total//opaque (tenths//tenths)

C2C3 = sky cover, 2//3 layers (tenths//tenths)

CLCn = sky condition//coverage, layer n = 1,2,3,4 (- -//tenths)

The second record of a surface observation is written as follows:

READ( ) CLT1, CLT2, CLT3, CLT4, PWTH, HZVS, TMPD, TMPW,

DPTP, RHUM, WDIR, WSPD, ASOSFLG

FORMAT (8X, 5(1X,I5.5), 7(1X,I5),2X,A1)

where CLTn = cloud type//height, n=1,2,3,4 (- -//kilometers), multiplied by 10

PWTH = present weather, liquid//frozen (no units, see codes below)

HZVS = horizontal visibility (kilometers), multiplied by 10

TMPD = dry bulb temperature (°C), multiplied by 10

TMPW = wet bulb temperature (°C), multiplied by 10

DPTP = dew-point temperature (°C), multiplied by 10

RHUM = relative humidity (percent)

WDIR = wind direction (tens of degrees from north)

WSPD = wind speed (meters/second), multiplied by 10

ASOSFLG = flag indicating whether observation is ASOS (‘A’) or 

non-ASOS (‘N’)

All reports of sky conditions (CLCn), cloud types or obscuring phenomena (CLTn) and 

present weather (PWTH) are stored using the TD-3280 numeric codes. This requires converting 

the appropriate variables in the CD-144 formatted file as a part of the extraction process. Since 

SCRAM uses the same convention, this discussion applies to that format as well. The following 

tables relate the TD-3280 codes to the CD-144 codes. Overpunch characters in the tables below 
C-4

for the CD-144 formats are represented by an ASCII character, which also appears in the data 

file. An “n.e.” indicates that there is “no equivalent” in the CD-144 format. Only weather 

producing liquid and/or frozen precipitation are reported in the PWTH variable.
C-5

TABLE C-1

SKY CONDITIONS

TD-3280 CD-144 Description of Sky Conditions

00

01

02

03

04

05

06

07

08

09

0

1

2

4

5

7

8

X or -

Blank

clear or less than 0.1 coverage 

thin scattered 0.1 to 0.5 coverage 

scattered 0.1 to 0.5 coverage 

thin broken 0.6 to 0.9 coverage 

broken 0.6 to 0.9 coverage 

thin overcast 1.0 coverage 

overcast 1.0 coverage 

obscuration 1.0 coverage 

partial obscuration <1.0 coverage 

unknown

TABLE C-2

CLOUD TYPES

TD-3280 CD-144 Description of Cloud Types

00

11

12

13

14

15

16

17

18

19

21

22

23

24

28

29 

32

35

37

39

0

4

n.e.

K

n.e.

3

2

M

5

N

6

O

7

n.e.

P

n.e

8

n.e.

9

R

none 

cumulus 

towering cumulus

stratus fractus 

stratus cumulus lenticular

stratus cumulus 

stratus 

cumulus fractus 

cumulonimbus 

cumulonimbus mammatus 

altostratus 

nimbostratus 

altocumulus 

altocumulus lenticular

altocumulus castellanus 

altocumulus mammatus

cirrus 

cirrocumulus lenticular

cirrostratus 

cirrocumulus 

TABLE C-3
C-6

OBSCURING PHENOMENA

TD-3280 CD-144 (cols. 30, 31) Description of Obscuring Phenomena

01

03

04

05

06

07

30

36

44

45

48

50

60

70

76

98

6

3

1

2

4

4

5

5

3

1

2

n.e.

n.e.

n.e.

n.e.

X or -

blowing spray

smoke and haze

smoke

haze

dust

blowing dust

blowing sand

blowing snow

ground fog

fog

ice fog

drizzle

rain

snow

ice crystals

obscuring phenomena other than fog 

(prior to 1984)

The code definitions for present weather conditions (PWTH) are presented below. They 

are divided into nine general categories that are subdivided into specific weather conditions. 

Dashes in a field indicate that there is no definition for that code. The 8-digit CD-144 format for 

weather conditions is converted to the 2-digit TD-3280 categories. Up to two different types of 

weather may be stored in the PWTH variable in AERMET; however, only weather producing 

liquid (codes 20-39) and/or frozen (codes 40-69) precipitation are retained in the PWTH variable 

as liquid//frozen precipitation. The SAMSON codes for present weather are identical to the 

TD-3280 codes.
C-7

TABLE C-4

PRESENT WEATHER

TD-3280 CD-144 (col. 24) Thunderstorm, Tornado, Squall

10

11

12

13

14

15

16

17

18

19

1

2

3

5

n.e.

n.e.

n.e.

n.e.

n.e.

n.e.

thunderstorm - lightning and thunder

severe thunderstorm - frequent intense 

lightning and thunder

report of tornado or water spout

light squall

moderate squall

heavy squall

water spout

funnel cloud

tornado

unknown

TD-3280 CD-144 (col. 25) Rain, Rain Shower, Freezing Rain

20

21

22

23

24

25

26

27

28

29

1

2

3

4

5

6

7

8

9

n.e.

light rain

moderate rain

heavy rain

light rain showers

moderate rain showers

heavy rain showers

light freezing rain

moderate freezing rain

heavy freezing rain

unknown

TD-3280 CD-144 (col. 26) Rain Squall, Drizzle, Freezing Drizzle

30

31

32

33

34

35

36

37

38

39

n.e.

n.e.

n.e

4

5

6

7

8

9

n.e.

light rain squalls

moderate rain squalls

heavy rain squalls

light drizzle

moderate drizzle

heavy drizzle

light freezing drizzle

moderate freezing drizzle

heavy freezing drizzle

unknown
C-8

TABLE C-4, continued

PRESENT WEATHER

TD-3280 CD-144 (col. 27) Snow, Snow Pellets, Ice Crystals

40

41

42

43

44

45

46

47

48

49

1

2

3

4

5

6

n.e.

8

n.e.

n.e.

light snow

moderate snow

heavy snow

light snow pellets

moderate snow pellets

heavy snow pellets

light snow crystals

moderate snow crystals

heavy snow crystals

unknown

TD-3280 CD-144 (col 28) Snow Shower, Snow Squalls, Snow Grains

50

51

52

53

54

55

56

57

58

59

1

2

3

n.e.

n.e.

n.e.

7

8

9

n.e.

light snow showers

moderate snow showers

heavy snow showers

light snow squalls

moderate snow squalls

heavy snow squalls

light snow grains

moderate snow grains

heavy snow grains

unknown

TD-3280 CD-144 (col. 29) Sleet, Sleet Shower, Hail

60

61

62

63

64

65

66

67

68

69

n.e.

n.e.

n.e.

n.e.

5

n.e.

8

n.e.

n.e.

n.e.

light ice pellet showers

moderate ice pellet showers

heavy ice pellet showers

light hail

moderate hail

heavy hail

light small hail

moderate small hail

heavy small hail

unknown
C-9

TABLE C-4, continued

PRESENT WEATHER

TD-3280 CD-144 (col. 30) Fog, Blowing Dust, Blowing Sand

70

71

72

73

74

75

76

77

78

79

1

2

3

4

5

n.e.

n.e.

n.e.

n.e.

n.e.

fog

ice fog

ground fog

blowing dust

blowing sand

heavy fog

glaze

heavy ice fog

heavy ground fog

unknown

TD-3280 CD-144 (col. 31) Smoke, Haze, Blowing Snow, Blowing 

Spray, Dust

80

81

82

83

84

85

86

87

88

89

1

2

3

4

5

6

n.e.

n.e.

smoke

haze

smoke and haze

dust

blowing snow

blowing spray

dust storm

- -

- -

unknown

TD-3280 CD-144 (col. 29) Ice Pellets, Hail Showers, Small Hail/Snow 

Pellet Showers, Fog

90

91

92

93

94

95

96

97

98

99

1

2

3

n.e.

light ice pellets

moderate ice pellets

heavy ice pellets

hail showers (begins July 1996)

small hail/snow pellet showers (begins7/96)

partial fog (begins 7/96)

patches fog (begins 7/96)

low drifting snow (begins 7/96)

- -

unknown
C-10

C.3 MERGE OUTPUT

The merged data file contains a block of records that are the cumulative header records of 

all input files to Stage 2. These records are followed by blocks of records for each day of 

observations. Each block of records contains a header record identifying how many records 

there are in the block for each of the three types of data present. Each block is subdivided into 

three blocks of records, where each sub-block contains all of the observations for that day for a 

particular type of data.

The records within a block are written with an 8(I8,1X) format, except for the multi-level 

site-specific records that are written with a 6(F14.6,1X) format. The 22 NWS surface variables, 

plus the date and time, for each hour are split across four records. Also, if there are more than 

eight single-level or six multi-level variables on a particular READ statement, then these records 

will also be divided across more than one record.

Daily Master Header Record

READ( ) year, month, day, j_day, n_ua, n_sfc, n_os

FORMAT (7(I8,1X))

where j_day = the Julian date for year/month/day.

n_ua = number of NWS upper air observations.

n_sfc = number of NWS surface observations.

n_os = number of site-specific observations.

Upper Air Records

Upper air data are stored in the same order as in upper air extract/QA files (see D.1).

Surface Records
C-11

For each hour, there is a header record with the year, month, day and hour followed by 

three data records. The 22 variables are written in the same order as shown in D.2, with a 

maximum of 8 variables per record.

Site-specific Records

Single-level Variables

These are written in the same order and on multiple records just as they were given on the 

READ statements, but using an 8(I8,1x) format instead of that given on the corresponding 

FORMAT statements.

Multi-level Variables

Like the single-level variables, these are also written in the same order and on multiple 

records just as they were given on the READ statements, but using a 6(F14.6,1x) format.

C.4 AERMOD FILES

Two files are produced for input to the AERMOD dispersion model. The surface 

OUTPUT contains observed and calculated surface variable, one record per hour. The PROFILE 

file contains the observations made at each level of a site-specific tower, or the one level 

observations taken from NWS data, one record per level per hour. The contents of these files 

can also be written to the general report by including a LIST statement in the METPREP block.
C-12

SURFACE OUTPUT

Header record:

READ( ) latitude, longitude, UA identifier, SF identifier, OS identifier, Version date

FORMAT (2(2X,A8), 8X,' UA_ID: ',A8, ' SF_ID: ',A8, ' OS_ID: ',A8, T85, 

'VERSION:', A6 )

where latitude = latitude specified in Stage 1 for primary surface station

longitude = longitude specified in Stage 1 for primary surface station

UA identifier = station identifier for upper air data; usually the WBAN 

number used to extract the data from an archive data set

SF identifier = station identifier for hourly surface observations; usually 

the WBAN number used in extracting the data

OS identifier = site-specific identifier

Version date = AERMET version date; this date also appears in the 

banner on each page of the summary reports

Note that the ‘ ??_ID: ’ fields in the FORMAT statement above include two 

spaces before the 2-character pathway ID and one space after the colon.

Data records:

READ( ) year, month, day, j_day, hour, H, u* , w* , VPTG, Zic, Zim, L, zo , Bo , r, Ws

, Wd , zref , temp, ztemp, ipcode, pamt, rh, pres, ccvr, WSADJ

FORMAT (3(I2,1X), I3,1X, I2,1X, F6.1,1X, 3(F6.3,1X), 2(F5.0,1X), F8.1,1X, 

F7.4,1X, 2(F6.2,1X), F7.2,1X, F5.0, 3(1X,F6.1), 1X,I5, 1X,F6.2, 2(1X, 

F6.0), 1X, I5, 1X, A7)

where j_day = Julian day

H = sensible heat flux (W/m2)

u* = surface friction velocity (m/s)

w* = convective velocity scale (m/s)

VPTG = vertical potential temperature gradient above Zic (K/m)

Zic = height of convectively-generated boundary layer (m)

Zim = height of mechanically-generated boundary layer (m)

L = Monin-Obukhov length (m)

z0 = surface roughness length (m)

B0 = Bowen ratio

r = Albedo
C-13

Ws = reference wind speed (m/s)

Wd = reference wind direction (degrees)

zref = reference height for wind (m)

temp = reference temperature (K)

ztemp = reference height for temperature (m)

ipcode = precipitation type code (0=none, 11=liquid, 22=frozen, 

99=missing)

pamt = precipitation amount (mm/hr)

rh = relative humidity (percent)

pres = station pressure (mb)

ccvr = cloud cover (tenths)

WSADJ = wind speed adjustment and data source flag

When site-specific data are included in the data base, the definition of the reference 

height wind speed and direction are subject to the following restrictions: 

• the wind speed, Ws, must be greater than or equal to the site-specific data threshold wind 

speed;

• the measurement height must be at or above 7*z0, where z0 is the surface roughness 

length;

• the height must be less than or equal to 100 meters;

If AERMET is run only with NWS data, i.e. no site-specific data are in the data base, 

then the restrictions above do not apply and the reference winds are taken to be the NWS winds 

independent of the height at which the winds were measured.

Ambient air temperature is subject to a similar, but less restrictive, selection process:

• the measurement height must be above z0; and

• the height must be less than or equal to 100 meters.
C-14

PROFILE OUTPUT

READ( ) year, month, day , hour, height, top, WDnn, WSnn, TTnn, SAnn, SWnn

FORMAT (4(I2,1X), F7.1,1X, I1,1X, F7.1,1X, F8.2,1X, F8.2,1X, F8.2,1X, F8.2)

where, height = measurement height (m)

top = 1, if this is the last (highest) level for this hour, or 0 otherwise

WDnn = wind direction at the current level (degrees)

WSnn = wind speed at the current level (m/s)

TTnn = temperature at the current level (°C)

SAnn = σθ (degrees)

SWnn = σw (m/s)
D-1

APPENDIX D. SUMMARY OF MESSAGES

During the processing of the runstream input and data files, AERMET writes messages to 

the file defined through the MESSAGES keyword on the JOB pathway. Each message has the 

form:

n block a1n1n2 ssssss: message

where

n = counter, date (in the form yymmdd), or blank

block = program block name

a1n1n2 = message code

ssssss: = subroutine name in which the message was generated

message = message (limited to 48 characters)

The counter n is either the sequence number of the keyword statement generating the message, 

zero when irrelevant, the Julian day plus the hour of an observation with a QA violation or the 

number of observations when processing is completed. If it is a sequence number, it may be 

relative to either the current runstream file or to the header statements of a file.

The message code is composed of a letter (a1) and a 2 digit code (n1n2). The letter can 

be one of the following: 

E Indicates a fatal error; if the error occurs during processing of keyword 

statements, the remaining statements are processed for syntax only. If the error 

occurs during the processing of data, processing ceases for the run.

W Indicates a potential problem that the user should check. Runstream and data 

processing continues.

I Provides information on the status of the processing; these messages report on the 

progress of an AERMET run.

Q Indicates a quality assessment violation; a value for a variable was either outside 

the interval defined by the upper and lower bounds or it was missing.
D-2

The 2 digit codes are grouped into general categories corresponding to the processing in 

Stages 1, 2, and 3. These categories are:

00 – 29 Input statement processing, file header and general processing that is 

applicable to all pathways;

30 – 39 Upper air sounding processing (Stage 1);

40 – 49 Surface observation processing (Stage 1);

50 – 59 On-site observation processing (Stage 1);

60 – 69 Merge processing (Stage2);

70 – 89 Stage 3 processing

These codes only provide an indication of the processing (runstream or data) that was occurring. 

They cannot completely specify the reason for the message. Further explanation is left to the 48 

character message.

D.1 INTERPRETING ERROR MESSAGES

AERMET can generate many messages in a single run. This section discusses the 

interpretation of a few of the error messages.

Anyone who has written software knows that a single syntax error in the source code can 

generate several error messages when the program is compiled. AERMET also may generate 

several error messages for an error in a runstream. The following is an example of such a 

situation that could occur in defining the surface characteristics in Stage 3.

Runstream fragment for the METPREP pathway:

FREQ_SECT ANNUAL 1

SECTOR 1 0 360

CHARS 1 1 0.250 0.750 0.006
D-3

The message file would contain something like:

16 METPREP E03 ST3SET: KEYWORD UNKNOWN: CHARS

METPREP I19 ST3SET: "END OF FILE" ON UNIT 5 AFTER RECORD # 

16

METPREP E29 MPTEST: EXPECTED 1 SITE_CHAR KEYWORD; 0 PROCESSED

METPREP E29 MPTEST: ERROR FOR PERIOD 1, SECTOR 1

The correct keyword was not used to define the surface characteristics: CHARS instead of 

SITE_CHAR. As each runstream record is processed, AERMET checks to make sure that it 

conforms to all the rules of syntax. The first message indicates that an unknown keyword was 

detected (by subroutine ST3SET) at record 16 in the runstream. Once the runstream is 

completely processed, as noted by the "END OF FILE" message, AERMET checks to be sure it 

has enough information to process the data. It is during this portion of the setup processing, in 

subroutine MPTEST, that AERMET detects additional problems. Based on the FREQ_SECT 

keyword, AERMET expected a single SITE_CHAR keyword (annual, one sector covering all 

wind directions) to define the surface characteristics, but it did not find any valid SITE_CHAR 

keywords (third message). The final message indicates that there was some kind of error with 

the first period for sector 1 and is tied to the third message.

One might argue that the number of error messages is excessive for such a minimal 

configuration for the surface characteristics. Remember that there can be up to 12 SECTOR 

keywords and 144 SITE_CHAR keywords, so AERMET provides the user with additional 

information to assist in identifying the exact location of the problem. 

Another error that causes multiple error messages occurs when a pathway is misspelled. 

Depending on the location in the runstream, AERMET reports it as an unknown 

pathway/keyword (the syntax and structure of the runstream makes it impossible to determine 

which). Since the pathway is not correctly defined, the keywords that follow it would be 

reported as invalid for the previous pathway.

Another error that a user could introduce is a misspelling of an input data file name. 

AERMET opens and processes file headers, if any, before processing any data. If a nonexistent 
D-4

file is opened, the file is created and is 0 bytes long. If there is critical information that is to be 

reprocessed from the header records of the correctly spelled file, then AERMET will not find 

that information in the incorrectly spelled file and report an error. Unfortunately, the message 

resulting from such an error is misleading. There is no way to recognize a 'zero-length' file using 

ANSI-standard Fortran at the point AERMET checks for sufficient information to process the 

data. For example, in merging data, if the input file name for the site-specific data (specified on 

the keyword QAOUT) is misspelled, then AERMET creates the (misspelled) file, reads from the 

file (and immediately encounters an end of file), and reports that there are no READ/FORMAT 

keywords to define the data structure. 

Most error messages are reasonably straightforward to interpret. However, from these 

few examples, one can see that is may take a little more than a casual glance at the message file 

if AERMET detects any errors during setup.

In the discussion of the error messages, the term >decode= (or a variant) is used. In 

Fortran, this term means that the program is translating data and transferring data between 

variables in internal storage rather than transferring data from an external file to variables. The 

term >internal read= may also be seen in this context. 

D.2 RUNSTREAM AND FILE HEADER PROCESSING, 00 – 29

Any messages that pertain to the setup of a run are included in this category.

ERRORS

E00 Reserved - this code is used to report internal programming errors.

E01 AERMET was not able to read a record in the runstream.

E02 Error defining the pathway - the conditions that may result in this error are:

1) Subr.FDPATH, in a call to subr.GETWRD, was not able to determine the pathway 

for the runstream record number indicated;

2) Invalid pathway for the stage of processing;
D-5

3) Duplicate pathway specified.

The message identifies which condition was encountered.

E03 Error defining a keyword - the conditions that may result in this error are:

1) The keyword did not match any of the 26 keywords recognized by AERMET. This 

error is independent of pathway;

2) The keyword is not valid for the pathway;

3) The keyword was duplicated for the pathway; only selected keywords are repeatable.

The message identifies which condition was encountered. See the tables in Appendix A 

for the list of keywords by pathway.

E04 Incomplete or superfluous information for a keyword. See the tables in Appendix A for 

the syntax of the keyword.

E05 This may indicate an invalid combination of processing options or problems with the 

merge file headers.

E06 The parameter associated with a keyword is in error. This error can be generated for 

multiple reasons. For example, if AERMET could not match a variable name on a 

keyword with the list of valid variable names, then this error code is used. Also, if 

AERMET has a ‘decoding’ error, then this code is used. A parameter on a keyword 

statement is not within bounds, is not known, or does not match any of the valid 

secondary keywords or parameters for this keyword.

E07 An error occurred in subroutine GETWRD or an error condition was returned to the 

calling routine. This subroutine retrieves the value of a field, whether it be a pathway, 

keyword, or parameter field, for additional processing.

E08 Error opening a file or the file name was previously specified for another file that is 

already open.

E12 Processing cannot be completed because a required keyword statement for the specified 

block is either missing or in error.

E15 A problem was encountered with the site-specific surface characteristics defined in Stage 

3. Possible errors include that the keywords were not specified in the correct order, or 

that surface characteristics for the secondary location are missing with the SUBNWS 

option (beginning with version 11059). While most keywords can appear in any order 

for a pathway, the surface characteristics must appear in a particular order. See Section 

4.7.7 for a discussion of the keywords.

E19 The chronological day was not computed correctly from the year, month and day (in 

SUBR.CHROND); or the year, month and day was not computed correctly from the 

chronological day (in SUBR.ICHRND).
D-6

E20 Error reading a header record from a file (including temporary files). This error could 

occur while reading through the header records of a file in an attempt to locate the first 

data record.

E21 Error writing a header record to a file.

E22 End of file encountered reading and existing file’s header records. This condition 

indicates that there are no data to process.

E23 Error re-reading an existing file’s header records written that had been written to an 

output file.

E24 Error conditions were detected for the JOB pathway; this message is issued during the 

final check after the setup processing.

E25 Error conditions were detected for the UPPERAIR pathway; this message is issued 

during the final check after the setup processing.

E26 Error conditions were detected for the SURFACE pathway; this message is issued during 

the final check after the setup processing.

E27 Error conditions were detected for the ONSITE pathway; this message is issued during 

the final check after the setup processing.

E28 Error conditions were detected for the MERGE pathway; this message is issued during 

the final check after the setup processing.

E29 Error conditions were detected for the METPREP pathway; this message is issued during 

the final check after the setup processing.

WARNINGS

W02 The input runstream record exceeds the maximum number of characters of 132. This 

may result in errors processing the runstream file. The message also includes a portion of 

the information beyond column 132, out to column 500.

W03 Beginning with version 11059, the LOCATION keyword is no longer valid on the 

METPREP pathway in Stage 3, and the information on the METPREP LOCATION 

keyword will be ignored. The location used for determining sunrise for convective 

mixing height calculations is the primary surface station location in Stage 1, i.e., the 

ONSITE location if available, otherwise the SURFACE location. 
D-7

W04 Too many fields are included on the DATA keyword. Beginning with version 11059 

some fields on the DATA keyword are no longer supported. This also applies to the 

station elevation on the DATA keyword for UPPERAIR data.

W06 Value on an input statement may be unreasonable, but processing continues with this 

value.

W15 Two sets of surface characteristics specified when only one set is needed. The secondary 

set will be ignored.

W19 The specified ONSITE data variable is currently not used by AERMET.

W20 Auditing a variable for QA is disabled for the ONSITE variable specified. The variable 

appeared on an AUDIT keyword statement but did not appear with any READ keywords.

W21 OSHEIGHTS keyword and HTnn height variables are both defined for ONSITE data. 

The OSHEIGHTS keyword will be used to define measurement heights and the HTnn 

variables will be ignored.

W22 The OSMN variable for ONSITE observation minute is specified on the READ keyword, 

but OBS/HOUR = 1. The OSMN variable will be ignored.

INFORMATIONAL

I19 End of file encountered on the input runstream file.

I25 No data are to be extracted, QA'd, or merged for UPPERAIR pathway.

I26 No data are to be extracted, QA'd, or merged for SURFACE pathway.

I27 No data are to be QA'd or merged for ONSITE pathway.

D.3 UPPER AIR PROCESSING, 30 – 39

Any messages that pertain to the UPPERAIR pathway and issued after the input 

statements are processed are in this category. A word of caution: if a problem requires 

examining the unprocessed TD-6201 (archive) data, be very careful if you edit the file with a text 

editor. Some editors could potentially modify the structure, rendering the file unreadable by 

AERMET. A better option would be to use a file viewer that cannot alter a file.
D-8

ERRORS

E30 An error occurred computing the chronological day number.

E31 No soundings were extracted and there were no errors that did not allow AERMET to 

extract any of the soundings specified in the runstream. Compare the station ID and the 

dates in the runstream to the station and dates in the input data file.

E32 An error occurred reading a block of data. A block of data contains all or part of a single 

sounding. Depending on the data structure of the archive data (fixed- or variable-length 

block), there can be up to 2876 characters in one block of data. An error reading a block 

is considered severe enough to stop processing the upper air data since the nature of the 

error cannot be ascertained very easily. The user will have to carefully examine the data 

to determine the cause of the error.

E33 An error was encountered decoding the portion of the block that contains the station 

identifier and date group, or an error occurred decoding a level of data in the sounding. 

In the former case, AERMET will stop processing the upper air data. In the latter case, 

AERMET will allow up to five such errors decoding sounding levels before processing of 

upper air data ceases. If AERMET cannot decode a sounding level, then it continues to 

the next level.

E34 The first character of the station ID is blank in the archive data file, indicating that the 

entire field likely is blank in the file. In the archive file, the station ID is supposed to fill 

the entire 8-character field, with leading 0's to fill out the field if the ID is shorter than 

eight characters. Either the process of reading the data is no longer synchronized with the 

data, or the station ID field is not what AERMET expects.

E35 At least one sounding was extracted, but error(s) occurred that did not allow AERMET to 

finish extracting all the soundings specified in the runstream. 

E36 No soundings were extracted and error(s) occurred that did not allow AERMET to extract 

any of the soundings specified in the runstream. 

E38 An error occurred while reading a sounding during the QA process. The data in the input 

file for QA should already be in a standard AERMET format (see Appendix C.1), but 

AERMET was unable to read the data from the file. Since AERMET reads and writes 

one sounding at a time, check the output file to see where the error occurred (the 

sounding after the last one in the file being written by the QA process).

WARNINGS
D-9

W33 Error decoding a level of data, but the maximum number of errors allowed (five) has not 

been exceeded.

W34 Surface elevation (elevation of the first sounding level) is missing or less than zero. The 

sounding levels in the archive file are reported as height above mean sea level. 

AERMET adjusts all soundings to be referenced relative to the local elevation rather than 

sea level. If AERMET cannot determine the surface elevation because it is missing (or 

below mean sea level), then this message is issued. Once the surface elevation is 

determined, that elevation is used to adjust all subsequent soundings.

W35 The process of decoding the levels of data in a sounding failed at the first level. It is 

likely that only a header record is present in the output file from the extract process. The 

user will have to examine the input data more closely to determine the cause of the 

problem.

W36 The first level of FSL upper air data is not the correct type and was skipped.

INFORMATIONAL AND QA

I30 Beginning UPPERAIR data processing.

I31 Data modifications for upper air soundings is enabled. See Section 5 for a discussion of 

these modifications.

I32 With the data modifications enabled, a level of data was deleted or modified from a 

sounding.

I39 End of file was encountered on the input file.

Q34 A vertical gradient cannot be computed at because at least one of the heights are missing.

Q35 The difference between the reported height and recomputed height exceeds 50 meters.

Q36 The heights have not been recomputed due to missing data.

Q37 A lower bound quality assessment violation for the variable indicated.

Q38 An upper bound quality assessment violation for the variable indicated.

Q39 The data value for this period and variable is missing.

D.4 SURFACE OBSERVATIONS PROCESSING, 40 – 49
D-10

Any messages that pertain to the SURFACE pathway and issued after the input 

statements are processed are in this category.

ERRORS

E40 An error occurred computing the chronological day number.

E41 An end of file was encountered in the input file and no hourly observations were 

extracted. Compare the station ID and dates in the runstream to the station and dates in 

the input file to determine if there is a mismatch.

E42 The maximum number of errors allowed reading a block of data from the archive data 

file has been exceeded. The limit is five errors.

E43 An internal read (decode) failed while trying to resolve the station ID or date group in the 

archive input data.

E44 The first character of the station ID is blank in the archive data file, indicating that the 

entire field likely is blank. Check the input file and make sure the file structure conforms 

to the format specified on the DATA card (e.g., if CD144 is specified on the DATA 

keyword, then the format of the file is the 80-character per observation format).

E45 No data fields useful to AERMET were defined when data were retrieved from the 

SAMSON CD. AERMET expects that the data the user retrieved from the SAMSON CD 

contains information that is required to calculate boundary layer parameters. This 

message is issued during the setup phase of the processing.

E46 An error occurred converting the variable ID number in a SAMSON input file from a 

string to an integer. The second record of the data retrieved from the SAMSON CD 

contains a list of integers that correspond to the weather variables that appear in the file. 

The integers range from 1 through 21. Without a correct interpretation of these integers, 

AERMET cannot process the data.

E47 The station ID in the SAMSON file does not match the station ID on the LOCATION 

keyword. See also E41; since the SAMSON data are processed slightly differently than 

the CD144 and SCRAM formats, a separate message is issued when no data are retrieved.

E48 An error was encountered while reading the hourly observation from the QA input file. 

Since AERMET reads and writes one observation at a time, check the output file to see 

where the error occurred (the observation after the last one in the file being written by the 

QA process).
D-11

WARNINGS

W40 SURFACE data is outside the valid range of dates for the specified data format, and 

cloud cover will be set to missing for ASOS records.

W41 Cloud cover set to missing for ASOS observations from reformatted SURFACE file 

format outside the valid date range for the format, for SAMSON and SCRAM data.

W42 Error reading/decoding the hourly observations, but the maximum number of errors 

allowed was not exceeded.

W43 An error occurred decoding an overpunch character  the missing valu 

variable will be substituted in the output file. See Section 4.3.1 for a discussion on 

overpunches. The number of the overpunch is reported (there are 35 overpunches 

possible, but AERMET does not examine all of them), and the table in Section 4.3.1.1 

can be used to identify the position in the record that caused the error.

W44 A problem occurred with extracting SURFACE data in the HUSWO format.

W45 AERMET has encountered a second set of SAMSON header records (the records 

beginning with the tilde (~)). These header records are not processed and the extraction 

of hourly surface observations stops. 

W46 Various messages related to SURFACE station elevations, whether specified by the user 

or included in the SURFACE data file. 

W47 Various messages related to consistency checks between SURFACE station ID specified 

by the user and station ID included in the SURFACE data file.

W48 Various messages associated with ISHD data.

W49 Various messages regarding the processing of the ASOS commissioning date and the 

ASOS data flags.

INFORMATIONAL AND QA

I40 Processing of the SURFACE data can begin.

I41 Cloud cover set to missing for ASOS observations from reformatted SURFACE file 

format outside the valid date range for the format, for SAMSON and SCRAM data; first 

24 occurrences are issued as warnings (W41).

I45 Message related to precipitation accumulation for SAMSON data.
D-12

I47 The SAMSON data identified with this message were modeled rather than observed 

when the data were imprinted on the CD.

I48 Report number of records extracted.

I49 End of file was encountered on the input file.

Q47 A lower bound quality assessment violation for the variable indicated.

Q48 An upper bound quality assessment violation for the variable indicated.

Q49 The data value for this period and variable is missing.

D.5 ON SITE DATA PROCESSING, 50 – 59

Any messages that pertain to the ONSITE pathway and issued after the input statements 

are processed are in this category.

ERRORS

E50 Error reading an input file header. 

E51 Error reading input file header record. This message would occur only if a file is QA’d 

more than once since there isn’t an extract process for site-specific data and there usually 

aren’t any headers in the site-specific data file prior to the first time the data are QA’d.

E52 The maximum number of errors allowed reading/decoding the input data has been 

exceeded. The limit is five errors.

E53 Error writing data to the output file defined on the QAOUT keyword statement.

E54 The observations are not sequential in time.

E55 The number of observations exceeds the number expected for the hour (by default, 1 or 

the value specified on the OBS/HOUR keyword statement).

E56 End of file on the input data was encountered before a complete observation (block of 

records) was read.
D-13

E57 A duplicated observation period was found in the ONSITE data.

E59 A gap of more than 1 year was found in the ONSITE data.

WARNINGS

W50 The measurement heights for ONSITE data vary within the data period processed. 

W51 No station elevation specified on the ONSITE LOCAITION keyword. Users are 

encouraged to specify station elevation for use in substitution hierarchy for missing 

station pressure. 

W52 Various messages related to reading ONSITE date records.

W55 Total ONSITE precipitation is based on less than the half the number of values for 

subhourly data. 

W59 A data gap occurred within the ONSITE data file.

INFORMATIONAL

I55 The number of subhourly ONSITE values is less than the minimum to calculate an hourly 

average.

I59 An end of file was encountered on the input file.

Q57 A lower bound quality assessment violation for the variable specified (for more than one 

observation per hour, this check is made after the subhourly values have been averaged).

Q58 An upper bound quality assessment violation for the variable specified (for more than one 

observation per hour, this check is made after the subhourly values have been averaged).

Q59 The data value for this variable and observation period is missing.

D.6 MERGE PROCESSING, 60 – 69

Any messages pertaining to merging the three data types and issued after the input 

statements are processed are in this category.
D-14

ERRORS

E60 Error computing the chronological day from Julian day and year.

E61 Error computing the Julian day and year from the chronological day.

E62 Error reading the UPPERAIR data.

E63 Error reading the SURFACE data.

E64 Error reading the ONSITE data.

E65 Error writing the ONSITE QA’d data to the OUTPUT file.

E66 Error processing an input file's headers.

E67 No data to merge - either the merge program or the setup have determined that there are 

no data to merge. AERMET will ‘merge’ data even if there is only one type of data 

(upper air, surface, or site-specific), but since no data are available to merge processing 

will aborted.

E68 The ASOS flag is missing or invalid in the SURFACE QAOUT file. This could indicate 

that the QAOUT file is from an old version of AERMET, prior to version 11059 when 

the ASOS flag was added to the QAOUT file.

WARNINGS

W66 Various messages regarding the use of 1-minute ASOS wind data. 

W69 Message regarding non-standard MERGE, e.g., UA and OS data only, or SF and OS data 

only. 

INFORMATIONAL

I66 The WBAN for the 1-minute ASOS wind data matches the WBAN for the SURFACE 

data.

I67 No XDATES statement  the beginning 

available date on the three pathways, and the ending chronological day was computed as 

the beginning day + 367. Without an XDATES keyword, AERMET has no knowledge 

of what data are in the input file(s), therefore, the zeroes are displayed in the report file 

for the dates to merge.
D-15

D.7 STAGE 3 PROCESSING, 70 – 89

Any messages that pertain to Stage 3 processing and issued after the input statements are 

processed are in this category.

ERRORS

E70 Error reading the master header from the merged data file for the Julian day shown. In 

the merged data file, there is a master header that precedes the data for each 24-hour 

block of data. AERMET was unable to read this record.

E71 There was an end-of file or error encountered reading the merged upper air data.

E72 There was an end-of file or error encountered reading the merged hourly surface 

observations.

E73 There was an end-of file or error encountered reading the merged site-specific data.

E74 The data are not on a 1-to-24 hour clock. This message can appear for surface or sitespecific data. Although the program to merge the data should write the data on a 1-to-24 

hour clock, there appears to be an hour outside this window, possibly an hour labeled 0. 

E75 There was an error converting the latitude and longitude in the runstream file from 

character to numeric.

E76 The hour in the merged data is defined as missing. For an unknown reason, the value for 

the hour was set to -9 in the merged data file.

E77 Bad wind sector specified (this is a second check on the wind direction sector).

E78 Upper air station location is blank.

E79 Error occurred assigning met variables in SUBST for hour.

E80 Input data are incomplete, either no UA data and no OS mixing heights, or no SURFACE 

data and no ONSITE data.

E81 ASOS flag is invalid, check the MERGED data.

E89 Error assigning location for Stage 3 based on SURFACE location or ONSITE location, 

could indicate a programming flaw.
D-16

E90 Error getting surface roughness; could indicate a programming flaw.

E91 Missing sky cover in subroutine NETRAD; could indicate a programming flaw.

WARNINGS

W70 The LST to GMT conversion appears to be incorrect. Based on the longitude provided, 

the (elementary) computation of the time zone does not agree with the conversion 

parameter (tadjust) on the LOCATION keyword.

W72 The upper air sounding cannot be extended because

- the maximum number of levels are in the sounding;

- the top of the sounding is too low (< 600 meters);

- could not identify two levels with which to calculate the potential temperature 

gradient required to extend the sounding.

W73 Convective boundary layer parameters not computed because

- no upper air data, especially the 12Z sounding, reported on this day

- other data required for the computation of the daytime planetary boundary layer 

height are missing.

W76 A minimum value of 0.001 m/s has been assigned to w*, since it was calculated to be less 

than 0.001.

W78 Calculated value for density is out of range (relative to lower and upper bounds specified 

at the point this check is made).

W79 Site-specific mixing heights are in the data base, but are missing for the hour; AERMET 

will calculate the mixing height.

W81 The reference wind speed from the NWS data are above the threshold wind speed but less 

than 21⁄2 *σv,min ( where σv,min = 0.2 m s-1

). This condition is not likely to occur unless 1-

minute ASOS wind data are used, since the minimum wind speed routinely reported by 

NWS is 3 knots (about 1.5 m s-1

), excluding calm winds.

W82 The default pressure of 1013.25 mb is being used since there were no site-specific or 

NWS pressure reported.

W83 Anemometer height from ASOS list differs from user-specified height.

W86 Delta-T height range may not be appropriate for BULKRN method.
D-17

W98 The data period for 1-minute ASOS wind data predates 2000, the earliest data period 

available for 1-minute ASOS data.

INFORMATIONAL

I70 Hour 23 data was swapped in for hour 24 data for NWS surface data.

I71 Cloud clover is missing for a nighttime hour or both cloud cover (NWS) and net radiation 

(site-specific) are missing for a daytime hour, prohibiting calculation of all boundary 

layer parameters in AERMET.

I77 Net radiation is negative during a daytime hour or positive during the nighttime (relative 

to sunrise and sunset).

I78 Sky cover is missing for a stable hour, no SBL estimates are calculated.

I79 The end of the processing window, defined by the XDATES statement for the METPREP 

block, was encountered or, if no window was specified, the end of file was encountered.

I80 The conditions that produce this message are:

1) The reference wind speed from the site-specific data are above the threshold wind 

speed but less than 21⁄2 *σv,min ( where σv,min = 0.2 m s-1

), or 

2) The reference wind speed height is above 7z0 but below 20z0, where z0 is the surface 

roughness length. See the Site-specific Meteorological Program Guidance (EPA, 

1987) for additional discussion on specifying the height to use in calculating 

boundary layer parameters.

I81 In defining the reference wind speed, there were no site-specific winds that met the 

criteria and 1-minute ASOS or standard NWS winds were used for the reference wind 

speed.

I82 In defining the reference temperature, there was no site-specific temperature that met the 

criteria and NWS temperature was used for the reference wind speed.

I83 In defining the station pressure, there was no site-specific pressure and NWS winds were 

used for the reference wind speed. This message is seen only if the user indicates that 

there is pressure in the data base.

I85 Only the ONSITE reference temperature will be used, rather than the full profile of 

ONSITE temperatures, because the reference ONSITE wind is missing.

I86 BULKRN option for delta-T was not used due to missing ONSITE wind data.
D-18

I87 The reference wind speed is missing for the specified hour.

I88 The external file of surface characteristics for the AERSURF or AERSURF2 keyword 

was successfully opened.

I98 The data period for 1-minute ASOS wind data predates 2000, the earliest data period 

available for 1-minute ASOS data; the first 24 occurrences are issued as warnings (W98).