Figure 1-1.

AERMET processing steps

The first stage extracts the surface and upper air data from files in which the data are
stored in specific archive formats. The quality of the surface, upper air, and site-specific or
prognostic data is also assessed during Stage 1. The second stage reads the output from Stage 1,
calculates the boundary layer parameters required by AERMOD, and generates two AERMOD-
ready meteorological data files.

Note that the extraction phase of the raw site-specific data or processed prognostic data
is not included in Stage 1, though the data are QA'd in Stage 1. Unlike the surface and upper air
data, site-specific and processed prognostic data are not stored (archived) in any specific format.
Therefore, the data are not "extracted" from an archive file and only need to be QA'd. This is
explained in more detail in Section 3.5. Another important point to mention with respect to
Figure 1-1 is the input of 1-minute Automated Surface Observing Systems (ASOS) data into
Stage 2, referred to in the figure as ‘Hourly averaged 1-minute ASOS winds.’ 1-minute ASOS
data are surface wind data collected by the NWS/FAA with ASOS, stored as 1-minute averages,
and archived separately from the hourly NWS/FAA surface data. These higher resolution wind
data can be processed separately with the AERMINUTE program (EPA, 2023a) to produce 1-
hour averages that are more representative than the surface wind data in the standard hourly
archive formats (see Section 3.3). For more recent years (2000 to present), the hourly wind data
in the standard archive formats can be replaced with the hourly values derived from

1-2
AERMINUTE output when those data are available. Refer to Section 3.3.9 for a detailed
discussion on the use of 1-minute ASOS wind data. From here on, this user's guide refers to all
surface data collected by the NWS and/or the FAA, including the 1-minute ASOS data, as NWS
data. Surface characteristics are also input to Stage 2 and can be calculated from processors such
as AERSURFACE (EPA, 2020) for observed data and from the prognostic model when
processing prognostic data.

The AERMET program is designed to read a plain text file (a.k.a., the control file) which
contains the processing instructions such as user-specified options and the names and locations
of the input and output data files. Prior to version 18081 of AERMET, the control filename was
hardcoded as 'AERMET.INP’. Beginning with version 18081, the user can specify the control
filename on the command line when running AERMET. The input file can be in a different
directory than the directory in which the user is working, and the full pathname or relative
pathname can be entered. If no input file is provided, the hardcoded default ‘AERMET.INP’ is
assumed and must be in the directory in which the user is working. Note that all AERMET
output filenames are user-specified and are created automatically by AERMET during
processing.

Prior to version 21DRF, AERMET was configured to be run in three stages (extraction
and QA, data merger, and PBL calculations) with each stage run separately. Beginning with
21DRF, AERMET has been configured so that only two stages are executed (extraction and QA,
and PBL calculations) and both stages can be executed in the same AERMET run. It is no longer
necessary to run each stage separately, and the data merger stage has been eliminated. Therefore,
existing AERMET control files created prior to version 21DRFmust be revised. More details on
the differences between the 21DRF version and earlier versions can be found in Section 1.4.

In a typical application, AERMET can be executed two ways: 1) two times, once for
Stage 1 processing (extraction and quality assurance (QA) of the surface, upper air, and site-
specific data or prognostic data combined in a single run) and a second time for Stage 2
processing (boundary layer calculations and output); 2) alternatively AERMET can be executed
once, running both Stage 1 and 2 in the same AERMET run (see Section 1.4.1 for information
on combined stage control files). Since Stage 1 processing is designed to support QA of raw
1-3
input data, Stage 1 may involve multiple iterations if data problems are encountered. Prior to
running AERMET, the user should review the instructions in the control file and, as necessary,
replace them with instructions appropriate to the specific application and stage of processing. If
running each stage separately, a separate control file will be required for each stage, and each
given a unique name to avoid conflicts when the files are stored in the same directory.

1.1.1 Stage 1 – extraction and quality assessment

Stage 1 comprises the extraction/retrieval of data and assessment of the quality of the
data. Data extraction is generally a one-time activity, while the quality assessment (QA) may be
performed several times if the QA identifies problems with the data.

In the past, the NWS upper air and surface data are available from the National Oceanic
and Atmospheric Administration (NOAA) in a compact format. These formats are designed to
minimize the amount of space required to store the data and are not readily interpreted.
Therefore, the data that are stored in archive files are first extracted (i.e., retrieved) from the
archive file.

AERMET can extract upper air sounding data from three formats including: TD-6201,
the former Forecast Systems Laboratory (FSL) format, and beginning with 21DRF, the
Integrated Global Radiosonde Archive (IGRA). While TD-6201 is no longer in use and FSL
data is no longer available beginning in autumn of 2024, the IGRA format is available from the
NOAA National Centers for Environmental Information (NCEI) at
hhttps://www.ncei.noaa.gov/products/weather-balloon/integrated-global-radiosonde-archive.
Direct access to recent data can be found at https://www.ncei.noaa.gov/data/integrated-global-
radiosonde-archive/access/data-y2d/ or for full period of records for stations at
https://www.ncei.noaa.gov/data/integrated-global-radiosonde-archive/access/data-por/

AERMET can extract surface hourly weather observations from several standard formats
that have been used by NOAA's National Centers for Environmental Information (NCEI)
including Card Deck 144 (CD-144), Solar and Meteorological Surface Observation Network
(SAMSON), Hourly Surface Weather Observations (HUSWO), and the Integrated Surface

1-4
Hourly Database (ISHD a.k.a. ISH, ISD and DSI-3505), which are time-based formats (i.e., by
hour). Prior to version 21DRF, AERMET could also process the TD-3280 format, which is
element-based (i.e., by variable), originally stored on magnetic tape. Beginning with version
21DRF, AERMET no longer supports the TD-3280 format due to its age. While data stored in
some of the older formats (CD-144, SAMSON, and HUSWO) may be part of users' personal
archives and some formats may be available for purchase from the NCEI, recent U.S. and global
data are available for download via File Transfer Protocol (FTP), free of charge, from the NCEI
at: https://www1.ncdc.noaa.gov/pub/data/noaa (web browser) or
ftp://ftp.ncei.noaa.gov/pub/data/noaa (ftp client, anonymous access).

AERMET also processes an hourly surface data format available from the EPA Office of
Air Quality Planning and Standards (OAQPS). This format is a reduced form (fewer variables)
of the CD-144 format and is available for 1984-1992 from the Support Center for Regulatory
Air Models (SCRAM) website (https://www.epa.gov/scram).

There is no standard format or content for site-specific or processed prognostic

meteorological data. These data most likely will include observations made at one or more
levels on an instrumented tower or from remote sensing instrumentation or modeled vertical
grid for prognostic data. Additionally, near-surface measurements such as insolation, net
radiation, and temperature difference may be included. The non-standardized formats preclude
storing these data in a predefined archive format; thus, AERMET does not 'extract' site-specific
data. However, AERMET can read site-specific or processed prognostic data stored in an
ASCII 2 file with a structure that can be described by the user with standard Fortran format
statements. Additional restrictions and specification of site-specific and prognostic data are
discussed in more detail in Section 3.5.3.

Quality assessment (QA) is performed on all the data types except the 1-minute ASOS
wind data. The QA process identifies occurrences of missing data, values that are outside a
range of values, and inconsistencies between selected variables within an observation period.
Default values are defined for the upper and lower bounds and for missing values. The values

2
American Standard Code for Information Interchange

1-5
can be modified through the control file created by the user. Some variables are checked by
default (as noted in the tables in Appendix B) and the user can specify additional variables to be
checked.

If AERMET detects anomalous data, a message is written to the message file informing
the user of the violation. At present there are no provisions for AERMET to automatically
replace missing data or correct "suspect" values. The user should review the QA messages and
determine if the value(s) require modification or if they are acceptable.

If the data require modification, the output files from Stage 1 can be edited using a text
editor. However, any changes should be based on sound meteorological principles and comply
with any relevant regulatory guidance. Modifications should only be done on extracted data, and
not on the archive or raw data file. The archived or raw data should never be altered but should
be maintained as delivered. Whenever changes are made, the modified data should be
reprocessed through the QA process a second time. This stepwise procedure may identify new
problems that, in turn, need to be addressed. When the user is satisfied that the quality of the
extracted data cannot be improved further, the data are ready for the next stage.

1.1.2 Stage 2- PBL calculations and create model input files

The second stage of processing reads the output generated in Stage 1, computes the
boundary layer scaling parameters (e.g., surface friction velocity, mixing height, and Monin-
Obukhov length), and produces two input files for AERMOD. The first file contains the
computed boundary layer parameters, as well as the observed surface parameters (e.g.,
temperature, wind speed, and wind direction). The second file contains one or more levels (a
profile) of winds, temperature, and the standard deviation of the fluctuating components of the
wind if provided. Site-specific monitoring programs commonly collect temperature and wind
measurements at multiple levels. The prognostic data are also commonly multilevel. These
multilevel data are written to the profile file. In the absence of multilevel site-specific data, a
single level from site-specific or NWS hourly surface observations are written to this file.

1-6
1.2 Output files

AERMET creates several files during each stage of processing. These include a report
file that summarizes user options and QA results, a message file that stores errors, warnings, and
detailed QA messages generated during processing, separate extraction files for the NWS
surface and upper air data, and a separate data quality assessment file for NWS surface, upper
air, and site-specific or prognostic data. The extraction files contain the data that are extracted
from archive formats during Stage 1 and subsequently QA’d. The assessment files contain the
QA’d data and are nearly identical in structure and content to the extraction files. The
assessment files are input into Stage 2. As mentioned previously, site-specific (prognostic) data,
processed via the ONSITE (PROG) pathway, are read, and QA’d directly from the user-supplied
file.

The structure and contents of the summary and message files are discussed in the
examples in Section 4.0. The structure and content of the extraction and assessment files are
provided in Appendix C. It is important that the user not alter any of the header records in the
assessment files since they are input into Stage 2, otherwise the data could be processed in an
undesirable way or cause AERMET to fail with a processing error.

1.3 Document Overview

Section 2.0 describes the running of AERMET. Section 3.0 describes the keywords for
each pathway in detail and Section 4.0 presents a basic tutorial of AERMET. Section 5.0
presents technical notes about AERMET. Appendix A through Appendix D present more
information about keywords (Appendix A), meteorological variables (Appendix B), file formats
(Appendix C), and various messages (Appendix D). Appendix E provides a summary of the
different AERMET modules and subroutines, and Appendix F summarizes AERMOD
evaluations using AERMET 22112 and 21112 as part of the AERMET overhaul process.

1-7
1.4 Differences with older versions of AERMET

As part of the update process to AERMET, there are several differences between version
24142 of AERMET and previous versions (21112 and earlier). This section describes some of
the changes, including control file changes, user options, and programming changes that will
result in differences between 24142 AERMET and earlier versions (21112 and earlier).

1.4.1 Control file differences

As part of the update process, changes were made to AERMET that will require the user
to modify existing AERMET control files. The first such change is that the XDATES keyword
for each path now requires the years to be entered as 4-digit years. Previously, AERMET
allowed for 2-digit or 4-digit years. Use of 4-digit years makes processing for years spanning a
century crossover i.e., 1999-2004, easier. See Sections 3.3.3, 3.4.3, 3.5.2, and 3.7.6 for more
information on date extractions for SURFACE, UPPERAIR, ONSITE or PROG, and
METPREP processing.

As discussed in Section 1.1, beginning with version 21DRF, AERMET is now a two-
stage process, instead of a three-stage process. To facilitate the use of existing AERMET input
control files, AERMET 24142 will read existing control files and ignore paths and keywords
that are no longer needed. To run an existing Stage 1 control file, the only change that is needed
by the user is to make sure the years associated with XDATES are 4-digit years. To run Stage 2
(old Stage 3) by itself, the user can combine an existing Stage 2 and Stage 3 control file
(AERMET 21112 or earlier) into one control file and remove the old Stage 3 JOB pathway and
keywords. AERMET will ignore the older MERGE pathway and DATA keyword associated
with the METPREP path. Additionally, the user should ensure all years associated with
XDATES are 4-digit years. To run a new combined Stage 1 and 2 AERMET run, the user can
combine existing Stage 1, 2, and 3 control files (AERMET 21112 and earlier) into one control
file. As previously stated, AERMET will ignore the MERGE pathway and DATA keyword
associated with the METPREP path. Again, the user should ensure all years associated with
XDATES are 4-digit years and remove the Stage 2 and Stage 3 JOB pathway and keywords.

1-8
1.4.2 Other differences

The following is a list of differences between AERMET version 22112 and later with
previous versions of AERMET, version 21112 and earlier. The list includes the topics discussed
above in Section 1.4.1. For some changes, the user can expect to see differences in output
between 23112 AERMET and previous versions (prior to 22112). Those expected differences
are explained when applicable.

• AERMET is now a two-stage process instead of a three-stage process. The merge stage,
Stage 2 in previous versions of AERMET has been eliminated and the previous Stage 3
is now Stage 2. If the MERGE pathway (Section 3.6) is found in the AERMET control
file, AERMET will ignore the associated keywords. Likewise, if AERMET encounters
the DATA keyword (Section 3.7.1) with the METPREP pathway (Section 3.7),
AERMET will ignore the DATA keyword and associated file (old Stage 2 output).

• Years associated with XDATES must be 4-digit years.

• AERMET will now preserve the case (lower or upper case) of any input or output files,
instead of assuming all upper case for filenames. This makes the code more portable for
Linux operating systems as Linux systems are case sensitive while Microsoft Windows
DOS systems are case insensitive.

• Stage 1 EXTRACT and QAOUT files have different formats between AERMET 22112
and previous versions. The ONSITE QAOUT file now has a consistent format, where
before, the QAOUT file followed the format of the raw input file.

• A new averaging option for vector averaging of winds has been added to Stage 1 for
sub-hourly site-specific data. The user invokes the option by specifying the word
VECTOR after the number of observations per hour with the OBS_HOUR keyword. The
default averaging is a scalar average.

1-9
• A new upper air data source, the Integrated Global Radiosonde Archive (IGRA), has
been added in addition to the 6201 and FSL formats.

• The 3280 format for SURFACE data has been dropped and will no longer be supported
by future versions of AERMET.

• The addition of a new pathway, PROG for prognostic data. The PROG pathway is
analogous to the ONSITE pathway and uses the same keywords. The PROG pathway is
utilized for prognostic data to allow for processing of certain variables when the
application is overwater versus overland (Section 3.5.1). When using the PROG
pathway, AERMET will output a text string to the AERMET OUTPUT file (Section
3.13) in the header and for each hour denoting that the data are prognostic. This allows
AERMOD to know the data are prognostic.

• In conjunction with the new PROG pathway, AERMET has additional ONSITE or
PROG variables that can be used for overwater applications. See Appendix B, Table
B-3, and Table B-4. See Section 3.5.1 for details on the overland or overwater
assignments and treatment of variables.

• Additionally, in conjunction with overwater applications, if Monin-Obukhov length is an

input variable and used for overwater applications, AERMET will use Monin-Obukhov
length to determine the stability of the hour (convective or stable) instead of the solar
angle approach currently used. The solar angle approach is used when Monin-Obukhov
length is not available.

• AERMET now allows for the specification of year specific surface characteristics via the
FREQ_SECT, FREQ_SECT2, AERSURF, and AERSURF2 keywords. This allows for a
multi-year AERMET run for Stage 2 in one AERMET run instead of separate annual
AERMET runs when surface characteristics change on an annual basis. See Section
3.7.9.5 for more details.

1-10
• For seasonal surface characteristics only, AERMET uses the primary and secondary
station coordinates to determine the hemisphere of the respective station. This is used to
allocate the seasonal characteristics to the appropriate months based on the hemisphere.
For example, for winter characteristics, if the station is in the Northern Hemisphere, the
winter characteristics are assigned to January, February, and December. If the station is
in the Southern Hemisphere, then the winter characteristics are assigned to June, July,
and August. This feature allows the user to enter seasonal characteristics that represent
the season for the hemisphere. Thus, for applications in the Southern Hemisphere, the
user does not need to assign representative summer surface characteristics to winter so
that AERMET will assign the characteristics to the correct months. See Section 3.7.9 for
more details.

• The no persistence keyword, NOPERS, used for cloud cover and temperature
substitution for hours 23 and 24 in METPREP are now obsolete. These keywords were
present because previous versions of AERMET processed each day separately within the
program and previous versions could not read ahead to the next day to allow for hours
23 and 24 interpolations. Based on the recoding of AERMET, AERMET can now read
the next day’s observations so hours 23 and 24 can be interpolated in the same manner
as other hours in the day.

• In previous versions of AERMET, when processing NWS data, if hour 24 was

completely missing from the Stage 2 output, i.e., the hour was not in the raw data file in
Stage 1, AERMET would copy hour 23 (if available) to hour 24 of the day. This is no
longer done in AERMET version 22112 or later, so hour 24 may be missing in the final
AERMET output. Additionally, temperature and cloud cover may be substituted from
hour 23 of the same day and hour 1 or 2 of the next day. This change could result in
differences for hours 24, 1, and 2 when comparing AERMET version 22112 and later to
previous versions of AERMET.

• Hourly precipitation values may differ between 22112 AERMET and previous versions.
Previous versions of AERMET do not reset hourly precipitation to zero in METPREP

1-11
 before reading the precipitation from the MERGED output. This can result in
precipitation values for hours that are missing in the MERGE output because previous
versions of AERMET do not reinitialize the precipitation, so the previous day’s value of
precipitation is used for the hour. 21DRF AERMET corrects this issue.

• For applications involving site-specific or prognostic mixing heights, AERMET version

22112 and later smooths the mixing height based on the previous hour’s mixing height,
like when AERMET calculates mechanical mixing heights. Previous versions of
AERMET did not smooth the mechanical mixing heights read from the site-specific or
prognostic data.

• As part of the overhaul of AERMET with version 21DRF, the variables that are type real
in FORTRAN are now double precision in AERMET. Previous versions of AERMET
treated these variables as real. Due to the differences between double precision and real,
some variables may have slightly different values due to rounding, and other variables
may have more differences as logic code within AERMET may have different outcomes,
even though the numbers used in the logic are slightly different. This could result in
different processing based on the logic, leading to different output values.

• NWS wind speeds associated with variable wind directions are not corrected for
truncation (Section 3.7.7.3) in Stage 2 as done in previous versions of AERMET.

1.5 Updates from 23132 to 24142

Following is a list of changes made to version 23132 as part of the 24142 update:

1-12
Bug fixes

• Modify subroutine READ_CD144 in mod_surface.f90 to convert negative

temperatures from Fahrenheit to Celsius when reading NWS data in CD-144 format.

• Correct implementation of the AERMET default mixing height calculations option

(MIX_DFAULT) for COARE processing in COARE and MECH_HT subroutines.

• Correct bugs related to surface roughness calculations in COARE using wave data
(period and height). Correct bug in up_modify to only set a particular day’s value in
the lsound array, not the entire array. Modify AERMET to write out un-successful
completion of AERMET when non-numeric characters encountered in the OUTPUT
and PROFILE files. AERMET issues an ERROR in the message file but did not
report an un-successful AERMET run.

Enhancements

• Modify AERMET to use the following hierarchy to substitute missing surface level
heights in a sounding: 1) the most recent non-missing surface level read from the
data file, 2) use the user-supplied station elevation from the LOCATION keyword
when no recent surface level is available, or 3) use the surface level’s pressure and
the standard atmosphere to calculate a surface level height.

• Modify AERMET so that the user MUST supply a station elevation on the
LOCATION keyword for the UPPERAIR station. The elevation is used to
substitute for missing surface level heights for soundings.

1-13
Miscellaneous

• Add information and warning messages about certain input variables such as u*,
Monin-Obukhov length, etc. will not be used when invoking COARE but will be
calculated by COARE Modify AERMET such that user has to select a surface
roughness option for COARE; no longer default to zo based on u* if no option
selected.

1-14
2.0 Running AERMET

This section is designed to provide the user with a basic understanding of the
requirements to run AERMET. This section will explain the pathway and keyword approach
and associated syntax rules for processing meteorological data in AERMET.

2.1 AERMET execution

AERMET is a DOS-based program and is run from the command prompt on computers
running a version of Microsoft Windows. AERMET can also be compiled and executed on Unix
or Linux systems. On Windows systems, the syntax for running AERMET for a single stage or
combined stages is:

path-to-AERMET.EXE\AERMET

path-to-AERMET.EXE\AERMET input_filename

On Linux or Unix systems, the syntax is:

path-to-AERMET.EXE/AERMET

path-to-AERMET.EXE/AERMET input_filename

where path-to-AERMET.EXE is the directory path to the AERMET executable file.

When no input file name is specified, AERMET assumes the input filename is ‘aermet.inp’ for
each stage and the file resides in the current working folder or directory. The specification of an
input filename is applicable to versions of AERMET beginning with version 18081 and the
filename can include a full directory pathname for the file. When running AERMET with no
input filename as an argument, each stage’s input file should be copied to a file named
aermet.inp (case insensitive on DOS and case sensitive on Unix or Linux systems). Examples
following in the rest of this document are for the latest version of AERMET.

2-1
 As AERMET runs, the progress is displayed on the screen, unless the option NOPRINT
(Section 3.2.4) is specified on the JOB pathway (Section 3.2). In addition to the output data
files, each run will produce a message file and report file if a report file is specified. Note, the
filenames and extensions are all user-defined, i.e., there are no default names or extensions.

A word of caution for this example and for all AERMET runs, all output files are opened
with the Fortran file OPEN specifier of STATUS = 'UNKNOWN'. With this specifier, if the file
already exists, the contents will be overwritten without any opportunity to save it.

More details and examples about running AERMET are available in Section 4.0.

2.2 Control file

Processing meteorological data with the AERMET preprocessor is divided into two
stages as shown in Figure 1-1. Each stage can be run separately or in a combined run. A file
containing a sequence of control statements is required to define the actions that AERMET is to
perform and how to perform them. This file is referred to as the input control file. There can be a
separate control file for each stage of processing or a single control file that runs both stages in
one run. The user can enter the unique name of the control file on the command line when
executing AERMET from the command line as discussed in Section 2.1.

The statements in the control file are divided into six functional groups, or pathways:

• JOB for specifying information pertaining to the entire run;

• UPPERAIR for extracting and QA'ing NWS upper air sounding data;

• SURFACE for extracting and QA'ing NWS hourly surface observations;

• ONSITE for QA'ing user-supplied, site-specific meteorological data;

• PROG for QA'ing user-supplied, prognostic meteorological data; and

• METPREP for estimating boundary layer parameters for AERMOD.

2-2
 The pathway identifier appears on a line by itself and identifies the beginning of a
contiguous block of statements that apply only to that pathway. Depending on the stage of
processing and the type of data that are being processed, there will be two to five pathways
specified in a single AERMET control file. A seventh pathway, MERGE, is a legacy of
AERMET prior to the 21DRF version (AERMET version 21112 and earlier). If AERMET
(21DRF and later) detects the MERGE pathway, it is ignored.

The records within a pathway make use of a keyword and parameter approach for
specifying the input to AERMET. The keywords and parameters that make up this file can be
thought of as a command language through which the user directs AERMET. It is the
combinations of keywords and parameters that direct AERMET how to process the data.
However, there are several rules of syntax that must be observed for AERMET to correctly
process the data.

2.2.1 Control file setup

While the control file has been designed to provide the user with flexibility in the way it
is structured, there are some basic syntax rules that must be followed. These rules standardize
the format of the control file. These rules are:

• The pathway identifier appears on a line by itself followed by all the input records
for that pathway. In other words, all the records for a particular pathway must be
contiguous without any intervening keywords for other pathways.

• Each record in the control file cannot exceed 500 characters in length. Prior to
AERMET 21DRF, the limit was 132 characters in length. The record can begin in
any column, so long as the entire length of the record, including leading blanks,
does not exceed 500 characters. For example, records starting with keywords can
be indented for readability (as is done throughout this user's guide). Each field on a
record must be separated by one or more spaces or a comma and must appear in a
particular order (with a few exceptions as noted later in the user's guide).

• Blank records can be included anywhere in the control file to improve readability.

2-3
• If asterisks appear in columns 1 and 2 (**), AERMET ignores the statement. By
using the asterisks, the statement acts as a comment, which can be used to identify
the purpose of the control file, clarify the content of an individual keyword, or
ignore a keyword if the user edits a control file but wants to preserve the prior
content.

• Alphabetical characters can appear in either upper case or lower-case letters.

• AERMET converts these characters to upper case (which is why any information
echoed to an output file is all upper case) to insure exact matches on keywords and
parameters. However, beginning with version 21DRF, AERMET retains the
original case of character strings associated with filenames. This allows AERMET
to work more efficiently with Linux and UNIX systems, which are case sensitive.

• Some keywords are mandatory, while others are optional. A keyword is mandatory
to the extent that there are data to process for the pathway and without the
keyword, the eventual product from AERMET (the output files from Stage 2)
could not be generated. Optional keywords are used to include or extend data
processing actions. Most of the keywords used in the tutorial are mandatory. Some
keywords are repeatable, such as the keywords to specify the format of any site-
specific data, while others may only appear once. These terms are discussed in
more detail in Section 3.0. Keywords by pathway are provided in Appendix A and
are identified as mandatory or optional, repeatable or nonrepeatable.

• In general, the order of keywords within a pathway is not important, though there
are a few exceptions for the ONSITE (PROG) and METPREP pathways. These
keywords pertain to the variables and format of the site-specific (prognostic) data
in Stage 1and the surface characteristics on the METPREP pathway in Stage 2.

• Filenames must conform to the naming conventions appropriate to the computing

platform and cannot exceed 300 characters in length. Prior to version 21DRF, the
filenames could not exceed 96 characters in length.

2-4
3.0 Keyword reference

3.1 Definitions and control file processing

The terms "mandatory" and "optional" indicate whether the keyword for a particular
pathway is required to run AERMET (mandatory) or if it enhances or modifies the processing
(optional). Several keywords may be mandatory or optional depending on the point they are
used in the processing of the data. For example, QAOUT serves two purposes: to define the
output file for Stage 1 QA and to define the input file for Stage 2 calculations. While data QA is
optional in Stage 1, the keyword is mandatory if the AERMET run is not a combined Stage 1
and 2 run. A distinction will be made when the keyword type may be ambiguous. For the
discussions in the following sections, the stages to which the keyword refers to will be in
parentheses following the terms "mandatory" and "optional". If 'All' is specified, then the
keyword applies to all stages of processing.

The terms "repeatable" and "nonrepeatable" refer to whether the keyword can appear
only once (nonrepeatable) or more than once (repeatable) for the same pathway in a control file.
For example, the MESSAGES keyword can appear only once on the JOB pathway, thus it is
nonrepeatable. However, the RANGE keyword for assessing the validity of the data can appear
multiple times on a pathway, thus it is repeatable. A nonrepeatable keyword may appear
multiple times in a control file, but only once per pathway. For example, the QAOUT keyword
defines the input file for each pathway for Stage 2 (merging data and PBL calculations). It can
appear only once for each pathway, but it will appear two or three times in the control file
because there is usually more than one type of data used in Stage 2.

Except for a few keywords, there are no special requirements for the order of the
keywords within each pathway, but it is recommended that a logical order be maintained to be
able to understand the processing defined by each control file.

The syntax descriptions in the following sections use certain conventions. The keywords
are all upper case, and the parameters are all lower case. Square brackets around a parameter
indicate that the parameter is optional, and a default value may be used if it is omitted.

3-1
 A word of caution that deserves repeating: for an AERMET run, all output files are
opened with STATUS = 'UNKNOWN'. With this specifier, if the file already exists, AERMET
will open it without providing any opportunity to save it. With the first write action to the file,
the contents of an existing file are erased. Before running AERMET, the user should be certain
that any output file name specified in a control file either does not exist or can be overwritten.

3.2 JOB Pathway

The JOB pathway appears in all AERMET control files. The primary purpose of the JOB
pathway is to specify the file names for reporting all the preprocessor actions that are performed
for that run.

3.2.1 MESSAGES

All error, warning, informational, and QA messages issued by AERMET are written to
the file name specified with the MESSAGES keyword. The contents of this file are discussed
throughout the tutorial in Section 4.0. This keyword is mandatory because the program later
uses this file to summarize the processing. The syntax and type are:

Syntax: MESSAGES message_filename

Type: Mandatory (All), Nonrepeatable

The message_filename must conform to the naming conventions appropriate to the

computing platform. The maximum length of this file name is 300 characters.

3.2.2 REPORT

At the conclusion of a run, AERMET reads the file of messages, tabulates the different
types of messages (errors, warnings, etc...), and summarizes all the actions for that run in a file
specified with the REPORT keyword. The REPORT file also summarizes input and output
filenames, quality assurance summary (Stage 1), requested processing steps, and other inputs

3-2
such as surface characteristics. The contents of a run summary are discussed throughout the
tutorial in Section 4.0. The syntax and type for this keyword are:

Syntax: REPORT summary_filename

Type: Optional (All), Nonrepeatable

The summary_filename must conform to the naming conventions appropriate to the

computing platform. The maximum length of this file name is 300 characters.

This keyword is optional. If it is omitted, then the summary is written to the output
control device connected to logical unit 6. On a personal computer, this unit is normally the
video monitor. This information can be captured using redirection (as discussed in
Section 4.0).

3.2.3 CHK_SYNTAX

AERMET processes all the statements in a control file prior to processing any data.
Incomplete information on a keyword or the omission of a keyword will cause AERMET to
terminate the run. The CHK_SYNTAX keyword directs AERMET to process the control file
and report any problems without performing any data processing. The user can review the
summary and message files and correct any errors or make any changes to the control file prior
to processing data. The syntax and type of the CHK_SYNTAX keyword are:

Syntax: CHK_SYNTAX
Type: Optional (All), Nonrepeatable

No parameters accompany this keyword.

3-3
 The user gets a full report of the processing of the control file, i.e., the MESSAGES file
and REPORT file are generated and can be reviewed. In the REPORT file, the following
appears near the top of the file:

THIS RUN ONLY CHECKS THE RUNSTREAM INPUT

3.2.4 NOPRINT

Beginning with version 21DRF, AERMET will suppress output to the screen. This
usually is the progression of operations through each day. The syntax and type of the NOPRINT
keyword are:

Syntax: NOPRINT
Type: Optional (All), Nonrepeatable

No parameters accompany this keyword.

3.2.5 DEBUG

Beginning with version 21DRF, AERMET has a debug option that will output certain
calculations and messages from Stage 1 and most calculations in Stage 2 to a debug file. The
syntax and type for this keyword are:

DEBUG
Syntax:
Or
DEBUG debug_filename
Type:
Optional (All), Nonrepeatable

3-4
 Note that the DEBUG keyword can be followed by an optional filename. If the filename
is not listed, the default filename is aermet_debug.txt. When the debug keyword is used for
Stage 1 processing, the following is output to the debug file:

• When calculated upper air variables, speed shear, direction shear, and lapse rate
are audited, AERMET outputs the variables and calculations for those variables.

• When reading sub-hourly site-specific data, AERMET will output the values
used for hourly averaging of sub-hourly variables.

When the debug keyword is used for Stage 1 processing, the following is output to the
message file:

• When reading ISHD data, AERMET will output messages to the message file
regarding replacement of observations with report type.

When the DEBUG keyword is used with Stage 2 processing, AERMET will output the
following to the debug file:

• Upper air sounding used for each day

• Value and source of key observed variables such as winds, temperature, pressure,
cloud cover, precipitation, etc.

• Values are used for temperature and cloud cover substitution

• Solar angle, critical angle, and resulting convective/stable assignment for each
hour

• Calculations for variables such as surface friction velocity, convective velocity

scale, mechanical and convective mixing heights, etc.

The debug option will provide output for each day and hour designated by the XDATES
keyword. The debug file can become quite large so the debug option should be used with
caution.

3-5
3.3 SURFACE pathway

The SURFACE pathway defines all the necessary information for processing NWS
hourly surface weather observations or surrogate data that complies with an established format.
These data provide information on temperature, winds, and cloud cover that can be used in
estimating dispersion parameters. The data generally come from first order observation stations
(observations 24 hours per day) located at or near airports. AERMET can read and process a
variety of formats, each discussed below with the DATA keyword.

3.3.1 DATA

Hourly NWS surface observations are stored in a variety of compact formats. Data
stored in one of these formats is referred to as archived data. One of AERMET's functions is to
read and interpret the archived data and to write the results in another format for later
processing. The DATA keyword is used to specify the file name and define the archive file
format. The syntax and type for the DATA keyword are:

Syntax: DATA archive_filename file_format [ASOS]

Type: Mandatory* (Stage 1 only; Stage 1 and 2 combined), Nonrepeatable

The archive_filename must conform to the naming conventions appropriate to the

computing platform.The maximum length of the archive_filename is 300 characters. The
keyword is mandatory under certain conditions and is optional under other conditions. The
keyword is mandatory if performing Stage 1 processing (separately or in a combined Stage 1
and 2 AERMET run) and the EXTRACT keyword (Section 3.3.2) is not used or the file
associated with the EXTRACT keyword is empty. The DATA keyword is optional if the
EXTRACT keyword is present, and the file associated with the EXTRACT keyword is not
empty. In that case, the data in the file associated with the EXTRACT keyword is the input data.

For processing archive data, the file_format must be specified as one of the following:
CD144, EXTRACT, SCRAM, SAMSON, HUSWO, or ISHD. Each of these formats is
discussed in more detail below. Beginning with version 21DRF, a new format, EXTRACT can

3-6
be used. This can be used to read in NWS data in the format of the EXTRACT or QAOUT file
generated by AERMET. Also beginning with AERMET version 21DRF, two formats, 3280VB
and 3280FB are no longer supported due to their age.

AERMET includes a table of ASOS commission dates used to identify whether NWS
surface data input to AERMET are from an ASOS site. The ASOS parameter is applicable only
for the ISHD format and is used to identify the data as having originated from an ASOS site for
stations that are not included in the table of ASOS commission dates. The optional ASOS
parameter should only be used if the data are known to be from an ASOS site that is not
included in the table of ASOS commission dates. Wind speeds collected at ASOS sites,
archived in the ISHD format, are truncated rather than rounded to whole numbers (NOAA,
2008). This introduces a bias in the data toward lower wind speeds. To compensate, AERMET
adds ½ knot (0.26 m/s) to all ASOS-based wind speeds. A more detailed discussion of this
adjustment to ASOS wind speeds is in Section 3.7.7.3.

NOTE: In earlier versions of AERMET, the DATA keyword included the blocking factor and
data type (ASCII or EBCDIC) parameters. These 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 with the DATA keyword.

3.3.1.1 CD-144 and SCRAM formats

The CD144 format is an older standard format previously used by the NCEI for
archiving surface observations. Alphanumeric characters are used to represent various weather
elements. All the weather elements for one hour are stored on one logical record and the length
of each logical record is 79 characters.

The SCRAM format is a reduced version of the CD144 format and is available from the
EPA's Support Center for Regulatory Air Models (SCRAM) website. Fewer weather elements
are reported. Each logical record is 28 characters and includes data for cloud ceiling height, dry
bulb temperature, wind speed and direction, and opaque sky cover. AERMET requires surface

3-7
station pressure for some of its computations (e.g., density of air). The SCRAM format does not
include station pressure and sea level pressure, so a standard atmosphere (1013.25 millibars) is
assumed when this format is used.

AERMET operates on a 01 - 24 clock but these two formats report data on a 00 - 23

clock. Hour 00 is hour 24 of the previous day. In previous versions of AERMET, when data
were retrieved from an archive file for a specific period, the first hour was discarded since it was
prior to the beginning time. Likewise, since the data for a day end with hour 23, the last day in
the extracted data file will only have 23 hours. This has been changed beginning with AERMET
21DRF in that the conversion from 00 – 23 to 01 – 24 takes place before comparing the data’s
dates against the processing dates.

AERMET reads several of the columns in the CD-144 format as character since numbers
or letters could appear in those columns. AERMET then attempts to decipher/decode these
columns by comparing the character it has read with a list of valid characters. If there is no
match, then AERMET issues a warning on which overpunch position could not be deciphered.
The following table lists the correspondence between the overpunch character and column in the
CD-144 format. Note, the term ‘overpunch’ refers to the ‘old’ days when 80-column computer
cards were used and the amount of information on a single card was limited. Overpunches
conserved space and were produced by pressing the overpunch key and pressing a numeric
value (0-9) and another key, usually the sign of the number. This overpunch technique
generated a character rather than a numeric value, which is what AERMET is trying to decode.

3-8
 Overpunch CD-144 CD-144 element
1-3 14-16 Ceiling height
4 17 First sky cover layer
5 18 Second sky cover layer
6 19 Third sky cover layer
7 20 Fourth sky cover layer
8 36 Sign of the dew point (X | dew
9 41 1st digit of wind speed (X|speed
10 47 Sign of the dry bulb (X | dry bulb
11 50 Sign of the wet bulb (X | wet bulb <
12 56 Total sky cover
13-34 57-78 Cloud data by layer
35 79 Opaque sky cover

The data associated with overpunches 9, 10, 12, and 35 (in bold above) may be used by
AERMET, depending on the availability of other (e.g., site-specific) data. The other fields are
decoded, but the weather information contained in them currently are not used by AERMET.

3.3.1.2 SAMSON format

As storage technology and capacity improved, larger amounts of data can be stored in
smaller amounts of space. The NCEI made available solar and meteorological data for the first
order stations in the United States for the period 1961-1990 on a set of three CD-ROMs,
collectively referred to as the Solar and Meteorological Surface Observational Network
(SAMSON) dataset. This disc set is still available from NCEI (https://www.ncei.noaa.gov/), and
AERMET can process the data retrieved from these CD-ROMs.

→AERMET cannot access the data directly on a SAMSON CD-ROM.

Rather, the user must run the software provided with the data to retrieve the station(s), period(s)
of time and variables for the site and period to be modeled. The software is a DOS-based,
interactive graphical interface. The output files are written as an ASCII file on the user's local
drive. It is this output that AERMET processes.

Retrieving the meteorological data from the CD-ROM is completely under the control of
the user, i.e., the user specifies which meteorological elements to retrieve from a list of 21

3-9
elements stored for each station. When processing SAMSON data with AERMET, the following
elements should be retrieved: ceiling height, wind direction and speed, dry bulb temperature,
opaque cloud cover, total sky cover, and station pressure. These elements result in an ASCII file
of about 450 Kb for one year of meteorological data. If all 21 variables are retrieved, then a file
size of about 1.2 Mb is created, although the file size will vary because precipitation data (in
field 21) are reported only if there was precipitation for the hour, making some records longer
than others.

When the data are retrieved from the CD-ROM, two records are written at the beginning
of the file that identify the station (first record) and the variables retrieved (second record).
These two initial records, or headers, begin with the tilde character (~). AERMET processes
both records to obtain information about the station (e.g., station WBAN number) and to
determine how to process the data that follow. It is imperative that the user not alter or delete
these records.

If more than one year of data are retrieved from the CD-ROM, then two records
beginning with the tilde appear before each year in the file. When the second set of headers is
encountered, AERMET will print a warning in the message file and continue processing data. It
is recommended that the user restrict data retrieved from CD-ROM to one station and one year
per file or edit a multi-year file such that there is only one year per file.

The header records are followed by the data records. There is one record for each hour of
the period the user retrieved. Unlike the CD-144 format which reports the hour on the 00-23
clock, the hour is reported on the 01-24 clock, which is consistent with AERMET data
processing.

3-10
3.3.2 EXTRACT

The EXTRACT keyword specifies the file name to which the data retrieved from the
archive file are written. The syntax and type are:

Syntax: EXTRACT extracted_data_filename

Mandatory (Stage 1 only), Nonrepeatable
Type: Or
Optional (Stage 1 and 2 combined), Nonrepeatable

The extracted_data_filename must conform to the naming conventions appropriate to the

computing platform. The maximum length of this file name is 300 characters. Note that when
running AERMET for Stage 1 only, the EXTRACT keyword is mandatory. However, if
performing a combined Stage 1 and 2 AERMET run, the EXTRACT keyword is optional as
Stage 2 will use the internal AERMET arrays to read extracted data from Stage 1.

The variables written to the EXTRACT file are those variables only needed for Stage 2
processing and are the variables that are not shaded in Table C-1 in Appendix C.

3.3.3 XDATES

The amount of data extracted from an archive file can be limited by using the XDATES
keyword to specify the beginning and ending dates of the data to be extracted. The syntax and
type are:

XDATES YB/MB/DB [TO] YE/ME/DE

Syntax: Or
XDATES YB/MB/DB [-] YE/ME/DE
Mandatory (Stage 1 only), Nonrepeatable
Type: Or
Optional (Stage 1 and 2 combined), Nonrepeatable

3-11
 YB, MB and DB are the beginning year, month, and day, respectively, of the data to
extract and YE, ME, and DE are the ending year month and day, respectively. Beginning with
version 21DRF, the year must be entered as a four-digit integer (e.g., 1992). The month is a one-
or two-digit integer corresponding to the month of the year and the day is the one- or two-digit
day of the month. The dates can be entered in various ways. The individual components of start
date or end date can be separated by spaces or the ‘/’ character or no separator at all. However,
the start date cannot be separated by spaces and the end date separated by ‘/’ or vice-versa. Both
dates must use the same delimiter. The complete start date and end date can be separated by a
space, ‘- ‘, or the word “TO”. The case of the word “TO” can be upper, lower, or a mix of cases.
The following are valid methods to enter the dates, using January 1, 2020 and December 31,
2020 as the dates:

• 2020/01/01 2020/12/31
• 2020/01/01 TO 2020/12/31
• 2020/01/01 – 2020/12/31
• 2020 01 01 TO 2020 12 31
• 2020 01 01 – 2020 12 31
• 2020 01 01 2020 12 31
• 20200101 20201231

The following are invalid methods to enter dates, again using January 1, 2020 and December 31,
2020 as the dates:

• 2020/01/01 2020 12 31
• 2020 01 01 2020/12/31
• 2020/01/01 - 2020 12 31
• 2020 01 01 - 2020/12/31
• 2020/01/01 TO 2020 12 31
• 2020 01 01 TO 2020/12/31

3-12
 The XDATES keyword is mandatory if performing Stage 1 processing only. The
XDATES keyword is optional if performing combined Stage 1 and 2 processing and XDATES
is present for the METPREP pathway. If XDATES is present for the METPREP pathway,
AERMET will use the METPREP dates for extraction of surface data if SURFACE EXTRACT
or QAOUT files are not requested. If SURFACE EXTRACT or QAOUT files are requested,
then the surface extraction uses the dates associated with XDATES on the SURFACE pathway.

3.3.4 LOCATION

The LOCATION keyword identifies the meteorological station by the station's identifier,
latitude and longitude of the station, and a time adjustment factor used to adjust the data to local
standard time. The syntax and type are:

Syntax: LOCATION site_id NWS_lat/long NWS_long/lat [tadjust] [elevation]

Type: Mandatory (Stage 1), Nonrepeatable, Reprocessed
Order: Latitude (lat) and longitude (long) can appear in either order

The site_id is a five-to-eight-character alphanumeric specifier that identifies the station

for which data are to be extracted. For the standard formats listed on the DATA keyword, these
identifiers are five-digit WBAN (Weather Bureau Army Navy) numbers. Prior to version
21DRF, the site_id must be specified with leading zeros to fill a minimum of five characters
(e.g., 3928 had to be entered as 03928) since the field was read as a type character and not an
integer. This is no longer the case beginning with 21DRF, so 3928 can be entered as 3928, not
03928. However to avoid warnings in AERMOD, all characters of the site_id should be numeric
as AERMOD expects a numeric value in the AERMOD control file which should match the ID
of the SURFACE station identifier in the surface file generated by AERMET. A master list of
WBAN numbers for stations throughout the world can be obtained from NCEI.

The NWS station latitude (lat) and longitude (long) can be entered in either order
because AERMET distinguishes between the two by the suffix on each: N or S with the latitude
and W or E with the longitude. For example, "38.4N 81.9W" will be interpreted the same as

3-13
"81.9W 38.4N" in AERMET. AERMET cannot use, nor does it recognize, "+" or "-" to
discriminate between north and south, and east and west. Therefore, the latitude and longitude
should always be specified as positive numbers.

The parameter, tadjust, is an optional adjustment factor that is subtracted from the
reported hour to convert the time to local standard time. The default value is zero if omitted
from the LOCATION keyword on the SURFACE pathway. Though optional, it should be
included when the offset to local standard time is non-zero and when the last parameter,
elevation, is specified, which is also optional. For stations west of Greenwich, England, i.e., the
Prime Meridian (0° longitude), tadjust should be specified as a positive number. Apart from
ISHD, the standard NWS surface data formats processed by AERMET report the time as local
standard time. Therefore, tadjust is zero for all standard NWS formats processed by AERMET,
apart from the ISHD format, unless the data are known to be reported for a time zone that is not
local standard.

The final parameter, elevation, refers to the station elevation above mean sea-level
(MSL), in meters, and is also optional with a default value of zero meters. Station elevation
should be included, however, when the actual station elevation is non-zero since it will be used
in the substitution hierarchy for missing station pressure (see Section 5.5 ).

3.3.5 QAOUT

One purpose of AERMET is to contribute to the quality assurance process by identifying

data that are out of range or suspect so the user can determine appropriate steps to accept,
modify, or reject the data. The quality assessment (QA) is performed by including the QAOUT
keyword in the control file. This keyword is also used to specify the input file to Stage 2. The
syntax and type for the QAOUT keyword are:

3-14
 Syntax: QAOUT qa’d_data_filename
Optional (Stage 1 only; Stage 1 and 2 combined),
Type: Nonrepeatable
Mandatory (Stage 2 only) if reading SURFACE data,
Nonrepeatable

The qa_output_filename must conform to the naming conventions appropriate to the

computing platform. The maximum length of this file name is 300 characters.

Quality assessment is an optional process, and the user does not have to perform a QA
prior to using the data in PBL calculations. However, this step is recommended to identify
possible errors in the data that are used to derive the boundary layer parameters. Note that when
running AERMET for Stage 1 only or a combined Stage 1 and 2 run, the QAOUT keyword is
optional. For a combined Stage 1 and 2 run, Stage 2 will use the internal AERMET arrays to
read extracted data from Stage 1. However, if running AERMET for Stage 2 only, the QAOUT
keyword is mandatory for Stage 2 to read the QA’d output. The variables written to the QAOUT
file are those variables needed for Stage 2 processing plus additional variables not needed for
Stage 2 but can be used for quality assurance. The additional variables are those that are shaded
in Table C-1 in Appendix C.

AERMET's QA procedures include verifying that the values of the weather elements are
not outside a range of 'acceptable' values and keeping track of the number of missing values.
These checks operate on one observation period at a time, i.e., temporal variations of the data
are not checked.

On the SURFACE pathway, when a quality assessment is performed, several of the

weather elements are automatically tracked (audited) and included in a summary of the QA
process. These elements are dry bulb temperature, wind speed, and wind direction. The hourly
value of each variable is compared to a missing value indicator and if the value is not missing,
then the value is compared to an upper and lower bound that define the range of acceptable
values. Each time a value is missing or violates one of the bounds, a message is written to the
message file defined by the MESSAGES keyword. The message includes the value, the

3-15
violation, and the date and time of the meteorological record where the violation occurred. The
date is reported in the first field of the message. The number of times the weather element is
missing, exceeds the upper bound and exceeds the lower bound is tallied and reported in the
summary file defined by the REPORT keyword.

In the current version of AERMET there are no provisions for automatically replacing
missing values or adjusting values that are outside the range of acceptable values. It is up to the
user to review the QA summary information and, using sound meteorological principles and
regulatory guidance, decide whether to retain or replace the value(s) in question.

There are default upper and lower bounds in AERMET, as well as a default missing
value indicator. These values can be changed by the user using the RANGE keyword, as
described below. The user can also choose to QA additional weather elements by using the
AUDIT keyword.

3-16
3.3.6 AUDIT

As mentioned in the previous section, there are only three weather elements that are
tracked by default during QA. The user can track additional weather elements for a particular
AERMET run by specifying the element name with the AUDIT keyword. The syntax and type
for this keyword are:

AUDIT sfname1 ... sfnamen

Syntax: or
AUDIT ALL
Optional (Stage 1 or Stage 1 and 2 combined),
Type:
Repeatable

where sfname1, ..., sfnamen are the internal AERMET names of the weather elements as defined
in Table B-1 of Appendix B. As many names can be specified on a single keyword use, so long
as they fit within the 500-character limitation of a line. This keyword is repeatable, so more than
one AUDIT keyword can be used to define additional elements to track. Beginning with version
21DRF, if the user wishes to audit all variables, the user enters the word ALL after the keyword
AUDIT. The case of the word ALL is case insensitive.

While the AUDIT keyword can add weather elements to the QA, there is no method to
remove any of the default weather elements from the QA. They are always reported.

3.3.7 RANGE

The user can modify the upper or lower bound limits for the QA if the values are not
appropriate for the data. The missing value indicator can be changed as well and is the most
likely reason this keyword is used. These changes are accomplished using the RANGE
keyword. The syntax and type for the RANGE keyword are:

3-17
 Syntax: RANGE sfname lower_bound <[=] upper_bound missing_indicator
Optional (Stage 1 or Stage 1 and 2 combined), Repeatable,
Type:
Reprocessed

where sfname is the internal AERMET name of the weather element as defined in Table B-1 of
Appendix B, lower_bound and upper_bound are the new lower and upper bounds to be used in
the QA, and missing_indicator is a new missing value code. The special symbol "<" and the
optional "=" indicate whether to exclude (<) or include (<=) the lower and upper bound values
in the QA, i.e., exclude or include the endpoints of the acceptable range of values. All
parameters must be specified for this keyword; if a parameter is not changing, the default value
should be specified.

Prior to version 21DRF, data for the SURFACE pathway were written as integers with
some variables being multiplied by 10 when extracted to retain significant digits. Table B-1
provides information on which variables use a multiplier. The default upper and lower bounds
are multiplied as well, therefore, the user must multiply any new upper and lower bounds by the
same multiplier when entering the data on the RANGE keyword. However, the multiplier is not
applied to the missing_indicator. Beginning with version 21DRF, the data are written out as
their actual values, i.e., recorded temperature in the EXTRACT or QAOUT file is the actual
temperature, not temperature multiplied by 10.

Several weather elements have been concatenated to form a single variable in the
extracted_data_file. These variables are noted in Table B-1 and are related to cloud cover,
weather type and height (locate the double slash (//) in the descriptions). If the user wants to
modify the bounds and the missing value indicator through a RANGE keyword, these values
must be concatenated also.

3.3.8 NO_MISSING

Every time a bound is violated or a value is missing, a message is written to the message
file (defined with the MESSAGES keyword). If one weather element that is tracked for
reporting (either by default or defined by an AUDIT keyword) is missing or is equal to the

3-18
missing value on several records (e.g., station pressure in a SCRAM archive file), the message
file could become very large. To reduce the number of missing value messages and the size of
the message file, the NO_MISSING keyword can be included for the QA. The syntax and type
are:

NO_MISSING sfname1 ... sfnamen

Syntax: Or
NO_MISSING ALL
Type: Optional (Stage 1 or Stage 1 and 2 combined), Repeatable

where sfname1, ..., sfnamen are the internal AERMET names of the weather elements to omit
from the message file. Beginning with version 21DRF, if the user wishes to suppress messaging
for all variables, then the word ALL can follow the keyword NO_MISSING. Though the
NO_MISSING keyword suppresses messages written to the message file, a count of missing
values for audited variables are still tallied and included in the summary report file.

3.3.9 ASOS1MIN

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 within the U.S. The U.S. NWS
and FAA began an effort in 1992 to replace the traditional observer-based system for collecting
and reporting weather data 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.

In addition to the standard archives of surface observations based on ASOS, the NCEI
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

3-19
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.

Beginning with version 11059, AERMET was updated to accept hourly averages of
wind speed and wind direction derived from 1-minute or 5-minute ASOS wind observations
available from the NCEI at https://www.ncei.noaa.gov/data/automated-surface-observing-
system-one-minute-pg1/access/ for 1-minute data and at
https://www.ncei.noaa.gov/data/automated-surface-observing-system-five-minute/access/ for 5-
minute data. 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, 2023a).
Hourly-averaged wind speed and direction data derived from 1-minute or 5-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

3-20
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:

Syntax: ASOS1MIN file_name

Optional (Stage 2 or Stage 1 and 2 combined), Non-repeatable

Type:
Must be input on the SURFACE pathway

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 ONSITE winds or replace
standard SURFACE winds, the secondary keyword REFLEVEL (Section 3.7.7.2) must be
specified with the SUBNWS parameter as a METHOD on the METPREP pathway in the Stage
2 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 to be written to the surface file (SFC) generated during Stage 2
processing:

1. ONSITE winds,
2. 1-min ASOS winds; then
3. standard SURFACE winds.

Neither NWS SURFACE wind data 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 2 control file.

3.4 UPPERAIR

The UPPERAIR pathway defines all the necessary information for processing NWS
rawinsonde (sounding) data. These data provide information on the vertical structure of the
atmosphere and are used to calculate convective mixing heights in Stage 2. The height, pressure,

3-21
dry bulb temperature, relative humidity (which is used to obtain dew point temperature) and
winds are reported. There are about 50 stations around the United States, and most countries in
the world have an upper air observation program. The data are generally collected twice daily, at
0000 GMT and 1200 GMT (these times are also referred to as 00Z and 12Z, respectively).

AERMET can read and process three formats, as discussed below with the DATA
keyword. However, surrogate data can be used if the user can reformat data into a format that is
ready for Stage 1 QA (i.e., skip the extraction process). AERMET has been designed to accept
24 soundings per day. However, for AERMET to correctly read the file, the format must follow
the format described in Table C-2 in Appendix C.

3.4.1 DATA

NWS rawinsonde data are stored in a variety of formats. However, AERMET is

designed to read only three of those formats, plus data in the format of the EXTRACT file for
upper air data. As with hourly surface observations, data stored in this format are referred to as
archived data. AERMET reads and interprets the sounding data and writes it to a separate file
for later processing. The DATA keyword is used to specify the file name and define the archive
file format for AERMET. The syntax and type for the DATA keyword are:

Syntax: DATA archive_filename file_format

Type: Mandatory* (Stage 1 only; Stage 1 and 2 combined), Nonrepeatable

The archive_filename must conform to the naming conventions appropriate to the

computing platform. The maximum length of the archive file is 300 characters. The keyword is
mandatory if performing Stage 1 processing (separately or in a combined Stage 1 and 2
AERMET run) and the EXTRACT keyword (Section 3.3.2) is not used or the file associated
with the EXTRACT keyword is empty. The DATA keyword is optional if the EXTRACT
keyword is present, and the file associated with the EXTRACT keyword is not empty. In that
case, the data in the file associated with the EXTRACT keyword are the input data.

3-22
 AERMET can process upper air data in the TD-6201, FSL, and IGRA (new to versions
21DRF and later) formats in addition to the EXTRACT format. TD-6201 is now obsolete,
though historical data may exist in corporate and personal archives. Neither TD-6201 or FSL
format is available from the NCEI. Prior to the autumn of 2024, historical and current upper air
data in the FSL format were available for download, free of charge, from the online
NOAA/ESRL Radiosonde Database (https://ruc.noaa.gov/raobs/). However, beginning in the
autumn of 2024, historical and current upper air data in the FSL format are no longer available.
For any applications that require a download of upper air data after the autumn of 2024 3, IGRA
data will be the only available data. IGRA data can be downloaded free of charge from the
NCEI ftp server (ftp://ftp.ncei.noaa.gov/pub/data/igra). TD-6201 data are stored either as fixed-
length or variable length records, and the file_format should be specified as either 6201FB or
6201VB, respectively. file_format for upper air data in the FSL, IGRA, or EXTRACT format
should be specified as FSL, IGRA, or EXTRACT respectively. Note, that even though TD-6201
and FSL data are no longer available, existing files in these formats can be processed in
AERMET.

Note that beginning with version 11059, the blocking_factor and data type (ASCII or
EBCDIC) parameters have been removed from the DATA keyword specifications, and
AERMET no longer supports their use if specified by the user. A value of '1' for blocking_factor
and 'ASCII' for data type have been coded into AERMET. AERMET will issue a warning
message if these parameters are included on the DATA keyword.

3
This can apply to historical data prior to 2024 that has not been previously downloaded or current data
that is 2024 or later and has not been downloaded.

3-23
3.4.2 EXTRACT

The EXTRACT keyword specifies the file name to which the data retrieved from the
archive file are written. The syntax and type are:

Syntax: EXTRACT extracted_data_filename

Mandatory (Stage 1 only), Nonrepeatable
Type: Or
Optional (Stage 1 and 2 combined), Nonrepeatable

The extracted_data_filename must conform to the naming conventions appropriate to the

computing platform. The maximum length of this file name is 300 characters. Note that when
running AERMET for Stage 1 only, the EXTRACT keyword is mandatory. However, if
performing a combined Stage 1 and 2 AERMET run, the EXTRACT keyword is optional as
Stage 2 will use the internal AERMET arrays to read extracted data from Stage 1. The variables
written to the EXTRACT file are those variables only needed for Stage 2 processing: height,
pressure, winds, temperature, and dewpoint. These are the variables that are not shaded in Table
C-2 of Appendix C.

3.4.3 XDATES

The amount of data extracted from an archive file can be limited by using the XDATES
keyword to specify the beginning and ending dates of the data to be extracted. The syntax and
type are:

XDATES YB/MB/DB [TO] YE/ME/DE

Syntax:
Or
XDATES YB/MB/DB [-] YE/ME/DE
Mandatory (Stage 1 only), Nonrepeatable
Type:
Or
Optional (Stage 1 and 2 combined), Nonrepeatable

3-24
 YB, MB and DB are the beginning year, month, and day, respectively, of the data to
extract and YE, ME, and DE are the ending year month and day, respectively. Beginning with
version 21DRF, the year must be entered as a four-digit integer (e.g., 1992). The month is a one-
or two-digit integer corresponding to the month of the year and the day is the one- or two-digit
day of the month. The dates can be entered in various ways. The individual components of start
date or end date can be separated by spaces or the ‘/’ character or no separator at all. However,
the start date cannot be separated by spaces and the end date separated by ‘/’ or vice-versa. Both
dates must use the same delimiter. The complete start date and end date can be separated by a
space, ‘- ‘, or the word “TO”. The case of the word “TO” can be upper, lower, or a mix of cases.
The following are valid methods to enter the dates, using January 1, 2020 and December 31,
2020 as the dates:

• 2020/01/01 2020/12/31
• 2020/01/01 TO 2020/12/31
• 2020/01/01 – 2020/12/31
• 2020 01 01 TO 2020 12 31
• 2020 01 01 – 2020 12 31
• 2020 01 01 2020 12 31
• 20200101 20201231

The following are invalid methods to enter dates, again using January 1, 2020 and December 31,
2020 as the dates:

• 2020/01/01 2020 12 31
• 2020 01 01 2020/12/31
• 2020/01/01 - 2020 12 31
• 2020 01 01 - 2020/12/31
• 2020/01/01 TO 2020 12 31
• 2020 01 01 TO 2020/12/31

3-25
 The XDATES keyword is mandatory if performing Stage 1 processing only. The
keyword is optional if performing combined Stage 1 and 2 processing and XDATES is present
for the METPREP pathway. If XDATES is present for the METPREP pathway, AERMET will
use the METPREP dates for extraction of upper air data if UPPERAIR EXTRACT or QAOUT
files are not requested. If UPPERAIR EXTRACT or QAOUT files are requested, then the upper
air extraction uses the dates associated with XDATES on the UPPERAIR pathway.

3.4.4 LOCATION

The LOCATION keyword identifies the meteorological station by the station's identifier,
latitude and longitude of the station, and a time adjustment factor used to adjust the data to local
standard time. The syntax and type are:

Syntax: LOCATION site_id NWS_lat/long NWS_long/lat [tadjust]

Mandatory (Stage 1 only; Stage 1 and 2 combined), Nonrepeatable,
Type:
Reprocessed
Order: Latitude (lat) and longitude (long) can appear in either order

The site_id is a five-to-eight-character alphanumeric specifier that identifies the station

for which data are to be extracted. For the standard formats listed on the DATA keyword, these
identifiers are five-digit WBAN (Weather Bureau Army Navy) numbers. Prior to version
21DRF, the site_id must be specified with leading zeros to fill a minimum of five characters
(e.g., 03928 must be entered as 03928) since the field was read as a type character and not an
integer. This is no longer required beginning with 21DRF so 3928 can be entered as 3928, not
03928. However, to avoid warnings in AERMOD, all characters of the site_id should be
numeric as AERMOD expects a numeric value in the AERMOD control file which should
match the ID of the UPPERAIR station identifier in the surface file generated by AERMET. A
master list of WBAN numbers for stations throughout the world can be obtained from the NCEI.

The NWS station latitude (lat) and longitude (long) can be entered in either order
because AERMET distinguishes between the two by the suffix on each: N or S with the latitude
and W or E with the longitude. For example, "38.4N 81.9W" will be interpreted the same as

3-26
"81.9W 38.4N" in AERMET. AERMET cannot use, nor does it recognize, "+" or "-" to
discriminate between north and south, and east and west. Therefore, the latitude and longitude
should always be specified as positive numbers.

The parameter, tadjust, is an optional adjustment factor that is subtracted from the
reported hour to convert the time to local standard time. The default value is zero if omitted
from the LOCATION keyword on the SURFACE pathway. Though optional, it should be
included when the offset to local standard time is non-zero. For stations west of Greenwich,
England, i.e., the Prime Meridian (0° longitude), tadjust should be specified as a positive
number. Apart from EXTRACT, the standard NWS upperair data formats processed by
AERMET report the time as GMT. Therefore, tadjust should be non-zero for all standard NWS
formats processed by AERMET, apart from the EXTRACT format, unless the data are known to
be reported for a time zone that is not local standard. Beginning with version 23132, if the GMT
to LST conversion is zero, AERMET will use the longitude on the LOCATION keyword line to
approximate the GMT to LST conversion for the sunrise/sunset times and if the approximated
conversion is greater than 1, AERMET will issue a message that the approximate conversion
will be used for sunrise and sunset times. Therefore, care should be taken when using a GMT to
LST conversion of zero as the approximated conversion may not be the actual conversion
associated with the longitude.

Note that beginning with version 11059, AERMET no longer supported the user-
specified station elevation as a parameter on the UPPERAIR LOCATION keyword and
AERMET would issue a warning message if the elevation field was included, and the elevation
ignored. However, beginning with AERMET 24142, the user will have to specify a station
elevation that will be used to substitute for missing surface level heights in soundings. If the
station elevation is not included, AERMET will issue an error message and abort processing.

3.4.5 QAOUT

One purpose of AERMET is to contribute to the quality assurance process by identifying

data that are out of range or suspect such that the user can determine appropriate steps to accept,
modify, or reject the data. The quality assessment (QA) is performed by including the QAOUT

3-27