User’s Guide for the AERMOD Meteorological

Preprocessor (AERMET)
 EPA-454/B-18-002
April, 2018

User's Guide for the AERMOD Meteorological Preprocessor (AERMET)

U.S. Environmental Protection Agency

Office of Air Quality Planning and Standards
Air Quality Assessment Division
Air Quality Modeling Group
Research Triangle Park, North Carolina
Disclaimer

This report has been reviewed by the Office of Air Quality Planning and Standards, U.S.
Environmental Protection Agency, and has been approved for publication. Mention of trade
names or commercial products does not constitute endorsement or recommendation for use. The
following trademarks appear in this guide:

Microsoft is a registered trademark of Microsoft Corp.

IBM is a registered trademark of International Business Machines

ii
Preface

AERMET provides a general purpose meteorological preprocessor for organizing

available meteorological data into a format suitable for use by the AERMOD air quality
dispersion model. This user's guide provides instructions for setting up and running the
AERMET preprocessor. Hourly surface observations from the National Weather Service
(NWS), Federal Aviation Administration (FAA) or other sources, NWS twice-daily upper air
soundings and data from a site-specific meteorological measurement program can be processed
in AERMET. There are three stages to processing the data. The first stage extracts
meteorological data from archive data files and processes the data through various quality
assessment checks. The second stage merges all data available for 24-hour periods (NWS/FAA
and site-specific data) and stores these data together in a single file. The third stage reads the
merged meteorological data and estimates the necessary boundary layer parameters for use by
AERMOD. AERMET generates two meteorological output files for input to AERMOD: a file
of hourly boundary layer parameter estimates and a file of multiple-level observations of wind
speed and direction, temperature, and standard deviation of the fluctuating components of the
wind.

iii
Acknowledgments

The AERMET User's Guide was originally prepared by James O. Paumier and Roger W.
Brode of MACTEC, Research Triangle Park, North Carolina. This effort was funded by the
U.S. Environmental Protection Agency under Contract No. 68D70069, with Warren D. Peters as
Work Assignment Manager.

The Agency wishes to acknowledge AERMIC (the American Meteorological

Society/Environmental Protection Agency Regulatory Model Improvement Committee),
members of which have given a considerable amount of time, energy and dedication over the
last 10 years to develop the AERMOD air dispersion modeling system:

J. C. Weil, Cooperative Institute for Research in Environmental Sciences, University of

Colorado

A. Venkatram, College of Engineering, University of California at Riverside

R. B. Wilson, U.S. Environmental Protection Agency, Region X

R. J. Paine, ENSR Corporation

S.G. Perry1, Atmospheric Sciences Modeling Division, Air Resources Laboratory, EPA/ NOAA

R. F. Lee, Consultant, Meteorologist

A. J. Cimorelli, U.S. Environmental Protection Agency, Region III

W.D. Peters, U.S. Environmental Protection Agency, OAQPS, EMAD, AQMG

1
On assignment to the Atmospheric Research and Exposure Assessment Laboratory, U.S.
Environmental Protection Agency.
iv
Contents

Section Page

1.0 Introduction ............................................................................................................................ 1-1

1.1 Overview of AERMET .................................................................................................... 1-1

1.1.1 Stage 1 - extraction and quality assessment ............................................................ 1-6

1.1.2 Stage 2 - merging data ............................................................................................ 1-8

1.1.3 Stage 3 - creating model input files ........................................................................ 1-8

1.2 Output Files ...................................................................................................................... 1-9

1.3 Document overview ....................................................................................................... 1-10

2.0 Getting started - a basic tutorial ............................................................................................. 2-1

2.1 AERMET command language ......................................................................................... 2-1

2.1.1 Basic rules for structuring a control file ................................................................. 2-2

2.1.2 Tutorial basics ......................................................................................................... 2-4

2.2 Example 1: National Weather Service data ..................................................................... 2-4

2.2.1 Stage 1 - processing hourly surface observations ................................................... 2-7

2.2.1.1 JOB pathway .................................................................................................. 2-8

2.2.1.2 SURFACE pathway ....................................................................................... 2-9

2.2.1.3 Running STAGE 1 and reviewing the output .............................................. 2-14

2.2.2 Stage 1 - processing twice-daily soundings .......................................................... 2-23

2.2.2.1 UPPERAIR pathway.................................................................................... 2-24

2.2.2.2 Running Stage 1 and reviewing the output .................................................. 2-29

2.2.3 Stage 2 - merging data .......................................................................................... 2-35

2.2.3.1 Running Stage 2 and reviewing the output .................................................. 2-38

2.2.4 Stage 3 - estimating boundary layer parameters for AERMOD ........................... 2-44

v
 2.2.4.1 Running Stage 3 and reviewing the output .................................................. 2-52

3.0 Advanced tutorial ................................................................................................................... 3-1

3.1 Example 2: site-specific data ........................................................................................... 3-1

3.1.1 Stage 1 - processing site-specific data .................................................................... 3-3

3.1.1.1 JOB pathway .................................................................................................. 3-7

3.1.1.2 ONSITE pathway ........................................................................................... 3-7

3.1.2 Running Stage 1 and reviewing the output ........................................................... 3-13

3.1.3 Stage 2 - merging data .......................................................................................... 3-21

3.1.4 Stage 3 - estimating boundary layer parameters for AERMOD ........................... 3-24

3.2 Combining or separating processing steps ..................................................................... 3-31

4.0 Keyword reference ................................................................................................................. 4-1

4.1 Definitions and control file processing ............................................................................ 4-1

4.2 JOB pathway .................................................................................................................... 4-3

4.2.1 Messages from AERMET - MESSAGES............................................................... 4-3

4.2.2 Run summary - REPORT ....................................................................................... 4-3

4.2.3 Checking the control file for errors - CHK_SYNTAX ........................................... 4-4

4.3 SURFACE pathway ......................................................................................................... 4-5

4.3.1 Retrieving archived data - DATA ........................................................................... 4-5

4.3.1.1 CD-144 and SCRAM formats ........................................................................ 4-7

4.3.1.2 SAMSON format ........................................................................................... 4-8

4.3.2 Saving dearchived data - EXTRACT ................................................................... 4-10

4.3.3 Extracting a subset of the data - XDATES ........................................................... 4-10

4.3.4 Identifying the station - LOCATION ................................................................... 4-11

4.3.5 How good are the data? - QAOUT ....................................................................... 4-12

vi
 4.3.6 Adding weather elements to the QA - AUDIT ..................................................... 4-14

4.3.7 Changing the default values for the QA - RANGE .............................................. 4-14

4.3.8 Reducing the number of QA messages - NO_MISSING ..................................... 4-15

4.4 UPPERAIR pathway ...................................................................................................... 4-16

4.4.1 Retrieving archived data - DATA ......................................................................... 4-16

4.4.2 Saving dearchived data - EXTRACT ................................................................... 4-17

4.4.3 Extracting a subset of the data - XDATES ........................................................... 4-18

4.4.4 Identifying the station - LOCATION ................................................................... 4-18

4.4.5 How good are the data? - QAOUT ....................................................................... 4-20

4.4.6 Adding upper air variables to the QA - AUDIT ................................................... 4-22

4.4.7 Changing the default values for the QA - RANGE .............................................. 4-22

4.4.8 Reducing the number of QA messages - NO_MISSING ..................................... 4-23

4.4.9 Adjusting sounding data - MODIFY .................................................................... 4-23

4.5 ONSITE pathway ........................................................................................................... 4-24

4.5.1 Retrieving archived data - DATA ......................................................................... 4-25

4.5.1.1 Where is the EXTRACT keyword? ............................................................. 4-25

4.5.2 Defining the file structure - READ and FORMAT .............................................. 4-26

4.5.3 Processing a subset of the data - XDATES .......................................................... 4-32

4.5.4 Identifying the station - LOCATION ................................................................... 4-32

4.5.5 How good are the data? - QAOUT ....................................................................... 4-33

4.5.6 Adding site-specific variables to the QA - AUDIT .............................................. 4-35

4.5.7 Changing the default values for the QA - RANGE .............................................. 4-36

4.5.8 Reducing the number of QA messages - NO_MISSING ..................................... 4-36

4.5.9 An alternate specification of measurement heights - OSHEIGHTS ..................... 4-37

vii
 4.5.10 Temperature differences - DELTA_TEMP ........................................................ 4-38

4.5.11 Threshold wind speeds - THRESHOLD............................................................. 4-39

4.5.12 Multiple observation periods for each hour - OBS/HOUR ................................ 4-39

4.6 MERGE pathway ........................................................................................................... 4-40

4.6.1 Output file - OUTPUT .......................................................................................... 4-41

4.6.2 Substitution of NWS/FAA surface wind data with 1-minute ASOS wind data ... 4-41

4.6.2.1 Use of 1-minute ASOS wind data ................................................................ 4-42

4.6.2.2 Threshold wind speed for 1-minute ASOS winds ....................................... 4-44

4.6.3 Merging a subset of the data - XDATES .............................................................. 4-45

4.7 METPREP pathway ....................................................................................................... 4-45

4.7.1 Input data file - DATA.......................................................................................... 4-46

4.7.2 Choosing a dispersion model - MODEL .............................................................. 4-46

4.7.3 Identifying the site - LOCATION......................................................................... 4-47

4.7.4 Instrumentation heights for NWS data - NWS_HGT ........................................... 4-48

4.7.5 Processing a subset of the merged data - XDATES ............................................. 4-49

4.7.6 Processing options - METHOD ............................................................................ 4-49

4.7.6.1 Randomization of NWS wind directions – WIND_DIR ............................. 4-50

4.7.6.2 NWS data substitution - REFLEVEL .......................................................... 4-51

4.7.6.3 Adjustment to truncated ASOS wind speeds – ASOS_ADJ ....................... 4-51

4.7.6.4 Option to adjust u* under low wind/stable conditions - STABLEBL ......... 4-52

4.7.6.5 Substitutions for missing cloud cover and temperature – CCVR, TEMP ... 4-53

4.7.6.6 Upper air sounding selection by sunrise - SUNRISE .................................. 4-55

4.7.7 Adjusting the default sounding window - UAWINDOW..................................... 4-58

4.7.8 Surface characteristics - FREQ_SECT(2), SECTOR(2), and SITE_CHAR(2) ... 4-59

viii
 4.7.9 Output from Stage 3 - OUTPUT and PROFILE ................................................... 4-67

5.0 Technical notes ...................................................................................................................... 5-1

5.1 Quality assessment procedures ........................................................................................ 5-1

5.2 Identifying ASOS observations ....................................................................................... 5-3

5.3 Validation of NWS surface format by active data range ................................................. 5-5

5.3.1 Validation of WBAN between Stage 1 control file and NWS surface data file ..... 5-6

5.3.2 ASOS cloud cover from SCRAM and SAMSON set to missing ........................... 5-7

5.4 Site-specific data - averaging subhourly values............................................................... 5-7

5.5 Upper air data modifications ............................................................................................ 5-8

5.5.1 Mandatory levels ..................................................................................................... 5-9

5.5.2 Calm wind conditions ............................................................................................. 5-9

5.5.3 Missing dry bulb and dew-point temperatures........................................................ 5-9

5.6 Station elevations ........................................................................................................... 5-10

5.7 Boundary layer parameter estimates in Stage 3 ............................................................. 5-13

5.7.1 Reference wind and temperature .......................................................................... 5-13

5.7.2 Surface characteristics .......................................................................................... 5-14

5.7.2.1 Choice of sector-dependent surface characteristics ..................................... 5-15

5.7.3 Estimates for the unstable atmosphere .................................................................. 5-17

5.7.4 Estimates for the stable atmosphere ...................................................................... 5-21

5.7.5 More on mixing heights ........................................................................................ 5-24

6.0 References .............................................................................................................................. 6-1

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
C.1 Upper air soundings ................................................................................................. C-1

ix
 C.2 Surface observations ................................................................................................ C-2
C.3 MERGE output....................................................................................................... C-11
C.4 AERMOD files ....................................................................................................... C-13
Appendix D. Summary of messages......................................................................................... D-1
D.1 Interpreting error messages ...................................................................................... D-2
D.2 Control file and file header processing, 00 – 29 ...................................................... D-5
D.3 Upper air processing, 30 – 39 .................................................................................. D-8
D.4 Surface observations processing, 40 – 49 .............................................................. D-11
D.5 On site data processing, 50 – 59 ............................................................................ D-13
D.6 Merge processing, 60 – 69 ..................................................................................... D-15
D.7 Stage 3 processing, 70 – 89 .................................................................................... D-16
Appendix E. Processing NWS data from magnetic tape ...........................................................E-1
E.1 SURFACE pathway...................................................................................................E-1
E.2 UPPERAIR Pathway .................................................................................................E-3
E.3 Data on diskette and tape ...........................................................................................E-3
Appendix F. AERMET enhancements ..................................................................................... F-1
F.1 Daytime mixing height adjustments .......................................................................... F-1
F.2 An objective determination of the Bowen ratio ......................................................... F-2
F.3 Urban effects .............................................................................................................. F-3
F.4 Urban mixing heights ................................................................................................ F-6
Appendix G. Overview of AERMET revisions........................................................................ G-1

x
Figures

Figure Page

Figure 1-1. AERMET Processing ................................................................................................ 1-2

Figure 2-1. Stage 1 Processing for Hourly Surface Observations ............................................... 2-7

Figure 2-2. Example Control File to Extract and QA NWS Surface Data (EX1-SF.INP) .......... 2-8

Figure 2-3. Message from Stage 1 (EX1-SF1.INP, Surface Extraction Only) .......................... 2-16

Figure 2-4. First Part of the Report File - Processing NWS Surface Observations ................... 2-20

Figure 2-5. Second Part of the Report File - Processing NWS Hourly Surface Observations .. 2-21

Figure 2-6. Third Part of the Report File - Processing NWS Hourly Surface Observations. .... 2-22

Figure 2-7. Stage 1 Processing Upper Air Soundings ............................................................... 2-23

Figure 2-8. Example Control File to Extract and QA NWS Upper Air Sounding Data ............ 2-24

Figure 2-9. Message File from Processing NWS Upper Air Data ............................................. 2-29

Figure 2-10. First Part of the Report File from Processing Upper Air Soundings .................... 2-33

Figure 2-11. Second Part of the Report File from Processing Upper Air Soundings ................ 2-34

Figure 2-12. Third Part of the Report File from Processing Upper Air Soundings ................... 2-35

Figure 2-13. Stage 2 Processing that Merges the Hourly Surface Observations and Upper Air
Soundings into a Single File ................................................................................. 2-36

Figure 2-14. Example Control File to Merge NWS Data .......................................................... 2-36

Figure 2-15. Message File from Merging the NWS Data .......................................................... 2-38

Figure 2-16. First Part of the Summary File for the Merge Processing ..................................... 2-41

Figure 2-17. Second Part of the Summary File for the Merge Processing ................................ 2-42

Figure 2-18. Third Part of the Summary File for the Merge Processing ................................... 2-43

Figure 2-19. Stage 3 Processing Using the Merged NWS Data to Create the Input Meteorology
for AERMOD ....................................................................................................... 2-44
xi
Figure 2-20. Example Stage 3 Control File to Create the Output Files for AERMOD ............. 2-45

Figure 2-21. Message File from Stage 3 for EX1-ST3.INP ...................................................... 2-53

Figure 2-22. First Part of the Summary File from Stage 3 ........................................................ 2-56

Figure 2-23. Second Part of the Summary File from Stage 3 .................................................... 2-57

Figure 2-24. Third Part of the Summary File from Stage 3 ....................................................... 2-58

Figure 2-25. First 36 Hours of the Boundary Layer Parameter File, AERMET.SFC ............... 2-59

Figure 2-26. First 36 Hours of the Profile File, AERMET.PFL ................................................ 2-60

Figure 3-1. Stage 1 Processing of the Site-specific Data ............................................................. 3-4

Figure 3-2. Subset of Site-specific Meteorological Data for Example 2 ..................................... 3-5

Figure 3-3. Control File to QA Site-specific Tower Data ........................................................... 3-6

Figure 3-4. Portion of the Message File from Site-specific Data QA ....................................... 3-14

Figure 3-5. First Page of the Summary File for the Site-specific Data QA ............................... 3-16

Figure 3-6. Second Page of the Summary File for the Site-specific Data QA .......................... 3-17

Figure 3-7. Third Page of the Summary File for the Site-specific Data QA ............................. 3-18

Figure 3-8. Fourth Page of the Summary File for the Site-specific Data QA ........................... 3-19

Figure 3-9. Stage 2 Processing that Merges the Surface Observations, Soundings, and Site-
specific Data into a Single File ............................................................................. 3-21

Figure 3-10. Control File to Merge NWS Upper Air, Surface Data, and Site-specific Data in to a
Single File ............................................................................................................. 3-22

Figure 3-11. Second Page of the Summary File ........................................................................ 3-23

Figure 3-12. Stage 3 Processing Using the Merged NWS and Site-specific Data to Create the
Input Meteorology for AERMOD ........................................................................ 3-24

Figure 3-13. Stage 3 Control File .............................................................................................. 3-25

Figure 3-14. Message File from Stage 3 (partial) ...................................................................... 3-29

xii
Figure 3-15. Control File to Extract and QA All Data Types in One Run ................................ 3-32

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

xiii
Tables

Table Page

Table 2-1. Command-line Entries to Run 3 Stages of AERMET for Example 1 ........................ 2-6

Table 4-1. Sounding Selection by Time Zone .......................................................................... 4-57

Table 4-2. Albedo of Ground Covers by Land Use and Season ................................................ 4-63

Table 4-3. Daytime Bowen Ratio by Land Use and Season – Dry Conditions ......................... 4-64

Table 4-4. Daytime Bowen Ration by Land Use and Season - Average Moisture Conditions . 4-64

Table 4-5. Daytime Bowen Ratio by Land Use and Season - Wet Conditions ......................... 4-65

Table 4-6. Surface Roughness Length, in Meters, by Land Use and Season ............................ 4-65

Table 5-1. Format Active Dates .................................................................................................. 5-6

Table A-1. Description of Job Pathway Keywords .................................................................... A-3

Table A-2. Description of Keyword Parameters for the JOB Pathway ...................................... A-3

Table A-3. Description of UPPERAIR Keywords ..................................................................... A-4

Table A-4. Description of Keyword Parameters for the UPPERAIR Pathway .......................... A-5

Table A-5. Description of SURFACE Pathway Keywords ........................................................ A-8

Table A-6. Description of Keyword Parameters for the SURFACE Pathway ........................... A-9

Table A-7. Description of ONSITE Pathway Keywords .......................................................... A-13

Table A-8. Description of Keyword Parameters for the ONSITE Pathway ............................. A-15

Table A-9. Description of MERGE Pathway Keywords .......................................................... A-20

Table A-10. Description of Keyword Parameters for the MERGE Pathway ........................... A-20

Table A-11. Description of METPREP Pathway Keywords .................................................... A-21

Table A-12. Description of Keyword Parameters for the METPREP Pathway ....................... A-24

Table B-1. Variable and QA Defaults for the UPPERAIR Variables ........................................ B-3

xiv
Table B-2. Variable and QA Defaults for SURFACE Variables ................................................ B-4

Table B-3. Variable and QA Defaults for the ONSITE (Site-specific) Single-value and
Date/Time Variables .............................................................................................. B-6

Table B-4. Variable and QA Defaults for the ONSITE (Site-specific) Multi-level Variables ... B-7

Table C-1. Sky Conditions .......................................................................................................... C-5

Table C-2. Cloud Types .............................................................................................................. C-6

Table C-3. Obscuring Phenomena .............................................................................................. C-7

Table C-4. Present Weather ........................................................................................................ C-8

Table F-1. Average Anthropogenic Heat Flux (Qa) and Net Radiation (Rn) for Several Urban
Areas (from Oke, 1978) .......................................................................................... F-5

Table F-2. Surface Roughness Length for Urban Environments (from Stull, 1988) ................... F-6

xv
1.0 Introduction

The U. S. Environmental Protection Agency (EPA), in conjunction with the American

Meteorological Society (AMS), developed the AMS/EPA Regulatory Model (AERMOD),
promulgated by the EPA in 2005 as the preferred regulatory air dispersion model for predicting
near-surface pollutant concentrations within 50 kilometers (km) of an emission source.
AERMET, the subject of this user’s guide, is the meteorological preprocessor for AERMOD
and estimates the atmospheric boundary layer (BL), also called the planetary boundary layer
(PBL), parameters used in the dispersion calculations in AERMOD.

1.1 Overview of AERMET

AERMET processes three types of data: 1) hourly surface observations that are typically,
but not exclusively, collected at airports by the National Weather Service (NWS) and/or the
Federal Aviation Administration (FAA); 2) twice-daily upper air soundings collected by the
NWS; and 3) data collected from an on-site or site-specific measurement program or prognostic
meteorological data processed through a processor such as the Mesoscale Model Interface
(MMIF) (EPA, 2018)2. Data processing occurs in three distinct stages that are unrelated to the
type of data being processed, each required to be run separately, but the stages areas illustrated
in Figure 1-1. 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
data is also assessed during Stage 1. The second stage combines or merges the extracted surface
and upper air data with the site-specific data into distinct 24-hour periods or blocks and writes
the merged data to an intermediate file. The third and final stage reads the merged data file,
calculates the boundary layer parameters required by AERMOD, and generates two AERMOD-
ready meteorological data files.

Note in Figure 1-1 that the extraction phase of the raw site-specific data is not included
in Stage 1, though the data are QA'd in Stage 1. Unlike the surface and upper air data, site-

2
Throughout this document, site-specific references will also apply to the processing of MMIF output,
which is processed in the ONSITE pathway in AERMET.
1-1
specific data are not stored (archived) in any particular 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 4.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 ‘1-min ASOS.’ 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 with the
AERMINUTE program (EPA, 2010) to produce 1-hour averages that are more representative
than the surface wind data in the standard hourly archive formats (see Section 4.3). For more
recent years, the hourly wind data in the standard archive formats can be replaced with the
hourly values derived from the 1-minute ASOS data when those data are available. Similar to
the site-specific data, 1-minute ASOS data do not need to be extracted. The extraction and QA
of the 1-minute ASOS data is performed by the AERMINUTE program (EPA, 2010). Refer to
Section 4.6.2 for a detailed discussion on the use of 1-minute ASOS wind data. From here on,
this user's guide refer to all surface data collected by the NWS and/or the FAA, including the
1-minute ASOS data, as NWS data.

Figure 1-1. AERMET Processing

AERMET defines the ONSITE pathway (Section 4.5) for inputting hourly surface
observations taken from an on-site, or site-specific meteorological tower. Note that the
Guideline on Air Quality Models (Appendix W to 40 CFR Part 51) was modified in April 2003

1-2
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, this user’s guide has
been updated to use the term ‘site-specific’ in the place of ‘on-site’ when referring to data that
are processed per the ONSITE pathway.

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 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 located 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, which is created automatically by AERMET
during each of the three stages of processing. As currently configured, each of the three
processing stages must be run separately, and there must be a separate 'AERMET.INP' file for
each of the three stages. The program is run by entering ‘AERMET’ or the full pathname of the
AERMET executable at a ‘DOS’ command prompt or by double-clicking the AERMET.EXE
file from a folder view. In a typical application the command line would be entered three times,
once for stage 1 processing (extraction and quality assurance (QA) of the surface, upper air, and
site-specific data combined in a single run), a second time for Stage 2 processing (merge), and a
third time for Stage 3 processing (boundary layer calculations and output). Since stage 1
processing is designed to support QA of raw 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

1-3
the particular application and stage of processing. Because each stage requires a separate
control file, ' they should each be given a unique filename originally to avoid name conflicts
when the files are stored in the same directory. A DOS 'batch' file (.bat) is often used to run
each of the three stages successively:

aermet stage1.inp

aermet stage2.inp

aermet stage3.inp.

1-4
@ 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 ..
PAUSE

:STOP

1-5
 Note that some of the QA defaults presented in this guide have been revised from
previous versions of AERMET due to changes in the AERMET code, including upper and lower
bounds and missing indicators. These revisions are reflected in Appendix B. Additional details
regarding revisions to the AERMET code are presented in the AERMET Model Change
Bulletins (MCBs) and in Appendix G of this guide, as well as in the comments embedded in the
Fortran source code.

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.

Typically, 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 two formats including: TD-6201 and
the former Forecast Systems Laboratory (FSL) format. While TD-6201 is no longer in use,
global upper air data in FSL format is available online from the NOAA Earth System Research
Laboratory (ESRL) Radiosonde Database at http://esrl.noaa.gov/raobs/.

AERMET can extract surface hourly weather observations from several standard formats
that have been used by NOAA's former National Climatic Data Center (NCDC), now the
NOAA 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 Hourly Database (ISHD a.k.a.
ISH, ISD and DSI-3505), which are time-based formats (i.e., by hour), and the TD-3280 format,
which is element-based (i.e., by variable), originally stored on magnetic tape. While data stored
1-6
in some of the older formats (CD-144, SAMSON, HUSWO, and possibly TD-3280) 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: http://www.ncdc.noaa.gov/isd/data-access.

AERMET also processes an hourly surface data format available from the EPA Office of
Air Quality Planning and Standards (OAQPS) Technology Transfer Network (TTN). 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 meteorological data. Site-

specific data most likely will include observations made at one or more levels on an
instrumented tower or from remote sensing instrumentation. 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 is capable of reading site-
specific data stored in an ASCII3 file with a structure that can be described by the user with
standard Fortran format statements. Additional restrictions and specification of site-specific
data are discussed in more detail in Section 3.0 and Section 4.5.

Quality assessment 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 inconsistences between selected variables within an observation period. Default
values are defined for the upper and lower bounds and for missing values. The values can be
modified through an input file created by the user that controls preprocessor actions. Some
variables are checked by default (as noted in the tables in Appendix B) and the user can specify
additional variables to be checked.

3
American Standard Code for Information Interchange
1-7
 If AERMET detects anomalous data, a message is written to a 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 file. The archived 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 - merging data

The second stage of the processing combines the data processed during Stage 1,
including the extracted NWS surface and upper air, 1-minute ASOS, and site-specific data, into
a single ASCII file. The file is organized into data blocks such that each block contains all of
the observations for a 24-hour period, a single day. Each period begins with hour 1 and ends
with hour 24, where hour 1 represents the period from 0001 local standard time (LST), or one
minute past midnight LST, to 0100 or 1:00 AM LST. Hour 24 represents 2301 (11:01 PM) LST
to 2400 (midnight) LST. During Stage 2 processing, for any hours of data that are physically
missing (e.g., instrument down for maintenance), AERMET inserts a data record with the
appropriate day and hour and sets the value of the meteorological variables to missing value
indicators. This ensures there are no gaps in the final AERMET output files. The default
missing value indicators used by AERMET are provided in Appendix B. The user also has the
option or redefine the values as explained in the following sections.

1.1.3 Stage 3 - creating model input files

1-8
 The final stage of processing reads the merged file generated in Stage 2, 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. This multilevel data are writing to this latter 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.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 data, and separate data quality assessment files for NWS surface,
upper air, and site-specific 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 to into Stage 2. As mentioned previously, site-specific data, which are processed via
the ONSITE 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 Section
2.0 and Section 3.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.

In addition to the summary and message files, as discussed previously, Stage 2 generates
a “merge” file and Stage 3 generates a surface and a profile file that contain the observed and
1-9
computed parameters. The merge file is a single file in which all the data are combined and is
input to Stage 3, and the surface and profile files from Stage 3 are input into AERMOD.

1.3 Document overview

In Section 2.0, the basic requirements to run AERMET with NWS data are presented in
the form of a basic tutorial. The keyword approach and basic rules for constructing the input
control files for each stage of processing are discussed, and the summary reports and message
files are reviewed. Section 3.0 presents an advanced tutorial by expanding the first example to
include site-specific meteorological data. Section 4.0 discusses the keywords in more detail,
many of which were not used in the tutorials. Section 5.0 discusses some of the technical
aspects of AERMET such as the QA procedures and the basis for the parameter estimates in the
final stage of processing.

Appendix A through Appendix D collectively form a reference guide for running

AERMET. Appendix A describes the input control file statements, while Appendix B describes
the input variables and their default bounds and missing values codes. Appendix C describes
the format and content of the AERMET input and output files. Appendix D describes the
various error messages that may be generated by AERMET and suggests why the error message
was generated. Appendix E discusses processing data archived on magnetic tape. Appendix F
discusses possible future enhancements to the preprocessor. Appendix G is an historical
overview of revisions that have been made to AERMET.

1-10
2.0 Getting started - a basic tutorial

This section is designed to provide the user with a basic understanding of the
requirements to run AERMET. In this section, we will:

• Explain the pathway and keyword approach, and associated syntax rules, for
processing meteorological data through AERMET; and

• Present an example using NWS hourly surface observations, 1-minute ASOS data,
and twice-daily upper air sounding data.

2.1 AERMET command language

Processing meteorological data with the AERMET preprocessor is divided into three
stages as shown in Figure 1-1. Each stage must be run separately, though a single executable
(AERMET.EXE) is used for all three stages. 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 must be a separate control file for stage of
processing, and Prior to version 18081, AERMET expected the control file to be named
‘AERMET.INP’ for each stage. Therefore, each of the control files should be named uniquely
if stored in the same directory and renamed prior to running each stage. Beginning with version
18081, the user can enter the unique name of the control for each stage on the command line
when executing AERMET from the command line.

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, on-site meteorological data;

2-1
 • MERGE for combining (merging) the meteorological data; and

• METPREP for estimating boundary layer parameters for AERMOD.

The pathway identifier appears on a line by itself 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 from two to five pathways
specified in a single AERMET control file.

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.1.1 Basic rules for structuring a control file

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 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 132 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-2
• 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 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. Throughout this document, the convention of using upper case letters
in the control files will be followed. Note: For Linux/UNIX users, since file names
on Linux/UNIX-based systems are case sensitive and since AERMET converts all
alphabetic characters to upper case, the names of the files stored on the system
would be required to be upper case.

• 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 3)
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 4.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 and METPREP pathways. These keywords
pertain to the variables and format of the site-specific data and the site-specific
surface characteristics on the METPREP pathway.

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

platform and cannot exceed 96 characters in length.

2-3
2.1.2 Tutorial basics

This basic tutorial and the advanced tutorial in Section 3.0 discusses only those
keywords needed for these simple examples. These are but a subset of keywords available.
Section 4.0 contains a comprehensive discussion of all the keywords for each of the pathways.
A summary of all of the keywords for each pathway is presented in Appendix A which is a
complete reference guide for the function, syntax, and order (if applicable) of each keyword.

A text editor should be used to create the control files as plain text ASCII files. Word
processors (e.g., Microsoft Word) can be used, but the file must be saved as a "Plain Text" file,
i.e., without special format control characters that are included when the file is saved in its
native format. Saving the file in a word processor's native format will introduce characters that
cannot be interpreted by AERMET and prevent AERMET from processing any data.

2.2 Example 1: National Weather Service data

This first example leads the user through the steps that are necessary to generate the
input control files for AERMET and run AERMET using only NWS data. This example is
divided into four steps and a separate control for each of these steps is presented and discussed
below. The control files will illustrate the basic requirements for each stage. The function and
purpose of each record in the control files will be described in the context of the desired
processing.

Before reading the discussion of the keywords and output for this example, we
recommend running AERMET to generate the output files - the message files, the summary
reports, and the meteorological data output. The four steps and associated control files to
generate the meteorological data for AERMOD for this example include:

1. extract and QA NWS hourly surface observations (Stage 1): EX1-SF.INP

2-4
 2. extract and QA NWS twice-daily upper air soundings (Stage 1): EX1-UA.INP

3. combine these two types of data into 24-hour blocks of data (Stage 2):
EX1-MRG.INP

4. process the combined data to produce the meteorological input for AERMOD
(Stage 3): EX1-ST3.INP.

AERMET is a DOS-based program and is run from the command prompt on computers running
a version of Microsoft Windows. In this example, there are two separate control files for Stage 1
in order to demonstrate the extraction and QA of the NWS surface data and upper air sounding
data independently from one another. The syntax for running AERMET is as follows:

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. The first
example is applicable to all versions of AERMET and assumes the input filename is
‘aermet.inp’ for each stage and the file resides in the current working folder. The second
example is applicable to versions of AERMET beginning with version 18081 in which the user
can specify the input filename, which can include a full directory pathname for the file. The
input filename for this example is EX1-SF.INP, EX1-UA.INP, EX1-MRG.INP, or EX1-
ST3.INP depending on the stage being processed. 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-5
 Table 2-1 shows the text to type at the command prompt for each step in this example.
The first two can be run in either order, but steps three and four must follow the first two and
run in the order shown.

Table 2-1. Command-line Entries to Run 3 Stages of AERMET for Example 1

Meteorological
To: At the command prompt, type: input data file(s) Output data file(s)

Extract and QA AERMET EX1-SF.INP S1473588.144 SFEXOUT.DSK

NWS hourly SFQAOUT.DSK
surface data

Extract and QA AERMET EX1-UA.INP 14735-88.UA UAEXOUT.DSK

NWS upper air data UAQAOUT.DSK

Merge data AERMET EX1-MRG.INP SFQAOUT.DSK MERGE.DSK

UAQAOUT.DSK

Create AERMET EX1-ST3.INP MERGE.DSK AERMET.SFC

meteorological files AERMET.PFL
for AERMOD

As AERMET runs, the progress is displayed on the screen. The display is described
below, after the discussion of the keywords. In addition to the output data files, each run will
produce a message file (.MSG) and report file (.RPT) file. 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.

The minimum meteorological input data requirements using only NWS data to produce
the two meteorological files for input to AERMOD are:

Hourly Surface Observations:

2-6
 • wind speed and direction;

• ambient temperature;

• opaque sky cover; in the absence of opaque sky cover, total sky cover;

• station pressure is recommended, but not required, since it is used only to calculate
the density of dry air; AERMET will use a default value of 1013.25 millibars (sea
level pressure) in the absence of station pressure.

Upper Air Soundings:

• morning sounding (the 1200 GMT sounding for applications in the United States)

2.2.1 Stage 1 - processing hourly surface observations

Figure 2-1 shows the steps for processing the NWS hourly surface observations in
Stage 1. The entire flow diagram shown in Figure 2-1 is shown here, but the steps that are not
required to process the surface data do not contain any text.The first step in this example is to
extract and QA the hourly surface observations from the data archive file. Figure 2-2 shows the
control files for this step, which is provided in the file EX1-SF.INP. Blank records have been
inserted between records and the keywords indented to enhance legibility. The text to the right
provides a short comment on the pathway or keyword and must not appear in the control files
used to run AERMET (the comments are omitted in the files provided for this tutorial).

Figure 2-1. Stage 1 Processing for Hourly Surface Observations

2-7
JOB Start of the JOB pathway

MESSAGES SURFACE.MSG File for all messages

REPORT SURFACE.RPT File for the run summary

SURFACE Start of the SURFACE pathway

DATA S1473588.144 CD144 Archive data file, format

EXTRACT SFCEXOUT.DSK File to which the extracted data are

written

XDATES 88/3/1 TO 88/03/10 Dates to extract from the archive file

LOCATION 14735 42.75N 73.8W 0 83.8 Station identifier,

latitude, longitude, and
conversion to local time,
station elevation (m)

QAOUT SFQAOUT.DSK File for the output from QA

Figure 2-2. Example Control File to Extract and QA NWS Surface Data (EX1-SF.INP)

2.2.1.1 JOB pathway

This pathway is common to all AERMET runs and may appear anywhere in the control
file, but it usually appears first. The basic keywords associated with the JOB pathway are:

MESSAGES - specifies the file name where all the errors, warning and
informational messages generated by AERMET are written; a
mandatory keyword.

REPORT - specifies the file name where the summary of the run is written; an
optional, but highly recommended, keyword. If this keyword is
omitted, then the report streams to the default output device, usually the
screen, and can be captured to a file using DOS redirection on a PC
(discussed later in this section)

In this example, the messages are written to SURFACE.MSG and the report is written to
SURFACE.RPT. The files are written in the directory in which AERMET is started. The files
are ASCII files that can be viewed with any common text editor or viewing program. Both files

2-8
contain information that can be used to determine if a particular run was successful or failed,
and if the run failed, give possible reasons.

There are several hundred different places in AERMET that could generate a message -
from an error (fatal to processing) to a warning (could cause problems) to an informational
message. Messages are written at the time the control file is processed as well as when data are
processed. Appendix E contains a list of these messages with a brief explanation of each.
Depending on the pathways and keywords defined in a particular run, this file could be very
long, particularly when the data are QA'd, so it is advisable to check the size or view it prior to
printing it.

One other keyword is associated with the JOB pathway:

CHK_SYNTAX - checks the syntax of the control file for errors, without processing any
data; use this keyword to check a newly created control file before
processing any data to locate possible syntax errors.

A detailed discussion of all the keywords for the JOB pathway is provided in
Section 4.0, with a synopsis of each keyword in Appendix A.

2.2.1.2 SURFACE pathway

The SURFACE statement indicates that a block of keyword statements for the
SURFACE pathway are to follow. The basic keywords required to extract and assess the
quality of NWS surface data are:

DATA - specifies the input file name of the archived data and the file format for
the extraction process;

EXTRACT - specifies the output file name of extracted data; this keyword also
specifies the input file name for the data QA;

XDATES - specifies the period of time to be extracted from the archived data file;

2-9
 LOCATION - specifies the station identifier, latitude and longitude, the factor to
convert the time of each data record to local standard time, and the
station elevation;

QAOUT - specifies the output file name from the QA process; this keyword is
also used to specify the input file name to Stage 2 - see Section 2.2.3.

The order of these keywords within the SURFACE pathway is not important. The
presence of both the DATA and EXTRACT keywords (without error) directs AERMET to
extract hourly observations from a file of archived data. The presence of both the EXTRACT
and QAOUT keyword statements directs AERMET to assess the quality of the data. Therefore,
in this example, the surface data will be both extracted and QA'd.

DATA and EXTRACT

The first parameter associated with the DATA keyword identifies the name of the
archive data file, S1473588.144 in this example. On a PC, the file name must conform to the
standard operating system naming convention and is limited by AERMET to 96 characters. The
second parameter, CD144 in this example, identifies the archive format of the file. The format
parameter indicates that the archive data are in NCDC's CD-144 format, which consists of all
the weather observations for one hour on a single, 80-column record.

In addition to the CD144 format, AERMET can process: SCRAM,SAMSON, HUSWO,

ISHD, and TD-3280. The more common format for current modeling applications that use
NWS surface data is the ISHD format while TD-3280 is for data that were stored on magnetic
tape (see Appendix E) and is now obsolete. These formats are discussed in detail in Section 4.3.

Note that in previous versions of AERMET the DATA keyword included 'blocking
factor' and 'data type' as two optional parameters. Beginning with version 11059, these two
parameters are no longer supported by AERMET, and AERMET will issue a warning
message if these parameters are included on the DATA keyword.

2-10
 The EXTRACT keyword specifies the name of the file to which the extracted data are to
be written. It is an ASCII file. In this example, the data are written to SFEXOUT.DSK. The
hourly surface data are written to the output file as integers, with some variables multiplied by
10 or 100 to retain significant digits. Information on the specific structure for NWS hourly
surface observations in the extracted data file is provided in Appendix C.

XDATES

XDATES identifies the inclusive dates, in the form YY/MM/DD, of the data to be
retrieved, where YY is the year, MM is the month, and DD is the day, all specified as integers.
The word "TO" is optional and is ignored during processing if it is present. The "/" between
each part of the date is required. There can be no blanks in the date field, otherwise AERMET
will not correctly interpret this record and will terminate with an error. In this example, NWS
hourly surface observations for the period March 1, 1988 through March 10, 1988, inclusive, are
extracted from the archive file. Notice that the month and day can be specified with or without
leading zeros.

LOCATION

The LOCATION keyword is required and specifies station information on which data
are to be extracted from the archive file. The parameters associated with this keyword are the
station identifier, latitude, longitude, a time conversion factor, and the station elevation. In this
example, the station identifier is 14735 and is a Weather Bureau Army Navy (WBAN) number
(discussed in Section 4.0) for Albany, New York. This station identifier is carried through all
the stages of processing and appears on the first record of the boundary layer parameter output
file from Stage 3. The NWS station latitude and longitude are specified in decimal degrees.
These coordinates can be specified in either order, but the directional specifiers (N and W in this
case) are required. AERMET does not recognize "+" and "-" to distinguish between north or
south and east or west; therefore, latitude and longitude should be specified as positive numbers.
The LOCATION keyword also defines the number of hours required to convert the time of each
data record to local standard time (LST). For stations west of Greenwich, this value is specified
2-11
as a positive number. In most of the older archive formats date and time information is stored in
local standard time, in which case the conversion is 0, also the default value. Therefore, if this
adjustment is zero, this parameter can be omitted. If data are reported in GMT or Coordinated
Universal Time (UTC), then the number of time zones west (positive number) or east (negative
number) of Greenwich is specified. The archive format now used by the NCEI is the ISHD
format in which date and time information is stored in GMT.

Beginning with version 06341, the LOCATION keyword on the SURFACE pathway
also includes the station elevation as an optional last parameter. The elevation is used to
estimate station pressure if omitted from the raw surface data file or for hours the station
pressure is missing. A default value of 0 meters is assumed if the station elevation is omitted
from the LOCATION keyword. The station elevation may be included in the surface data file,
depending on the file format. AERMET will use the elevation read from the surface file rather
than the elevation specified in the control file when both are provided. Refer to Section 5.6 for
a more detailed discussion of the use of the station elevation on the LOCATION keyword in
SURFACE and ONSITE pathways.

QAOUT

The QAOUT keyword identifies the file where the data that have undergone the QA
process are written. In this example, the output is written to SFQAOUT.DSK.

Several variables on the SURFACE pathway are checked (audited) by default. These
are the total and opaque sky cover, station pressure, dry bulb temperature, and wind speed and
direction. During the quality assessment process, audited variables are checked as being
missing or outside a range of acceptable values. The default values for the SURFACE pathway
are defined in Appendix B, Table B-2. A violation of the range or a missing value is reported in
the message file, SURFACE.MSG. The variable name, value, upper or lower bound (depending
on the violation) or missing value indicator, and date/time are reported in this file (the structure
of the message is explained in Appendix D. The user should review the message file to
determine if the violations are true errors (e.g., a temperature of 100 °C) and need correction or
2-12
if they can be ignored (e.g., a temperature that is 0.1 °C higher than an upper bound of 35 °C).
The total number of violations and missing values are summarized by variable in the REPORT
file, SURFACE.RPT. In the message and summary files, the value and bound or missing
indicator is multiplied by the same factor that was used to "integerize" the data (see the
discussion for the EXTRACT keyword above). This "integerization" should be kept in mind
when reviewing the results of the QA.

The AERMET preprocessor does not make changes to the data during the QA process. If
the quality assessment identifies any problems, then either the extracted data file or the QA
output file can be edited to manually correct the data in accordance with sound meteorological
principles and within any relevant regulatory guidelines. If the modifications are extensive, it is
recommended that the data be reprocessed through the QA to identify any problems that may be
introduced as a result of the modifications.

The output file from the QA process is identical to the input file, except for the addition
of a header record. The preprocessor reads the hourly data and writes the same data to the
output file. One may question the need for a separate QA output file since the data are a copy of
the EXTRACT output file. The answer is that this method will allow for future accommodation
of automatic replacement procedures for missing values, if such procedures are established. By
having the two files (identified with the EXTRACT and QAOUT keywords), the AERMET
system has a logical design for assessing the data, reporting suspect or missing values, and
storing the new or modified values.

There are several additional keywords for the SURFACE pathway that are optional:

AUDIT - adds variables to the list of default variables to be tracked during QA;
use the names in the Table B-2 to identify the additional variables;

RANGE - allows the user to modify the default lower and upper QA bounds, the
inclusion/exclusion of the endpoints, and the missing value indicator
for the variable specified;

2-13
 NO_MISSING - suppresses the message that data are missing for variables being tracked
(audited) during the QA process; this keyword is useful in reducing the
size of the message file if an audited variable is missing most of the
time.

A detailed discussion of each of the valid keywords for the SURFACE pathway is provided in
Section 4.0, with a synopsis of each in Appendix A.

2.2.1.3 Running STAGE 1 and reviewing the output

Once a control file has been created, the next step is to run AERMET for that stage.
Remember, for this example we have divided Stage 1 into two separate runs: 1) extraction and
QA of the NWS surface data and 2) the extraction and QA of the NWS upper air data. To
process the NWS surface data at the command prompt, type:

AERMET EX1-SF.INP

Note that it is not necessary to include the .EXE extension to invoke the executable program.

As AERMET runs, the progress is displayed on the screen. AERMET first displays
which executable is running and the version date. Next, the message "Processing the Setup
Information" is displayed as the control file records are processed. If there is an error in the
control file, AERMET will display the message:

********************************************************
*** AERMET Setup Finished UN-successfully ***
********************************************************

If the setup processing is successful, the data processing begins. The year, month, and
day are displayed as each day is processed. Once all the data are processed, AERMET displays
a message that the processing is complete and the summary report is being written. If the data
were successfully processed, the following message is displayed:

2-14
 ********************************************************
*** AERMET Data Processing Finished Successfully ***
********************************************************

For an unsuccessful run (e.g., a period of time not included in the archive file is specified
with the XDATES keyword such that no data are extracted), the following is displayed:

********************************************************
*** AERMET Data Processing Finished UN-successfully ***
********************************************************

In both of these latter cases, the final message displayed on the screen informs the user where to
locate the summary report.

As was noted above, the REPORT keyword on the JOB pathway is optional. If the
keyword is used, then the summary information will be written to the file associated with the
REPORT keyword. If there is no REPORT keyword, then the summary information will be
written to the standard output device, which is normally the video monitor on a PC. Since the
summary fills more than one screen, the report can be sent to a destination other than the screen
by redirecting the report to a file as follows:

AERMET EX1-SF1.INP> STAGE1.LOG

The ">" directs AERMET to send output that would be written to the screen to the file
STAGE1.LOG. However, if this method is used, then all information displayed on the screen is
captured in the file, including the lines showing the progress of the processing.

Figure 2-3 shows the message file that results from running EX1-SF.INP. Most of the
messages are easily interpreted and relate to the data QA. The structure of these messages is
explained in Appendix D. Briefly, the first field is either a counter, blank or a date; the second
field is the pathway; the third field is a three-character code used to tabulate the messages for

2-15
the REPORT file; the fourth field is the subroutine that generated the message; and the fifth
field is the message.

JOB I19 SETUP : "END OF FILE" ON UNIT 5 AFTER RECORD # 19

JOB I25 TEST : SUMMARY: NO DATA EXTRACTION FOR UPPERAIR
JOB I25 TEST : SUMMARY: NO DATA QA FOR UPPERAIR
JOB I27 TEST : SUMMARY: NO DATA QA FOR ONSITE
SURFACE I40 SFEXT : *** SURFACE OBSERVATION EXTRACTION ***
SURFACE I41 FNDCOMDT: ASOS commission date FOUND for WBAN = 14735;
CALL4 = KALB; CALL3 = ALB; CommDate = 19950801
SURFACE I49 GETSFC : END-OF-DATA window encountered
SURFACE I49 SFEXT : 240 SURFACE records extracted
880302 SURFACE CLM SFQASM : CALM WINDS FOR HR 02
880302 SURFACE CLM SFQASM : CALM WINDS FOR HR 03
880302 SURFACE CLM SFQASM : CALM WINDS FOR HR 04
880302 SURFACE CLM SFQASM : CALM WINDS FOR HR 05
880302 SURFACE CLM SFQASM : CALM WINDS FOR HR 06
880302 SURFACE CLM SFQASM : CALM WINDS FOR HR 07
880303 SURFACE CLM SFQASM : CALM WINDS FOR HR 19
880303 SURFACE CLM SFQASM : CALM WINDS FOR HR 21
880306 SURFACE CLM SFQASM : CALM WINDS FOR HR 00
880306 SURFACE CLM SFQASM : CALM WINDS FOR HR 01
880306 SURFACE CLM SFQASM : CALM WINDS FOR HR 02
880306 SURFACE CLM SFQASM : CALM WINDS FOR HR 03
880306 SURFACE CLM SFQASM : CALM WINDS FOR HR 04
880306 SURFACE CLM SFQASM : CALM WINDS FOR HR 05
880306 SURFACE CLM SFQASM : CALM WINDS FOR HR 06
880306 SURFACE CLM SFQASM : CALM WINDS FOR HR 07
880308 SURFACE CLM SFQASM : CALM WINDS FOR HR 21
880308 SURFACE CLM SFQASM : CALM WINDS FOR HR 22
880309 SURFACE CLM SFQASM : CALM WINDS FOR HR 00
880309 SURFACE CLM SFQASM : CALM WINDS FOR HR 01
SURFACE I49 SFQASM : END OF FILE AFTER HOURLY OBS # 240

Figure 2-3. Message from Stage 1 (EX1-SF1.INP, Surface Extraction Only)

The first four messages are informational messages, as denoted by the 'I' in the first
position in the third field, and pertain to the control file setup processing. The first message
indicates that 19 records (including blank and comment lines) were processed before
encountering an end of file on the input control file. This is usually the first record in the
message file. The next three records indicate actions that will not be performed and relate to the
UPPERAIR and ONSITE pathways. The remaining messages pertain to the processing of the
NWS hourly surface observations. Records 5-7 indicate that data were extracted for the
SURFACE pathway, the end of the extraction window (as defined by the XDATES keyword)
was encountered in the input data, and that 240 records were extracted. This value can be used
to determine if the correct number of records were processed. In this example, since the
XDATES keyword specified the 10-day period March 1-10, one would expect that 240 records
(10 days x 24 hours/day) should be extracted. Since 240 records were extracted, we can be
2-16
reasonably certain that AERMET processed the data correctly. The QA will assist in making
the final determination.

These informational messages are followed by QA messages. In this example, all the
QA messages pertain to calm winds, as denoted by the 'CLM' in the third field. The number at
the left of the message indicates the year, month, and day the calm wind was encountered and
the hour is contained in the body of the message. The final record in this file is another
informational record indicating that the end of file on the QA input file (associated with the
EXTRACT keyword) was encountered after record number 240, the same number of records
that were extracted. These messages do not indicate anything unusual during the processing of
the hourly surface observations.

The summary report file is composed of the following general features:

• a banner identifying AERMET and the data and time the data were processed; this
banner appears at the top of each new AERMET report page;

• a message enclosed by asterisks indicating the success or failure of the setup or

data processing;

• a summary of information and processing in words and tables.

Figure 2-4 through Figure 2-6 show the report file that was generated. This file
summarizes the input information and tabulates the messages and QA results. In Figure 2-4, the
AERMET banner is followed by the message that the setup processing finished successfully.
The user should look for this message to confirm that there were no problems in the setup
processing. This message is followed by the control file input summary and contains
information by pathway:

1. JOB - the file names for the message and summary files;

2. UPPERAIR - AERMET determined that there were no upper air data to

process in this run;

2-17
 3. SURFACE - AERMET determined that NWS hourly surface observations are
to be processed and summarizes the information as follows:

a) the station information (identifier, latitude, longitude and time conversion factor);

b) a message on what processing AERMET performed on the data - extract and QA in this
example;

c) the input and output file names and if they were successfully opened;

d) the extract dates;

4. ONSITE - AERMET determined that there were no site-specific data to

process in this run

Compare the information in this figure to the control file in Figure 2-2 and the message
file in Figure 2-3 and you will see that this figure reflects the input control file and records 2
through 4 of the message file (the summary of the actions that were not performed).

Figure 2-5 shows the summary of the QA, which begins on a new page. This table
summarizes all QA messages generated by AERMET. The table includes the variable name (as
defined in Table B-2) on the far left, the total number of observations of that variable, the
number missing, the number of lower and upper bound violations, and the percent accepted. On
the right side of the table, the values that the data were tested against are shown. Recall that all
hourly observations are converted to integer format, with some values (such as wind speed and
temperature) multiplied by 10 to retain significant digits. These same multipliers are applied to
the values on the right side of the QA summary table. Table B-2 shows which variables have
been multiplied by 10 (1000 in the case of precipitation). The user is reminded of this fact
below the table.

In addition to the bounds violations and missing data, AERMET also checks for other
anomalous data: calm winds, zero wind speed and nonzero wind direction, dew point
temperature greater than ambient air temperature. The processing summary table (Figure 2-3)
did not include these QA results, but are summarized below the QA summary table. Compare

2-18
this summary to Figure 2-3. There are 20 messages in Figure 2-3 with the 'CLM' code, which is
the number reported in this summary.

This QA summary provides a quick means of assessing the validity of the data.
AERMET only performs simple data comparisons and reports its findings. It is up to the user to
determine if the reported violations are indicative of an error in the data or if the limits are too
restrictive. If the reported violation is due to the latter condition, the RANGE keyword can be
used to define new limits and the QA can be run again (without extracting the data again, as
described at the end of Section 3.0). If the reported violation is an error in the data, then the
user will have to judge on how to proceed - correcting the data or changing the data to indicate
that it is missing.

Figure 2-6 shows the tabulation of the messages that appear in Figure 2-3. This table
starts on a new page, therefore, the AERMET banner appears at the top. The banner is followed
by the message that the data processing finished successfully. This is the identical message that
is displayed on the screen when AERMET completes a successful run. Next is a record
indicating general processing activity (EXTRACT AND/OR QA THE METEOROLOGICAL
DATA). This record is followed by the table. Below the table, any error and warning messages
that appeared in the message file are redisplayed here. In this example, there were no error or
warning messages.

AERMET uses the third field in a message to construct the table. Only messages that
utilize the 'E', 'W', 'I', and 'Q' in the first position of the third field are tabulated. Messages with
special message codes, such as 'CLM', are excluded from this tabulation. The second and third
positions of the third field relate to the pathway being processed, as explained in Appendix D.
While the message file contains the individual messages, this table displays the distribution of
these messages.

2-19
 AERMET, A Meteorological Processor for the AERMOD Dispersion Model
Version 15181

Data Processed on 17-JUN-2016 at 09:40:12

Stage 1 Page 1

********************************************************
*** AERMET Setup Finished Successfully ***
********************************************************

1. Job File Names

Listing of Messages: SURFACE.MSG

Summary (this file): SURFACE.RPT

2. Upper Air Data

AERMET Has Determined That Processing For This Pathway Includes:

NONE, NO DATA TO BE PROCESSED ON THIS PATH

3. NWS Surface Data

Site ID Latitude(deg.) Longitude(deg.) Time Adjustment Elev. (m)

14735 42.75N 73.8W 0 83.8

Data Format: CD144

AERMET Has Determined That Processing For This Pathway Includes:

EXTRACT AND QUALITY ASSESSMENT

Extract Input - OPEN: S1473588.144

Extract Output- OPEN: SFCEXOUT.DSK
QA Output - OPEN: SFQAOUT.DSK

The Extract Dates Are: Starting: 1-MAR-1988

Ending: 10-MAR-1988

4. On-site Data

AERMET Has Determined That Processing For This Pathway Includes:

NONE, NO DATA TO BE PROCESSED ON THIS PATH

Figure 2-4. First Part of the Report File - Processing NWS Surface Observations

2-20
 AERMET, A Meteorological Processor for the AERMOD Dispersion Model
Version 15181

Data Processed on 17-JUN-2016 at 09:40:12

Stage 1 Page 2

********************************************************
*** AERMET Data Processing Finished Successfully ***
********************************************************

**** SUMMARY OF THE QA AUDIT ****

SURFACE DATA |------VIOLATION SUMMARY------| |-----TEST VALUES-----|

TOTAL # LOWER UPPER % MISSING LOWER UPPER
# OBS MISSING BOUND BOUND ACCEPTED FLAG BOUND BOUND
TMPD 240 0 0 0 100.00 999.0, -300.0, 400.0
WDIR 240 0 0 0 100.00 999.0, 0.0, 36.0
WSPD 240 0 0 0 100.00 999.0, 0.0, 500.0

NOTE: Test values were also multiplied by the same factors applied to the data
(see Appendix B of the AERMET User's Guide)

In addition, for the 240 hourly obs, AERMET reports that there are:

20 CALM WIND CONDITIONS (WS=0, WD=0)

0 ZERO WIND SPEEDS WITH NONZERO WIND DIRECTIONS
0 DEW-POINT GREATER THAN DRY BULB TEMPERATURES

The date & time of these occurrences can be found in

the message file SURFACE.MSG

THIS CONCLUDES THE AUDIT TRAIL

Figure 2-5. Second Part of the Report File - Processing NWS Hourly Surface Observations

2-21
 AERMET, A Meteorological Processor for the AERMOD Dispersion Model
Version 15181

Data Processed on 17-JUN-2016 at 09:40:12

Stage 1 Page 3

********************************************************
*** AERMET Data Processing Finished Successfully ***
********************************************************

EXTRACT AND/OR QA THE METEOROLOGICAL DATA

**** AERMET MESSAGE SUMMARY TABLE ****

0- 9 10-19 20-29 30-39 40-49 50-59 60-69 70-89 TOTAL

------------------------------------------------------------------------

JOB
E 0 0 0 0 0 0 0 0 0
W 0 0 0 0 0 0 0 0 0
I 0 1 3 0 0 0 0 0 4

SURFACE
E 0 0 0 0 0 0 0 0 0
W 0 0 0 0 0 0 0 0 0
I 0 0 0 0 5 0 0 0 5
Q 0 0 0 0 0 0 0 0 0
------------------------------------------------------------------------
0 1 3 0 5 0 0 0 9

**** ERROR MESSAGES ****

--- NONE ---

**** WARNING MESSAGES ****

--- NONE ---

ASOS Commission Date for Surface Station 14735 (YYYYMMDD): 19950801

Figure 2-6. Third Part of the Report File - Processing NWS Hourly Surface Observations.

2-22
2.2.2 Stage 1 - processing twice-daily soundings

The steps required to process the upper air soundings through Stage 1 are shown in
Figure 2-7.

Figure 2-7. Stage 1 Processing Upper Air Soundings

The next step in this tutorial is the extraction and QA of the twice-daily upper air
soundings. Figure 2-8 shows the control file for this step and is provided in the file
EX1-UA.INP. The text to the right on each record provides a short comment on the pathway or
keyword and must not appear in the control file.

2-23
 JOB Start of the JOB pathway

REPORT UPPERAIR.RPT File for all messages

MESSAGES UPPERAIR.MSG File for the run summary

UPPERAIR Start of the UPPERAIR pathway

DATA 14735-88.UA 6201FB Archive data file name, format

EXTRACT UAEXOUT.DSK File to which the extracted data are

written

XDATES 88/3/1 TO 88/3/10 Dates to extract from the archive file

LOCATION 00014735 73.8W 42.75N 5 Station identifier, location, and

conversion to local time

QAOUT UAQAOUT.DSK File for the output from QA

AUDIT UATT UAWS UALR Upper air variables to QA

Figure 2-8. Example Control File to Extract and QA NWS Upper Air Sounding Data

The discussion for the JOB pathway associated with the extraction and QA of the hourly
surface observations in Section 2.2.1 applies here as well. The messages and summary report
for this run are written to UPPERAIR.MSG and UPPERAIR.RPT, respectively.

2.2.2.1 UPPERAIR pathway

The UPPERAIR statement indicates that a block of keywords for the UPPERAIR
pathway are to follow. The extraction and quality assessment of NWS upper air sounding data
is very similar to that of NWS surface data and uses the same basic keywords. The keywords
used in this example are:

DATA - specifies the input file name of the archived data, the file format for
the extraction process, and the data blocking factor;

EXTRACT - specifies the output file name of extracted data; this keyword also is
used for the input file name for the data to QA;

XDATES - specifies the period of time to be retrieved from the archived data file;

2-24
 LOCATION - specifies the station identifier, latitude and longitude and the factor
to convert the time of each data record to local standard time;

QAOUT - specifies the output file name from the QA process; this keyword is
also used to specify the input file name to Stage 2 - see Section 2.2.3;

AUDIT - this keyword is optional; since none of the UPPERAIR variables

are automatically checked, then variables are QA'd on the
UPPERAIR pathway only if this keyword is used to include them in
the QA.

The order of these keywords within the UPPERAIR pathway is not important. The
presence of both the DATA and EXTRACT keywords directs AERMET to extract soundings
from a file of archived data. The presence of both the EXTRACT and QAOUT keyword
statements directs AERMET to assess the quality of the sounding data. Therefore, in this
example, the upper air data will both be extracted and QA'd.

DATA and EXTRACT

The first parameter associated with the DATA keyword identifies the name of the
archived data file, 14735-88.UA in this example. As with any file name in a control file, the
name could include a drive and directory path so long as the length of the name does not exceed
the (AERMET-imposed) 96-character limit. The second parameter, 6201FB, identifies the
format of the archive data set. This parameter indicates that the data are in NCDC's TD-6201
format (the 6201 portion) and that the data are fixed-length blocks (the FB part). Sounding data
in this format consist of 2876-character records with 79 levels of data per record. If there are
less than 79 levels in a sounding, the record is filled out with missing data indicators. The
discussion in Section 4.4 provides additional discussion on fixed-length and variable-length
blocks for the UPPERAIR pathway. AERMET can extract upper air data only from the TD-
6201 and NOAA/ESRL FSLformats. FSL is the more common format for upper air data
processed by AERMET for current modeling applications.

2-25
 The EXTRACT keyword specifies the name of the file to which the extracted data are to
be written. It is an ASCII file. In this example, the data are written to UAEXOUT.DSK.
Information on the specific structure for NWS upper air soundings in the extracted data file is
provided in Appendix C. The sounding data are written to the output file as integers, with some
variables multiplied by 10 or 100 to retain significant digits.

XDATES

XDATES identifies the inclusive dates, in the form YY/MM/DD, of the data to be
retrieved, where YY is the year, MM is the month, and DD is the day, all specified as integers.
The word "TO" is optional and is ignored during the processing of this keyword if it is present.
The "/" between each part of the date is required and there can be no blanks in the date field,
otherwise AERMET will terminate with an error. In this example, data for the period March 1,
1988 through March 10, 1988, inclusive, are extracted from the archive file.

LOCATION

The LOCATION keyword is required and specifies station information on which data
are to be extracted from the archive file. The parameters associated with keyword are the
station identifier, latitude, longitude, and the conversion of the sounding time to local standard
time. In this example, the station identifier is 00014735 and corresponds to Albany, New York.
Unlike the SURFACE pathway, the UPPERAIR identifier requires leading zeros because this
field contains leading zeroes in the archive file and the field is read as a character variable rather
than an integer. Hence, for AERMET to match the station identifier in the archive file with the
identifier in the control file, the leading zeroes are required. This station identifier is carried
through all the stages of processing and appears on the first record of the boundary layer
parameter output file from Stage 3.

The NWS station latitude and longitude are specified in decimal degrees. These
coordinates can be specified in either order, but the directional specifiers (N and W in this case)
are required. AERMET does not recognize "+" and "-" to distinguish between north or south
2-26
and east or west. Therefore, latitude and longitude should be specified as positive numbers.
The LOCATION keyword also defines the number of hours required to convert the time of each
data record to local standard time. For stations west of Greenwich, a positive value for this
factor must be specified. The times in the archive file are reported in GMT and this conversion
factor is subtracted from GMT to obtain local standard time. The reason for performing this
operation is to insure that all data for the current day are properly specified for the Stage 2
merging process. In this example, to convert the time to Eastern standard time (the time zone
for 73.8 west longitude), AERMET subtracts the last parameter for this keyword (5) from GMT
to get LST. For sounding dates in this archive file, this adjustment yields 1900 LST of the
previous day for the 0000 GMT sounding and 0700 LST for the 1200 GMT sounding in the
extracted file.

Note that beginning with version 11059, AERMET no longer supports the user-specified
station elevation as a parameter on the UPPERAIR LOCATION keyword. AERMET will issue
a warning message if the elevation field is included, but the user-specified elevation will be
ignored and processing will continue.

QAOUT and AUDIT

The QAOUT keyword identifies the file where the data are written that have passed
through the quality assessment. In this example, the output is written to UAQAOUT.DSK.

By default, no upper air variables are automatically checked (audited) in the QA process.
The AUDIT keyword must be used to QA the data for missing data and range violations. The
variable names, as shown in Table B-1, are specified on this statement. In this example, the
temperature (UATT), wind speed (UAWS) and lapse rate (UALR) are checked. While the
temperature and wind speed are in the file of extracted data, the lapse rate is computed during
the QA. The lapse rate can alert the user to unusual, but possibly valid, variations in the
temperature structure of the atmosphere, such as strong elevated inversions. However, it is not
retained for further use (i.e., the lapse rate is not saved in the output file).

2-27
 During the quality assessment process, audited variables are checked as being missing or
outside a range of acceptable values. The default values for the UPPERAIR pathway are
defined in Table B-1. A violation of the range or a missing value is reported in the message file,
UPPERAIR.MSG. The variable name, value, upper or lower bound (depending on the
violation) or missing value indicator, and date/time are reported in this file. As with the data for
the SURFACE pathway, both the value and bound or missing indicator may have been
multiplied by a factor to integerize and retain significant digits. The user should review the
message file to determine if the violations are errors in the data and need correction or if they
can be ignored. The total number of violations and missing values are summarized by variable
in the REPORT file, UPPERAIR.RPT.

AERMET does not modify the data during the QA. If the quality assessment identifies
any problems, then either the EXTRACT file (UAEXOUT.DSK) or the QAOUT file
(UAQAOUT.DSK) may be edited to manually correct the data in accordance with
meteorological principles and within any relevant regulatory guidelines. If the modifications are
extensive, the data should be reprocessed through the quality assessment procedures to identify
any problems that may be introduced with the modifications.

There are several optional keywords available for the UPPERAIR pathway. These are:

RANGE - modifies the default QA bounds and missing value indicator for the
variable specified;

NO_MISSING - suppresses the message that data are missing for variables being
audited during the QA process; this keyword is useful in reducing
the size of the message file if an audited variable is missing most of
the time.

MODIFY - directs to perform automatic modifications to the upper air data as

the data are extracted; these modifications are described in Section
4.0 with the discussion of this keyword.

A detailed discussion of each of the keywords on the UPPERAIR pathway is provided in

Section 4.0, with a synopsis of each in Appendix A.
2-28
2.2.2.2 Running Stage 1 and reviewing the output

To run Stage 1 and extract and QA the NWS upper air data with EX1-UA.INP, execute
the following command at a command prompt4:

AERMET EX1-UA.INP

The executable and version date, setup processing, and data processing are displayed on the
screen as described in Section 2.2.1.3.

Figure 2-9 shows the message file that results from running EX1-UA.INP. Most of the
messages are easily interpreted and are related to the data QA. The structure of these messages
is explained in Appendix D.

JOB I19 SETUP : "END OF FILE" ON UNIT 5 AFTER RECORD # 20

JOB I26 TEST : SUMMARY: NO DATA EXTRACTION FOR SURFACE
JOB I26 TEST : SUMMARY: NO DATA QA FOR SURFACE
JOB I27 TEST : SUMMARY: NO DATA QA FOR ONSITE
UPPERAIR I30 UAEXT : **** UPPER AIR EXTRACTION ****
UPPERAIR I39 GET620 : END-OF DATA WINDOW ENCOUNTERED
UPPERAIR I39 UAEXT : 20 SOUNDINGS EXTRACTED
880302 UPPERAIR Q39 UAQASM : UAWS MISSING FOR HR 07 AT LEVEL 8
880302 UPPERAIR Q39 UAQASM : UAWS MISSING FOR HR 07 AT LEVEL 9
880302 UPPERAIR Q39 UAQASM : UAWS MISSING FOR HR 07 AT LEVEL 10
880304 UPPERAIR Q37 REALQA : LB: UALR= -4.44 < -2.00 FOR HR 19, LVL 08
880306 UPPERAIR Q38 REALQA : UB: UALR= 5.71 > 5.00 FOR HR 07, LVL 02
880306 UPPERAIR Q38 REALQA : UB: UALR= 5.06 > 5.00 FOR HR 07, LVL 03
880309 UPPERAIR Q37 REALQA : LB: UALR= -3.00 < -2.00 FOR HR 19, LVL 02
880310 UPPERAIR Q38 REALQA : UB: UALR= 5.90 > 5.00 FOR HR 07, LVL 09
UPPERAIR I39 UAQASM : EOF AFTER UPPERAIR SOUNDING # 20

Figure 2-9. Message File from Processing NWS Upper Air Data

The first four messages are informational messages, as denoted by the 'I' in the first
position in the third field, and pertain to the control file setup processing. The first message
indicates that 20 records were processed (including blank and comment lines) before
encountering an end of file on the input control file. This is usually the first record in the
message file. The next three records indicate actions that will not be performed and relate to the

4
See Section 2.2 for a discussion on file redirection using the "<" symbol.
2-29
SURFACE and ONSITE pathways. The remaining messages pertain to the processing of the
NWS twice-daily upper air data. Records 5 through 7 indicate that data were extracted for the
UPPERAIR pathway and that 20 soundings were extracted. This value can be used to
determine if the correct number of soundings were processed. In this example, since the
XDATES keyword specified the 10-day period March 1-10, the correct number of soundings
were extracted (10 days x 2 soundings/day). These informational messages are followed by QA
messages, as denoted by the 'Q' in the first position of the third field. The number at the left of
the message indicates the year, month, and day of the QA violation and the hour is contained in
the body of the message. The final record in this file is another informational record indicating
that the end of file on the input file was encountered after sounding number 20, the same
number of soundings that were extracted.

The message file recorded two types of QA violations that were encountered during
processing. Records 8 through 10 indicate that the wind speed, as denoted by the variable name
UAWS (see Table B-3 for a list of UPPERAIR variable names), was missing for the 0700 LST
sounding on March 3, 1988 at levels 8, 9 and 10. Since wind speed is not currently used in any
calculations, these messages only serve as an indicator of the quality of the wind data.

Records 11 through 15 relate to the change in temperature, or lapse rate, between two
levels of data, as denoted by the variable name UALR in the body of the message. For the hour
and level reported, the lapse rate value was either less than the lower bound (LB) or greater than
the upper bound (UB). The format of these five messages is similar for all upper and lower
bound violation messages that the upper air QA generates. The messages contain the following
information:

Field 1: the sounding date

Field 2: the pathway
Field 3: the message code
Field 4: the subroutine that issued the message
Field 5: the message

• LB: = lower bound violation

2-30
 • UB: = upper bound violation

• UALR= variable in question, the lapse rate in this example calculated value <
lower bound or calculated value > upper bound hour of the sounding in LST
between the level reported in the message and the level below

AERMET calculates the lapse rate and, if the result is outside a range of values, AERMET
issues a QA message. In the first of these messages, a lapse rate of -0.0444 K/m was computed
(and multiplied by 100) and compared to the default value of -0.02 K/m (also multiplied by 100
in Table B-1). Since -0.0444 < -0.02, the message was written. There are default values in
AERMET (see Table B-1) but these bounds can be redefined using the RANGE keyword (as
described earlier and in Section 4.4).

None of these messages indicate anything extremely unusual during the QA of the
sounding data but, nonetheless, the user should review the data to confirm this assumption.
Figure 2-10 through Figure 2-12 show the summary report for the run and are very similar in
format and content to Figure 2-4 through Figure 2-6 for the SURFACE pathway. However, the
QA summary in Figure 2-11 appears different from Figure 2-5 because there are several levels
of data per sounding. The page begins with the AERMET banner and is followed by the
message that the data processing finished successfully. Below this heading is a table that is
divided into layer thicknesses: surface, eight layers that are 500 meters thick, and all data above
4000 meters. The reason for this division is that the height at which upper air data are reported
varies from sounding to sounding, except that there is always a level at the surface. The general
structure of the table is identical to the table for the summary of the QA of hourly surface
observations with the variable name and violation summary on the left and the test values used
for the QA on the right. Only the variables that were included with the AUDIT keywords
appear in this table because none of the upper air variables are automatically QA'd. Examining
the table reveals that there were three missing wind speeds in the 500-1000 meter layer, two
lower bound violations and three upper bound violations, which corresponds to the number of
individual messages written to the message file (Figure 2-9). Also note that the lapse rate is not
reported for the surface. None of the variables that compute a change between layers (wind
shear, lapse rates) can be reported for the surface.
2-31
 Below the table is a report on several other conditions that AERMET checks: calm
winds, zero wind speed and a nonzero wind direction, dew point temperature greater than
ambient air temperature, and the number of soundings that do not extend to 5000 meters. The
first three are identical to the checks made for the hourly surface observations. AERMET
extracts sounding data from an archive file up to the first level above 5000 meters. The last
check reports the number of soundings where the top of the sounding was below 5000 meters.
The date and time of such a sounding is reported in the message file. In Stage 3, AERMET
extrapolates the heights to 5000 meters for these "low" soundings if it becomes necessary in
order to complete the boundary layer parameter estimates. This extrapolation process is
explained in Section 5.7.4.

2-32
 AERMET, A Meteorological Processor for the AERMOD Dispersion Model
Version 15181

Data Processed on 17-JUN-2016 at 09:40:12

Stage 1 Page 1

********************************************************
*** AERMET Setup Finished Successfully ***
********************************************************

1. Job File Names

Listing of Messages: UPPERAIR.MSG

Summary (this file): UPPERAIR.RPT

2. Upper Air Data

Site ID Latitude(deg.) Longitude(deg.) Time Adjustment

00014735 42.75N 73.8W 5

Data Format: 6201FB

AERMET Has Determined That Processing For This Pathway Includes:

EXTRACT AND QUALITY ASSESSMENT

Extract Input - OPEN: 14735-88.UA

Extract Output- OPEN: UAEXOUT.DSK
QA Output - OPEN: UAQAOUT.DSK

The Extract Dates Are: Starting: 1-MAR-1988

Ending: 10-MAR-1988

Upper Air Data Above the First Level Above 5000 Meters Not Extracted
Upper Air Automatic Data Checks Are: OFF

3. NWS Surface Data

AERMET Has Determined That Processing For This Pathway Includes:

NONE, NO DATA TO BE PROCESSED ON THIS PATH

4. On-site Data

AERMET Has Determined That Processing For This Pathway Includes:

NONE, NO DATA TO BE PROCESSED ON THIS PATH

Figure 2-10. First Part of the Report File from Processing Upper Air Soundings

2-33
 AERMET, A Meteorological Processor for the AERMOD Dispersion Model
Version 15181

Data Processed on 17-JUN-2016 at 09:40:12

Stage 1 Page 2

********************************************************
*** AERMET Data Processing Finished Successfully ***
********************************************************

**** SUMMARY OF THE QA AUDIT ****

SOUNDINGS |------VIOLATION SUMMARY------| |-----TEST VALUES-----|

TOTAL # LOWER UPPER % MISSING LOWER UPPER
# OBS MISSING BOUND BOUND ACCEPTED FLAG BOUND BOUND
SURFACE
UATT 20 0 0 0 100.00 -9990.0, -350.0, 350.0
UAWS 20 0 0 0 100.00 9990.0, 0.0, 500.0
0 - 500M
UATT 65 0 0 0 100.00 -9990.0, -350.0, 350.0
UAWS 65 0 0 0 100.00 9990.0, 0.0, 500.0
UALR 65 0 1 2 95.38 -9999.0, -2.0, 5.0
500 - 1000M
UATT 46 0 0 0 100.00 -9990.0, -350.0, 350.0
UAWS 46 3 0 0 93.48 9990.0, 0.0, 500.0
UALR 46 0 0 0 100.00 -9999.0, -2.0, 5.0
1000 - 1500M
UATT 43 0 0 0 100.00 -9990.0, -350.0, 350.0
UAWS 43 0 0 0 100.00 9990.0, 0.0, 500.0
UALR 43 0 1 0 97.67 -9999.0, -2.0, 5.0
1500 - 2000M
UATT 49 0 0 0 100.00 -9990.0, -350.0, 350.0
UAWS 49 0 0 0 100.00 9990.0, 0.0, 500.0
UALR 49 0 0 1 97.96 -9999.0, -2.0, 5.0
2000 - 2500M
UATT 50 0 0 0 100.00 -9990.0, -350.0, 350.0
UAWS 50 0 0 0 100.00 9990.0, 0.0, 500.0
UALR 50 0 0 0 100.00 -9999.0, -2.0, 5.0
2500 - 3000M
UATT 31 0 0 0 100.00 -9990.0, -350.0, 350.0
UAWS 31 0 0 0 100.00 9990.0, 0.0, 500.0
UALR 31 0 0 0 100.00 -9999.0, -2.0, 5.0
3000 - 3500M
UATT 29 0 0 0 100.00 -9990.0, -350.0, 350.0
UAWS 29 0 0 0 100.00 9990.0, 0.0, 500.0
UALR 29 0 0 0 100.00 -9999.0, -2.0, 5.0
3500 - 4000M
UATT 20 0 0 0 100.00 -9990.0, -350.0, 350.0
UAWS 20 0 0 0 100.00 9990.0, 0.0, 500.0
UALR 20 0 0 0 100.00 -9999.0, -2.0, 5.0
> 4000M
UATT 76 0 0 0 100.00 -9990.0, -350.0, 350.0
UAWS 76 0 0 0 100.00 9990.0, 0.0, 500.0
UALR 76 0 0 0 100.00 -9999.0, -2.0, 5.0

NOTE: Test values were also multiplied by the same factors applied to the data
(see Appendix B of the AERMET User's Guide)

In addition, for the 20 soundings, AERMET reports that there are:

0 CALM WIND CONDITIONS (WS=0, WD=0)

0 ZERO WIND SPEEDS WITH NONZERO WIND DIRECTIONS
0 DEW POINT GREATER THAN DRY BULB TEMPERATURE
1 SOUNDINGS THAT DO NOT EXTEND TO 5000 METERS

The date, time and level of the occurrences for the first three
can be found in the message file UPPERAIR.MSG

THIS CONCLUDES THE AUDIT TRAIL

Figure 2-11. Second Part of the Report File from Processing Upper Air Soundings
2-34
 AERMET, A Meteorological Processor for the AERMOD Dispersion Model
Version 15181

Data Processed on 17-JUN-2016 at 09:40:12

Stage 1 Page 3

********************************************************
*** AERMET Data Processing Finished Successfully ***
********************************************************

EXTRACT AND/OR QA THE METEOROLOGICAL DATA

**** AERMET MESSAGE SUMMARY TABLE ****

0- 9 10-19 20-29 30-39 40-49 50-59 60-69 70-89 TOTAL

------------------------------------------------------------------------

JOB
E 0 0 0 0 0 0 0 0 0
W 0 0 0 0 0 0 0 0 0
I 0 1 3 0 0 0 0 0 4

UPPERAIR
E 0 0 0 0 0 0 0 0 0
W 0 0 0 0 0 0 0 0 0
I 0 0 0 4 0 0 0 0 4
Q 0 0 0 8 0 0 0 0 8
------------------------------------------------------------------------
0 1 3 12 0 0 0 0 16

**** ERROR MESSAGES ****

--- NONE ---

**** WARNING MESSAGES ****

--- NONE ---

Figure 2-12. Third Part of the Report File from Processing Upper Air Soundings

2.2.3 Stage 2 - merging data

In Stage 2, the data processed in Stage 1 are merged (combined) into a single, formatted
ASCII file with the data grouped in 24-hour periods (in local standard time). Figure 2-13 shows
the processing flow associated with Stage 2 for this example. In this step, the NWS hourly
surface observations and upper air soundings are combined. Figure 2-14 shows the control file
for Stage 2 and is provided in the file EX1-MRG.INP.

2-35
 Figure 2-13. Stage 2 Processing that Merges the Hourly Surface Observations and
Upper Air Soundings into a Single File

JOB Start of the JOB pathway

REPORT MERGE-1.RPT File for all messages

MESSAGES MERGE-1.MSG File for run summary

SURFACE Start of the SURFACE pathway

QAOUT SFQAOUT.DSK Input file with NWS hourly observations

UPPERAIR Start of the UPPERAIR pathway

QAOUT UAQAOUT.DSK Input file with NWS upper air data

MERGE

OUTPUT MERGE.DSK Output file with merged

meteorological data

XDATES 88/03/01 88/03/04 Period to include in the output

Figure 2-14. Example Control File to Merge NWS Data

2-36
 Merging data must be executed as a stand-alone process. Neither Stage 1 extraction/QA
nor Stage 3 data processing can be performed with the merge. If the user attempts such a
combination, AERMET issues an error message and does not process any data.

The only valid keywords for the MERGE pathway are:

OUTPUT - specifies the output file name of merged data/input file name for Stage 3;

XDATES - an optional keyword that specifies the period of time to be retrieved from
the input files and merged together.

The OUTPUT keyword defines the file to which the merged data are written. It is an
ASCII file. In this example, the output is written to MERGE.DSK.

The range of dates in the files that are to be combined are specified using the XDATES
keyword. The syntax is identical to its usage in the extract and QA processes in Stage 1. Notice
in this example the optional "TO" has been omitted. By using the XDATES keyword, a subset
of the data can be merged. This is useful if the user had processed a large amount of data (e.g.,
one year of data), but is interested in a shorter time period for dispersion modeling. In this
example, data between March 1, 1988 and March 4, 1988, inclusive, are merged (recall that data
for the period March 1 - March 10 were processed in Stage 1 for both SURFACE and
UPPERAIR data).

The XDATES keyword is optional and if it is omitted, then AERMET begins merging
data corresponding with the earliest date found in the input data files. The ending date is always
367 days later, even if the last day of data in all the input files is prior to the 367th day. The user
can determine if there are days without data by examining the summary file as explained at the
end of this subsection. AERMET can MERGE multi-year data files if the XDATES keyword is
specified.

2-37
 The input files to Stage 2 are specified with the QAOUT keyword for the appropriate
pathway. The example in Figure 2-14 uses the two files that were created from the QA process
for the SURFACE and UPPERAIR pathways above. The QAOUT keywords are the only
allowable keywords for the SURFACE and UPPERAIR pathways when data are merged. The
algorithms in Stage 3 require certain meteorological data to compute the boundary layer
parameters. A merge cannot be performed with NWS upper air data alone. AERMET interprets
this situation as an error and will not process any data.

2.2.3.1 Running Stage 2 and reviewing the output

To merge the data using EX1_MRG.INP, the following command is typed at a DOS
prompt on the PC:

AERMET EX1-MRG.INP

The executable and version date, setup processing, and data merging are displayed on the screen
as described in Section 2.2.1.3.

The message file for Stage 2 (Figure 2-15) is very brief and lists the actions AERMET
will not perform and reports the total number of header records processed from the input files.

JOB I19 SETUP : "END OF FILE" ON UNIT 5 AFTER RECORD # 21

JOB I25 TEST : SUMMARY: NO DATA EXTRACTION FOR UPPERAIR
JOB I25 TEST : SUMMARY: NO DATA QA FOR UPPERAIR
JOB I26 TEST : SUMMARY: NO DATA QA FOR SURFACE
JOB I27 TEST : SUMMARY: NO DATA QA FOR ONSITE
JOB I27 TEST : SUMMARY: NO ONSITE data to merge
29 HEADERS PROCESSED FROM INPUT FILES

Figure 2-15. Message File from Merging the NWS Data

Figure 2-16 through Figure 2-18 show the summary report for the Stage 2 run. Like the
previous runs, the first page of output echoes the input in a more readable format. In Figure
2-16, notice that the station locations have been included for the SURFACE and UPPERAIR

2-38
pathways even though they were not specified in the control file (Figure 2-14). Recall that the
general output file structure (Section Error! Reference source not found.) includes header
records, which are the control file records with additional characters at the beginning of each
record. AERMET reads all these input file header records. If a header record contains a special
character at the beginning of the record (inserted by AERMET at the time the record was written
to the output file), then AERMET reprocesses the record as if it had been included in the control
file. This is the case with the LOCATION keywords for the SURFACE and UPPERAIR
pathways and why this information appears in the summary of the merge process.

The second page of the output is shown in Figure 2-17 and contains a table with the
number of observations merged by pathway for each day. Since only the period March 1-4 was
specified with the XDATE keyword, only four days appear in this table which is also noted just
above the table. The structure of this table and explanation of each line is as follows:

1) The month and day - up to 10 days per five-record grouping.

2) Number of soundings merged per day; although the soundings normally are
reported twice per day, AERMET also includes the afternoon sounding from
the previous day and the morning sounding for the next day. Since the upper
air sounding data were extracted beginning with March 1, there is no previous
afternoon sounding (on 2/29/88) to include in the merged data; hence only three
soundings were merged on 3/1/88.

3) Number of hourly surface observations - since there are 24 each day, there
were no days with any missing hourly surface data.

4) Number of hourly site-specific data observations - since there were no

site- specific data in the data base, this line contains all zeroes.

5) Number of hourly observations derived from the 1-minute ASOS wind

data – this line also contains all zeros since 1-minute ASOS data were not
included in the data base.

If there are more than 10 days in the merged data file, then another group of records would have
appeared below the first. One year of data requires nearly 200 records.

2-39
 Below this table is a summary of the number observations read (but not necessarily
merged) from each input file. Note that AERMET read 98 hourly surface observations rather
than 96 (4 days x 24 hours/day) to create the merged data file. There are two reasons for these
extra observations to be read (but not merged). First, for the CD-144 format, the initial hour in
the file is hour 0 on March 1, which is equivalent to hour 24 of the previous day (February 29).
AERMET operates on the 1-to-24 hour clock, so the first record is read but not merged.
Secondly, the first record on March 5 is read before AERMET determines that the hourly
surface data are outside the period specified with the XDATES keyword, hence it is not
included in the merged data file. Hence, two additional records were read to merge 96 hours
(four days) of data.

The third page of the summary is shown in Figure 2-18 and contains the message
summary table. Since no messages associated directly with the merge process were written to
the message file, there isn't a separate block (with all 0's) for the MERGE pathway.

2-40
 AERMET, A Meteorological Processor for the AERMOD Dispersion Model
Version 15181

Data Processed on 17-JUN-2016 at 09:40:12

Stage 2 Page 1

********************************************************
*** AERMET Setup Finished Successfully ***
********************************************************

1. Job File Names

Listing of Messages: MERGE-1.MSG

Summary (this file): MERGE-1.RPT

2. Upper Air Data

Site ID Latitude(deg.) Longitude(deg.) Time Adjustment

00014735 42.75N 73.8W 5

AERMET Has Determined That Processing For This Pathway Includes:

MERGE ONLY

QA Output - OPEN: UAQAOUT.DSK

3. NWS Surface Data

Site ID Latitude(deg.) Longitude(deg.) Time Adjustment

14735 42.75N 73.8W 0

AERMET Has Determined That Processing For This Pathway Includes:

MERGE ONLY

QA Output - OPEN: SFQAOUT.DSK

4. On-site Data

AERMET Has Determined That Processing For This Pathway Includes:

NONE, NO DATA TO BE PROCESSED ON THIS PATH

5. Merged Data
Merge Output - OPEN: MERGE.DSK

Figure 2-16. First Part of the Summary File for the Merge Processing

2-41
 AERMET, A Meteorological Processor for the AERMOD Dispersion Model
Version 15181

Data Processed on 17-JUN-2016 at 09:40:12

Stage 2 Page 2

Merging the Meteorological Data

The Merged Dates Are: Starting: 1-MAR-1988

Ending: 4-MAR-1988

***** Daily Output Statistics *****

1988 MO/DY: 3/ 1 3/ 2 3/ 3 3/ 4
NWS Upper Air Sdgs 2 4 4 4
NWS Sfc Observations 24 24 24 24
On-site Observations 0 0 0 0
Ave 1-min ASOS Winds 0 0 0 0

TOTAL OBSERVATIONS READ:

Upper Air Soundings : 9
NWS Sfc Observations: 98
On-site Observations: 0
1-min ASOS Wind Data: 0

***** MERGE PROCESS COMPLETED *****

Figure 2-17. Second Part of the Summary File for the Merge Processing

2-42
 AERMET, A Meteorological Processor for the AERMOD Dispersion Model
Version 15181

Data Processed on 17-JUN-2016 at 09:40:12

Stage 2 Page 3

********************************************************
*** AERMET Data Processing Finished Successfully ***
********************************************************

**** AERMET MESSAGE SUMMARY TABLE ****

0- 9 10-19 20-29 30-39 40-49 50-59 60-69 70-89 TOTAL

------------------------------------------------------------------------

JOB
E 0 0 0 0 0 0 0 0 0
W 0 0 0 0 0 0 0 0 0
I 0 1 5 0 0 0 0 0 6
------------------------------------------------------------------------
0 1 5 0 0 0 0 0 6

**** ERROR MESSAGES ****

--- NONE ---

**** WARNING MESSAGES ****

--- NONE ---

Figure 2-18. Third Part of the Summary File for the Merge Processing

2-43
2.2.4 Stage 3 - estimating boundary layer parameters for AERMOD

With all the NWS meteorological data merged into one file, Stage 3 can be run to
generate the two input files for AERMOD, as shown in Figure 2-19.

Figure 2-19. Stage 3 Processing Using the Merged NWS Data to Create the Input
Meteorology for AERMOD

The meteorological data for AERMOD are generated in Stage 3. The input control file
can only include statements for the JOB and METPREP pathways which control the Stage 3
processing. An example control file is shown in Figure 2-20 and is provided in the file
EX1-ST3.INP.

2-44
JOB Start of the JOB pathway

REPORT STAGE3-1.RPT File for all messages

MESSAGES STAGE3-1.MSG File for the run summary

METPREP Start of the METPREP pathway

DATA MERGE.DSK Input meteorological data file from Stage 2

METHOD REFLEVEL SUBNWS Processing method: allow substitution of NWS
data

METHOD WIND_DIR RANDOM Processing method: randomize NWS wind directions

NWS_HGT WIND 6.1 NWS wind measurement height

OUTPUT AERMET.SFC Output file with boundary layer parameters

PROFILE AERMET.PFL Output file with profile data

FREQ_SECT ANNUAL 1 Frequency and number of wind direction sectors to

define the primary site characteristics

SECTOR 1 0 360 Definition of wind direction sectors for primary

site characteristics

SITE_CHAR 1 1 0.15 2.00 0.12 Definition of primary site characteristics by

period
and wind direction sector

Figure 2-20. Example Stage 3 Control File to Create the Output Files for AERMOD

The keywords used in this example are:

DATA - specifies the input file name of the merged data from Stage 2;

NWS_HGT - specifies the instrument height for the variable indicated;

METHOD - defines a specific processing methodology for the secondary keyword

specified with this keyword;

OUTPUT - specifies the output file of fluxes, scaling parameters, mixing height,
near-surface winds and temperature;

PROFILE - specifies the output file of the multi-level observations of temperature,

winds and fluctuating components of the wind;

2-45
 FREQ_SECT - specifies the frequency and number of wind direction sectors for defining
the primary set of characteristics of surface roughness length, albedo and
midday Bowen ratio; this keyword must appear before the next two
keywords;
SECTOR - specifies the lower and upper bounds of individual wind direction
sectors for the primary set of characteristics; up to 12 sectors can be
defined and the directions so specified must account for all directions;

SITE_CHAR - defines the albedo, midday Bowen ratio and surface roughness length by
frequency and sector (in that order) for the primary set of characteristics;

Note that the LOCATION keyword under the METPREP pathway in Stage 3 is no
longer used by AERMET, unless site-specific mixing heights are used without any upper air
sounding data. 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 site-specific mixing heights, without upper air data, the LOCATION
keyword under the METPREP should be used to specify the conversion from GMT to LST.

Beginning with version 11059, AERMET requires two sets of surface characteristics
(primary and secondary) when both NWS surface data (including 1-minute ASOS wind data)
and site-specific data are provided. If either NWS surface data or site-specific data are omitted,
only a single (primary) set of surface characteristics is required. The secondary set of surface
characteristics and related parameters are specified, similar to the primary set, with the
keywords FREQ_SECT2, SECTOR2, and SITE_CHAR2.

DATA, OUTPUT, and PROFILE

The input data file created by Stage 2, MERGE.DSK, is identified through the DATA
keyword. The OUTPUT and PROFILE keywords define the output files that will be used as
input to the AERMOD dispersion model. In this example, the two files are AERMET.SFC and
AERMET.PFL, respectively. The output files are ASCII files and can be viewed with a text

2-46
editor or file viewer. The format of these two output files is given in Appendix D. Each record
of the OUTPUT file contains the surface fluxes of heat and momentum, scaling and stability
parameters, boundary layer height, and the site’s surface characteristics, winds and temperature
that were used to compute these values. The PROFILE file usually consists of one or more
levels of wind, temperature and standard deviations of the wind from a site-specific observation
program or from NWS data if site-specific data are missing or not in the data base.

METHOD

The METHOD keyword and associated secondary keywords direct AERMET to process
the data in a particular manner. Depending on the data in the data base and the intended use for
the output, this keyword may be optional or mandatory.

In this example REFLEVEL and WIND_DIR are used. (Refer to Section 4.7.6 for a
discussion of the different processing options that can be specified using the METHOD
keyword.) The REFLEVEL secondary keyword takes a single parameter and the only valid
parameter, SUBNWS which directs AERMET to substitute NWS data in the computations in
the event there are no site-specific data to use. If there are no site-specific data in the data base,
this secondary keyword becomes mandatory. If it is omitted, AERMET detects this condition
(no site-specific data and do not substitute NWS data) as an error and will not process any data.
If there are site-specific data in the data base, but some of the variables required for the
computations are missing, then this parameter directs AERMET to use the NWS data to
estimate the boundary layer parameters. Also, if the site-specific profiles of wind or
temperature are missing, this parameter directs AERMET to use NWS data to create the profile
of wind and/or temperature.

NWS wind directions are recorded to the nearest 10 degrees. The WIND_DIR
secondary keyword directs AERMET to randomize these directions if the RANDOM parameter
is specified or to leave the directions as they were extracted from the archive file if the
NORAND parameter is specified. Prior to version 16216, the default was not to randomize, so
if this secondary keyword was omitted, then any NWS wind directions would appear to the
2-47
nearest 10 degrees (equivalent to specifying NORAND). Beginning with version 16216, the
default has been changed to randomize NWS wind directions if not specified by the user. This
example uses the RANDOM parameter and all NWS wind directions used in the computations
and written to the output files are randomized. The EPA's standard table of random integers,
which is built into AERMET, is used to randomize wind direction.

NWS_HGT

Many computations in AERMET require the height at which a variable was measured.
The NWS_HGT keyword is used to define these heights for AERMET and is a mandatory
keyword when the REFLEVEL secondary keyword is used with the SUBNWS parameter.
Otherwise, the NWS_HGT keyword can be omitted. This keyword requires a secondary
keyword and parameter. The secondary keyword identifies the instrument that is being
referenced, and the parameter defines the height of the instrument, which must be specified in
meters. Currently, the only secondary keyword is WIND. Typical measurement heights at
NWS/FAA ASOS stations are 26 feet (7.9 meters) or 33 feet (10.1 meters). Heights for
historical data likely differ from these. The Local Climatological Data Annual Summaries
available from NCDC contain a historical record of instrumentation sites. In this example, the
height of the anemometer that measures the wind is at 6.1 meters (20 feet).

FREQ_SECT, SECTOR, and SITE_CHAR

The algorithms in Stage 3 require characteristics about the underlying surface where the
surface meteorological data were collected, including: the noon-time albedo, daytime Bowen
ratio, and surface roughness length. Beginning with version 11059, AERMET requires two sets
of these surface values when both site-specific and NWS surface data (including 1-minute
ASOS wind data) are provided to AERMET and the SUBNWS parameter is specified. In that
case, the characteristics for the site-specific location are the primary set, and the NWS
collection site is the secondary set. When only site-specific or NWS surface data are used, only
a primary set of surface characteristics is required, and they should be representative of the site
where the data were collected. Three keywords are used to define primary set of surface
2-48
characteristics: FREQ_SECT, SECTOR, and SITE_CHAR. A primary set of surface
characteristics is always required. Similarly, the secondary set are defined with the keywords
FREQ_SECT2, SECTOR2, and SITE_CHAR2. The secondary set is conditional as explained
above.

The FREQ_SECT and FREQ_SECT2 keywords have two parameters associated with
them: the first defines the frequency with which the site characteristics vary and the second
defines the number of contiguous, nonoverlapping wind direction sectors that define unique
upwind surface characteristics.

→ The FREQ_SECT keyword must precede the SECTOR and SITE_CHAR

keywords. Likewise, the FREQ_SECT2 keyword must precede the SECTOR2 and
SITE_CHAR2 keywords.

There are three valid time frequencies: ANNUAL, SEASONAL, or MONTHLY. For
program operation, the definition of SEASONAL in AERMET follows the calendar rather than
any vegetation cycles. Winter corresponds to December, January and February; spring
corresponds to March, April and May; summer corresponds to June, July and August; and
autumn corresponds to September, October and November. The user will have to determine
how the definitions of the seasons in the tables relate to vegetation cycles for a particular
application. Currently, there is no method in AERMET to specify the surface characteristics
more frequently than monthly.

In this example, the surface characteristics are to be defined with a frequency of

ANNUAL for one distinct wind direction sector; i.e., only the three surface characteristics are
changed while the default frequency and sector definition are retained. If the maximum
frequency and sectors had been defined, then it would require 144 (12 frequencies and 12
sectors) uses of the SITE_CHAR keyword to completely define the surface characteristics. An
example of MONTHLY characteristics for two sectors in given in Section 3.0.

2-49
 The SECTOR and SECTOR2 keywords each define the beginning and ending directions
of each sector, with one sector defined on each use of the keyword. There are several rules to
follow when specifying the sectors:

1) The sectors are defined clockwise as the direction from which the wind is
blowing, with north corresponding to 360°.

2) The sectors must cover the full circle, and these must be defined so that the end
of one sector is the beginning of another, i.e., for multiple sector definitions, the
beginning value for one sector must match the end value of the previous sector.

3) The beginning direction is considered part of the sector, while the ending
direction is excluded from the sector.

4) The maximum number of sectors is 12.

One SECTOR keyword is required in this example because '1' was specified with the
FREQ_SECT keyword. The sector must be 0° - 360° so as not to violate rule 2 above.

The surface characteristics are specified with the SITE_CHAR and SITE_CHAR2
keywords, one for each combination of periods defined by the frequency and direction sector.
The parameters associated with these keywords include:

1) the time period corresponding with the frequency on the FREQ_SECT (or
FREQ_SECT2) keyword;

2) wind sector index;

3) the midday albedo (nondimensional);

4) daytime Bowen ratio (nondimensional);

5) surface roughness length (meters).

These parameters are used in the computation of the fluxes and stability of the
atmosphere. The albedo is the fraction of total incident solar radiation reflected by the surface
back to space without absorption. Typical values range from 0.1 for thick deciduous forests to
0.90 for fresh snow. The Bowen ratio, an indicator of surface moisture, is the ratio of the
sensible heat flux to the latent heat flux. Although the Bowen ratio can have significant diurnal
2-50
variation, it is used to determine the planetary boundary layer parameters for convective
conditions. During the daytime, the Bowen ratio usually attains a fairly constant positive value,
which range from about 0.1 over water to 10.0 over desert at midday. The surface roughness
length is related to the height of obstacles to the wind flow and is, in principle, the height at
which the mean horizontal wind speed is zero. Values range from as small as 0.001 meter over
a calm water surface to 1 meter or more over a forest or urban area.

Tables 4-1 to 4-3 (from Paine, 1987) show typical values of the albedo, Bowen ratio and
surface roughness length as a function of season and land use type. The season in these tables
are based on the emergence and growth of vegetation. For example, March in one part of the
country may represent spring whereas in another part of the country it may well be winter. See
Section 4.7.8 and Section 5.7.2 for additional discussions on the surface characteristics.

The LOCATION keyword is now a conditional keyword that is mandatory when site-
specific mixing heights are used without upper air sounding data. Refer to Section 4.7.3 for
more discussion on the use of the LOCATION keyword on the METPREP pathway.

Optional keywords that are available for Stage 3 processing are:

XDATES - restricts the processing to a subset of the input data;

MODEL - specifies the dispersion model for which the estimates are made; currently
AERMET only generates the meteorological data for AERMOD, so this
keyword is optional.

A detailed discussion of each of the keywords on the METPREP pathway is provide in Section
4.0, with a synopsis of each in Appendix A.

2-51
2.2.4.1 Running Stage 3 and reviewing the output

To run Stage 3 to create the meteorological files for AERMOD, the following command
line is used:

AERMET EX1-ST3.INP

where EX1-ST3.INP is the example control file name. The discussion for redirecting output
(Section 2.2) also applies to Stage 3 processing. The executable and version date, setup
processing, and data processing are displayed on the screen as described in Section 2.2.1.3.

Figure 2-21 shows the message file that results from running EX1-ST3.INP. The file
begins with the familiar message that the end of file was located after record number 26. This
message is followed by eight messages that the boundary layer parameters were not computed
for the specified date (leftmost) field and time (at the end of the message) due to calm winds.
When calm wind conditions are encountered, AERMET does not perform any computations and
inserts missing data indicators into the output files for the boundary layer parameters (see Figure
2-25 for an example of the output file). The final message indicates that AERMET encountered
an end of file on the input meteorological data, i.e., on the merged data file, after March 4, 1988.
Since March 1-4, 1988 were the only days merged, this message indicates that all the data
appear to have been processed.

2-52
 JOB I19 SETUP : "END OF FILE" ON UNIT 5 AFTER RECORD # 26
METPREP I41 FNDCOMDT: ASOS commission date FOUND for WBAN = 14735;
CALL4 = KALB; CALL3 = ALB; CommDate = 19950801
880301 METPREP I84 MPPBL : Upper air sounding selected for this day: 12 Z
880301 METPREP I84 MPPBL : UAID = 1 for HR: 7 LST
880302 METPREP I71 MPPBL : Calm wind - No BL calculations for hour: 02
880302 METPREP I71 MPPBL : Calm wind - No BL calculations for hour: 03
880302 METPREP I71 MPPBL : Calm wind - No BL calculations for hour: 04
880302 METPREP I71 MPPBL : Calm wind - No BL calculations for hour: 05
880302 METPREP I71 MPPBL : Calm wind - No BL calculations for hour: 06
880302 METPREP I71 MPPBL : Calm wind - No BL calculations for hour: 07
880302 METPREP I84 MPPBL : Upper air sounding selected for this day: 12 Z
880302 METPREP I84 MPPBL : UAID = 3 for HR: 7 LST
880303 METPREP I71 MPPBL : Calm wind - No BL calculations for hour: 19
880303 METPREP I71 MPPBL : Calm wind - No BL calculations for hour: 21
880303 METPREP I84 MPPBL : Upper air sounding selected for this day: 12 Z
880303 METPREP I84 MPPBL : UAID = 3 for HR: 7 LST
880304 METPREP I84 MPPBL : Upper air sounding selected for this day: 12 Z
880304 METPREP I84 MPPBL : UAID = 3 for HR: 7 LST
4 METPREP I79 FETCH : EOF reached on input data file after 000000

Figure 2-21. Message File from Stage 3 for EX1-ST3.INP

The summary of the run is shown in Figure 2-22 through Figure 2-24. The first and last
pages of the summary (Figure 2-22 and Figure 2-24) contain similar information as the first and
last pages of the summaries generated in stages 1 and 2. The second page includes the
following :

1. The names of the input and output files and whether the files were opened.

2. The name of the dispersion model for which the data are prepared.

3. The processing options.

4. The site identifiers and locations for each of the meteorological data pathways.

5. The sit6. The output file names for the dispersion model identified.

Figure 2-25 shows the first 36 hours from the boundary layer parameter file. The first
record contains the latitude and longitude used in processing the meteorological data in Stage 3,
the station identifiers, and the AERMET version date. The identifier after OS_ID: is a 0
because no site-specific data were processed. The OS_ID is not the identifier specified in the
Stage 3 control file; the three identifiers that are displayed come from the processing in Stage 1.

2-53
This record is followed by one record per hour of meteorological output data. The contents of
this file are:

field(s) description
1-5 year (2-digit), month, day, Julian day, and hour
6 sensible heat flux (W/m2)
7 surface friction velocity (m/s)
8 convective velocity scale (set to -9.0 for stable atmosphere) (m/s)
9 potential temperature gradient above the mixing height (K/m)
10 convectively-driven mixing height (-999. for stable atmosphere) (m)
11 mechanically-driven mixing height (computed for all hours) (m)
12 Monin-Obukhov length (m)
13 surface roughness length (month and wind direction dependent) (m)
14 Bowen ratio (month and wind direction dependent) (non-dimensional)
15 albedo (month and wind direction dependent; 1.0 for hours before sunrise
or after sunset) (non-dimensional)
16-18 wind speed, wind direction, and anemometer height that were used in the
computations in Stage 3 (m/s degrees, m)
19-20 temperature and measurement height that were used in the computations
in Stage 3 (K and m)
21 precipitation type code
22 precipitation amount (mm/hr)
23 relative humidity (%)
24 station pressure (mb)
25 cloud cover (tenths)
26 wind speed adjustment and data source flag
27 cloud cover and temperature substitution by interpolation

The format of this file is included in Appendix C. The theoretical bases for the calculations that
estimate the boundary layer parameters are in Section 5.0.

Notice that for March 2, 1988, hours 2-7, the boundary layer parameters are represented
by missing value indicators (the various '-9' fields). Examining either the message file or the
second page of the summary report, note that the winds were calm for these time periods. The
wind speed and direction (fields 16 and 17) are set to 0.0 indicating a calm wind.

In the absence of site-specific data, as in this example, AERMET substitutes the NWS
data. Note that the anemometer height (field 18) is the height specified with the NWS_HGT

2-54
keyword. Field 26 reports if wind speeds were adjusted for the hour to account for a bias that
occurs in wind speed data collected at NWS/FAA sites that use an Automated Surface
Observing System (ASOS). This field also reports the source of the wind data for the hour. In
the example, though the source of the wind data for each hour is a standard NWS/FAA surface
archive format (SFC), the site was not ASOS-based at the time the data were collected and the
wind speeds were not adjusted (NAD). The adjustment applied to ASOS-based wind data is
discussed further in Section 4.7.6.3. Field 27 indicates whether cloud cover and/or temperature
for the hour was substituted using interpolation (see Section 4.7.6.5). In Section 3.0, we will see
how the introduction of site-specific data affects the output in this file.

Figure 2-26 shows the first 36 hours from the profile file. The contents of this file are:

field(s) description
1-4 year (2-digit), month, day, and hour
5 measurement height (m)
6 indicator flag: 1=last level in profile for the hour, 0=not the last level
7-8 wind direction and speed (m/s, m)
9 temperature (°C)
10 σϴ- standard deviation of the lateral wind direction (degrees)
11 σw - standard deviation of the vertical wind speed (m/s)-1

The format of this file is provided in Appendix C. None of the parameters in this file are
computed; the only changes that may occur are conversion of the units.

For this example there is one record per hour of meteorological output data. Since there
are no site-specific data in this example, AERMET constructed a one-level profile by
substituting NWS data. These data match the last fields in the boundary layer parameter file,
except that the temperature is expressed in different units. Since the NWS does not report the
fluctuating components of the wind (the σ's), these fields are filled with the missing value
indicators. In Section 3.0, we will see how the introduction of site-specific data affects the
output in this file.

2-55
 AERMET, A Meteorological Processor for the AERMOD Dispersion Model
Version 15181

Data Processed on 2-SEP-2016 at 13:09:21

Stage 3 Page 1

********************************************************
*** AERMET Setup Finished Successfully ***
********************************************************

1. Job File Names

Listing of Messages: STAGE3-1.MSG

Summary (this file): STAGE3-1.RPT

2. Upper Air Data

Site ID Latitude(deg.) Longitude(deg.) Time Adjustment

00014735 42.75N 73.8W 5

AERMET Has Determined That Processing For This Pathway Includes:

NONE, NO DATA TO BE PROCESSED ON THIS PATH

3. NWS Surface Data

Site ID Latitude(deg.) Longitude(deg.) Time Adjustment Elev. (m)

14735 42.75N 73.8W 0 83.8

AERMET Has Determined That Processing For This Pathway Includes:

NONE, NO DATA TO BE PROCESSED ON THIS PATH

4. On-site Data

AERMET Has Determined That Processing For This Pathway Includes:

NONE, NO DATA TO BE PROCESSED ON THIS PATH

Figure 2-22. First Part of the Summary File from Stage 3

2-56
 AERMET, A Meteorological Processor for the AERMOD Dispersion Model
Version 15181

Data Processed on 2-SEP-2016 at 13:09:21

Stage 3 Page 2

********************************************************
*** AERMET Setup Finished Successfully ***
********************************************************

1. Input/Output Files

STAGE3-1.RPT OPENED SUCCESSFULLY

STAGE3-1.MSG OPENED SUCCESSFULLY
MERGE.DSK OPENED SUCCESSFULLY
AERMET.SFC OPENED SUCCESSFULLY
AERMET.PFL OPENED SUCCESSFULLY

2. Dispersion Model for which Data Are Processed

AERMOD

The Processed Dates Are: Starting: 1-MAR-1988

Ending: 4-MAR-1988

Based on the MERGE file header records.

3. Processing Options

Process Scheme Description

------- ------ -----------
WIND DIRECTION RANDOM NWS wind directions are RANDOMIZED
CLOUD COVER CCVR_Sub Missing CCVR substitutions ARE included
TEMPERATURE TEMP_Sub Missing TEMP substitutions ARE included
SBL PROCESSING UCALST The default (Holtslag) method is used
ASOS ADJUSTMENT ASOS_ADJ ASOS wind speeds, if present, ARE adjusted for truncation
SDG SELECTION 00Z/12Z Sounding selection based on 12Z sdg
Selection window: -1 1
REFERENCE LEVEL SUBNWS NWS WIND & TEMP data ARE SUBSTITUTED for missing ONSITE data
Anemometer height(m): 6.10

4. Locations of Meteorological Data

Data Site Longitude Latitude

Pathway ID (degrees) (degrees)
------- ---- --------- ---------
UPPERAIR 00014735 73.8W 42.75N
SURFACE 14735 73.8W 42.75N

5. Primary Site Surface Characteristics

User Inputs Varied by: Annual

Wind Sector Bowen Roughness

Month Start End Albedo Ratio Length (m)
----------------------------------------------------
1 0. 360. 0.15 2.00 0.1200
2 0. 360. 0.15 2.00 0.1200
3 0. 360. 0.15 2.00 0.1200
4 0. 360. 0.15 2.00 0.1200
5 0. 360. 0.15 2.00 0.1200
6 0. 360. 0.15 2.00 0.1200
7 0. 360. 0.15 2.00 0.1200
8 0. 360. 0.15 2.00 0.1200
9 0. 360. 0.15 2.00 0.1200
10 0. 360. 0.15 2.00 0.1200
11 0. 360. 0.15 2.00 0.1200
12 0. 360. 0.15 2.00 0.1200

6. Input File(s) for AERMOD

Surface Meteorology: AERMET.SFC

Profile Data : AERMET.PFL

Figure 2-23. Second Part of the Summary File from Stage 3

2-57
 AERMET, A Meteorological Processor for the AERMOD Dispersion Model
Version 15181

Data Processed on 2-SEP-2016 at 13:09:21

Stage 3 Page 3

********************************************************
*** AERMET Data Processing Finished Successfully ***
********************************************************

PROCESSING METEOROLOGICAL DATA FOR DISPERSION MODELING

**** AERMET MESSAGE SUMMARY TABLE ****

0- 9 10-19 20-29 30-39 40-49 50-59 60-69 70-89 TOTAL

------------------------------------------------------------------------

JOB
E 0 0 0 0 0 0 0 0 0
W 0 0 0 0 0 0 0 0 0
I 0 1 0 0 0 0 0 0 1

METPREP
E 0 0 0 0 0 0 0 0 0
W 0 0 0 0 0 0 0 0 0
I 0 0 0 0 1 0 0 17 18
T 0 0 0 0 0 0 0 0 0
------------------------------------------------------------------------
0 1 0 0 1 0 0 17 19

**** ERROR MESSAGES ****

--- NONE ---

**** WARNING MESSAGES ****

--- NONE ---

ASOS Commission Date for Surface Station 14735 (YYYYMMDD): 19950801

The number of CALM winds encountered is: 8

The number of VARIABLE WD encountered is: 0
The number of miss CCVR substitutions is: 0
The number of miss TEMP substitutions is: 0

Figure 2-24. Third Part of the Summary File from Stage 3

2-58
 42.75N 73.8W UA_ID: 00014735 SF_ID: 14735 OS_ID: VERSION: 15181 CCVR_Sub TEMP_Sub
88 3 1 61 1 -30.4 0.283 -9.000 -9.000 -999. 361. 66.5 0.1200 2.00 1.00 3.10 275.0 6.1 270.4 2.0 0 -9.00 999. 1003. 4 NAD-SFC NoSubs
88 3 1 61 2 -45.5 0.392 -9.000 -9.000 -999. 588. 118.1 0.1200 2.00 1.00 4.10 279.0 6.1 270.4 2.0 0 -9.00 999. 1003. 1 NAD-SFC NoSubs
88 3 1 61 3 -45.7 0.392 -9.000 -9.000 -999. 588. 117.5 0.1200 2.00 1.00 4.10 279.0 6.1 269.2 2.0 0 -9.00 999. 1003. 1 NAD-SFC NoSubs
88 3 1 61 4 -58.4 0.499 -9.000 -9.000 -999. 845. 190.0 0.1200 2.00 1.00 5.10 290.0 6.1 268.1 2.0 0 -9.00 999. 1003. 1 NAD-SFC NoSubs
88 3 1 61 5 -64.0 0.563 -9.000 -9.000 -999. 1012. 249.2 0.1200 2.00 1.00 5.70 290.0 6.1 267.5 2.0 0 -9.00 999. 1003. 0 NAD-SFC NoSubs
88 3 1 61 6 -25.7 0.218 -9.000 -9.000 -999. 407. 35.9 0.1200 2.00 1.00 2.60 295.0 6.1 267.5 2.0 0 -9.00 999. 1004. 0 NAD-SFC NoSubs
88 3 1 61 7 -59.0 0.499 -9.000 -9.000 -999. 845. 188.1 0.1200 2.00 1.00 5.10 286.0 6.1 267.0 2.0 0 -9.00 999. 1004. 0 NAD-SFC NoSubs
88 3 1 61 8 6.3 0.420 0.241 0.009 78. 658. -1045.4 0.1200 2.00 0.38 4.10 315.0 6.1 267.5 2.0 0 -9.00 999. 1005. 6 NAD-SFC NoSubs
88 3 1 61 9 66.0 0.741 0.942 0.005 453. 1530. -551.8 0.1200 2.00 0.24 7.20 273.0 6.1 268.1 2.0 0 -9.00 999. 1005. 7 NAD-SFC NoSubs
88 3 1 61 10 132.4 0.847 1.361 0.005 683. 1863. -410.8 0.1200 2.00 0.19 8.20 297.0 6.1 268.1 2.0 0 -9.00 999. 1005. 6 NAD-SFC NoSubs
88 3 1 61 11 191.7 0.802 1.591 0.005 755. 1730. -241.2 0.1200 2.00 0.17 7.70 297.0 6.1 268.8 2.0 0 -9.00 999. 1005. 2 NAD-SFC NoSubs
88 3 1 61 12 211.8 0.912 1.724 0.005 867. 2082. -320.4 0.1200 2.00 0.16 8.80 268.0 6.1 268.8 2.0 0 -9.00 999. 1004. 0 NAD-SFC NoSubs
88 3 1 61 13 214.9 0.962 1.822 0.005 1008. 2256. -370.0 0.1200 2.00 0.16 9.30 271.0 6.1 269.2 2.0 0 -9.00 999. 1003. 0 NAD-SFC NoSubs
88 3 1 61 14 194.9 0.753 1.821 0.005 1108. 1631. -196.0 0.1200 2.00 0.17 7.20 306.0 6.1 269.2 2.0 0 -9.00 999. 1002. 0 NAD-SFC NoSubs
88 3 1 61 15 152.6 0.958 1.712 0.005 1177. 2240. -514.1 0.1200 2.00 0.18 9.30 256.0 6.1 268.8 2.0 0 -9.00 999. 1002. 0 NAD-SFC NoSubs
88 3 1 61 16 90.0 0.743 1.454 0.005 1221. 1603. -407.7 0.1200 2.00 0.22 7.20 268.0 6.1 268.8 2.0 0 -9.00 999. 1001. 0 NAD-SFC NoSubs
88 3 1 61 17 13.1 0.897 0.766 0.005 1225. 2032. -4930.7 0.1200 2.00 0.33 8.80 270.0 6.1 267.5 2.0 0 -9.00 999. 1001. 0 NAD-SFC NoSubs
88 3 1 61 18 -64.0 0.889 -9.000 -9.000 -999. 2012. 979.8 0.1200 2.00 0.65 8.80 266.0 6.1 265.9 2.0 0 -9.00 999. 1001. 0 NAD-SFC NoSubs
88 3 1 61 19 -64.0 0.889 -9.000 -9.000 -999. 2012. 979.8 0.1200 2.00 1.00 8.80 273.0 6.1 265.4 2.0 0 -9.00 999. 1001. 0 NAD-SFC NoSubs
88 3 1 61 20 -64.0 0.670 -9.000 -9.000 -999. 1379. 419.5 0.1200 2.00 1.00 6.70 278.0 6.1 264.2 2.0 0 -9.00 999. 1002. 0 NAD-SFC NoSubs
88 3 1 61 21 -64.0 0.670 -9.000 -9.000 -999. 1317. 419.0 0.1200 2.00 1.00 6.70 285.0 6.1 263.8 2.0 0 -9.00 999. 1001. 0 NAD-SFC NoSubs
88 3 1 61 22 -53.3 0.445 -9.000 -9.000 -999. 766. 147.6 0.1200 2.00 1.00 4.60 294.0 6.1 263.1 2.0 0 -9.00 999. 1001. 0 NAD-SFC NoSubs
88 3 1 61 23 -33.4 0.278 -9.000 -9.000 -999. 382. 57.5 0.1200 2.00 1.00 3.10 220.0 6.1 262.5 2.0 0 -9.00 999. 1001. 0 NAD-SFC NoSubs
88 3 1 61 24 -26.1 0.216 -9.000 -9.000 -999. 244. 34.6 0.1200 2.00 1.00 2.60 209.0 6.1 261.4 2.0 0 -9.00 999. 1001. 0 NAD-SFC NoSubs
88 3 2 62 1 -6.9 0.076 -9.000 -9.000 -999. 71. 5.8 0.1200 2.00 1.00 1.50 289.0 6.1 260.4 2.0 0 -9.00 999. 1001. 0 NAD-SFC NoSubs
88 3 2 62 2 -999.0 -9.000 -9.000 -9.000 -999. -999. -99999.0 0.1200 2.00 1.00 0.00 0.0 6.1 259.2 2.0 0 -9.00 999. 1000. 0 NAD-SFC NoSubs
88 3 2 62 3 -999.0 -9.000 -9.000 -9.000 -999. -999. -99999.0 0.1200 2.00 1.00 0.00 0.0 6.1 258.8 2.0 0 -9.00 999. 999. 0 NAD-SFC NoSubs
88 3 2 62 4 -999.0 -9.000 -9.000 -9.000 -999. -999. -99999.0 0.1200 2.00 1.00 0.00 0.0 6.1 258.1 2.0 0 -9.00 999. 999. 0 NAD-SFC NoSubs
88 3 2 62 5 -999.0 -9.000 -9.000 -9.000 -999. -999. -99999.0 0.1200 2.00 1.00 0.00 0.0 6.1 258.8 2.0 0 -9.00 999. 999. 0 NAD-SFC NoSubs
88 3 2 62 6 -999.0 -9.000 -9.000 -9.000 -999. -999. -99999.0 0.1200 2.00 1.00 0.00 0.0 6.1 257.5 2.0 0 -9.00 999. 999. 0 NAD-SFC NoSubs
88 3 2 62 7 -999.0 -9.000 -9.000 -9.000 -999. -999. -99999.0 0.1200 2.00 1.00 0.00 0.0 6.1 257.5 2.0 0 -9.00 999. 999. 2 NAD-SFC NoSubs
88 3 2 62 8 -3.0 0.208 -9.000 -9.000 -999. 227. 268.5 0.1200 2.00 0.37 2.10 118.0 6.1 262.0 2.0 0 -9.00 999. 999. 0 NAD-SFC NoSubs
88 3 2 62 9 73.4 0.438 0.789 0.019 238. 696. -102.0 0.1200 2.00 0.23 4.10 163.0 6.1 264.2 2.0 0 -9.00 999. 999. 0 NAD-SFC NoSubs
88 3 2 62 10 143.1 0.651 1.127 0.010 357. 1260. -171.8 0.1200 2.00 0.18 6.20 174.0 6.1 265.9 2.0 0 -9.00 999. 1000. 5 NAD-SFC NoSubs
88 3 2 62 11 187.5 0.504 1.350 0.012 469. 881. -60.9 0.1200 2.00 0.17 4.60 147.0 6.1 267.0 2.0 0 -9.00 999. 1000. 5 NAD-SFC NoSubs
88 3 2 62 12 217.5 0.508 1.505 0.012 560. 869. -53.7 0.1200 2.00 0.16 4.60 165.0 6.1 269.2 2.0 0 -9.00 999. 1000. 1 NAD-SFC NoSubs

Figure 2-25. First 36 Hours of the Boundary Layer Parameter File, AERMET.SFC

2-59
88 3 1 1 6.1 1 275.0 3.10 -2.80 99.00 99.00
88 3 1 2 6.1 1 279.0 4.10 -2.80 99.00 99.00
88 3 1 3 6.1 1 279.0 4.10 -3.90 99.00 99.00
88 3 1 4 6.1 1 290.0 5.10 -5.00 99.00 99.00
88 3 1 5 6.1 1 290.0 5.70 -5.60 99.00 99.00
88 3 1 6 6.1 1 295.0 2.60 -5.60 99.00 99.00
88 3 1 7 6.1 1 286.0 5.10 -6.10 99.00 99.00
88 3 1 8 6.1 1 315.0 4.10 -5.60 99.00 99.00
88 3 1 9 6.1 1 273.0 7.20 -5.00 99.00 99.00
88 3 1 10 6.1 1 297.0 8.20 -5.00 99.00 99.00
88 3 1 11 6.1 1 297.0 7.70 -4.40 99.00 99.00
88 3 1 12 6.1 1 268.0 8.80 -4.40 99.00 99.00
88 3 1 13 6.1 1 271.0 9.30 -3.90 99.00 99.00
88 3 1 14 6.1 1 306.0 7.20 -3.90 99.00 99.00
88 3 1 15 6.1 1 256.0 9.30 -4.40 99.00 99.00
88 3 1 16 6.1 1 268.0 7.20 -4.40 99.00 99.00
88 3 1 17 6.1 1 270.0 8.80 -5.60 99.00 99.00
88 3 1 18 6.1 1 266.0 8.80 -7.20 99.00 99.00
88 3 1 19 6.1 1 273.0 8.80 -7.80 99.00 99.00
88 3 1 20 6.1 1 278.0 6.70 -8.90 99.00 99.00
88 3 1 21 6.1 1 285.0 6.70 -9.40 99.00 99.00
88 3 1 22 6.1 1 294.0 4.60 -10.00 99.00 99.00
88 3 1 23 6.1 1 220.0 3.10 -10.60 99.00 99.00
88 3 1 24 6.1 1 209.0 2.60 -11.70 99.00 99.00
88 3 2 1 6.1 1 289.0 1.50 -12.80 99.00 99.00
88 3 2 2 6.1 1 0.0 0.00 -13.90 99.00 99.00
88 3 2 3 6.1 1 0.0 0.00 -14.40 99.00 99.00
88 3 2 4 6.1 1 0.0 0.00 -15.00 99.00 99.00
88 3 2 5 6.1 1 0.0 0.00 -14.40 99.00 99.00
88 3 2 6 6.1 1 0.0 0.00 -15.60 99.00 99.00
88 3 2 7 6.1 1 0.0 0.00 -15.60 99.00 99.00
88 3 2 8 6.1 1 118.0 2.10 -11.10 99.00 99.00
88 3 2 9 6.1 1 163.0 4.10 -8.90 99.00 99.00
88 3 2 10 6.1 1 174.0 6.20 -7.20 99.00 99.00
88 3 2 11 6.1 1 147.0 4.60 -6.10 99.00 99.00
88 3 2 12 6.1 1 165.0 4.60 -3.90 99.00 99.00

Figure 2-26. First 36 Hours of the Profile File, AERMET.PFL

2-60
3.0 Advanced tutorial

In the example in Section 2.0, only NWS data were used to estimate the boundary layer
parameters for AERMOD. In this section, a second example is presented that introduces data
from a site-specific meteorological observation program into the data processing. This example
builds on the data that were processed in Section 2.0 - the hourly surface observations and upper
air soundings - without modification. The keywords associated with the ONSITE pathway for
Stage 1 and the related required modifications to the control files for Stage 2 and Stage 3 are
presented. At the end of this section, a short discussion on combining and separating processing
steps in Stage 1 is presented.

3.1 Example 2: site-specific data

Unlike NWS data where the data are in predefined formats and the processing is
reasonably straightforward, site-specific data do not come in a 'prepackaged' archive format and
the user must know the structure of the data, including how missing values are reported.
Processing the data becomes more complicated. Several exercises will be suggested, requiring
minimal modifications to the control files provided with this example, so the user can see the
consequence of including or excluding keywords.

The example leads the user through the steps necessary to generate the input data files
for AERMOD using both NWS and site-specific meteorological data. Before reading the
discussion of the keywords and output for this example, we recommend running AERMET to
generate the output files - the message files, the summary reports, and the meteorological data
output. For this example, it is assumed that the hourly surface and upper air data were
extracted and QA'd in the first example. The three additional steps and associated control file
names to generate the meteorological data for AERMOD are:
• QA site-specific data (Stage 1): EX2-OS.INP

3-1
 • combine the surface, upper air and site-specific data into one file (Stage 2):
EX2-MRG.INP

• process the combined data to produce the meteorological output for AERMOD
(Stage 3): EX2-ST3.INP.

The following table shows what to type at the DOS prompt for each step in this example.
These steps must be run in the order shown.

Meteorological
To: At the DOS prompt, type: input data Output
file(s) data
QA site-specific AERMET.EXE EX2-OS.INP ONSITE.MET file(s)
OSQAOUT.DSK
data
Combine data AERMET.EXE EX2-MRG.INP SFQAOUT.DSK* MERGE2.DSK
UAQAOUT.DSK*
OSQAOUT.DSK
Create AERMET.EXE EX2-ST3.INP MERGE2.DSK AERMET2.SFC
meteorological files AERMET2.PFL
for AERMOD
* - these files were generated in the first example.

3-2
 As AERMET runs, the progress is displayed on the screen. The display is described
below, after the discussion of the keywords. In addition to the output data files, each run will
produce a message file (.MSG) and report file (.RPT) file. Note: the file names and extensions
are all user-defined; i.e., there are no default names or extensions.

A reminder: 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.

3.1.1 Stage 1 - processing site-specific data

Site-specific data are assumed to be from one or more levels of an instrumented tower, a
remote sensor (e.g. sodar), or a combination of the two, and possibly with additional near-
surface data, such as insolation and net radiation. The site-specific data that will be processed in
this example come from a 100-meter meteorological tower with three levels of data - 10, 50, and
100 meters - with winds, temperature and the fluctuating components of the wind. Four new
keywords are added with this example.

There is no standard archive format or content for site-specific data and, as such, places
the format of the data completely under the control of the user. Therefore, since there is no
archive file, there is no extraction step and the data can be QA'd immediately, as shown in
Figure 3-1.

3-3
 Figure 3-1. Stage 1 Processing of the Site-specific Data

Without a standard format or content, the user must specify the file format (data
structure) in AERMET control file. The format of the site-specific data is reasonably flexible,
subject to the following rules:

1) The data for one observation period can be one or more data records, and the
records for the period must be contiguous (for this tutorial, refer to this as an
"observation group");

2) There can be up to 12 equally-spaced observation periods per hour, i.e., as

frequent as every 5 minutes (see the keyword OBS/HOUR in Section 4.0
for a discussion on how to provide AERMET with the frequency of site-
specific observations);

3) The same set of variables must appear for all observation periods but not all
the same variables must appear on every record in the observation period;

4) The date and time information for each observation must be contained in the first
record of the observation period if the observation period spans multiple records;
these may occur in any order within the first record, and must be integer format;
meteorological variables can also appear on the first record;

5) The variables present within each observation should be a subset of those listed
in Appendix B, and Table B-4 (although the user can direct AERMET to skip
fields);

3-4
 6) Single-level variables (e.g., heat flux and observed mixing heights) must be read
before any multi-level variables (e.g., winds and temperature); these two types of
variables are described below;

7) The file must be an ASCII text file and it must be in a form that can be read
using Fortran FORMAT statements. Note that AERMET supports the free
format read which simplifies how the format of the data is specified,, but all
values must be read from data records for which a free format read statement
is used (see Section 4.5.2).

Figure 3-2 shows a subset of the data for this example. There are three records for
each observation group and the data are reported once per hour. The structure and fields are
explained below under the "READ and FORMAT" heading. The connection between the
rules and the data should become clearer when the keywords used to read the data are
discussed.

1 3 88 1 0 10.0 48.7 0.110 0.64 317.50 0.80

1 3 88 1 0 50.0 14.7 -99.000 1.84 323.30 2.00
1 3 88 1 0 100.0 9.1 0.410 1.64 320.50 3.70
1 3 88 2 0 10.0 22.5 0.080 0.34 273.10 0.90
1 3 88 2 0 50.0 15.6 -99.000 1.04 304.00 1.50
1 3 88 2 0 100.0 13.4 0.340 0.74 308.50 2.50
1 3 88 3 0 10.0 63.3 0.080 -0.76 276.50 0.60
1 3 88 3 0 50.0 32.9 -99.000 0.04 331.70 1.30
1 3 88 3 0 100.0 27.0 0.390 -0.16 319.10 2.30

Figure 3-2. Subset of Site-specific Meteorological Data for Example 2

Figure 3-3 shows the control file that will be used to QA the site-specific data in this
example, and is provided in the file EX2-OS.INP. Several keywords for the ONSITE pathway
are identical to those on the SURFACE and UPPERAIR pathways. The basic requirements to
process the site-specific data are described below.

3-5
JOB Start of the JOB pathway

MESSAGES ONSITE.MSG Message file

REPORT ONSITE.RPT Summary report file

ONSITE Start of the ONSITE pathway

DATA ONSITE.MET Input file with site-

specific
meteorological data

XDATES 88/3/1 TO 88/3/10 Period of observations to QA

LOCATION 99999 74.0W 41.3N 0 115.0 Site identifier and location

QAOUT OSQAOUT.DSK Output file

READ 1 OSDY OSMO OSYR OSHR HT01 SA01 SW01 TT01 WD01 WS01 Variables to read: 1st record
of the observation

READ 2 HT02 SA02 SW02 TT02 WD02 WS02 Variables to read: 2nd record

READ 3 HT03 SA03 SW03 TT03 WD03 WS03 Variables to read: 3rd record

FORMAT 1 (4(I2,1X),4X,F5.1,1X,F5.1,1X,F7.3,1X,F6.2,1X,F7.2,1X,F7.2) Format: 1st record of

the observation

FORMAT 2 (16X,F5.1,1X,F5.1,1X,F7.3,1X,F6.2,1X,F7.2,1X,F7.2) Format: 2nd record

FORMAT 3 (16X,F5.1,1X,F5.1,1X,F7.3,1X,F6.2,1X,F7.2,1X,F7.2) Format: 3rd record

RANGE TT -30 < 40 -99 Redefine QA parameters

for temperature

RANGE SA 0 <= 95 -99 Redefine QA parameters for

σϴ

RANGE WS 0 < 50 -999 Redefine QA parameters

for wind speed

RANGE WD 0 <= 360 -999 Redefine QA parameters

for wind direction

THRESHOLD 0.3 Minimum wind speed below

which site-specific winds are
treated as calm

Figure 3-3. Control File to QA Site-specific Tower Data

3-6
3.1.1.1 JOB pathway

The JOB pathway keywords are identical to what was presented for the first example.
The messages are written to the file ONSITE.MSG and the summary report is written to the file
ONSITE.RPT.

3.1.1.2 ONSITE pathway

As with the SURFACE and UPPERAIR pathway statements, the ONSITE statement
indicates that a block of keyword statements for the ONSITE pathway are to follow. The basic
keywords to QA the site-specific data in this example are:

DATA - specifies the input file name of the raw data;

XDATES - specifies the period of time to be retrieved and QA'd from the data file;

LOCATION - specifies the station identifier, latitude and longitude, the value to
convert time to local standard time, and the station elevation in
meters;

QAOUT - specifies the output file name from the QA process; this keyword is
also used to specify the input file name to Stage 2;

READ - defines the order of the variables as they appear in the DATA file;
this keyword is repeatable up to the number of records per
observation period;

FORMAT - defines the format of the variables as they appear in the DATA file;
this keyword is repeatable;

THRESHOLD - defines the lowest allowable wind speed in the site-specific data; any
wind speeds that are less than this value are treated as calm;

RANGE - modifies the default upper and lower QA bounds as well as the
missing value indicator for the meteorological variable specified.

All of these keywords except the last one are mandatory. The order of these keywords within
the ONSITE pathway is not important. Notice that there is no EXTRACT keyword since the
data are QA'd directly from the raw data file.
3-7
DATA, LOCATION, XDATES, and QAOUT

The site-specific data are stored in a file called ONSITE.MET as shown with the DATA
keyword. A file format is not required with this keyword on the ONSITE pathway because
there is no standard archive format associated with site-specific data. The definition of the
format is provided by the user through the READ and FORMAT keywords described below.

The XDATES, LOCATION and QAOUT keywords for the ONSITE pathway are
identical in content and purpose to the same keyword for the SURFACE pathway. The only
difference of note is that the site identifier for the LOCATION keyword can be any integer
descriptor, with a maximum length of eight characters, since the content of this field is not
checked in AERMET. However, this identifier is written to one of the AERMET output files
and is, in turn, checked by AERMOD against the identifier in the AERMOD control file. Since
AERMOD reads the site identifier as an integer from the control file, the user should specify the
site identifier as an integer to avoid an error in AERMOD. In this example, the site identifier is
99999.

READ and FORMAT

The READ and FORMAT keywords, rather than a predefined format, are the keys to
reading the site-specific data. There are some rules to follow in using these two keywords:

1) For every READ keyword there must be a corresponding FORMAT keyword

in the control file;

2) The two keywords are linked through an index immediately following

the keyword to identify which data record in the observation group is
being referenced.

3) Blanks in the format specification must be avoided because AERMET

recognizes blanks as field delimiters on keywords.

4) To direct AERMET to read the data as free format (i.e., list-directed), the list-
directed format specifier, '*', cannot be used with the FORMAT keyword
Instead, the secondary keyword FREE, along with the FORMAT keyword, is
3-8
 used to direct AERMET. Every value must be read from a data record specified
as FREE format.

The READ keyword defines the variables present on each data record in the order they
are to be read from the input file. The first parameter after the READ keyword is the index
indicating the data record in the observation group the READ keyword references. The list of
variables to be read follows the index.

There are two types of site-specific meteorological variables that are recognized by
AERMET: single-level and multi-level. The single-level measurements are usually observed
near the earth's surface. Examples of single-level variables are net radiation and sensible heat
flux. Site-specific observations of mixing heights are also included in the list of single-level
measurements even though they may not be near-surface for a highly convective atmosphere.
The multi-level variables can be reported at multiple heights and can come from an
instrumented meteorological tower, a remote sensor (e.g., sodar or lidar), or any other
meteorological instrumentation that can report data at several levels in the atmosphere (e.g.,
tethered balloon). Examples of multi-level variables are temperature, wind direction, and wind
speed. Each variable is identified by a 4-character name; the allowable names are listed in
Appendix C. The complete name of multi-level variables depends on the level at which they are
observed. The first two characters identify the meteorological variable and the last two
characters are numeric and identify the level from which the data are reported. The naming
convention for multi-level variable is described in more detail in Section 4.5.2.

The format of the variables on each data record is specified on a corresponding

FORMAT keyword. This keyword contains an index number that indicates which record in the
observation group the keyword references followed by the Fortran format string used to read the
data, enclosed in parentheses. The format must comply with all the rules of syntax for
constructing a FORMAT statement, and the parentheses are mandatory. Refer to any
introductory text on Fortran programming or compiler manual for the Fortran syntax rules.
There can be a maximum of 50 data records per observation period and a maximum of 50

3-9
variables on any one data record. Remember, however, that the maximum length of a control
file record is limited to 132 characters.

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 / descriptors in the Fortran
READ statement. However, the same format used to read the original site-specific data file
is also used to write the QA file.

If some variables are skipped (using the X and T descriptors) or entire lines of data are skipped
(using the “/”), then the QA output file will contain corresponding blank fields and/or blank
lines.

Referring to Figure 3-2, three records corresponding to the three measurement levels
define the site-specific data for a single observation period. The observation period in this
example is one hour (site-specific data may contain more than one observation period per hour;
see Section 4.5.12 for a discussion of the keyword OBS/HOUR). The first data record contains
the day, month, year, hour, and minute of the observation. These fields are followed by the
observation height (meters), σ (degrees), σw (meters/second), ambient air temperature (°C),
ϴ

wind direction (degrees), and wind speed (meters/second). The second and third records contain
the same information. This structure is repeated for all hours of the data set. It is only
coincidental that the same variables are repeated for each measurement height. It is entirely
possible, and a situation that AERMET can handle, that different variables are measured at
different levels.

In this example, 10 variables are read from the first record of the observation group in Figure
3-2. In the control file, the variables corresponding to these data are defined on the READ
keyword followed by the index 1. The first four variables are the day, month, year, and hour
and are read into the integer variables OSDY, OSMO, OSYR, and OSHR, respectively (see
Table B-3 and Table B-4 for the list of valid variable names). The next six variables are σ , σw,
ϴ

temperature, wind direction, and wind speed - all at the first level. These data are read into

3-10
SA01, SW01, TT01, WD01, and WS01, respectively. These variable names consist of a 2-letter
prefix and a 2-digit suffix. The prefix identifies the variable, as defined in Table B-4, and the
suffix identifies the measurement level. This record is read with the format defined on the
FORMAT keyword that is followed by the index 1.

The second and third records of the observation period are read in a similar manner.
Note, however, that the second and third data records also contain the date and time data, but
that information is skipped by AERMET - no date variables are specified and the FORMAT
utilized '16X' to skip the first 16 columns in the data file.

With these six statements in the control file, the site-specific data format is completely
specified. If, for any reason, the data structure changes within the file, then AERMET will stop
processing data and identify where the problem was encountered.

THRESHOLD

Anemometers measuring the wind speed may not detect air movement below certain
speeds, or thresholds. These thresholds are instrument-dependent. While it is hoped that winds
reported in the raw data base have already accounted for this minimum, it is possible that speeds
less than the threshold for the instrument appear in the data. The keyword THRESHOLD is
used to define the threshold wind speed and directs AERMET to treat any site-specific wind
speeds that are below this threshold as calm winds. This is a mandatory keyword - AERMET
will not process the site-specific data without it. In this example, the threshold wind speed is
0.3 meters/second. For prognostic meteorological data, refer to the Guidance on the Use of the
Mesoscale Model Interface Program (MMIF) for AERMOD Applications (EPA, 2018), for the
appropriate threshold value to use in AERMET.

RANGE

An optional, but very useful, keyword is the RANGE keyword. This keyword can be used on
the SURFACE and UPPERAIR pathways, but is most useful on the ONSITE pathway where
3-11
indicators of missing values (e.g., -999.0) are data base dependent. AERMET has default upper
and lower bounds for the QA and missing value indicator for each variable (see Table B-3

and Table B-4). The RANGE keyword allows the user to change one or all of these values for a
variable. If AERMET is not made aware of the correct missing value indicator(s), then it will
assume the default indicator identifies the missing data and AERMET may use invalid data in a
calculation. This situation could lead to an abrupt termination of the program, such as
attempting to compute the square root of a negative number, without any indications in the
message and summary file as to what happened.

One RANGE keyword is required for each variable's QA parameters that the user wants
to modify. The parameters associated with the RANGE keyword are:

1) variable name - for multi-level variables such as temperature and wind

speed, only the first two characters are needed - the changes apply to all
measurement levels;

2) lower bound;

3) symbol indicating whether the range of valid values should include (<=)
or exclude (<) the endpoints (bounds);

4) upper bound;

5) missing value indicator.

Any or all of items 2 through 5 can be changed, but each of these parameters must appear with
the RANGE keyword. If, for example, the missing value indicator needs to be modified but the
bounds can remain the same, the default bounds for the variable defined in Table B-3 and Table
B-4 should be used with the new missing indicator specified. This situation is exactly why this
keyword had to be included in this example. Several of the QA bounds also were changed.
Compare the parameters on the RANGE keywords to the values in Table B-4 and then examine
the data for March 1, 1988, hour 11 in the file ONSITE.MET.

3-12
 There are two optional keywords available for the ONSITE pathway that perform the
same function as on the SURFACE and UPPERAIR pathways. These are:

AUDIT - adds variables to the list of variables to be tracked and reported during
QA;
NO_MISSING - suppresses the message that data are missing for variables being audited
during the QA process; this keyword is useful in reducing the size of the
message file if an audited variable is missing most of the time.

Additional optional keywords specific to the ONSITE pathway include:

DELTA_TEMP - defines the height(s), in meters, for temperature difference data, if it exists
in the data base;

OSHEIGHTS - defines the heights of the site-specific measurements; this keyword is

needed if the heights are not included on each of the multi-level data
records or not on the READ keywords;

OBS/HOUR - number of observation periods per hour; required only if the number of
periods exceeds 1/hour;

All the keywords are discussed in detail in Section 4.0, and a synopsis of each is
provided in Appendix A.

3.1.2 Running Stage 1 and reviewing the output

To run Stage 1 to QA the site-specific meteorological data, the following command line
is used:

3-13
 AERMET EX2-OS.INP

where EX2-OS.INP is the example control file name.

Figure 3-4 shows a portion of the messages that result from running EX2-OS.INP. All
the QA messages were the same, so the middle section was omitted. The 'standard' end of file
and processing that was not performed precede the QA messages. These messages show how
the QA violations of the multi-level data are reported.

JOB I19 SETUP : "END OF FILE" ON UNIT 5 AFTER RECORD # 38

JOB I25 TEST : SUMMARY: NO DATA EXTRACTION FOR UPPERAIR
JOB I25 TEST : SUMMARY: NO DATA QA FOR UPPERAIR
JOB I26 TEST : SUMMARY: NO DATA EXTRACTION FOR SURFACE
JOB I26 TEST : SUMMARY: NO DATA QA FOR SURFACE
JOB I27 OSTEST : Minimum and maximum ONSITE height level indices
derived from data file are: 1 3
880301 ONSITE Q59 OSQACK : TT missing for HR: 11; LEVEL : 1
880301 ONSITE Q59 OSQACK : TT missing for HR: 11; LEVEL : 2
880301 ONSITE Q59 OSQACK : TT missing for HR: 11; LEVEL : 3
880301 ONSITE Q59 OSQACK : WD missing for HR: 11; LEVEL : 1
880301 ONSITE Q59 OSQACK : WD missing for HR: 11; LEVEL : 2
880301 ONSITE Q59 OSQACK : WD missing for HR: 11; LEVEL : 3
880301 ONSITE Q59 OSQACK : WS missing for HR: 11; LEVEL : 1
880301 ONSITE Q59 OSQACK : WS missing for HR: 11; LEVEL : 2
880301 ONSITE Q59 OSQACK : WS missing for HR: 11; LEVEL : 3
. . . .
. . . .
. . . .

880308 ONSITE Q59 OSQACK : TT missing for HR: 10; LEVEL : 1

880308 ONSITE Q59 OSQACK : TT missing for HR: 10; LEVEL : 2
880308 ONSITE Q59 OSQACK : TT missing for HR: 10; LEVEL : 3
880308 ONSITE Q59 OSQACK : WD missing for HR: 10; LEVEL : 1
880308 ONSITE Q59 OSQACK : WD missing for HR: 10; LEVEL : 2
880308 ONSITE Q59 OSQACK : WD missing for HR: 10; LEVEL : 3
880308 ONSITE Q59 OSQACK : WS missing for HR: 10; LEVEL : 1
880308 ONSITE Q59 OSQACK : WS missing for HR: 10; LEVEL : 2
880308 ONSITE Q59 OSQACK : WS missing for HR: 10; LEVEL : 3

Figure 3-4. Portion of the Message File from Site-specific Data QA

The QA messages contain the following information:

Field 1: the observation date

Field 2: the pathway
Field 3: the message code
Field 4: the subroutine that issued the message
3-14
 Field 5: the message which includes:
• the variable in question: TT = temperature, WD = wind direction, and WS = wind
speed

• the problem: data are missing for the hour with the level indicated.

Figure 3-5 through Figure 3-8 show the summary report associated with running
EX2-OS.INP. For the most part, the summary for the site-specific should look familiar to the
summaries from the SURFACE and UPPERAIR processing except that only the site-specific
data section contains processing information.

The second page (Figure 3-6) shows the QA summary table. Only temperature, wind
speed, and wind direction are automatically QA'd, which are multi-level variables. No
additional variables were specified with the AUDIT keyword for QA. The summary is reported
by level and by variable within the level. Recall that 10 days were processed for a total of 240
hours. The "% accepted" exceeds 98% for all variables, except for temperature at the 50-meter
level. The 41 reported missing values may cause the user to check the data to insure the data are
really missing. Unlike the QA for hourly surface and upper air data, the "Test Values" at the
right of the table are not multiplied by any factors.

The third page of the summary report (Figure 3-7) shows some of the important
parameters that will also be used in the processing including the threshold wind speed. The
'Heights for multi-level data' shows the heights at which the site-specific data measurements
were observed, but only if the OSHEIGHTS keyword was used. Otherwise, the heights are
shown as 0.0.

Note that on the message summary table on the fourth page (Figure 3-8) there were 62
QA messages in the 50-59 range. Examining the message file, we see that all the missing data
messages had the message code 'Q59', which were categorized into the 50-59 range.

Once the user is satisfied that there is nothing unusual in the data, the ONSITE data are
ready to merge with the data from the SURFACE and UPPERAIR pathways.

3-15
 AERMET, A Meteorological Processor for the AERMOD Dispersion Model
Version 15181

Data Processed on 17-JUN-2016 at 11:37:50

Stage 1 Page 1

********************************************************
*** AERMET Setup Finished Successfully ***
********************************************************

1. Job File Names

Listing of Messages: ONSITE.MSG

Summary (this file): ONSITE.RPT

2. Upper Air Data

AERMET Has Determined That Processing For This Pathway Includes:

NONE, NO DATA TO BE PROCESSED ON THIS PATH

3. NWS Surface Data

AERMET Has Determined That Processing For This Pathway Includes:

NONE, NO DATA TO BE PROCESSED ON THIS PATH

4. On-site Data

Site ID Latitude(deg.) Longitude(deg.) Time Adjustment Elev. (m)

99999 41.3N 74.0W 0 115.0

AERMET Has Determined That Processing For This Pathway Includes:

QUALITY ASSESSMENT ONLY

Extract Output- OPEN: ONSITE.MET

QA Output - OPEN: OSQAOUT.DSK

The Extract Dates Are: Starting: 1-MAR-1988

Ending: 10-MAR-1988

Figure 3-5. First Page of the Summary File for the Site-specific Data QA

3-16
 AERMET, A Meteorological Processor for the AERMOD Dispersion Model
Version 15181

Data Processed on 17-JUN-2016 at 12:16:24

Stage 1 Page 2

********************************************************
*** AERMET Data Processing Finished Successfully ***
********************************************************

**** SUMMARY OF THE QA AUDIT ****

THERE IS NO AUDIT TRAIL FOR SITE SCALARS

SITE VECTORS |------VIOLATION SUMMARY------| |-----TEST VALUES-----|

TOTAL # LOWER UPPER % MISSING LOWER UPPER
# OBS MISSING BOUND BOUND ACCEPTED FLAG BOUND BOUND
10.00 M
TT 240 2 0 0 99.17 -99.0, -30.0, 40.0
WD 240 4 0 0 98.33 -999.0, 0.0, 360.0
WS 240 4 0 0 98.33 -999.0, 0.0, 50.0
50.00 M
TT 240 41 0 0 82.92 -99.0, -30.0, 40.0
WD 240 3 0 0 98.75 -999.0, 0.0, 360.0
WS 240 2 0 0 99.17 -999.0, 0.0, 50.0
100.00 M
TT 240 2 0 0 99.17 -99.0, -30.0, 40.0
WD 240 2 0 0 99.17 -999.0, 0.0, 360.0
WS 240 2 0 0 99.17 -999.0, 0.0, 50.0

THIS CONCLUDES THE AUDIT TRAIL

Figure 3-6. Second Page of the Summary File for the Site-specific Data QA

3-17
 Version 15181

Data Processed on 17-JUN-2016 at 12:16:24

Stage 1 Page 3

THE FOLLOWING ON-SITE VALUES ARE IN EFFECT

Number of OBS/HOUR:

Threshold wind speed (m/s):

0.30

Heights for tower data (m), based on HTnn fields in data file:

10.00 50.00 100.00

Figure 3-7. Third Page of the Summary File for the Site-specific Data QA

3-18
 AERMET, A Meteorological Processor for the AERMOD Dispersion Model
Version 15181

Data Processed on 17-JUN-2016 at 12:16:24

Stage 1 Page 4

********************************************************
*** AERMET Data Processing Finished Successfully ***
********************************************************

EXTRACT AND/OR QA THE METEOROLOGICAL DATA

**** AERMET MESSAGE SUMMARY TABLE ****

0- 9 10-19 20-29 30-39 40-49 50-59 60-69 70-89 TOTAL

------------------------------------------------------------------------

JOB
E 0 0 0 0 0 0 0 0 0
W 0 0 0 0 0 0 0 0 0
I 0 1 5 0 0 0 0 0 6

ONSITE
E 0 0 0 0 0 0 0 0 0
W 0 0 0 0 0 0 0 0 0
I 0 0 0 0 0 0 0 0 0
Q 0 0 0 0 0 62 0 0 62
------------------------------------------------------------------------
0 1 5 0 0 62 0 0 68

**** ERROR MESSAGES ****

--- NONE ---

**** WARNING MESSAGES ****

--- NONE ---

Figure 3-8. Fourth Page of the Summary File for the Site-specific Data QA

3-19
EXERCISE:

Remove or comment out (by placing asterisks in the first two columns, **) the RANGE
keywords in EX2-OS.INP and rerun the QA for the site-specific data. Review the message file
and note that the 'missing data' messages have been replaced with 'lower bound' violations.
Why did the messages change? Examine the QA summary table - a similar changed occurred
there, too.

EXERCISE:

Reactivate the RANGE keywords by removing the asterisks that were inserted for the previous
exercise. Then, add the following to the ONSITE pathway in the control file: NO_MISSING
TT and rerun the QA for the site-specific data. Notice that the message file is much shorter and
the number of QA messages reported in the message summary table (as in Figure 3-8) is less.
The NO_MISSING keyword suppressed all QA messages and tallying that related to
temperature.

3-20
3.1.3 Stage 2 - merging data

Since the hourly surface observations and upper air data that were processed in Stage 1
in the first example are to be used in this example, the three QA'd data files are ready for
Stage 2. Figure 3-9 shows the processing flow associated with Stage 2 and Figure 3-10 shows
the control file, which is provided in EX2-MRG.INP.

Figure 3-9. Stage 2 Processing that Merges the Surface Observations, Soundings,
and Site-specific Data into a Single File

The only differences to note between this control file and the Stage 2 control file for
Example 1 (Figure 2-14) is the inclusion of the ONSITE pathway. The output file generated in
the Stage 1 QA of site-specific data, OSQAOUT.DSK, is specified with the QAOUT keyword.
Also note that the file names associated with the keywords on the JOB pathway and the
MERGE output were changed so as to not overwrite any of the files generated in the first
example.

3-21
 JOB Start of JOB pathway

REPORT MERGE-2.RPT Report file

MESSAGES MERGE-2.MSG Message file

UPPERAIR Start of UPPERAIR pathway

QAOUT UAQAOUT.DSK UPPERAIR input file to Stage 2

SURFACE Start of SURFACE pathway

QAOUT SFQAOUT.DSK SURFACE input file to Stage 2

ONSITE Start of ONSITE pathway

QAOUT OSQAOUT.DSK ONSITE input file to Stage 2

MERGE Start of MERGE pathway

OUTPUT MERGE2.DSK Output of merged meteorological data

XDATES 88/03/01 88/03/04 Period of observations to merge

Figure 3-10. Control File to Merge NWS Upper Air, Surface Data,
and Site-specific Data in to a Single File

To run Stage 2 to merge the three files of meteorological data, the following command
line is used:

AERMET EX2-MRG.INP

The message file is similar to the one generated in Example 1, so it is not shown here.

The summary report is also very similar and only the second page is shown (Figure
3-11). The only item to note is the number of site-specific observations merged each day.
Rather than zero as we had in Example 1, the data base now includes 24 site-specific
observation periods per day.

3-22
 AERMET, A Meteorological Processor for the AERMOD Dispersion Model
Version 15181

Data Processed on 17-JUN-2016 at 12:16:24

Stage 2 Page 2

Merging the Meteorological Data

The Merged Dates Are: Starting: 1-MAR-1988

Ending: 4-MAR-1988

***** Daily Output Statistics *****

1988 MO/DY: 3/ 1 3/ 2 3/ 3 3/ 4
NWS Upper Air Sdgs 2 4 4 4
NWS Sfc Observations 24 24 24 24
On-site Observations 24 24 24 24
Ave 1-min ASOS Winds 0 0 0 0

TOTAL OBSERVATIONS READ:

Upper Air Soundings : 9
NWS Sfc Observations: 98
On-site Observations: 97
1-min ASOS Wind Data: 0

***** MERGE PROCESS COMPLETED *****

Figure 3-11. Second Page of the Summary File

3-23
3.1.4 Stage 3 - estimating boundary layer parameters for AERMOD

With all the meteorological data merged into one file, Stage 3 can be run to generate the
two input files for AERMOD, as shown in Figure 3-12.

Figure 3-12. Stage 3 Processing Using the Merged NWS and Site-specific Data to Create
the Input Meteorology for AERMOD

The input control file for this example, shown in Figure 3-13, is nearly identical to the
control file for Example 1 with the exception of the file names and the surface characteristics.

3-24
JOB Start of the JOB pathway

REPORT STAGE3-2.RPT File for all messages

MESSAGES STAGE3-2.MSG File for the run summary

METPREP Start of the METPREP pathway

DATA MERGE2.DSK Input meteorological data file from Stage 2

METHOD REFLEVEL SUBNWS Processing method: allow substitution of NWS data

METHOD WIND_DIR RANDOM Processing method: randomize NWS wind directions

NWS_HGT WIND 6.1 NWS wind measurement height

OUTPUT AERMET2.SFC Output file with boundary layer parameters

PROFILE AERMET2.PFL Output file with profile data

FREQ_SECT MONTHLY 2 Frequency and number of wind direction sectors to

define the site characteristics for site-specific
observations (primary site)

SECTOR 1 35 225 Definition of 1st wind sector for site-specific

observations (primary site)

SECTOR 2 225 35 Definition of 2nd wind sector for site-specific

observations (primary site)

Onsite (primary site) Surface characteristics:

SITE_CHAR 1 1 0.350 0.800 0.300 January, sector 1
SITE_CHAR 2 1 0.350 0.800 0.300 February, sector 1
SITE_CHAR 3 1 0.350 0.800 0.300 .
SITE_CHAR 4 1 0.250 0.400 0.500 .
SITE_CHAR 5 1 0.250 0.400 0.500 .
SITE_CHAR 6 1 0.120 0.200 0.700 .
SITE_CHAR 7 1 0.120 0.200 0.700 .
SITE_CHAR 8 1 0.120 0.200 0.700 .
SITE_CHAR 9 1 0.200 0.600 0.500 .
SITE_CHAR 10 1 0.200 0.600 0.500 .
SITE_CHAR 11 1 0.200 0.600 0.500 November, sector 1
SITE_CHAR 12 1 0.350 0.800 0.300 December, sector 1
SITE_CHAR 1 2 0.500 1.500 0.750 January, sector 2
SITE_CHAR 2 2 0.500 1.500 0.750 February, sector 2
SITE_CHAR 3 2 0.500 1.500 0.750 .
SITE_CHAR 4 2 0.250 0.700 1.000 .
SITE_CHAR 5 2 0.250 0.700 1.000 .
SITE_CHAR 6 2 0.150 0.300 1.500 .
SITE_CHAR 7 2 0.150 0.300 1.500 .
SITE_CHAR 8 2 0.150 0.300 1.500 .
SITE_CHAR 9 2 0.200 1.000 1.250 .
SITE_CHAR 10 2 0.200 1.000 1.250 .
SITE_CHAR 11 2 0.200 1.000 1.250 November, sector 2
SITE_CHAR 12 2 0.500 1.500 0.750 December, sector 2

FREQ_SECT2 ANNUAL 1 Frequency and number of wind direction sectors to

define the site characteristics for NWS surface
observations (secondary site)

SECTOR2 1 0 360 Definition of wind direction sectors for NWS surface

observations (secondary site)

SITE_CHAR2 1 1 0.15 2.00 0.12 Definition of site characteristics by period

and wind direction sector for NWS surface
observations (secondary site)

Figure 3-13. Stage 3 Control File

3-25
 In Example 1, the location where NWS surface data were collected, the tower at the
airport, was designated as the primary site since site-specific data were not used in Example 1.
In this example (Example 2), the surface characteristics for the airport were retained but
reassigned as the secondary site as indicated by the keywords FREQ_SECT2, SECTOR2, and
SITE_CHAR2. As in Example 1, SUBNWS is specified which means NWS wind data from the
airport will be substituted for hours when the site-specific wind data are missing. The location
where the site-specific data were collected was designated as the primary site and site
characteristics are specified MONTHLY for two unique wind direction sectors, as indicated
with the FREQ_SECT, SECTOR, and SITE_CHAR keywords. Note that there are 24 records
with the SITE_CHAR keyword defining the surface characteristics – one record for each
combination of month and sector.

The site-specific sectors defined for this example are 35°-225° and 225°-35°. Notice
that the second sector crosses through north (360°). AERMET checks to make sure that the end
point of one sector matches the start point of the next sector, and also compares the end point of
the last sector with the start point of the first sector. These checks insure that surface
characteristics are specified for all wind directions.

The SITE_CHAR (and SITE_CHAR2) keyword is followed by the period indices based
on the period defined with the FREQ_SECT (and FREQ_SECT2) keyword, and the sector
indices as defined with the SECTOR (and SECTOR2) keyword. Since MONTHLY was
specified as the period for the primary site, the period indices range from 1 to 12 which
represent January to December, respectively. In this example, the albedo ranges from 0.12 in
the summer when trees are in full leaf to 0.500 in winter when there is likely to be snow on the
ground, the Bowen ratio ranges from 0.2 in the summer when the flow is mostly over water east
of the site to 1.5 in the winter when the flow is over the hillier terrain to the west, and the
roughness length ranges from 0.3 meters in the winter when the flow is mostly over water to 1.5
meters in the summer when the flow is over the fully-leafed hills west of the site.

3-26
 For each hour, AERMET attempts to locate a level of wind speed and direction from the
site-specific measurements to define the surface characteristics. This level is defined as the
lowest level with a nonmissing wind speed and direction between 7z0 and 100 meters
(inclusive), where z0 is the surface roughness length. If the only valid nonmissing wind speed is
a calm wind, then the hour is treated as a calm and the reference level is the lowest level of
nonmissing wind.

If there is no valid reference wind, then the lowest level is treated as the reference level
and the reference wind is missing. However, if the option to substitute NWS data is specified in
the control file (see Section 4.7.6 for the keyword METHOD, secondary keyword REFLEVEL),
then AERMET will substitute the NWS hourly wind speed observations for the reference wind
speed and use the height specified with the keyword NWS_HGT (see Section 4.7.4) as the
reference height. If NWS substitution is not specified, then the reference wind will be missing.

The selection of the reference temperature is independent of the selection of the

reference wind. A valid reference temperature is defined as the lowest level with a non-missing
temperature between z0 and 100 meters (inclusive). If there is no valid reference temperature in
the site-specific data and the option to substitute NWS data is specified in the control file, then
AERMET will substitute the NWS hourly ambient temperature for the reference temperature.

To generate the two files of meteorological data for AERMOD, Stage 3 is run with
the following command line:

AERMET EX2-ST3.INP

The message file that is created from this run is shown in Figure 3-14. There are several
new messages that were not seen in Example 1. None of the message were fatal to the data
processing, but serve as a way of making the user aware of some possible unusual conditions.

The first, and most frequent, of these messages in this example is the "REF WIND
FROM PROFILE BELOW 20*Z0." When site-specific data are included in the data base, the
3-27
definition of the reference height wind speed and direction are subject to the restrictions noted
above. When the reference height for wind is below 20z0, then AERMET writes this warning.
Record 13 in the message file indicates that AERMET could not locate site-specific data that
satisfy these criteria and that NWS wind speed and direction were substituted. The presence of
the METHOD keyword and secondary keyword REFLEVEL with the parameter SUBNWS
included in the control file (Figure 3-13) directed AERMET to make the substitution. Recall
that all the site-specific data were missing for hour 11 on March 1, hence this message is
appropriate. A little further down in the message file, there is a more explicit message that states
NWS data (meaning wind and temperature) were substituted for onsite data. Of course, the
substitutions are subject to the NWS data not being missing for the hour.

3-28
 JOB I19 SETUP : "END OF FILE" ON UNIT 5 AFTER RECORD # 59
JOB I27 OSTEST : Minimum and maximum ONSITE height level indices
derived from data file are: 1 3
METPREP I41 FNDCOMDT: ASOS commission date FOUND for WBAN = 14735;
CALL4 = KALB; CALL3 = ALB; CommDate = 19950801
880301 METPREP I80 SUBST : Ref level for wind below 20*Z0 for hour: 01
880301 METPREP I80 SUBST : Ref level for wind below 20*Z0 for hour: 02
880301 METPREP I80 SUBST : Ref level for wind below 20*Z0 for hour: 03
880301 METPREP I80 SUBST : Ref level for wind below 20*Z0 for hour: 05
880301 METPREP I80 SUBST : Ref level for wind below 20*Z0 for hour: 06
880301 METPREP I80 SUBST : Ref level for wind below 20*Z0 for hour: 07
880301 METPREP I80 SUBST : Ref level for wind below 20*Z0 for hour: 08
880301 METPREP I80 SUBST : Ref level for wind below 20*Z0 for hour: 09
880301 METPREP I80 SUBST : Ref level for wind below 20*Z0 for hour: 10
880301 METPREP I81 SUBST : NWS winds used as reference wind for hour: 11
880301 METPREP I80 SUBST : Ref level for wind below 20*Z0 for hour: 12
.
.
.
880301 METPREP I80 SUBST : Ref level for wind below 20*Z0 for hour: 23
880301 METPREP I80 SUBST : Ref level for wind below 20*Z0 for hour: 24
880301 METPREP I84 MPPBL : Upper air sounding selected for this day: 12 Z
880301 METPREP I84 MPPBL : UAID = 1 for HR: 7 LST
880301 METPREP I71 MPOUT : NWS data subst'd for ONSITE profile at HR: 11
880302 METPREP I80 SUBST : Ref level for wind below 20*Z0 for hour: 01
880302 METPREP I80 SUBST : Ref level for wind below 20*Z0 for hour: 02
.
.
.
880304 METPREP I80 SUBST : Ref level for wind below 20*Z0 for hour: 12
880304 METPREP I80 SUBST : Ref level for wind below 20*Z0 for hour: 13
880304 METPREP I80 SUBST : Ref level for wind below 20*Z0 for hour: 14
880304 METPREP I80 SUBST : Ref level for wind below 20*Z0 for hour: 15
880304 METPREP I80 SUBST : Ref level for wind below 20*Z0 for hour: 16
880304 METPREP I80 SUBST : Ref level for wind below 20*Z0 for hour: 17
880304 METPREP I80 SUBST : Ref level for wind below 20*Z0 for hour: 18
880304 METPREP I80 SUBST : Ref level for wind below 20*Z0 for hour: 19
880304 METPREP I80 SUBST : Ref level for wind below 20*Z0 for hour: 20
880304 METPREP I80 SUBST : Ref level for wind below 20*Z0 for hour: 21
880304 METPREP I80 SUBST : Ref level for wind below 20*Z0 for hour: 22
880304 METPREP I80 SUBST : Ref level for wind below 20*Z0 for hour: 23
880304 METPREP I80 SUBST : Ref level for wind below 20*Z0 for hour: 24
880304 METPREP I84 MPPBL : Upper air sounding selected for this day: 12 Z
880304 METPREP I84 MPPBL : UAID = 3 for HR: 7 LST
4 METPREP I79 FETCH : EOF reached on input data file after 000000

Figure 3-14. Message File from Stage 3 (partial)

3-29
 The summary report file is identical in nature to the summary report for Stage 3 in
Example 1. Rather than keep repeating the same or similar information about the report file, the
user is left to compare the two Stage 3 report files from Examples 1 and 2.

EXERCISE:

How are the report files from Stage 3 in Examples 1 and 2 different? What are the similarities?

EXERCISE:

Remove or comment out (by placing two asterisks in columns 1 and 2) the METHOD
REFLEVEL SUBNWS record in EX2-ST3.INP and rerun Stage 3 (change the output file names
so the different runs can be compared). Are the NWS data substitution messages still present?
Compare the boundary layer parameter output files - how have the results changed for March 1,
hour 11?

EXERCISE:

In any of the control files that have been presented in Section 2.0 and Section 3.0, add the
CHK_SYNTAX keyword to the JOB pathway and rerun the appropriate program (STAGE1N2
or STAGE3). What is displayed on screen? What are the contents of the output files?

Note: even if the only activity is to check the control file syntax, AERMET still opens files, so it
is possible that some zero-byte files will appear or files only with header records will appear. It
is best to delete these files before running AERMET without the CHK_SYNTAX keyword.

3-30
3.2 Combining or separating processing steps

These examples required several separate runs to generate the boundary layer
parameters. However, several steps in Stage 1 can be combined to reduce the number of times
the programs must be run, but AERMET always requires a minimum of three separate steps to
process the data - one step for each stage of processing.

One example of combining steps was used throughout the tutorial - the extract and QA
of data was performed in one run. Another way to combine steps is to extract and QA all
available data types - hourly surface observations, upper air data, and site-specific data - in one
run. It is really a concatenation of several of the control files above, but with one JOB pathway
rather than three. The advantage to this procedure is in minimizing the number of input control
files and the time spent in running Stage 1. The disadvantage is that an error in one data type
stops the processing. Any data type(s) processed prior to the error would be completed
successfully; the data type in which the error occurred is partially completed; and data type(s)
that are to be processed subsequent to the error are not processed.

3-31
 JOB
MESSAGES ANYNAME.MSG
REPORT ANYNAME.RPT

SURFACE
DATA S1473588.144 CD144
EXTRACT SFCEXOUT.DSK
XDATES 88/3/1 TO 88/03/10
LOCATION 14735 42.75N 73.8W 0 83.8
QAOUT SFQAOUT.DSK

UPPERAIR
DATA 14735-88.UA 6201FB
EXTRACT UAEXOUT.DSK
XDATES 88/3/1 TO 88/3/10
LOCATION 00014735 73.8W 42.75N 5
QAOUT UAQAOUT.DSK
AUDIT UATT UAWS UALR

ONSITE
DATA ONSITE.MET
XDATES 88/3/1 TO 88/3/10
LOCATION 99999 74.0W 41.3N 0 115.0
QAOUT OSQAOUT.DSK
READ 1 OSDY OSMO OSYR OSHR HT01 SA01 SW01 TT01 WD01 WS01
READ 2 HT02 SA02 SW02 TT02 WD02 WS02
READ 3 HT03 SA03 SW03 TT03 WD03 WS03
FORMAT 1 (4(I2,1X),4X,F5.1,1X,F5.1,1X,F7.3,1X,F6.2,1X,F7.2,1X,F7.2)
FORMAT 2 (16X,F5.1,1X,F5.1,1X,F7.3,1X,F6.2,1X,F7.2,1X,F7.2)
FORMAT 3 (16X,F5.1,1X,F5.1,1X,F7.3,1X,F6.2,1X,F7.2,1X,F7.2)
RANGE TT -30 < 40 -99
RANGE SA 0 <= 95 -99
RANGE WS 0 < 50 -999
RANGE WD 0 <= 360 -999
THRESHOLD 0.3

Figure 3-15. Control File to Extract and QA All Data Types in One Run

Another alternative in Stage 1 is to perform the extraction and QA separately, increasing

the number of times AERMET is run to complete Stage 1. This can be done for the UPPERAIR
and SURFACE pathways. There is only one step for the ONSITE pathway since the data can
only be QA'd. This could be useful if the data are likely to be QA'd more than once. The
combinations of the keywords DATA, EXTRACT, and QAOUT direct AERMET on how to
process the data, as follows:

3-32
 DATA EXTRACT
& QAOUT
& → extract and QA
DATA EXTRACT
& → extract
DATA EXTRACT QAOUT
& → QA (UPPERAIR and SURFACE)

DATA & QAOUT → QA (ONSITE only)

For example, in EX1-SF.INP, remove or comment out the line

QAOUT SFQAOUT.DSK

and run AERMET. The SURFACE data are extracted but not QA'd. To QA the data, a new
control file has to be constructed. This new control file will have a JOB pathway and a pathway
for the SURFACE data. For example, the following control file might be used:

JOB
MESSAGES QAONLY.MSG
REPORT QAONLY.MSG
SURFACE
EXTRACT SFEXOUT.DSK
QAOUT SFQAOUT2.DSK

Try running this control file and comparing the resulting message and summary report files with
the ones generated using EX1-SF.INP. Also compare the output files (notice that the name was
changed here so as not to overwrite the one created with EX1-SF.INP - AERMET will not
warn you if a file is being overwritten!). Note here that no blank lines were used and
keywords are not indented in the control file. AERMET reads this control file without any
problem, but the user might have a more difficult time.

3-33
4.0 Keyword reference

This section provides a detailed reference for all the keywords available in AERMET,
expanding the discussion of the keywords presented in Section 2.0 and Section 3.0 presenting
additional keywords that were not used or mentioned. The discussion in this section assumes
that the reader has a basic understanding of the pathway, keyword and parameter approach.
Novice users should review Section 2.1 to obtain a basic knowledge of the approach.

The information in this section is organized by pathway, with the more commonly used
keywords for that pathway discussed first. The syntax for each keyword is provided using
dummy parameter names. The keyword types - mandatory or optional, repeatable or
nonrepeatable, and reprocessed - are specified. The definition of these terms is discussed below.
Additionally, any special requirements, such as the order within the pathway, are specified.

4.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 and 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 merge. While data QA is
optional in Stage 1, the keyword is mandatory if the data for the pathway are to be merged in
Stage 2. A distinction will be made when the keyword type may be ambiguous. For the
discussions in Sections 4.2 - 4.5, the stages to which the keyword refers 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 or not 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
4-1
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). 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 to merge.

When AERMET processes meteorological data in Stage 1 and Stage 2, output records
used to control the preprocessor's actions are written at the top of the output file(s). These
records are referred to as header records. Special symbols are added at the beginning of some of
these records that direct AERMET to reprocess the header record when it is read from the data
file, i.e., the headers are read and processed as if they had been included as a part of the current
control file. If a keyword can be reprocessed, then the keyword type includes the term
"reprocessed". By allowing AERMET to reprocess a header record, the user does not have to
specify certain keywords for subsequent runs. The best example of this is for the ONSITE
pathway on which the user must specify the structure of the data. Specify them once and
AERMET will use the information to read the data in subsequent runs.

→ The output files specified in the control files are created and/or opened and the
header records are written to the file(s). If a run should generate a setup error,
subsequent runs after the error is corrected may reintroduce the error (due to
header reprocessing). Therefore, if a run generates an error, it is
recommended that the user delete the output files before rerunning AERMET.

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 uppercase 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.

4-2
 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.

4.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 the particular run.

4.2.1 Messages from AERMET - 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 2.0 and Section 3.0 and in Appendix D. This keyword is
mandatory because the program later interrogates 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 96 characters.

4.2.2 Run summary - REPORT

At the conclusion of a run, AERMET interrogates the file of messages, tabulates the
different types of messages (errors, warnings, etc...), and summarizes all the actions for that
particular run in a file specified with the REPORT keyword. The contents of a run summary are
4-3
discussed throughout the tutorial in Section 2.0 and Section 3.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 96 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 2.0).

4.2.3 Checking the control file for errors - 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 actually processing data. WARNING: AERMET opens all output files and writes the header
records to those files, overwriting any data in the file if the file existed. The syntax and type of
the CHK_SYNTAX keyword are:

Syntax: CHK_SYNTAX
Type: Optional (All), Nonrepeatable

No parameters accompany this keyword.

4-4
 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 each page in the file:

********************************************************
*** THIS RUN ONLY CHECKS THE RUNSTREAM SETUP ***
********************************************************

The message also appears on the screen at the conclusion of a run that only checks the syntax.

4.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 (particularly important)
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.

4.3.1 Retrieving archived data - 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 for AERMET. The syntax and type for the DATA keyword are:

Syntax: DATA archive_filename file_format [ASOS]

Type: Mandatory (Stage 1), Nonrepeatable

4-5
The archive_filename must conform to the naming conventions appropriate to the computing
platform. The maximum length of the archive_filename is 96 characters.

For processing archive data on a PC, the file_format must be specified as one of the
following: CD144, SCRAM, SAMSON, 3280VB, 3280FB, HUSWO, or ISHD. Each of these
formats is discussed in more detail below. 3280VB and 3280FB are based on the TD-3280
format, which was originally stored on magnetic tape. AERMET could read the format as it
was extracted from the tape. The last two characters, 'VB' and 'FB' refer to 'variable block' and
'fixed block' which is related to the data structure of each record.

Beginning with version 11059, AERMET includes a table of ASOS commissions 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 notes (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
4.7.6.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.

4-6
4.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 on the 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 station pressure for some of its computations (e.g., density of air). The
SCRAM format does not include station pressure and sea level pressure in 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 the 00 - 23
clock. Hour 00 is hour 24 of the previous day. Thus, when data are retrieved from an archive
file for a specific time period, the first hour is discarded since it is 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.

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.
4-7
 Overpunch CD-144 CD-144 element
position(s)
1-3 columns14-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 point < 1st
0) digit of wind speed (X|speed
10 47 >100 kt)Sign of the dry bulb (X | dry bulb
11 50 < 0) Sign of the wet bulb (X | wet bulb <
12 56 0) 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.

4.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 the NCEI, 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.

4-8
 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
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 of these 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 time 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.

4-9
4.3.2 Saving dearchived data - 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

Type: Mandatory (Stage 1), Nonrepeatable

The extracted_data_filename must conform to the naming conventions appropriate to the

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

4.3.3 Extracting a subset of the data - 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:

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

Type: Mandatory (Stage 1), Nonrepeatable

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. The "/" is required between
each field, and there cannot be any spaces within a date group because the space is used as a
delimiter between parameter fields. The year can be entered as either a two-digit or four-digit
integer (e.g., 1992 or 92). 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 word "TO" is optional
and only serves to make the statement a little more readable. It is ignored by AERMET when
this keyword is processed.

4-10
4.3.4 Identifying the station - 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. 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 is read as a type character and not an integer. However, 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 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: an N or S with the
latitude and W or E with the longitude. For example, "38.4N 81.9W" would be interpreted the
same as "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 NWS latitude and longitude on the
SURFACE pathway are not used for any purpose at this time. They are simply another way to
identify the NWS station being processed.

4-11
 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, tadjust should be
specified as a positive number. With the exception of 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, with the exception of 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 because it will be
used in the substitution hierarchy for missing station pressure (see Section 5.6).

4.3.5 How good are the data? - 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
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:

Syntax: QAOUT qa_output_filename

Optional (Stage 1), Nonrepeatable
Type: Mandatory (Stage 2) if there are data to merge,
Nonrepeatable

The qa_output_filename must conform to the naming conventions appropriate to the computing
platform. The maximum length of this file name is 48 characters. For one year of data, the size
of the output file is approximately 1.3 Mb.

4-12
 Quality assessment is an optional process and the user does not have to perform a QA
prior to merging the data. However, this step is recommended to identify possible errors in the
data that are used to derive the boundary layer parameters.

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 violation, and the date and time of the meteorological record where the violation
occurred. The date is reported in the first field in 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 on 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 any
regulatory guidance, either retain or replace the value 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 through the use of the RANGE
keyword, as described below. Also, the user can QA additional weather elements by using the
AUDIT keyword.

4-13
4.3.6 Adding weather elements to the QA - AUDIT

As mentioned in the previous section, there are only three weather elements that are
tracked by default during a 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:

Syntax: AUDIT sfname1 ... sfnamen

Type: Optional (Stage 1), Repeatable

where sfname1, ..., sfnamen are the internal AERMET names of the weather elements as defined
in Table B-2 of Appendix B. As many names can be specified on a single keyword that will fit
within the 132-character limitation of a keyword. Since this keyword is repeatable, more than
one AUDIT keyword can be used to define all the additional elements to track.

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.

4.3.7 Changing the default values for the QA - 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:

RANGE sfname lower_bound <[=] upper_bound

Syntax:
missing_indicator
Type: Optional (Stage 1), Repeatable, Reprocessed

where sfname is the internal AERMET name of the weather element as defined in Table B-2 of
Appendix B, lower_bound and upper_bound are the new lower and upper bounds to be used in

4-14
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.

Data for the SURFACE pathway are written as integers with some variables having been
multiplied by 10 when extracted to retain significant digits. Table B-2 provides information on
which variables use a multiplier. The default upper and lower bounds are multiplied also,
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.

Several weather elements have been concatenated to form a single variable in the
extracted_data_file. These variables are noted in Table B-2 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.

4.3.8 Reducing the number of QA messages - 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 on an AUDIT keyword) is missing most of the time (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:

Syntax: NO_MISSING sfname1 ... sfnamen

Type: Optional (Stage 1), Repeatable

4-15
where sfname1, ..., sfnamen are the internal AERMET names of the weather elements to omit
from the message file. 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.

4.4 UPPERAIR pathway

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. The height, pressure, 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 one format, 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. Note though, for AERMET to correctly read the file, a minimum of one
header record consisting of three asterisks (in columns 1-3) must appear on a separate record
before the data (these asterisks inform AERMET that there are no more headers to process).

4.4.1 Retrieving archived data - DATA

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

designed to read only a couple of those formats. As with hourly surface observations, data
stored in this format is 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:

4-16
 Syntax: DATA archive_filename file_format
Type: Mandatory (Stage 1), Nonrepeatable

The archive_filename must conform to the naming conventions appropriate to the computing
platform. The maximum length of the archive file is 96 characters.

AERMET can process upper air data in the TD-6201 and FSL formats as mentioned
previously. TD-6201 is now obsolete, though historical data may exist in corporate and
personal archives. Neither format is available from the NCEI; however, historical and current
upper air data in the FSL format is available for download, free of charge, from the online
NOAA/ESRL Radiosonde Database (http://esrl.noaa.gov/raobs/). The format specifications are
also available at that same web address. TD-6201 data are stored either as fixed-length or
variable length records, and the file_format should be specified as either 6201FB or 6201FB,
respectively. file_format for upper air data in the FSL format should be specified as FSL.

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.

4.4.2 Saving dearchived data - 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

Type: Mandatory (Stage 1), Nonrepeatable

The extracted_data_filename must conform to the naming conventions appropriate to the

computing platform. The maximum length of this file name is 96 characters.
4-17
4.4.3 Extracting a subset of the data - XDATES

The amount of data extracted from an archive data 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:

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

Type: Mandatory (Stage 1), Nonrepeatable

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. The "/" is
required between each field and there cannot be any spaces within a date group since a space is
used as a delimiter between parameter fields. The year can be entered as either a two-digit or
four-digit integer (e.g., 1992 or 92). 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 word "TO" is
optional and only serves to make the statement a little more readable. It is ignored by AERMET
when this keyword is processed.

4.4.4 Identifying the station - LOCATION

The LOCATION keyword identifies the upper air 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]

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 format listed on the DATA keyword, these

4-18
identifiers are five-digit WBAN numbers. However, the site_id should be entered to match the
form of the identifier of the upper air station as it is recorded in the upper air file. For instance,
6201FB and 6201VB formats include a five-digit WBAN with leading zeros to fill the entire
eight-character field (e.g., 14735 is recorded as 00014735) and should be specified as such on
the LOCATION keyword in the UPPERAIR pathway since the field is read as type character
and not as an integer. On the other hand, the WBAN in the FSL format is recorded as a five-
digit number (14735) and should be specified on the LOCATION keyword with only five digits
to match the WBAN in the FSL file. A mismatch in the station identifiers between the
AERMET control file and the upper air file will generate a warning message, but processing
will continue. As in the case of the site_identifier for the LOCATION keyword on the
SURFACE pathway, AERMOD expects all characters to be numeric.

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: an N or S with the
latitude and W or E with the longitude. For example, "38.4N 81.9W" would be interpreted the
same as "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 latitude and longitude of the upper air
station are used by AERMET to select the most appropriate sounding available in the upper air
data file. Refer to Sections 4.7.6.6 and 4.7.7 for information on AERMET's options for upper
air sounding selection.

The final parameter for this keyword, tadjust, is optional and is an adjustment factor to
convert the time of each observation in the input data file from the reported time to local
standard time. The default value for tadjust is zero. For NWS upper air data processed by
AERMET, the reported time is GMT. The value for tadjust is subtracted from GMT to obtain
local standard time. Therefore, in the United States, which is west of Greenwich, the value 5 is
specified to convert GMT to Eastern Standard Time, 6 is specified to convert GMT to Central
Standard Time, 7 is specified to convert GMT to Mountain Standard Time, and 8 is specified to
convert GMT to Pacific Standard Time.

4-19
 Note that beginning with version 11059, AERMET no longer supports the user-specified
station elevation as a parameter on the UPPERAIR LOCATION keyword. AERMET will issue
a warning message if the elevation field is included. The user-specified elevation will be
ignored and processing will continue. Refer to Section 5.6 for more detailed information about
the history and use of the station elevation in the UPPERAIR, SURFACE, and ONSITE
pathways.

4.4.5 How good are the data? - 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 QA is performed by including the QAOUT keyword in a control
file. This keyword is also used to specify the input file for Stage 2. The syntax and type for the
QAOUT keyword are:

Syntax: QAOUT qa_output_filename

Optional (Stage 1), Nonrepeatable
Type:
Mandatory (Stage 2) if there are data to merge, Nonrepeatable

The qa_output_filename must conform to the naming conventions appropriate to the computing
platform. The maximum length of this file name is 96 characters.

Quality assessment is an optional process and the user does not have to perform a QA
prior to merging the data. However, this step is recommended to identify any potential
problems in the data that are used to derive the dispersion parameters.

Presently, AERMET's capabilities in this area are limited to verifying the values of the
upper air data are not outside a range of acceptable values and keeping track of the number of
missing values. These checks operate one sounding at a time, i.e., sounding to sounding
variations are not checked.

4-20
 Unlike the SURFACE pathway, there are no variables that are tracked (audited)
automatically on the UPPERAIR pathway. The user must specify variables to QA through the
AUDIT keyword, as discussed below. For each of the specified variables, the value of each
variable at each level 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 containing the value, the violation, the date and time of occurrence and the
sounding level. The number of times the variable is missing, exceeds the upper bound and
exceeds the lower bound is tallied and reported in the summary file (defined on the REPORT
keyword).

The number of levels in a sounding and the heights at which the data are recorded vary
from sounding to sounding. It is impractical to report on every level. AERMET divides the
atmosphere into 10 regions in which to summarize the QA information for the soundings. These
regions are based on the thickness increment defined to be 500 meters (in the variable UAINC
in the file BLOCK1.INC). These regions are: surface (the first level in the sounding), every 500
meters up to 4000 meters and everything above 4000 meters. By changing the value of UAINC
(and recompiling the software), these regions could be increased or decreased.

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 any
regulatory guidance, either replace the value in question or leave it alone.

There are default upper and lower bounds in AERMET, as well as a default missing
value indicator for each variable. These values can be changed by the user through the use of
the RANGE keyword, as described below.

4-21
4.4.6 Adding upper air variables to the QA - AUDIT

As mentioned above, there are no upper air variables that are tracked by default during a
QA. The user can track some or all variables for a particular AERMET run by specifying the
variable names on an AUDIT keyword. The syntax and type for this keyword are:

Syntax: AUDIT uaname1 ... uanamen

Type: Optional (Stage 1), Repeatable

where uaname1, ..., uanamen are the upper air variable names as defined in Table B-1 of
Appendix B. As many variable names can be specified on a single keyword that will fit within
the 132-character limitation of a keyword. Since this keyword is repeatable, more than one
AUDIT keyword can be used to define the variables to track.

4.4.7 Changing the default values for the QA - RANGE

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

RANGE uaname lower_bound <[=] upper_bound

Syntax:
missing_indicator
Type: Optional (Stage 1), Repeatable, Reprocessed

where uaname is the upper air variable 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 indicator. 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 even if a parameter is not changing; if a parameter is not changing,
the default value should be specified.
4-22
 Data for the UPPERAIR pathway are written as integers to the output file with some
variables having been multiplied by 10 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.

4.4.8 Reducing the number of QA messages - NO_MISSING

Every time a bound is violated or a value is missing, a message is written to the message
file (defined on the MESSAGES keyword). If a variable that is tracked is missing most of the
time, 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:

Syntax: NO_MISSING uaname1 ... uanamen

Type: Optional (Stage 1), Repeatable

where uaname1, ..., uanamen are the variable names of the weather variables to omit from the
message file. The missing values are tallied and the count is included in the report file but the
individual message each time there is an occurrence is not included in the report or the message
file

4.4.9 Adjusting sounding data - MODIFY

AERMET has been designed to check for other problems with the upper air data and
correct them if the MODIFY keyword is used. The MODIFY keyword directs AERMET to
'turn on' the process and perform some preliminary quality control as the data are extracted. The
syntax and type of the keyword are:

4-23
 Syntax: MODIFY
Type: Optional (Stage 1), Nonrepeatable

This keyword does not have any parameters associated with it. By specifying this
keyword, the following actions occur:

- Some mandatory levels are deleted from the sounding;

- A nonzero wind direction is set to 0 if the wind speed is 0;
- Missing ambient and dew point temperatures are replaced by interpolated values.

If a mandatory sounding level is within one percent of a significant level (with respect to
pressure) then the mandatory level is deleted. This modification is performed to reduce the
possibility of reporting large gradients during the quality assessment (if the user opts to QA
those gradients). There is little loss of information in the sounding since mandatory levels are
derived from significant levels. However, the deletion process takes place after the data are
extracted from the archive data and reduces the number of levels extracted. AERMET does not
attempt to read more levels after deleting a level.

The wind speed and wind direction at each level are checked to insure that there are no
levels with a zero wind speed and a non-zero wind direction. If one is found, the wind direction
is set to zero to represent calm conditions. The winds from the soundings are not used in any
boundary layer parameter estimates.

If the dry-bulb or dew-point temperature is missing at some level, then an estimate for
the missing temperature is made by linearly interpolating to the level in question. The data from
the level immediately below and above the level in question are used. If the data that are
required for the interpolation are also missing, then no interpolation is performed.

4.5 ONSITE pathway

The ONSITE pathway provides a means of including data recorded during an

observation program such as might be required for dispersion modeling for a facility. Such a
4-24
program may utilize an instrumented tower (with data from several levels), a remote sensing
device (such as lidar), and instrumentation at or near ground level (such as measuring fluxes).
Much of this type of data can be used in AERMET to provide better estimates of the boundary
layer parameters than using NWS data alone. As previously noted, the ONSITE pathway is also
used to process prognostic data processed via MMIF output in AERMET.

There are several keywords that are nearly identical to those found on the SURFACE
and UPPERAIR pathways, and there are several keywords that are unique for this type of data.
The only additional statements that must be included for site-specific data are those required to
describe the structure of the data and a minimum detectable wind speed. All other statements
are optional and could be omitted.

4.5.1 Retrieving archived data - DATA

The file containing the site-specific data is specified on the DATA keyword. Unlike the
SURFACE and UPPERAIR pathways, there is no standard format or content for site-specific
data. Thus, only the file name is specified on this keyword. The syntax and type for the DATA
keyword are:

Syntax: DATA data_filename

Type: Mandatory (Stage 1), Nonrepeatable

The data_filename must conform to the naming conventions appropriate to the computing
platform. The maximum length of this file name is 96 characters.

4.5.1.1 Where is the EXTRACT keyword?

Unlike SURFACE and UPPERAIR data, site-specific data are not stored (archived) in
any particular format. Therefore, the data are not "extracted" from an archive file, and there is
no need for the EXTRACT keyword. The processing can begin with the quality assessment.
Thus, the input file to the QA is defined on the DATA keyword.
4-25
4.5.2 Defining the 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
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
4-26
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-3
for “scalar” (single-level) variables and Table B-4 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, users 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 free-
formatted data, in accordance with Fortran language standards. Free-formatted, also called list-
directed 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 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 (i.e., filled with a missing value indicator) for certain
hours;
4-27
 (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 observation 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, Table B-3, and Table B-4, 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. The different methods available for specifying the
measurement heights for ONSITE data processed through AERMET are discussed in detail in
Section 4.5.9.

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

4-28
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" format specifier 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
4-29
 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 rather than a
fixed number of digits after the decimal. 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

4-30
Table B-3 and Table B-4). 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 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.

It may be the case that 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 "/" specifiers
in the Fortran FORMAT statement. 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 control
file and avoiding introducing errors on these two keywords. Processing a Subset of the Data -
XDATES.

4-31
4.5.3 Processing a subset of the data - XDATES

The amount of data processed 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:

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

Type: Mandatory (Stage 1), Nonrepeatable

YB, MB and DB are the beginning year, month and day, respectively, of the data to
process and YE, ME, and DE are the ending year month and day, respectively. The "/" is
required between each field and there cannot be any spaces within the date group. The year can
be entered as either a two-digit or four-digit integer (e.g., 1992 or 92). 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 word "TO" is optional and only serves to make the statement a little more
readable. It is ignored by AERMET when this keyword is processed.

4.5.4 Identifying the station - LOCATION

AERMET requires location information about the site where the measurements are
taken. The LOCATION keyword specifies the station identifier, latitude and longitude, and a
time adjustment factor. The syntax and type are:

Syntax: LOCATION site_id site_lat/long site_long/lat [tadjust] [elevation]

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

The site_id (up to eight characters) is an alphanumeric specifier that identifies the site.
Since data are not extracted from archived data, this identifier is used only to identify the site in
the output files (reports and from Stage 3). However, as with the LOCATION keyword on the
UPPERAIR and SURFACE pathways, all characters entered that make up the site_id should be

4-32
numeric as AERMOD expects a numeric value entered in the AERMOD control file.
AERMOD processing will abort if the value is not numeric.

The measurement site latitude and longitude can be entered in either order because
AERMET distinguishes between the two by the suffix on each: a N or S with the latitude and W
or E with the longitude. For example, "38.4N 81.9W" would be interpreted the same as "81.9W
38.4N". AERMET cannot use, nor does it recognize, "+" or "-" to discriminate between north
and south and east and west. The site latitude and longitude for the ONSITE pathway are not
used at this time. They are simply another way to identify the site being processed.

The parameter, tadjust is optional with a default value of zero and is an adjustment factor
to convert the time of each observation in the input data file from the reported time to local
standard time. Note, however, tadjust must be specified when also specifying the last parameter
for the LOCATION keyword, elevation. The adjustment factor is subtracted from the reported
hour. Since there is no standard format for site-specific data, the time reported could be relative
to any time frame. For example, one time frame the user should verify is if the data are reported
in local daylight time. If this is the case, then tadjust could be specified as 1 to return the data to
local standard time, assuming that daylight time was used throughout the entire data period.

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

4.5.5 How good are the data? - QAOUT

As with the UPPERAIR and SURFACE pathways, AERMET can assess the quality of
the site-specific data by including the QAOUT keyword in the control file. This keyword is also
used to specify the input file name to Stage 2. The syntax and type for the QAOUT keyword
are:

4-33
 Syntax: QAOUT qa_output_filename
Optional (Stage 1), Nonrepeatable
Type:
Mandatory (Stage 2), Nonrepeatable

The qa_output_filename must conform to the naming conventions appropriate to the computing
platform. The maximum length of this file name is 96 characters.

Quality assessment is an optional process and the user does not have to perform a QA
prior to merging the site-specifc data. However, this step is recommended to identify any
possible problems with the data that are used to derive the boundary layer parameters.

Presently, AERMET's capabilities in this area are limited to verifying the values of the
site-specific data are not outside a range of acceptable values and keeping track of the number of
missing values. These checks operate one observation period at a time, i.e., variations over a
period of time are not checked.

Site-specific data may be reported more frequently than once per hour (see the
OBS/HOUR keyword discussed below in Section 4.5.12). For observations more frequent than
once per hour, the QA procedures operate on the subhourly data. There is no QA on the one-
hour averaged data.

When a quality assessment is performed on the site-specific data, several of the variables
are automatically tracked (audited) and included in a summary of the QA process. These
variables are: temperature, wind speed and wind direction. The value of each variable at each
level 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
on the MESSAGES keyword, which identifies the variable, the violation, and data and time of
occurrence. The number of times the variable is missing, exceeds the upper bound and exceeds
the lower bound is tallied and reported in the summary file defined by the REPORT keyword.

4-34
 There are no provisions for automatically replacing missing site-specific values in
AERMET, 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 any
regulatory guidance, either replace the value in question or leave it alone.

There are default upper and lower bounds in AERMET, as well as a default missing
value indicator for each variable. These values can be changed by the user through the use of
the RANGE keyword, as described below (Section 4.5.7). The user can QA additional variables
by using the AUDIT keyword.

4.5.6 Adding site-specific variables to the QA - AUDIT

As stated, only site-specific temperature, wind speed, and wind direction are tracked by
default during the QA. The user can track additional variables for a particular AERMET run by
specifying the variable name on an AUDIT keyword. The syntax and type for this keyword are:

Syntax: AUDIT osname1 ... osnamen

Type: Optional (Stage 1), Repeatable

where osname1, ..., osnamen are the site-specific variable names as defined in Table B-3 and
Table B-4. For the multi-level variables (e.g., temperature) only the two leading alphabetic
characters can be specified (e.g., TT), otherwise AERMET will terminate with an error. Every
level where the variable appears will be QA'd. As many variable names can be specified on a
single keyword that will fit within the 132-character limitation of a keyword. Since this
keyword is repeatable, more than one AUDIT keyword can be used to define additional
variables.

4-35
4.5.7 Changing the default values for the QA - RANGE

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

Syntax: RANGE osname lower_bound <[=] upper_bound missing_indicator

Type: Optional (Stage 1), Repeatable, Reprocessed

where osname is the site-specific variable as defined in Table B-3, 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 even if a parameter is not changing; if a parameter is not changing, the default value
should be specified. For the multi-level variables (e.g., wind speed and temperature), only the
first two characters should be specified (e.g., WS and TT).

Unlike data for the SURFACE and UPPERAIR pathways, the site-specific data are
written to the output file as real and integer values without multipliers because of the variety of
data and user-defined formats. The exceptions to this rule are the surface variables shared with
the SURFACE pathway.

4.5.8 Reducing the number of QA messages - NO_MISSING

Every time a bound is violated or a value is missing, a message is written to the message
file (defined on the MESSAGES keyword). If a variable that is tracked is missing most of the
time, 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 QA.
The syntax and type are:
4-36
 Syntax: NO_MISSING osname1 ... osnameN
Type: Optional (Stage 1), Repeatable

where osname1, ..., osnameN are the variable names of the weather variables to omit from the
message file. The missing values are tallied and the count is included in the report file but the
individual message each time there is an occurrence is not included in the report or the message
file.

4.5.9 An alternate specification of measurement heights - OSHEIGHTS

AERMET provides two options for specifying the measurement heights for the multi-
level 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
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-4). 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:

OSHEIGHTS height1 height2 ... heightn

Optional if height information is provided in the data; otherwise

Type:
mandatory (Stage 1), Repeatable, Reprocessed

4-37
 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.

4.5.10 Temperature differences - DELTA_TEMP

In addition to measuring ambient temperature directly, a site-specific data program may

measure differences in temperature. These measurements can be either between the levels
where the ambient temperature is measured or independently of these levels. Temperature
difference near the surface can be used to infer sensible heat flux. Measured temperature
differences are not the same as the ambient temperature difference between two levels. A true
temperature difference utilizes an instrument, such as a thermocouple, that couples two levels of
data, whereas ambient temperature at two levels most likely is measured by two independent
instruments.

The ONSITE data pathway has provisions for up to three temperature differences, which
are defined through the three variables DT01, DT02 and DT03 (see Table B-4). The heights
that define the temperature difference cannot be entered directly through the READ and
FORMAT keywords. The special keyword DELTA_TEMP defines the two levels that comprise
the temperature difference. The syntax and type are:

Syntax: DELTA_TEMP index lower_height upper_height

Type: Optional (Stage 1), Repeatable, Reprocessed

Each statement includes an index that corresponds to the temperature difference represented by
the lower_ and upper_heights. The index can range from one to three.

4-38
 At present, none of the processing options in Stage 3 utilizes temperature difference.
Methods may be incorporated in future versions of AERMET that require these values, and the
structure for processing such data will already exist.

4.5.11 Threshold wind speeds - THRESHOLD

The threshold wind speed, the minimum wind speed required to detect air flow varies,
from anemometer to anemometer. The user must specify the minimum detectable (threshold)
wind speed of the site-specific anemometer. There is no default value. The THRESHOLD
keyword is used for this purpose. The syntax and type for this keyword are:

Syntax: THRESHOLD threshold_wind_speed

Type: Mandatory (Stage 1), Nonrepeatable, Reprocessed

→ The THRESHOLD keyword must be included when site-specific data are

processed.

The threshold can be no greater than 1.0 m/s. A value greater than 1.0 generates an error
condition and AERMET does not process any data. For threshold values above 0.5 m/s,
AERMET writes a warning message.

AERMET also imposes a minimum allowable wind speed for defining the wind speed to
use in estimating the boundary layer parameters. This minimum is independent of the threshold
wind speed and is defined as 21/2 * σvmin, where σvmin = 0.2 m/s.

4.5.12 Multiple observation periods for each hour - OBS/HOUR

Site-specific data may be reported more frequently than once per hour. If the data
include more than one equally-spaced observation period each hour, the keyword OBS/HOUR
is used to specify the number of observations that AERMET should expect each hour.
AERMET currently allows up to 12 observation periods per hour (i.e., every 5 minutes) and will
4-39
calculate the average over all periods within the hour to produce an hourly average. At least
half the observations for a variable must not be missing for AERMET to compute the average,
otherwise the value for the hour is set to missing. A discussion on how the average is computed
for each variable is in Section 5.4. If there is one observation period per hour, this keyword is
optional. The syntax and type for this keyword are:

Syntax: OBS/HOUR n_obs

Mandatory for data with more than 1 observation per hour (Stage 1),
Type:
Nonrepeatable

All variables specified on the READ keywords must be reported at the same number of
observations per hour, e.g., one variable cannot be reported once per hour and the remaining
variables reported four times per hour.

Each hour of data must contain the same number of observation periods per hour. For
example, if the user specifies 4 OBS/HOUR, but there are only two observation periods for one
hour in the middle of the file, AERMET will not detect this condition and will not correctly
compute the hourly averages for all subsequent hours.

4.6 MERGE pathway

This pathway is referred to as Stage 2 processing, which involves combining the

different sources of data into one file composed of blocks of 24-hour data. This is an
intermediate, but necessary, step between extracting and QA'ing archived data and estimating
boundary layer parameters. As such, there are only two keywords related directly to this
pathway.

4-40
4.6.1 Output file - OUTPUT

As the data are combined/merged together in 24-hour blocks, the result is written to an
ASCII text output file. The file is specified on the OUTPUT keyword. The syntax and type for
OUTPUT are:

Syntax: OUTPUT merged_data_filename

Type: Mandatory, Nonrepeatable

The merged_data_filename must conform to the naming conventions appropriate to the

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

The input data are provided by the three data pathways through the QAOUT keyword
when such data are available. For example, if there are no site-specific data to merge, then only
the QAOUT keywords for the SURFACE and UPPERAIR pathways are required.

4.6.2 Substitution of NWS/FAA surface wind data with 1-minute ASOS wind 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 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.

4-41
4.6.2.1 Use of 1-minute 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
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 ASOS wind observations available from
the NCEI 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.”
4-42
 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:

Syntax: ASOS1MIN file_name

Type: Optional, Non-repeatable

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 4.7.6.2) 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.

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 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

4-43
reference wind speed and direction are set to missing and an error message is generated (see
Section 5.2 for more details).

4.6.2.2 Threshold wind speed for 1-minute ASOS winds

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).

Beginning with version 12345, a new THRESH_1MIN keyword was added for stage
Stage 3 processing to specify a threshold wind speed for the 1-minute ASOS data. This
threshold value only applies to the hourly averaged winds derived from the 1-minute ASOS data
and does not apply to the standard hourly NWS weather observations. Since the minimum
acceptable wind speed threshold for site-specific meteorological monitoring is 0.5 m/s under
current EPA guidance (EPA, 2000), user’s may specify the same threshold wind speed for
winds derived from 1-minute ASOS data.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,

The new THRESH_1MIN keyword uses the following syntax:

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
4-44
THRESH_1MIN option has been used, and also specifies the number of calm winds identified
based on the specified threshold value.

4.6.3 Merging a subset of the data - XDATES

As with the other data pathways, the amount of data merged can be limited by using the
XDATES keyword to specify the beginning and ending dates of the data to be merged. The
syntax and type are:

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

Type: Optional, Nonrepeatable

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. The "/" is required between
each field and there cannot be any spaces within a date group. The year can be entered as either
a two-digit or four-digit integer (e.g., 1992 or 92). 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 word "TO" is optional and only serves to make the statement a little more readable. It is
ignored by AERMET when this keyword is processed.

If the XDATES keyword is omitted, then the preprocessor searches all the input files to
this stage and determines the earliest date in the files. AERMET then merges the data beginning
with this date and continuing for 367 days, even if all the data are exhausted in the input files.

4.7 METPREP pathway

This pathway is also referred to as Stage 3, when the boundary layer parameters are
estimated that will be used by the dispersion model. This is the third and final step in the
sequence of steps that began with extracting data from archived data files.

4-45
 Several of the keywords seen on the previous pathways are also used on this pathway in
a nearly identical manner.

4.7.1 Input data file - DATA

Like all the previous stages, this stage requires input data. The data file generated by the
Stage 2 processing - merging data - is the required file and is defined with the DATA keyword.
The syntax and type are:

Syntax: DATA merged_data_filename

Type: Mandatory, Nonrepeatable

The merged_data_filename, which is an ASCII file, must conform to the naming conventions
appropriate to the computing platform. The maximum length of this file name is 96 characters.

4.7.2 Choosing a dispersion model - MODEL

Although AERMET currently only estimates parameters for the AERMOD dispersion
model, it is designed with the capability to estimate parameters for other dispersion models.
The MODEL keyword informs AERMET for which model to process the data. The syntax and
type are:

Syntax: MODEL model_name

Type: Optional, Nonrepeatable

where model_name identifies the dispersion model. The AERMOD model is the default model,
making this keyword optional.

4-46
4.7.3 Identifying the site - LOCATION

Past versions of AERMET required the LOCATION keyword under the METPREP
pathway in Stage 3. The METPREP LOCATION keyword had been used as the location for
determining the time of sunrise which is needed for convective mixing height calculations.
Beginning with version 11059, AERMET was modified to use the location of the primary
surface station (i.e., the ONSITE station or the NWS surface station) specified in Stage 1 to
determine the time of sunrise for mixing height calculations. The METPREP LOCATION
keyword is now only needed when site-specific mixing heights are provided during Stage 1 and
upper air sounding data are omitted from the processing. Otherwise, a warning message will be
generated if the LOCATION keyword is included under the METPREP pathway, and the
LOCATION parameters will be ignored. For applications with only site-specific mixing
heights, without upper air data, the METPREP LOCATION keyword is needed for the
conversion from GMT to LST, since the time zone specified on the ONSITE pathway is likely
referenced to local time.

For those applications of AERMET when the METPREP LOCATION keyword is

needed, it is identical in all respects to its usage on other pathways: the site identifier, latitude
and longitude, and a time adjustment factor. The syntax and type are:

Syntax: LOCATION site_id source_lat/long source_long/lat [tadjust]

Type: Conditional, Nonrepeatable
Order: Latitude (lat) and longitude (long) can appear in either order

The site_id is an eight-character alphanumeric specifier that identifies the site. This field is
simply a means to identify the site and is not used otherwise.

The latitude (lat) and longitude (long) on the METPREP pathway should reflect the
location of the source, i.e., the location where the dispersion model is to be applied. Latitude
and longitude can be entered in either order because AERMET distinguishes between the two
by the suffix on each: a N or S with the latitude and W or E with the longitude. For example,
4-47
"38.4N 81.9W" would be interpreted the same as "81.9W 38.4N". AERMET cannot use, nor
does it recognize, "+" or "-" to discriminate between north and south and east and west.

The final parameter for this keyword, tadjust, is required and is an adjustment factor to
convert GMT to LST. The value of this parameter should be entered as a positive number for
sites west of Greenwich such as in the U.S.

4.7.4 Instrumentation heights for NWS data - NWS_HGT

When various parameters are computed for the dispersion models, the height of the
instruments is usually required. With site-specific meteorological data, the heights of the
measurements are generally available and entered through the READ or OSHEIGHTS
keywords on the ONSITE pathway in the Stage 1 control file. If there are no site-specific data,
or for isolated hours when there are site-specific data, then NWS data may be substituted for the
computations. However, instrument height is not one of the reported parameters. The
NWS_HGT keyword is used to provide this information. The syntax and type are:

Syntax: NWS_HGT variable_name instrument_height

Type: Mandatory, Repeatable

The variable_name specifies which meteorological instrument is being referenced and is

followed by the instrument_height in the appropriate units. Currently, there is only one variable
name: WIND. Prior to the conversion to ASOS, the height of the wind instrument
(anemometer) was about 20 feet (6.7 meters) or 30 feet (9.1 meters). The height of wind
instrumentation at ASOS sites is typically 33 feet (10.1 meters) or 26 feet (7.9 meters). Annual
local climatological data are available from the NCEI and contain a historical record of
instrumentation sites and heights for the stations. The user should consult a reference such as
the annual summaries prior to running Stage 3 to obtain the correct height to use with this
keyword. AERMET requires the anemometer height in meters.
4-48
4.7.5 Processing a subset of the merged data - XDATES

Like all previous pathways, the amount of data processed can be limited by using the
XDATES keyword to specify the beginning and ending dates of the data to be merged. The
syntax and type are:

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

Type: Optional, Nonrepeatable

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. The "/" is required between
each field and there cannot be any spaces within the date group. The year can be entered as a
two-digit or four-digit integer (e.g., 1992 or 92). 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 word "TO" is optional and only serves to make the statement a little more readable. It is
ignored by AERMET when this keyword is processed.

If the XDATES keyword is omitted, then the AERMET processes all the data in the
input file specified on the DATA keyword.

4.7.6 Processing options - METHOD

The METHOD keyword is used to define processing methods for the input data
including: data substitution, special treatment of ASOS wind data, stable boundary layer
treatment, and upper air sounding selection. This METHOD keyword requires a secondary
keyword (process) to identify the particular meteorological variables that are affected and the
option (parameter) to use. The syntax and type are:

Syntax: METHOD process parameter

Type: Optional, Repeatable

4-49
 The list of valid secondary keywords for the METHOD keyword has grown substantially
with the more recent updates to AERMET. The following is a list of valid secondary keywords
that will be discussed in the subsections that follow: WIND_DIR, REFLEVEL, ASOS_ADJ,
UASELECT, STABLEBL, CCVR, and TEMP.

4.7.6.1 Randomization of NWS wind directions – WIND_DIR

National Weather Service wind directions are reported to the nearest 10°. The secondary
keyword WIND_DIR is used to enable and disable a randomization procedure which adjusts
NWS wind directions to yield directions to the nearest degree. The randomization procedure is
enabled or disabled by specifying RANDOM or NORAND, respectively, after the WIND_DIR
keyword. Prior to version 16216, randomization was disabled by default if the secondary
keyword WIND_DIR was not specified. Beginning with version 16216, AERMET’s default
behavior is to randomize NWS wind directions when the WIND_DIR keyword is not specified.
However, if the user wants a reminder as to how the data were processed, the RANDOM
parameter can be specified. WIND_DIR is included in the METPREP pathway using the
following format:

METHOD WIND_DIR RANDOM

Syntax: or
NORAND
Type: Optional, Non-repeatable

Randomization is accomplished by using a single-digit random number, with a separate

random number predefined for each hour of the year. This array of numbers is static and is the
EPA standard set of random numbers used to randomize wind directions. The random number
is added to the wind direction (which is first multiplied by 10) and 4 is subtracted from the result
to yield a direction to the nearest degree. The array of random numbers is internal to AERMET;
therefore, a separate file of these standard random numbers is not necessary.

4-50
 This keyword has no effect when site-specific data are available for the hour. It is
assumed that the site-specific wind direction is reported to the nearest degree and does not need
randomizing.

4.7.6.2 NWS data substitution - REFLEVEL

The secondary keyword REFLEVEL directs AERMET to substitute NWS data in the
computations in the event site-specific data are missing for the hour. The only valid parameter
is SUBNWS which enables data substitution to estimate boundary layer parameters. If there are
no site-specific data in the data base, i.e., only NWS hourly observations and upper air
soundings were merged, this secondary keyword REFLEVEL becomes mandatory, and if it is
omitted, AERMET detects this condition (i.e., no site-specific data and do not substitute NWS
data) as an error and will not process any data. If there are site-specific data in the data base,
but some of the variables required for the boundary layer computations are missing, then this
parameter directs AERMET to SUBstitute NWS data so the boundary layer parameters can be
calculated. Also, if the site-specific profiles of wind and/or temperature are missing for an hour,
this parameter directs AERMET to use NWS data to create a single-level profile of wind and/or
temperature. The format for enabling NWS substitution using the METHOD keyword in the
METPREP pathway is as follows:

Syntax: METHOD REFLEVEL SUBNWS

Type: Optional, Non-repeatable

4.7.6.3 Adjustment to truncated ASOS wind speeds – ASOS_ADJ

Beginning with version 11059, AERMET was been modified to add ½ 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).
4-51
 The ½ 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:

Syntax: METHOD ASOS_ADJ NO_ADJ

Type: Optional, Non-repeatable

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.

4.7.6.4 Option to adjust u* under low wind/stable conditions - STABLEBL

Beginning with version 12345, the AERMET program included a non-Default BETA
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 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* option is as follows:

4-52
 Syntax: METHOD STABLEBL ADJ_U*

Type: Optional, Non-repeatable

Beginning with version 16216, the ADJ_U* option is no longer a BETA option when
processing NWS surface meteorology or site-specific data that does not include turbulence
measurements (Sigma-Theta and/or Sigma-W). However, the ADJ_U* option is still BETA
and considered a non-Default option when site-specific data that include turbulence are
processed. For the latter circumstance, as a BETA option, the use of ADJ_U* is 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.

4.7.6.5 Substitutions for missing cloud cover and temperature – CCVR, TEMP

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
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

4-53
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:

4-54
 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)

4.7.6.6 Upper air sounding selection by sunrise - SUNRISE

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 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
4-55
was 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 north-
south line of longitude (see Figure 4-1). As a result, the time zone adjustment parameter on the
LOCATION keyword on the Stage 1 UPPERAIR pathway 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 by
computing 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 4-1 shows which default sounding AERMET will use based on the longitude-
dependent ‘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 4-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.

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

Table 4-1. Sounding Selection by Time Zone

Time Zone -12 - -10 -9 -8 -7 -6 -5 -4 -3 -2 -1 0
11
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 --

AERMET has also 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. Using
the new method, SUNRISE, AERMET can search for the sounding nearest to sunrise rather than
looking for a 00Z or 12Z sounding. By default, when this option is specified, AERMET
attempts to find a sounding within 6 hours before sunrise, and if that search fails, it searches up
to 2 hours after sunrise. This search window, as well as the default search window when the
SUNRISE method is not enabled, can be extended in either direction using the new keyword

4-57
UAWINDOW, described below in Section 4.7.7. When search for a sounding using the
SUNRISE method, 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 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

Note that the ‘E’ on ‘SUNRISE’ is optional and can be omitted.

4.7.7 Adjusting the default sounding window - UAWINDOW

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:

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

4-58
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 user 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.

As with the 12Z/00Z sounding search, the user can expand or contract the search
window for the SUNRISE option (-6 to +2 hours by default) using the UAWINDOW keyword.
The syntax for the UAWINDOW keyword is the same in both cases. When used UAWINDOW
is used in conjuction with the SUNRISE method, window_begin and window_end represent the
number of hours before and after 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.

4.7.8 Surface characteristics - FREQ_SECT(2), SECTOR(2), and SITE_CHAR(2)

Surface conditions at the measurement site, referred to as the surface characteristics,

influence boundary layer parameter estimates. Obstacles to the wind flow, the amount of
moisture at the surface, and reflectivity of the surface all affect the estimates. These influences
are quantified through the surface albedo, Bowen ratio and roughness length (z0). AERMET
was 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 when the
SUBNWS option is specified and both ONSITE and SURFACE data are provided (including

4-59
1-minute ASOS wind data). If either ONSITE data or SURFACE data are omitted, only a
single (primary) set of surface characteristics is required.

The primary set of surface characteristics are defined for AERMET through the three
keywords FREQ_SECT, SECTOR and SITE_CHAR used to specify the temporal frequency,
number of sectors, and the site characteristics (albedo, Bowen ratio, and effective surface
roughness length), respectively. The secondary set of site characteristics are specified using
similar keywords, FREQ_SECT2, SECTOR2, and SITE_CHAR2. These keywords for the
secondary set should be added to the METPREP pathway immediately after the primary set of
characteristics when defining both a primary and secondary set of surface characteristics.

The FREQ_SECT and FREQ_SECT2 keywords define how often the surface
characteristics change (the frequency), or alternatively, the period of time over which these
characteristics remain constant, and the number of non-overlapping sectors into which the 360°-
compass is divided (number_of_sectors).

→ The FREQ_SECT and FREQ_SECT2 keywords can appear only once and must
appear before the SECTOR (SECTOR2) and SITE_CHAR (SITE_CHAR2)
keywords.

The syntax and type for the FREQ_SECT and FREQ_SECT2 keywords are as follows:

FREQ_SECT
Syntax: or frequency number_of_sectors
FREQ_SECT2
Type: Mandatory (Stage 3), Nonrepeatable, Reprocessed
These keywords must appear before SECTOR (SECTOR2) and
Order:
SITE_CHAR (SITE_CHAR2)

The frequency can be ANNUAL, SEASONAL or MONTHLY, corresponding to 1, 4, or

12 periods, respectively. ANNUAL and MONTHLY are straightforward: the site characteristics
are the same for all months of the year, or the site characteristics vary from month to month,

4-60
respectively. When SEASONAL is specified, then the site characteristics are distributed by
month as follows:

Season # Season Months

1 Winter December, January, February
2 Spring March, April, May
3 Summer June, July, August
4 Autumn September, October, November

The number before the season represents the frequency-index that is specified for that season on
the SITE_CHAR keyword.

A minimum of 1 and a maximum of 12 can be specified for the number_of_sectors.

A SECTOR statement defines the beginning and ending wind direction sector for which
the surface characteristics apply. The syntax and type of this keyword are:

SECTOR sector_index beginning_direction ending_direction

Syntax: or
SECTOR2 sector_index beginning_direction ending_direction
SECTOR: Mandatory, SECTOR2: Conditional
Type:
(Stage 3), Repeatable, Reprocessed

One sector is defined per keyword, with the sector_index linking a specific sector to a
set of site characteristics. The sectors are defined clockwise, they must cover the full circle, and
these must be defined so that the end of one sector corresponds to the beginning of another. The
beginning_direction is considered part of the sector, while the ending_direction is excluded
from the sector. The directions reference the direction from which the wind is blowing. A
sector can cross through north (e.g., 345 - 15) or can start and stop at north (e.g., 0 - 30 and
270 - 360). AERMET will verify that the entire 360° circle is covered. See Section 3.1 and
Section 5.7.2 for additional discussions on defining the wind direction sector and the associated
surface characteristics.

4-61
 The site characteristics are specified on the SITE_CHAR and SITE_CHAR2 keywords,
with one statement for each combination of time period and wind sector. The syntax and type
for these keywords are:

SITE_CHAR
Syntax: or frequency_index sector_index albedo Bowen roughness
SITE_CHAR2
Type: Mandatory (Stage 3), Repeatable, Reprocessed

The frequency_index varies from one to the number of time periods corresponding to the
frequency defined on the FREQ_SECT (or FREQ_SECT2) keyword. The sector_index varies
from one to the number of sectors defined on the FREQ_SECT (or FREQ_SECT2) keyword.
These indices are followed by the albedo, Bowen ratio and roughness length for the
frequency/sector combination. If the maximum frequency (MONTHLY) and maximum number
of sectors were defined (12), then it would require 144 (12 frequencies and 12 sectors)
SITE_CHAR (or SITE_CHAR2) statements to completely define the site characteristics.

The albedo is the fraction of total incident solar radiation reflected by the surface back to
space without absorption. Typical values range from 0.1 for thick deciduous forests to 0.90 for
fresh snow. The daytime Bowen ratio, an indicator of surface moisture, is the ratio of the
sensible heat flux to the latent heat flux and is used for determining planetary boundary layer
parameters for convective conditions. While the diurnal variation of the Bowen ratio may be
significant, the Bowen ratio usually attains a fairly constant value during the day. Midday
values of the Bowen ratio range from 0.1 over water to 10.0 over desert. The surface roughness
length is related to the height of obstacles to the wind flow and is, in principle, the height at
which the mean horizontal wind speed is zero. Values range from less than 0.001 m over a calm
water surface to 1 m or more over a forest or urban area.

Table 4-2 through Table 4-6, from Paine (1987), provide some guidance on specifying
these values by land use type and season. In these tables, the seasons do not correspond to a
particular group of months, but more on latitude and the annual vegetative growth cycles.

4-62
Spring refers to the period when vegetation is emerging or partially green and applies to the 1-2
months after the last killing frost. The term summer applies to the period when vegetation is
lush. The term autumn refers to the period of the year when freezing conditions are common,
deciduous trees are leafless, soils are bare after harvest, grasses are brown and no snow is
present. Winter conditions apply to snow-covered surfaces and subfreezing temperatures. For
example, March in the southern United States is spring, but it is still winter in much of New
England. It is up to the user to determine how to apply this information.

Table 4-2. Albedo of Ground Covers by Land Use and Season

Land-Use Spring Summer Autumn Winter

Water (fresh and sea) 0.12 0.10 0.14 0.20
Deciduous Forest 0.12 0.12 0.12 0.50
Coniferous Forest 0.12 0.12 0.12 0.35
Swamp 0.12 0.14 0.16 0.30
Cultivated Land 0.14 0.20 0.18 0.60
Grassland 0.18 0.18 0.20 0.60
Urban 0.14 0.16 0.18 0.35
Desert Shrubland 0.30 0.28 0.28 0.45

The Bowen ratio for winter in the next three tables depends on whether a snow cover is
present continuously, intermittently or seldom. For seldom snow cover, the values between
autumn and winter may be more applicable; for continuous snow cover, the values for winter are
applicable. For bodies of water, it is assumed that the surface is frozen.

4-63
 Table 4-3. Daytime Bowen Ratio by Land Use and Season – Dry Conditions

Land-Use Spring Summer Autumn Winter

Water (fresh and sea) 0.1 0.1 0.1 2.0
Deciduous Forest 1.5 0.6 2.0 2.0
Coniferous Forest 1.5 0.6 1.5 2.0
Swamp 0.2 0.2 0.2 2.0
Cultivated Land 1.0 1.5 2.0 2.0
Grassland 1.0 2.0 2.0 2.0
Urban 2.0 4.0 4.0 2.0
Desert Shrubland 5.0 6.0 10.0 10.0

Table 4-4. Daytime Bowen Ration by Land Use and Season - Average Moisture
Conditions

Land-Use Spring Summer Autumn Winter

Water (fresh and sea) 0.1 0.1 0.1 1.5
Deciduous Forest 0.7 0.3 1.0 1.5
Coniferous Forest 0.7 0.3 0.8 1.5
Swamp 0.1 0.1 0.1 1.5
Cultivated Land 0.3 0.5 0.7 1.5
Grassland 0.4 0.8 1.0 1.5
Urban 1.0 2.0 2.0 1.5
Desert Shrubland 3.0 4.0 6.0 6.0

4-64
 Table 4-5. Daytime Bowen Ratio by Land Use and Season - Wet Conditions

Land-Use Spring Summer Autumn Winter

Water (fresh and sea) 0.1 0.1 0.1 0.3
Deciduous Forest 0.3 0.2 0.4 0.5
Coniferous Forest 0.3 0.2 0.3 0.3
Swamp 0.1 0.1 0.1 0.5
Cultivated Land 0.2 0.3 0.4 0.5
Grassland 0.3 0.4 0.5 0.5
Urban 0.5 1.0 1.0 0.5
Desert Shrubland 1.0 1.5 2.0 2.0

Table 4-6. Surface Roughness Length, in Meters, by Land Use and Season

Land-Use Spring Summer Autumn Winter

Water (fresh and sea) 0.0001 0.0001 0.0001 0.0001
Deciduous Forest 1.00 1.30 0.80 0.50
Coniferous Forest 1.30 1.30 1.30 1.30
Swamp 0.20 0.20 0.20 0.05
Cultivated Land 0.03 0.20 0.05 0.01
Grassland 0.05 0.10 0.01 0.001
Urban 1.00 1.00 1.00 1.00
Desert Shrubland 0.30 0.30 0.30 0.15

4-65
 An additional source of information for surface roughness length can be found in Stull
(1988). Surface characteristics used in AERSURFACE may be more appropriate than those
shown above and can be found in the AERSURFACE User's Manual (EPA, 2008).

The following shows the format for defining both a primary and a secondary set of
surface characteristics in the METPREP pathway:
** 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

The primary set of characteristics will be applied for those hours in which the data are
used when the 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.

AERMET includes optional keywords, AERSURF and AERSURF2 under the

METPREP pathway, which can be used to specify separate external files which contain the

4-66
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:

AERSURF primary_surfchar_filename
Syntax:
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.

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.

4.7.9 Output from Stage 3 - OUTPUT and PROFILE

AERMET Stage 3 processing creates two output files for the AERMOD dispersion
model. The first of these files contains the boundary layer parameters and some of the data that
went into computing these parameters. These parameters are stored in the file defined on the
OUTPUT keyword, with the following syntax and type:

4-67
 Syntax: OUTPUT parameter_filename
Type: Mandatory, Nonrepeatable

The parameter_filename must conform to the naming conventions appropriate to the computing
platform. The maximum length of this file name is 96 characters.

There is one record for each hour processed. These data are written with at least one
space between each element, i.e., "free format". The exact format of this file is in Appendix C.
The contents of this file are:

• Year

• Month (1 - 12)

• Julian Day (1 - 366)

• Hour (1 - 24)

• Sensible heat flux, H (Watts/meter2)

• Surface friction velocity, u* (meters/second)

• Convective velocity scale, w* (meters/second)

• Vertical potential temperature gradient in the 500 m layer above the planetary
boundary layer (kelvin/meter)

• Convective mixing height, zic (meters)

• Mechanical mixing height, zim (meters)

• Monin-Obukhov length, L (meters)

• Surface roughness length, zo (meters)

• Bowen ratio, Bo

• Albedo, r (ϕ)

• Wind speed - used in estimating the boundary layer parameters (meters/second)

• Wind direction - direction wind is blowing from (degrees)

4-68
 • Height at which the wind was measured (meters)

• Temperature - used in estimating boundary layer parameters (kelvin)

• Height at which the temperature was measured (meters)

• Precipitation type code (0=none, 11=liquid, 22=frozen, 99=missing)

• Precipitation amount (millimeters/hour)

• Relative humidity (%)

• Station pressure (millibars)

• Cloud cover (tenths)

• Wind speed adjustment flag for adjustment of ASOS wind speed data

(ADJ = adjust, NAD = not adjusted)

• Wind data source flag

(OS = ONSITE pathway input file, SFC = SURFACE pathway input file)

A second file is written during Stage 3 - a file of profile (multilevel) data as identified on
the PROFILE keyword. The syntax and type are:

Syntax: PROFILE profile_filename

Type: Mandatory, Nonrepeatable

The profile_filename must conform to the naming conventions appropriate to the computing
platform. The maximum length of this file name is 96 characters.

There are one or more records for each hour processed. The data are written with at least
one space between each element, i.e., the data are free format. The exact format of this file is in
Appendix C. The contents of this file are:

• Year

4-69
 • Month (1 - 12)

• Day (1 -31)

• Hour (1 - 24)

• Measurement height (meters)

• Top flag = 1, if this is the last (highest) level for this hour

• 0, otherwise

• Direction the wind is blowing from for the current level (degrees)

• Wind speed for the current level (meters/second)

• Temperature at the current level (degrees Celsius)

• Standard deviation of the wind direction fluctuations, σϴ (degrees)

• Standard deviation of the vertical wind speed fluctuations, σw (meters/second)

The data in this latter file are the multilevel (e.g., tower) site-specific meteorological data
if site-specific data are available. If there are no data for a particular variable for an hour, either
at one or all levels, then the field is filled with a missing value indicator. Only the variables
listed above are in this output file. Additional variables that may be specified on the ONSITE
pathway (e.g., the standard deviation of one of the horizontal components of wind) are not
written to this file.

AERMET was designed to be able to perform these dispersion parameter calculations

with NWS data only, i.e., no site-specific data. In this case, the NWS winds and temperature are
used to create a one-level "profile". The NWS data are also used in the event that all the
variables at all levels for a given hour are missing. However, this substitution depends on the
specification of the METHOD REFLEVEL keyword described in Section 4.7.6.

4-70
5.0 Technical notes

This section provides a technical description of the processing methods employed by

AERMET. This includes quality assessment procedures beyond the simple check against upper
and lower bounds, the averaging method used to produce hourly values when site-specific data
contains more than one observation period each hour, and modifications that can be made to
NWS upper air data. The section concludes with a discussion of the estimates of the boundary
layer parameters written to the OUTPUT file.

5.1 Quality assessment procedures

The main quality assessment procedures are similar for all types of data. Each variable
is checked to see if it is missing (its value matches the missing value code), and if not missing,
the value is checked to see if it is between the lower and upper bounds. Appendix B lists the
variables for each type of data, their units, default bounds and missing value codes. A violation
does not necessarily indicate an error in the data. For example, it could mean the bounds are not
reasonable for a particular time of year or location. It is up to the user to determine if the
reported violations constitute errors in the data.

For NWS hourly surface observations, several additional checks between variables are
also performed. NWS surface data are checked for dew-point temperature exceeding dry-bulb
temperature (DPTP > TMPD), and having a zero wind speed (WSPD = 0), indicating calm
conditions, but a non-zero wind direction (WDIR), indicating non-calm conditions, or vice
versa. The number of occurrences of calm wind conditions are also reported.

AERMET estimates the heights reported in the sounding using the hypsometric equation

𝑧2 = 𝑧1 + [(𝑅𝑑 ∗ 𝑇𝑣 ⁄𝑔)] ∗ ln(𝑝1⁄𝑝2 )

where z1 and p1 are the height and pressure at the lower level, z2 and p2 are the height and
pressure at the upper level, Rd is the dry gas constant, Tv is the mean virtual temperature through

5-1
the layer, and g is the gravitational acceleration. The recomputed height is compared to the
reported height. If the difference exceeds 50 meters, then a message is written to the message
file (defined on the MESSAGES keyword). If the surface height is missing, then this check is
skipped.

NWS upper air sounding data contain data for multiple levels, so AERMET will
examine the gradient of several variables within the sounding. AERMET checks four different
between- level gradients. Each is expressed as the change over a 100-meter layer because the
change per meter is usually very small. It is important to remember this distinction if the user
needs to change the default lower or upper bounds. The parameter and associated variable name
in AERMET and the default lower and upper bounds are shown in the table below.

Variable name Default lower Default upper

Parameter
in AERMET bound bound
Ambient temperature gradient UALR -2.0 °C +5.0 °C

Wind speed shear UASS 0.0 m/s | 5.0 m/s |

Wind direction shear UADS 0.0 degrees | 90.0 degrees |
Dew point temperature gradient UADD 0.0 °C 2.0 °C

The vertical gradient of the wind velocity, the wind shear, is a vector quantity. In
AERMET, the shear is computed separately for the speed shear (UASS) and direction shear
(UADS). The wind speed shear is computed as the absolute difference in the speeds between
adjacent levels. Since it is an absolute difference, it is always non-negative. The wind direction
shear is also an absolute difference.

The vertical gradient of the dew point temperature, unlike the other gradients, is
computed using three consecutive levels. An estimate of the dew point at each intermediate
height is found using linear interpolation between the dew points for the adjacent upper and
lower heights. The gradient of the dew point temperature is defined as the absolute difference
between the estimated and the observed dew point temperature at this intermediate level divided
by the difference between the upper and lower heights.
5-2
 The QA on the gradients is summarized with the QA of the observed sounding data.
Because there may be a variable number of levels in a sounding, and the heights of the levels
may differ from sounding to sounding, the results are accumulated into ten height categories.
These are defined as surface, 500 meter layers up to 4000 meters, and above 4000 meters. Thus
the categories are: surface, 0 - 500, 500 - 1000, ..., 3500 - 4000, and 4000+, where each
intermediate category includes the upper but not the lower height. (The "thickness" of the
categories is controlled by the internal variable UAINC. This is specified in a DATA statement
in BLOCK1.INC, and cannot be changed without also recompiling and relinking AERMET.)

Lapse rate and shear violations are tallied in the category containing the upper height,
while those of the dew-point gradient are tallied in the height category of the middle
(intermediate) point. In the absence of missing data and with N levels in a sounding, there
should be N-1 lapse rate and shear calculations, and N-2 dew-point gradient calculations. All
range violations and instances of missing values are reported in the MESSAGES file and
summarized in the general report.

5.2 Identifying ASOS observations

In order to implement the ASOS wind speed adjustment described in Section 4.7.6.3,
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 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
5-3
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.

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
5-4
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
AERMET, or later, will not process surface extraction or merge files generated with an
earlier version of AERMET.

5.3 Validation of NWS surface format by active data 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 5-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.

5-5
 Table 5-1. 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 --- ---

5.3.1 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 non-missing (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

5-6
‘99999’) WBAN number encountered is stored and used to compare against each subsequent
record.

5.3.2 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 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.

5.4 Site-specific data - averaging subhourly values

By default, AERMET assumes that there is one observation period per hour. However,
the on-site data could contain several observation periods during each hour (AERMET allows
up to 12). Since AERMET only computes the boundary layer parameters for one hour averages,
AERMET converts the subhourly observations to an hourly average. The user must tell
AERMET the number of observation periods per hour that are in the site-specific data through
the use of the OBS/HOUR keyword. See Section 4.5.12 for a discussion on how to use this
keyword. The site-specific meteorological guidance document (EPA, 1987) suggests at least
half of this number must be present to calculate an average for the hour. AERMET follows this
guidance and computes an average only when half or more of the subhourly values are not
missing.

5-7
 For most variables, the hourly value is computed as the arithmetic mean. However, the
wind speed and direction are treated differently to differentiate between cases when values are
missing and cases when values are present but below an instrument's threshold. This value is
defined by the user through the mandatory THRESHOLD keyword. Wind speeds less than the
threshold are given a value of one-half the threshold wind speed and the wind direction is set to
missing. The hourly wind speed is then computed as an arithmetic mean, while the hourly wind
direction is computed according to the method given in Section 6.1 of the on-site meteorological
guidance document (EPA, 1987) to properly account for the 0°-to-360° crossover.

To obtain a one-hour average of the standard deviation of the horizontal wind direction,
σθ, the procedure outlined in the Quality Assurance Handbook for Air Pollution Measurement
Systems, Volume IV (EPA, 1989) is followed. This procedure accounts for both the standard
deviation within each subhourly interval and the meander in the wind direction over the entire
hour. The hourly average is given by

𝑛
1 2 2
𝜎𝛳2 − ∑(𝜎𝛳𝑖 + 𝑊𝐷𝑖2 ) − 𝑊𝐷
𝑛
𝑖−1

where σθi is the standard deviation of the horizontal wind for period I, WDi is the average wind

direction for period I, 𝑊𝐷 is the average wind direction over all periods in the hour, and n is the
number of subhourly periods specified on the OBS/HOUR keyword.

5.5 Upper air data modifications

During the extraction of upper air soundings from the raw input DATA file, AERMET
can check for possible errors and reduce the impact of strong gradients in each sounding. If the
MODIFY keyword (Section 4.4.9) is included, the following modifications are performed:

• A mandatory level within 1 percent (with respect to pressure) of a significant level

is deleted;

5-8
 • For a non-zero wind direction with a corresponding zero wind speed, the wind
direction is replaced with zero;

• Missing values of dry bulb and dew-point temperature are replaced by an

interpolated value if the data for the levels immediately above and below are not
missing;

There is no way to turn on individual actions. Either all the actions are performed or
none of them are performed. Warning messages are written if the data are modified.

5.5.1 Mandatory levels

If a mandatory sounding level is within one percent of a significant level (with respect to
pressure) then the mandatory level is deleted, with little of information about the structure of the
atmosphere. If the maximum number of levels of data were extracted (currently set at 30 and is
defined in the variable UAML in UA1.INC), then a sounding may have fewer than the
maximum number of levels because the deletion process takes place after the data in a sounding
are extracted from the archived data file. AERMET does not attempt to read more levels after
deleting a level.

5.5.2 Calm wind conditions

The wind speed and wind direction at each level are checked to insure that there are no
levels with a zero wind speed and a non-zero wind direction. If one is found, the wind direction
is set to zero to represent calm conditions.

5.5.3 Missing dry bulb and dew-point temperatures

If the dry-bulb or dew-point temperature is missing at some level, then an estimate for
the missing temperature is made by linearly interpolating to the level in question. The data from

5-9
the level immediately below and above the level in question are used. If the data that are
required for the interpolation are also missing, then no interpolation is performed.

5.6 Station elevations

Beginning with version 06341, AERMET included the option to specify station
elevation above 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 user-
specified 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, except for one
circumstance. The METPREP LOCATION keyword is now only needed when site-specific
mixing heights are provided during Stage 1 and upper air sounding data are omitted from the
processing. Otherwise, a warning message will be generated if the LOCATION keyword is
included under the METPREP pathway, and the LOCATION parameters will be ignored.
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.

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.

5-10
 2. The station elevation is allowed as an optional argument on the
LOCATION keyword for the SURFACE and ONSITE pathways in
Stage 1.

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, based on the availability of ONSITE and/or SURFACE station pressure, sea-
level pressure and station elevation and depending on the source of ambient temperature data:

1. If ONSITE temperature data are 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;

5-11
 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;

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 millibars (mb) to station pressure.

2. If SURFACE temperature data are 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;

5-12
 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.

5.7 Boundary layer parameter estimates in Stage 3

AERMOD uses several different boundary layer parameters to model how pollutants
disperse in the atmosphere. Many of these parameters are not observed, but are estimated from
other variables that are more easily measured. To make these estimates, observed near-surface
wind and temperature (the 'reference' wind and temperature) and site-specific surface
characteristics are required. The surface characteristics are discussed in detail in Section 2.0
and Section 3.0, but because of the importance in estimating boundary layer parameters, they
are reviewed below. First, however, is a discussion on the criteria for defining the reference
wind and temperature.

5.7.1 Reference wind and temperature

If there are site-specific data in the meteorological input to Stage 3, then AERMET
searches these data for near-surface wind and temperature with which to estimate the boundary
layer parameters such as friction velocity and heat flux.

A valid reference wind is defined as the lowest level with a non-missing wind speed and
direction between 7z0 and 100 meters (inclusive), where z0 is the surface roughness length. If
5-13
the only valid non-missing wind speed is a calm wind, then the hour is treated as a calm and the
reference level is the lowest level of non-missing wind.

If there is no valid reference wind, then the lowest level is treated as the reference level
and the reference wind is missing. However, if the option to substitute NWS data is specified in
the control file (see Section 4.7.6.2 for the keyword METHOD, secondary keyword
REFLEVEL), then AERMET will substitute the NWS hourly wind speed observations for the
reference wind speed and use the height specified with the keyword NWS_HGT (see Section
4.7.4) as the reference height. If NWS substitution is not specified, then the reference wind will
be missing.

The selection of the reference temperature is independent of the selection of the

reference wind. A valid reference temperature is defined as the lowest level with a non-missing
temperature between z0 and 100 meters (inclusive). If there is no valid reference temperature in
the site-specific data and the option to substitute NWS data is specified in the control file, then
AERMET will substitute the NWS hourly ambient temperature for the reference temperature.

In the absence of site-specific data, the METHOD keyword with the REFLEVEL
secondary keyword must be specified for AERMET to utilize NWS wind and temperature data
for the reference level data (see Section 4.7.6.2). NWS data currently are not subject to the
criteria above for either wind or temperature.

5.7.2 Surface characteristics

The atmospheric boundary layer is that region between the earth's surface and the
overlying, free flowing (geostrophic) atmosphere. The fluxes of heat and momentum drive the
growth and structure of this boundary layer. The depth of this layer, and the dispersion of
pollutants within it, are influenced on a local scale by surface characteristics, such as the
roughness of the underlying surface, the reflectivity of the surface (or albedo), and the amount
of moisture available at the surface. From these input parameters and observed atmospheric
variables, AERMET calculates several boundary layer parameters that are important in the
5-14
evolution of the boundary layer, which, in turn, influences the dispersion of pollutants. These
parameters include the surface friction velocity u*, which is a measure of the vertical transport
of horizontal momentum; the sensible heat flux H, which is the vertical transport of heat to/from
the surface; the Monin-Obukhov length L, a stability parameter relating u* and H; the daytime
mixed layer height zi and the nocturnal surface layer height h; and w*, the convective velocity
scale that combines zi and H. These parameters all depend on the characteristics of the
underlying surface.

Although very general default values exist in AERMET, the user should specify the
albedo (r), which is the fraction of radiation reflected by the surface; the daytime Bowen ratio,
B0, which is the ratio of the sensible heat flux H to the heat flux used in evaporation λE; and the
surface roughness length z0, which is the height above the ground at which horizontal wind
velocity is typically zero. These measures depend on land-use type (e.g., urban area,
deciduous/coniferous forest, cultivated land, calm waters) and vary with the seasons (See Table
4-2 through Table 4-6) and wind direction.

The user specifies these values on SITE_CHAR keyword statements for one, four or 12
(ANNUAL, SEASONAL, or MONTHLY) time periods per year, and 1 - 12 non-overlapping,
contiguous wind direction sectors that cover the full 360°. The user is referred to Section 2.2.4,
Section 3.1.3, and Section 4.7.8 for detailed discussions on these parameters.

5.7.2.1 Choice of sector-dependent surface characteristics

In defining sectors for surface characteristics, Irwin (1994) and EPA (2000) suggest that
a user specify a sector no smaller than a 30-degree arc. The expected wind direction variability
over the course of an hour, as well as the encroachment of characteristics from the adjacent
sectors with travel time, make it hard to preserve the identity of a very narrow sector's
characteristics. However, using a weighted average5 of characteristics by surface area within a

5
Weighting should be based on wind direction frequency, such as determined from a wind rose
5-15
30-degree sector makes it possible to have a unique portion of the surface significantly influence
the properties of the sector that it occupies.

The length of the upwind fetch for defining the nature of the turbulent characteristics of
the atmosphere at the source location has been defined as 3 kilometers in EPA's Guideline on
Air Quality Models, which is published as Appendix W to 40 CFR Part 51 (as revised), for the
purpose of defining urban versus rural dispersion characteristics. This specification results from
a paper by Irwin (1978), which also cites a study by Högström and Högström (1978). The basic
premise is that when the wind blows over an area with a change in its surface characteristics, a
new "boundary layer" with the turbulent characteristics of the underlying surface develops and
deepens along the wind direction. Högström and Högström present tabular results for the
boundary layer growth as a function of roughness length in rural areas. Irwin (1978) noted that
the region of enhanced turbulence with a depth of 400 meters was reported by Shea and Auer
(1978) for St. Louis, and curves based on the Högström and Högström data indicate that a 3-km
fetch would attain this boundary layer height. The resulting 3-km fetch was also adopted by
METPRO (Paine, 1987), the CTDMPLUS meteorological pre-processor for its definition of
sector-specific surface characteristics.

For a surface with a large roughness, however, the rate of the boundary layer growth as
defined by Högström and Högström (1978) could be sufficiently rapid so as to grow to a depth
of 400 meters within 1 kilometer downwind. In the case of a lower boundary layer depth, such
as 100 meters, the Högströms calculate that the distance needed to attain an urban-influenced
boundary height of just 100 meters with a surface roughness ranging from 0.5 to 1.5 meters is
only about 250 meters for unstable (convective) conditions, 700 meters for neutral conditions,
and 1330 meters for slightly stable conditions.

For AERMET applications, an upwind fetch distance of 3 kilometers is recommended

for defining user-specified values such as albedo, Bowen ratio, and surface roughness. In each
sector, it is likely that a mixture of land use is present, and the resulting user input should be a
weighted average of the values selected for each land use type. For urban areas or areas with a
very large roughness length, consideration can be given for a smaller upwind fetch distance for
5-16
defining the user-specified surface characteristics. The actual fetch length selected would be a
function of the expected plume height, the roughness length, and any urban heat flux that would
tend to minimize the presence of stable conditions in the surface layer. Högström and Högström
(1978) can be used as guidance in these cases.

5.7.3 Estimates for the unstable atmosphere

As defined in AERMET, the atmosphere is unstable if the flux of sensible heat is upward
at the surface, and the time of day is approximately between sunrise and sunset. During daytime
convective conditions, the surface of the earth is heated, resulting in an upward transport of
heat. Hourly estimates of this heat flux are required to estimate the daytime mixed layer height.
The estimates here follow the development of Holtslag and van Ulden (1983). Beginning with
the surface energy balance, the sensible heat flux is determined hour-by-hour from the net
radiation and Bowen ratio. AERMET first looks for net radiation (from the site-specific data)
and uses it if found. If there is no net radiation, then AERMET looks for solar radiation (again
from the site-specific data) and uses it with temperature and opaque cloud cover (from the
NWS) to estimate net radiation. If there is no solar radiation, then it is estimated as described
below from cloud cover and surface temperature (using site-specific observations if available,
NWS data if not), Bowen ratio, and albedo. Once the heat flux is computed, u* and L are

determined through an iterative procedure using surface layer similarity. While u* and L change
with each iteration, the hourly heat flux remains fixed.

A simple equation that expresses the energy balance at the earth's surface for rural
applications is:

𝑅𝑛 − 𝐻 + 𝜆𝐸 + 𝐹𝐺 5.1

where Rn is the net radiation, λE is the latent heat flux, and FG is the flux of heat into the
ground. Following Holtslag and van Ulden (1983), FG = 0.1 Rn. Using this estimate for FG and
the Bowen ratio (B0 = H/λE) yields the following expression for H:

5-17
 𝐻 = 0.9𝑅𝑛 /(1 + (1/𝐵0 ) 5.2

Net radiation Rn can either be an observed quantity from site-specific data (variable
NRAD) or it can be estimated from the total incoming solar radiation, R (variable INSO), as
follows:
𝑅𝑛 = (1 − 𝑟(𝜙))𝑅 − 𝐼𝑛 5.3

where r(ϕ) is the surface albedo as a function of solar elevation angle (ϕ), and In is the net long-
wave radiation at the earth's surface.

In the general case in which clouds are present, R is computed using the following
estimate from Kasten and Czeplak (1980)

𝑅 = 𝑅0 (1 + 𝑏1 𝑛𝑏2 ) 5.4

where R0 is the incoming solar radiation at ground level for clear skies, and n is the fractional
opaque cloud cover (variable TSKC). The empirical coefficients b1 and b2 are assigned the
values of -0.75 and 3.4, respectively (from Holtslag and van Ulden, 1983). If cloud cover and
observed net radiation are missing for a particular hour, no further calculations can be made for
that hour. A warning message is written in this case.

The incoming solar radiation for clear skies R0 is given by

𝑅0 = 𝑎1 𝑠𝑖𝑛 𝜙 + 𝑎2 5.5

where ϕ is the solar elevation angle, a1 = 990 Wm-2 and a2 = -30 Wm-2. The constants a1 and a2
account for attenuation of the short wave radiation by water vapor and dust in the atmosphere.
The values used by AERMET are appropriate for mid-latitudes (Holtslag and van Ulden
(1983)).

5-18
 Substituting Eqs. 5.4 and 5.5 into 5.3 and parameterizing the net long-wave radiation as
a function of temperature (T) and cloud cover (n), Holtslag and van Ulden (1983) estimate the
net radiation as:

(1 − 𝑟(𝜙))𝑅 + 𝑐1 𝑇 6 − 𝜎𝑆𝐵 𝑇 4 + 𝑐2 𝑛
𝑅𝑛 = 5.6
1 + 𝑐3

where σSB= 5.67 × 10-8 W m-2 K-4 is the Stefan-Boltzmann constant and the other empirical

constants are as follows: c1 = 5.31 × 10-13 W m-2 K-6, c2 = 60 W m-2, c3 = 0.12.

The surface albedo supplied by the user should be for solar elevation angles above 30°,
for which the albedo is relatively constant. However, the albedo increases for lower angles
(Coulson and Reynolds (1971) and Iqbal (1983)). An empirical expression for the albedo as a
function of solar elevation angle is given by

𝑟(𝜙) = 𝑟 ′ + (1 − 𝑟)𝑒 𝑎𝜙+𝑏 5.7

(Paine, 1987) where r' is the albedo for the sun on the meridian as entered by the user as a site-
specific surface characteristic, ϕ is the solar elevation angle, a = -0.1, and b = -0.5 (1 – r')2.

With an estimate of the heat flux, AERMET next estimates the surf ace friction velocity
u* and the Monin-Obukhov length L for the convective boundary layer (CBL) through an
iterative procedure. (The technique used is similar to that used in the METPRO meteorological
preprocessor (Paine, 1987). The two equations for u* and L used in the iteration algorithm are:

𝑘𝑢
𝑢∗ =
𝑙𝑛(𝑧𝑟𝑒𝑓 ⁄𝑧0 ) − 𝛹𝑚 (𝑧𝑟𝑒𝑓 ⁄𝐿) + 𝛹𝑚 (𝑧0 ⁄𝐿)
5.8

𝜌𝑐𝑝 𝑇𝑢∗3
𝐿=− 5.9
𝑘𝑔𝐻

where:
5-19
 k is the von Karman constant (0.4),
u is the reference height wind speed (meters/second),
zref is the wind speed and direction reference height (as discussed in Section 3.1.4),
z0 is the surface roughness length (meters),
ρ is the density of dry air (kilograms/cubic meter),
cp is the specific heat capacity of air (Joules/kilogram/kelvin),
T is ambient temperature (kelvin), and
g is the acceleration due to gravity (meters/second/second).

The Ψ terms are given by:

1+𝜇 1 + 𝜇2
𝛹𝑚 (𝑧𝑟𝑒𝑓 ⁄𝐿) = 2 𝑙𝑛 ( ) + 𝑙𝑛 ( ) − 2𝑡𝑎𝑛−1 (𝜇) + 𝜋⁄2 5.10
2 2
1 + 𝜇0 1 + 𝜇02
𝛹𝑚 (𝑧0 ⁄𝐿) = 2 𝑙𝑛 ( ) + 𝑙𝑛 ( ) − 2𝑡𝑎𝑛−1 (𝜇0 ) + 𝜋⁄2 5.11
2 2

and

µ = (1 − 16𝑧𝑟𝑒𝑓 ⁄𝐿)1⁄4 5.12

µ0 = (1 − 16𝑧0 ⁄𝐿)1⁄4 5.13

This procedure requires an initial guess for u*, which is found by initially setting the Ψ

terms to zero. The iteration continues until consecutive values of L differ by 1% or less.

The estimate of the convectively-generated (or convective) mixing height (zic) is based
on the formulation by Carson (1973) and modified by Weil and Brower (1983). The Carson
model is based on a one-dimensional (height) energy balance approach, in which the heat flux in
the base of the elevated temperature inversion, and an increase of the energy of the boundary
layer air. The original Carson model is based on an initial (early morning) potential temperature
profile that is assumed to be linear with height. Weil and Brower (1983) extended Carson's
model to an arbitrary initial temperature distribution with height and allowed for stress-induced
mixing at top of the PBL. The latter can be important when the heat flux is small, e.g., in the

5-20
early morning or on overcast days. In AERMET, the stress-induced mixing at the top of the
mixed layer is ignored. An operational advantage of the arbitrary temperature distribution is the
ease of adapting it to initial profiles that are very irregular, as is sometimes found in early
morning rawinsondes.

Weil and Brower find zic implicitly from the following equation:

𝑧𝑖𝑐 𝑡
𝐻(𝑡 ′ )
𝑧𝑖𝑐 𝜃(𝑧𝑖𝑐 ) − ∫ 𝜃(𝑧)𝑑𝑧 = (1 + 2𝐴) ∫ 𝑑𝑡 5.14
0 0 𝜌𝑐𝑝

where θ(z) is the initial potential temperature distribution (from the selected morning sounding)
and the right-hand-side represents the cumulative heat flux input at z = 0, and A = 0.2
(Deardorff, 1980). AERMET restricts the growth of the convective mixing height to 4000
meters.

Once zic is found, the turbulent velocity scale w* can be found from the following
definition:

𝑤∗ = (𝑔𝐻𝑧𝑖𝑐 ⁄𝜌𝑐𝑝 𝑇)1⁄3 5.15

5.7.4 Estimates for the stable atmosphere

The stable boundary layer (SBL) calculations, based on an approach outlined by

Venkatram (1980), are straight-forward and do not require an iterative process as is used in the
CBL calculations. Estimates of u* and θ*, a temperature scale, are made from cloud cover, wind

speed and temperature, which, in turn, provides an estimate of the heat flux. The Monin-
Obukhov length then is computed directly from Eq. 5.9.

Using H = -D cp u* θ* in Eq. 5.9 and

𝑢 𝑧𝑟𝑒𝑓 𝑧𝑟𝑒𝑓
𝑘 = 𝑙𝑛 ( ) + 𝛽𝑚
𝑢∗ 𝑧0 𝐿

5-21
the friction velocity is obtained from

⁄ 2 1⁄2
𝑢∗ = 𝐶𝐷 𝑢⁄2 (1 + (1 − (2𝑢0 ⁄𝐶𝐷1 2 𝑢) ) ) 5.16

where CD is the neutral drag coefficient given by

𝑘
𝐶𝐷 = 𝑙𝑛(𝑧 , 5.17
𝑟𝑒𝑓 ⁄𝑧0 )

u0 is

𝑢0 = (𝛽𝑚 𝑧𝑟𝑒𝑓 𝑔𝜃∗ ⁄𝑇)1⁄2 5.18

and βm = 4.7 is a dimensionless constant. An estimate for the temperature scale θ* (in kelvin) is
given by

𝜃∗ = 0.09(1 − 0.5𝑛2 ) 5.19

where n is the fractional opaque cloud cover.

To obtain real-valued solutions for u*, the following condition must be true:

4𝑢02 ⁄(𝐶𝐷2 𝑢2 ) ≤ 1 5.20

Equality in the above condition corresponds to a minimum (critical) wind speed, ucr. For wind
speeds equal to or greater than ucr, a real-valued solution to Eq. 5.16 is obtained. The critical
wind speed is given by

𝑢𝑐𝑟 = (4 𝛽𝑚 𝑧𝑟𝑒𝑓 𝑔𝜃∗ ⁄(𝑇𝐶𝐷 ))1⁄2 5.21

For this value, there is a corresponding friction velocity, u*cr, such that

5-22
 𝑢∗𝑐𝑟 = 𝐶𝐷 𝑢𝑐𝑟 ⁄2 5.22

For wind speeds less than this critical value, Eq. 5.16 no longer yields a real-valued
solution. It is desirable to have u* → 0 as u → 0. Therefore, for u < ucr, u*cr is scaled by the ratio
u / ucr, and u* is calculated as

𝑢
𝑢∗ = 𝑢∗𝑐𝑟 5.23
𝑢𝑐𝑟

For u < ucr, van Ulden and Holtslag (1985) showed that there is a near-linear variation of
θ* with u*. Therefore, θ* is scaled similarly as

𝑢∗
𝜃∗ = 𝜃∗𝑐𝑟 5.24
𝑢∗𝑐𝑟

where θ*cr is given by 5.19.

With u* from Eq. 5.16 or 5.23 and θ* from Eq. 5.19 or 5.24, the heat flux for the stable
atmosphere is computed from

𝐻 = −𝜌𝑐𝑝 𝑢∗ 𝜃∗ . 5.25

Finally, using these estimates of u* and H, L is computed from Eq. 5.9.

In the case of strong winds, H may become unrealistically large. Therefore, a limit
of -64 Wm-2 is placed on the heat flux, which forces a limit on the product u* θ*. This yields a
cubic equation in u*, which is solved to obtain a new u*. With this value for u* and
H = -64 Wm-2, L is recomputed from Eqs. 5.9 and 5.25.
5-23
 The mechanically-generated (or mechanical) mixing height (zim) is found from the
diagnostic expression given by Venkatram (1980):

⁄
𝑧𝑖𝑚 = 2300𝑢∗3 2 . 5.26

Since w* is a scaling parameter for convective conditions, it is not computed for the
stable atmosphere.

5.7.5 More on mixing heights

Mixing heights in AERMET are given special attention. During stable conditions, when
L > 0, the mechanical mixing height is computed. During unstable conditions, defined when
L < 0, both the convective and mechanical mixing heights are computed. As long as no data are
missing to make the computations, this procedure yields a continuous record of mechanical
mixing heights while the record for convective mixing heights is restricted to daytime hours of
upward heat flux.

The mechanical mixing heights are smoothed so that the effect of any large hour-to-hour
fluctuations of the surface friction velocity on zim is reduced. The smoothing is performed for
all hours - stable and unstable. The smoothed mechanical mixing height for the current hour
(t+Δt) is given by:

̅̅̅̅̅̅̅̅̅̅̅ 𝑧𝑖𝑚(𝑡) −𝛥𝑡⁄𝜏 + 𝑧𝑖𝑚(𝑡+𝛥𝑡) [1 − 𝑒 −𝛥𝑡⁄𝜏 ]

𝑧𝑖𝑚(𝑡+𝛥𝑡) = ̅̅̅̅̅̅̅𝑒 5.27

where
𝑧𝑖𝑚(𝑡)
𝜏=
𝛽𝜏 𝑢∗ (𝑡 + 𝛥𝑡)

and βτ= 2.0. The term with the overbar on the right hand side of Eq. 5.27 is the smoothed
mechanical mixing height for the previous hour (t), zim(t+Δt) is the unsmoothed mechanical

5-24
mixing height for the current hour (t+Δt) as determined from Eq. 5.26, and u*(t+Δt) is the
surface friction velocity for the current hour. If (t+Δt) is the first hour in the data base, then no
smoothing is performed. Furthermore, if a missing mixing height occurs at time t, then the
smoothing restarts at time (t+Δt).

Both the smoothed mechanical and convective mixing heights are written to the output
file for AERMOD.

The convective mixing height relies on the selected morning sounding. AERMET
retrieves data up to and including the first measurement level above 5000 meters. Occasionally,
the sounding is lost at a low level (well below 5000 meters). When this situation happens, there
may not be sufficient upper air data to allow AERMET to calculate the convective mixing
height for all the daytime hours, particularly the late afternoon hours. To alleviate problems
such as this, AERMET extends the sounding to 5000 meters by computing the potential
temperature gradient in the upper 500 meters of the sounding and extends the sounding to 5000
meters as follows:

𝑑𝜃
𝜃(5000) − 𝜃(𝑧𝑡𝑜𝑝 ) + | (5000 − 𝑧𝑡𝑜𝑝 )
𝑑𝑧 500

where ztop is the height of the original sounding and dθ/dz|500 is the potential temperature gradient
in the upper 500 meters of the sounding. Messages are written to the message file at various
stages: reports of soundings that do not extend to 5000 meters are reported in the Stage 1 QA; in
Stage 3, the height of the original sounding and the potential temperature gradient that is used to
extend the sounding is reported, as well as those periods when the sounding extension was
required to compute a convective mixing height.

5-25
6.0 References

Auer, A.H. Jr. (1978): Correlation of land use and cover with meteorological anomalies. J.
Appl. Meteor., 17, 636-643.

Carson, D. J. (1973). The development of a dry inversion-capped convectively unstable

boundary layer. Quart. J. Royal Meteor. Soc., 99:450-467.

Coulson, K. L., and D. W. Reynolds (1971). The Spectral Reflectance of Natural Surfaces. J.
Appl. Meteor., 18:1495-1505.

Deardorf, J. W. (1980). Progress in understanding entrainment at the top of a mixed layer.

Workshop on the Planetary Boundary Layer, J. C. Wyngaard (ed.). American
Meteorological Society, Boston, MA, pp. 36-66.

EPA (1987). On-Site Meteorological Program Guidance for Regulatory Modeling Applications.
EPA-450/4-87-013, U.S. Environmental Protection Agency, Research Triangle Park, NC.

EPA (1989). Quality Assurance Handbook for Air Pollution Measurement Systems, Volume IV -
Meteorological Measurements. U.S. Environmental Protection Agency, Research
Triangle Park, NC.

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.

EPA (2000). Meteorological Monitoring Guidance for Regulatory Modeling Applications.

EPA-454/R-99-005. Office of Air Quality Planning & Standards, Research Triangle
Park, NC. (PB 2001-103606)

EPA (2008). AERSURFACE User’s Guide. EPA-454/B-08-001. U.S. Environmental Protection

Agency, Research Triangle Park, North Carolina.

EPA (2015). AERMINUTE User's Guide. EPA-454/B-15-006. U.S. Environmental Protection

Agency, Research Triangle Park, North Carolina.

EPA (2018). Guidance on the Use of the Mesoscale Model Interface Program (MMIF) for
AERMOD Applications. EPA-454/B-18-005. U.S. Environmental Protection Agency,
Research Triangle Park, North Carolina.

Högström and Högström (1978). A Practical Method for Determining Wind Frequency
Distributions for the Lowest 200 m from Routine Data. J. Appl. Meteor., 17, 942-954.

6-1
Holtslag, A.A.M., H.A.R. de Bruin, and A.P. van Ulden (1980). Estimation of the Sensible Heat
Flux from Standard Meteorological Data for Stability Calculations during Daytime.
Proceedings of the 11th International Technical Meeting on Air Pollution Modeling and
Its Applications. Plenum Press, Amsterdam, pp. 401-407.

Holtslag, A. A. M. and A. P. van Ulden (1983). A Simple Scheme for Daytime Estimates of the
Surface Fluxes from Routine Weather Data. J. Climate Appl. Meteor., 22:517-529.

Iqbal, M. (1983). An Introduction to Solar Radiation, Academic Press, NY.

Irwin, J.S. (1978). Proposed Criteria for Selection of Urban Versus Rural Dispersion
Coefficients. Staff Report. Meteorology and Assessment Division, U.S. Environmental
Protection Agency, Research Triangle Park, NC. (Air Docket Reference No. II-B-8 for
the Fourth Conference on Air Quality Modeling).

Irwin, J.S. (1994). Personal Communication with Robert J. Paine, ENSR.

Kasten, F. and G. Czeplak (1980). Solar and Terrestrial Radiation Dependent on the Amount
and Type of Cloud. Solar Energy, 24:177-189.

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.

NCDC (1998). Data Documentation for TD 6200 NCDC Upper Air Digital Files. National
Climatic Data Center, Asheville, North Carolina.

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

Oke, T. R. (1978). Boundary Layer Climates, John Wiley and Sons, New York.

Oke, T.R. (1982): The energetic basis of the urban heat island. Quart. J.Royal Meteor. Soc.,
108, 1-24.

Paine, R. J. (1987). User's Guide to the CTDM Meteorological Preprocessor (METPRO)

Program. EPA-600/8-88-004, U.S. Environmental Protection Agency, Research Triangle
Park, NC. (NTIS No. BP 88-162102).

Priestly, C.H.B. and R.J. Taylor (1972). On the Assessment of Surface Heat Flux and
Evaporation Using Large Scale Parameters. Mon. Wea. Rev., 100: 81-92.
6-2
Stull, R. B. (1988). An Introduction to Boundary Layer Meteorology. Kluwer Academic
Publishers, Dordrecht, The Netherlands, 666 pages.

Summers, P. W. (1965). An Urban Heat Island - Its Role in Air Pollution Problems, with
Application to Montreal. First Canadian Conference on Micrometeorology. 12-14 April
1965, Toronto, Canada. 29 pp.

Qian, W., and A. Venkatram (2011). Performance of Steady-State Dispersion Models Under
Low Wind-Speed Conditions. Boundary Layer Meteorology, 138, 475-491.

van Ulden, A. P., and A. A. M. Holtslag (1985). Estimation of Atmospheric Boundary Layer
Parameters for Diffusion Applications. J. Climate Appl. Meteor., 24:1196-1207.

Venkatram, A. (1980). Estimating the Monin-Obukhov Length in the Stable Boundary Layer for
Dispersion Calculations. Bound.-Layer Meteor., 19:481-485.

Weil, J. C., and R. P. Brower (1983). Estimating Convective Boundary Layer Parameters for
Diffusion Applications. Draft Report, prepared by the Environmental Center, Martin
Marietta Corp, for the state of Maryland.

6-3
Appendix A. Functional keyword/parameter reference

This appendix provides a functional reference for the keywords and parameters used by
the input control 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

A-1
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 control file
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 of double
quotes (“) as field delimiters for filenames is allowed to support filenames with embedded
spaces

A-2
 Table A-1. Description of Job Pathway Keywords
Keyword Type Description

JOB Optional, Start of JOB pathway. This statement is optional if the statements
Non-repeatable associated with this block appear first in the input control file.

CHK_SYNTAX Optional, Non- Flag indicating that only the syntax of the input statements should be
repeatable checked for errors, i.e., no data are processed.

MESSAGES Mandatory, Non- Identifies the warning/error messages file.

repeatable

REPORT Optional, Non- Identifies the general report file.

repeatable

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-3
 Table A-3. Description of UPPERAIR Keywords
Keyword Type Description

UPPERAIR Conditional, Start of UPPERAIR pathway.

Non-repeatable

AUDIT Optional, Repeatable Identify variables to be audited. These are in addition to any
automatically audited variables.

DATA Mandatory, Non-repeatable, File name of raw upper air data.

Reprocessed

EXTRACT Mandatory, Non-repeatable File name of extracted upper air data.

LOCATION Mandatory, Non-repeatable, Site ID and location information. Required only for extraction
Reprocessed processing.

MODIFY Optional, Non-repeatable, Flag indicating corrections should be made to the sounding
Reprocessed 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, Set new upper and lower bounds and missing values for QA of
Reprocessed the variable listed.

XDATES Mandatory, Non-repeatable Inclusive dates identifying the period of time to extract from
the archive data file.

A-4
 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

archive_filename The name of the file containing the archive of upper air data
where:
file_format 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 Centers for
Environmental Information (NCEI) web site. Also
available on the ‘Radiosonde Data of North America’ CD-
ROM and online from the National Oceanic and
Atmospheric Administration (NOAA) Earth System
Research Laboratory (ESRL) Radiosonde Database at
http://esrl.noaa.gov/raobs/.

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.

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-5
Keyword Parameter(s)

LOCATION site_id lat(long) long(lat) [tadjust]

where: site_id Site identifier for which data are to be processed.

lat(long) 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).

long(lat) 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).

[tadjust] 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 . . . Suppresses missing data messages for the upper air variables
. . . uanameN 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-6
Keyword Parameter(s)

RANGE uaname lower_bound <[=] upper_bound missing_indicator

where: uaname Variable name, as defined in Table B-1

lower_bound Minimum value of the valid range of values for uaname

<[=] Exclude (<) or include (<=) the lower and upper bounds (the
endpoints) in the QA

upper_bound Maximum value of the valid range of values for uaname

missing_indicator Value to indicate the value is missing

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

YB/MB/DB 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
[TO]
Optional; used to make this record more readable
YE/ME/DE
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-7
 Table A-5. Description of SURFACE Pathway Keywords
Keyword Type Description

SURFACE Conditional, 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, Input file name of raw surface data.

Reprocessed

EXTRACT Mandatory, Non-repeatable File name of extracted surface data.

LOCATION Mandatory, Non-repeatable, Site ID and location information.

Reprocessed

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, Set new upper and lower bounds and missing values for QA of
Reprocessed the variable listed.

XDATES Mandatory, Non-repeatable Inclusive dates identifying the period of time to extract from the
archive data file.

A-8
 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 ... Name(s) of variables that are to be tracked and reported during quality
... sfnameN assessment (as defined in Table B-2 of Appendix B).

DATA archive_filename file_format [ASOS]

A-9
 archive_filename The name of the file containing the archive of hourly surface observations
where:
file_format 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)

[ASOS] 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
Keyword Parameter(s)

EXTRACT extracted_data_filename

where: extracted_data_filenam Name of the output file for data extracted from an archive data file
e

LOCATION site_id lat(long) long(lat) [tadjust] [elevation]

where: site_id Site identifier for which data are to be processed.

lat(long) 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).
long(lat) 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).
[tadjust] 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).
[elevation] Station elevation (m above sea-level); default of 0m if omitted.

NO_MISSING sfname1 . . . sfnameN

where: sfname1 . . . Suppresses missing data messages for the surface variables specified, as
. . . sfnameN 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-11
Keyword Parameter(s)

RANGE sfname lower_bound <[=] upper_bound missing_indicator

where sfname Variable name, as defined in Table B-2

lower_bound Minimum value of the valid range of values for sfname
<[=] Exclude (<) or include (<=) the lower and upper bounds in the QA
upper_bound Maximum value of the valid range of values for sfname
missing_indicator Value to use to indicate the observed variable is missing

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

where YB/MB/DB 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
[TO] Optional; used to make this record more readable
YE/ME/DE 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, Input file name of site-specific data.

Reprocessed

DELTA_TEMP Optional, Repeatable, Define heights (meters) for temperature differences.

Reprocessed

FORMAT Mandatory, Repeatable, FORTRAN format for reading one site-specific data record.
Reprocessed

LOCATION Mandatory, Non-repeatable, Site ID and location information.

Reprocessed

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, Define heights of the site-specific measurements.

*
Reprocessed Mandatory if the heights are not defined in the data file.

QAOUT Mandatory, Non-repeatable File name of site-specific data for quality assessment
output/merge input

RANGE Optional, Repeatable, Set new upper and lower bounds and missing values for QA of
Reprocessed the variable listed.

READ Mandatory, Repeatable, Defines the name and order of variables as they appear in the
Reprocessed site-specific DATA file.

A-13
 Keyword Type Description

THRESHOLD Mandatory, Non-repeatable, Sets the minimum wind speed (meters/second) below which
Reprocessed 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 . . . Name(s) of variables, as defined in Table B-3 of Appendix B, that are to
. . . osnameN 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 Index for the ith temperature difference measurement

lower_height Lower measurement height for the ith temperature difference

upper_height Upper measurement height for the ith temperature difference

FORMAT record_index Fortran_format

where: record_index Specifies the record # in the ONSITE data to which the Fortran format
refers; linked to record_index on corresponding READ keyword

Fortran_format 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 control file 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

A-15
 will cause an AERMET runtime error. See Section 2.4 for a more
detailed discussion of the READ and FORMAT keywords.

LOCATION site_id lat(long) long(lat) [tadjust] [elevation]

where: site_id Site identifier for which data are to be processed.

lat(long) 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).

long(lat) 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).

[tadjust] An integer used to convert the time reported in the database to local
Standard time. For most onsite databases, the value is 0.

[elevation] Station elevation (m above sea-level); default of 0m if omitted.

NO_MISSING osname1 . . . osnameN

where: osname1 . . . Suppresses missing data messages for the ONSITE variables specified,
osnameN 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 . . . 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

A-16
 order from lowest to highest height. If the OSHEIGHTS keyword is
heightN 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-17
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 Variable name, as defined in Table B-3.

lower_bound 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.

upper_bound Maximum value of the valid range of values for osname.

missing_indicator 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 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 control 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
osname1 ...
are to be read. See Appendix B for ONSITE variable names.
osnameN
See Section 2.4 for a more detailed discussion of the READ and
FORMAT keywords.

A-18
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 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.
[TO]
Optional; used to make this record more readable.
YE/ME/DE
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-19
 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 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.

[TO] Optional; used to make this record more readable.

YE/ME/DE 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-20
 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, Number of surface characteristics by wind direction sector and
Reprocessed 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, Number of surface characteristics by wind direction sector and
Reprocessed 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.

A-21
Keyword Type Description and Usage

LOCATION Conditional*, Non- The LOCATION keyword under the METPREP pathway in
repeatable Stage 3 is no longer used by AERMET, unless ONSITE mixing
heights are used without any UPPERAIR data.

If UPPERAIR data are For applications with UPPERAIR data, sunrise for CBL height
available (with or without calculations is based on the primary surface station location in
ONSITE mixing heights): Stage 1; either the ONSITE pathway, if available, or the
OBSOLETE 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.

Beginning with AERMET For applications with only ONSITE mixing heights, without
version 13350, if ONSITE UPPERAIR data, the LOCATION keyword under the
mixing heights are used METPREP should be used to specify the conversion from
without UPPERAIR data: GMT to LST.
Mandatory

METHOD Conditional*, Specify processing methodology used for a particular variable.

*
Repeatable whether or not this keyword is mandatory depends on the
processing to be performed and the types of data included in
the merged database

MODEL Optional, Non-repeatable Name of model for which data are processed. Default:
AERMOD

NWS_HGT Conditional*, Non- NWS instrument height, in meters, for the specified variable.
*
repeatable Mandatory if METHOD REFLEVEL SUBNWS is specified

SECTOR Mandatory, Repeatable, Defines a wind direction sector in degrees for the primary
Reprocessed location. See also FREQ_SECT and SITE_CHAR.

SECTOR2 Conditional**, Repeatable, Defines a wind direction sector in degrees for the secondary
Reprocessed location. See also FREQ_SECT2 and SITE_CHAR2.

A-22
Keyword Type Description and Usage

SITE_CHAR Mandatory, Repeatable, Define the direction-dependent surface characteristics of

Reprocessed albedo, Bowen ratio, and surface roughness length (meters) for
the primary location. See also FREQ_SECT and SECTOR.

SITE_CHAR2 Conditional**, Repeatable, Define the direction-dependent surface characteristics of

Reprocessed 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-23
 Table A-12. Description of Keyword Parameters for the METPREP Pathway
Keyword Parameter(s)

AERSURF primary_surfchar_filenam (for primary surface data location)

AERSURF2 secondary_surfchar_filenam (for optional secondary surface data location)

where: primary_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)
secondary_surfchar_filenam
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 frequency number_of_sectors (for primary surface data location)

FREQ_SECT2 frequency number_of_sectors (for optional secondary surface data location)

where: frequency 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

number_of_sectors Specifies the number of wind direction sectors by which the

surface characteristics vary

A-24
Keyword Parameter(s)

LOCATION site_id lat(long) long(lat) [tadjust] [elevation]

where: site_id Site identifier for which data are to be processed.

lat(long) 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).

long(lat) 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).

[tadjust] 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).

[elevation] 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.

METHOD atmos_variable option

where: atmos_variable 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

A-25
Keyword Parameter(s)

TEMP – option to substitute for missing temperature

option 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 10º
or RANDOM – randomize NWS wind directions (default).
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* – 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.

A-26
Keyword Parameter(s)

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.

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 Weather variable that requires an instrument height to be defined; valid
names are:

WIND (to specify anemometer height)

instrument_heigh Height of the instrument above ground, in meters.

t

OUTPUT parameter_filename

where: parameter_ Name of the output file from STAGE 3, with one record per hour
filename

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

A-27
Keyword Parameter(s)

SECTOR sector_index beginning_direction ending_direction (for primary data location)

SECTOR2 sector_index beginning_direction ending_direction (for optional secondary data location)

where: sector_index Index that links a specific set of site characteristics to a specific wind
sector.

beginning_directi Specifies the beginning wind direction of the sector, and is considered a
on part of this sector.

ending_direction 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.

SITE_CHAR frequency_index sector_index albedo Bowen roughness (for primary data location)

SITE_CHAR2 frequency_index sector_index albedo Bowen roughness (for secondary data location)

where: frequency_index 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_index Sector corresponding to direction from which the wind is blowing.
albedo Albedo for the frequency index and sector index specified.
Bowen Bowen ratio for the frequency index and sector index specified.
roughness Surface roughness for the frequency index and sector index specified.

A-28
Keyword Parameter(s)

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 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)
window_end 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

where: YB/MB/DB Beginning year, month and day to process; a slash (/) between each part
of the date field is required; with no blanks
[TO] Optional; used to make this record more readable
YE/ME/DE Ending year, month and day to process; a slash (/) between each part of
the date field is required; with no blanks

A-29
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 that follow (Table B-1, Table B-2, Table B-3,
and Table B-4), 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.

B-1
 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 Missing Lower Upper
Name Description Units Type* Indicator Bound Bound

UAPR Atmospheric pressure millibars*10 < 99999 5000 10999

UAHT Height above ground meters <= 99999 0 5000

UATT Dry bulb temperature ºC*10 < 9990 350 +350

UATD Dew point temperature ºC*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 ºC/(100 meters) <= 9999 2 5

UADD Dew point deviation ºC/(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 SURFACE Variables
Variable Missing Lower Upper
Name Description Units Type Indicator Bound 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 ºC*10 < 999 -300 360

TMPW Wet bulb temperature ºC*10 < 999 -650 350

DPTP Dew-point temperature ºC*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

B-4
* 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-5
 Table B-3. Variable and QA Defaults for the ONSITE (Site-specific) Single-value
and Date/Time Variables

Variable Type Missing Lower Upper

Name Description Units * Indicator Bound 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-6
 Table B-4. Variable and QA Defaults for the ONSITE (Site-specific) Multi-level
Variables
Variable Missing Lower Upper
Name Description Units Type Indicator Bound 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.

B-7
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-1
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

PRCP = precipitation amount (millimeters), multiplied by 1000

C-2
 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
C-3
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
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-4
 Table C-1. Sky Conditions

TD-3280 CD-144 Description of Sky Conditions

00 0 clear or less than 0.1 coverage

01 1 thin scattered 0.1 to 0.5 coverage
02 2 scattered 0.1 to 0.5 coverage
03 4 thin broken 0.6 to 0.9 coverage
04 5 broken 0.6 to 0.9 coverage
05 7 thin overcast 1.0 coverage
06 8 overcast 1.0 coverage
07 X or - obscuration 1.0 coverage
08 Blank partial obscuration <1.0 coverage
09 unknown

C-5
 Table C-2. Cloud Types
TD-3280 CD-144 Description of Cloud Types
00 0 none
11 4 cumulus
12 n.e. towering cumulus
13 K stratus fractus
14 n.e. stratus cumulus lenticular
15 3 stratus cumulus
16 2 stratus
17 M cumulus fractus
18 5 cumulonimbus
19 N cumulonimbus mammatus
21 6 altostratus
22 O nimbostratus
23 7 altocumulus
24 n.e. altocumulus lenticular
28 P altocumulus castellanus
29 n.e altocumulus mammatus
32 8 cirrus
35 n.e. cirrocumulus lenticular
37 9 cirrostratus
39 R cirrocumulus

C-6
 Table C-3. Obscuring Phenomena
TD-3280 CD-144 (cols. 30, 31) Description of Obscuring Phenomena
01 6 blowing spray
03 3 smoke and haze
04 1 smoke
05 2 haze
06 4 dust
07 4 blowing dust
30 5 blowing sand
36 5 blowing snow
44 3 ground fog
45 1 fog
48 2 ice fog
50 n.e. drizzle
60 n.e. rain
70 n.e. snow
76 n.e. ice crystals
98 X or - 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 1 thunderstorm - lightning and thunder
11 2 severe thunderstorm - frequent intense
lightning and thunder
12 3 report of tornado or water spout
13 5 light squall
14 n.e. moderate squall
15 n.e. heavy squall
16 n.e. water spout
17 n.e. funnel cloud
18 n.e. tornado
19 n.e. unknown
TD-3280 CD-144 (col. 25) Rain, Rain Shower, Freezing Rain
20 1 light rain
21 2 moderate rain
22 3 heavy rain
23 4 light rain showers
24 5 moderate rain showers
25 6 heavy rain showers
26 7 light freezing rain
27 8 moderate freezing rain
28 9 heavy freezing rain
29 n.e. unknown
TD-3280 CD-144 (col. 26) Rain Squall, Drizzle, Freezing Drizzle
30 n.e. light rain squalls
31 n.e. moderate rain squalls
32 n.e heavy rain squalls
33 4 light drizzle
34 5 moderate drizzle
35 6 heavy drizzle
36 7 light freezing drizzle
37 8 moderate freezing drizzle
38 9 heavy freezing drizzle
39 n.e. unknown
C-8
TD-3280 CD-144 (col. 27) Snow, Snow Pellets, Ice Crystals
40 1 light snow
41 2 moderate snow
42 3 heavy snow
43 4 light snow pellets
44 5 moderate snow pellets
45 6 heavy snow pellets
46 n.e. light snow crystals
47 8 moderate snow crystals
48 n.e. heavy snow crystals
49 n.e. unknown
TD-3280 CD-144 (col 28) Snow Shower, Snow Squalls, Snow
Grains
50 1 light snow showers
51 2 moderate snow showers
52 3 heavy snow showers
53 n.e. light snow squalls
54 n.e. moderate snow squalls
55 n.e. heavy snow squalls
56 7 light snow grains
57 8 moderate snow grains
58 9 heavy snow grains
59 n.e. unknown
TD-3280 CD-144 (col. 29) Sleet, Sleet Shower, Hail
60 n.e. light ice pellet showers
61 n.e. moderate ice pellet showers
62 n.e. heavy ice pellet showers
63 n.e. light hail
64 5 moderate hail
65 n.e. heavy hail
66 8 light small hail
67 n.e. moderate small hail
68 n.e. heavy small hail
69 n.e. unknown

C-9
TD-3280 CD-144 (col. 30) Fog, Blowing Dust, Blowing Sand
70 1 fog
71 2 ice fog
72 3 ground fog
73 4 blowing dust
74 5 blowing sand
75 n.e. heavy fog
76 n.e. glaze
77 n.e. heavy ice fog
78 n.e. heavy ground fog
79 n.e. unknown
TD-3280 CD-144 (col. 31) Smoke, Haze, Blowing Snow, Blowing
Spray, Dust
80 1 smoke
81 2 haze
82 3 smoke and haze
83 4 dust
84 5 blowing snow
85 6 blowing spray
86 n.e. dust storm
87 --
88 --
89 n.e. unknown
TD-3280 CD-144 (col. 29) Ice Pellets, Hail Showers, Small Hail/Snow
Pellet Showers, Fog
90 1 light ice pellets
91 2 moderate ice pellets
92 3 heavy ice pellets
93 hail showers (begins July 1996)
94 small hail/snow pellet showers (begins7/96)
95 partial fog (begins 7/96)
96 patches fog (begins 7/96)
97 low drifting snow (begins 7/96)
98 --
99 n.e. 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_prv, n_curr, n_sfc, n_os, n_1min
FORMAT (7(I8,1X))
where
j_day = the Julian date for year/month/day.
n_ua = number of total NWS upper air observations (n_prv + n_curr).
n_prv = number NWS upper air observations from previous day.
n_curr = number of NWS upper air observations from current day.
n_sfc = number of NWS surface observations.
n_os = number of site-specific observations.
n_1min = number of 1-hour averages derived from of 1-minute ASOS data

C-11
 Upper Air Records

Upper air data are stored in the same order as in upper air extract/QA files.

Surface Records

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 Section C.2, with
a maximum of 8 variables per record.

Site-specific Records

Single-level Variables

Single-level variables are written in the same order and on multiple records just as they
were given on the Stage 1 ONSITE READ statements, but using an 8(I8,1x) format instead of
that given on the corresponding FORMAT statements.

Multilevel Variables

Like the single-level variables, the multilevel variables are also written in the same order
and on multiple records just as they were given on the Stage 1 ONSITE READ statements, but
using a 6(F14.6,1x) format.

C-12
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.

SURFACE OUTPUT

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 supported by AERMET. A description of the revised
surface file format is provided below:

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

C-13
 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
C-14
 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
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-15
 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)

C-16
Appendix D. Summary of messages

During the processing of the control file 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 control 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. Ddata processing
continues.
D-1
 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.

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 that was occurring. They cannot
completely specify the reason for the message. Further explanation is left to the 80-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

D-2
several error messages for an error in a model run. The following is an example of such a
situation that could occur in defining the surface characteristics in Stage 3.

Control file fragment for the METPREP pathway:

FREQ_SECT ANNUAL 1
SECTOR 1 0 360
CHARS 1 1 0.250 0.750 0.006

The message file would contain something like:

18 METPREP E03 SETUP : KEYWORD UNKNOWN: CHARS

JOB I19 SETUP : "END OF FILE" ON UNIT 5 AFTER RECORD # 20
METPREP E99 MPFIN : SITE_CHAR inputs missing for MONTH index 1 and SECT index 1!
METPREP E99 MPFIN : SITE_CHAR inputs missing for MONTH index 2 and SECT index 1!
METPREP E99 MPFIN : SITE_CHAR inputs missing for MONTH index 3 and SECT index 1!
METPREP E99 MPFIN : SITE_CHAR inputs missing for MONTH index 4 and SECT index 1!
METPREP E99 MPFIN : SITE_CHAR inputs missing for MONTH index 5 and SECT index 1!
METPREP E99 MPFIN : SITE_CHAR inputs missing for MONTH index 6 and SECT index 1!
METPREP E99 MPFIN : SITE_CHAR inputs missing for MONTH index 7 and SECT index 1!
METPREP E99 MPFIN : SITE_CHAR inputs missing for MONTH index 8 and SECT index 1!
METPREP E99 MPFIN : SITE_CHAR inputs missing for MONTH index 9 and SECT index 1!
METPREP E99 MPFIN : SITE_CHAR inputs missing for MONTH index 10 and SECT index 1!
METPREP E99 MPFIN : SITE_CHAR inputs missing for MONTH index 11 and SECT index 1!
METPREP E99 MPFIN : SITE_CHAR inputs missing for MONTH index 12 and SECT index 1!
METPREP E99 MPFIN : Errors in SITE_CHAR Array; Number of missing values
(< 0.0) = 12

In the example above, the correct keyword, SITE_CHAR, was not used to define the surface
characteristics. CHARS was used instead. As AERMET processes the control file, it checks to
make sure that each record conforms to all the rules of syntax which include the use of valid
keywords. The first message above indicates that an unknown keyword was encountered in the
control file (by subroutine SETUP) at record 18. Once the control file is processed, as noted by
the "END OF FILE" message, AERMET then checks to ensure all the required information to
process the data was included in the control file. During this portion of the setup processing
AERMET may detect additional problems such as missing keywords that are required or other
information that is required based on the options specified or the existence of other keywords in
the control file. Based on the FREQ_SECT keyword in the example above, AERMET expected
to find the SITE_CHAR keyword which should define the surface characteristic values for a
single wind sector that covers all directions. Error messages were generated (messages 3
through 14), which indicate AERMET did not find a valid SITE_CHAR keyword. The final

D-3
message indicates that there are values missing in the SITE_CHAR array, since none were
specified in the control file with a valid keyword.

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 control file, AERMET reports it as an unknown
pathway/keyword (the syntax and structure of the control file 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
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 it may take a little more than a casual glance at the message file
if AERMET detects any errors during setup.

D-4
 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 Control file 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 control file.

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 control file record number indicated;

2) Invalid pathway for the stage of processing;

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 keywords recognized by AERMET. This
error is independent of pathway;

2) The keyword is not valid for the pathway;

D-5
 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.8 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 control file record exceeds the maximum number of characters of 132. This
may result in errors processing the control 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 control 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

D-8
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.

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 control file. Compare the station ID and the
dates in the control file 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 control file.

E36 No soundings were extracted and error(s) occurred that did not allow AERMET to
extract any of the soundings specified in the control file.

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),
but AERMET was unable to read the data from the file. Since AERMET reads and

D-9
 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

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

D-10
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

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 control file 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.
D-11
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).

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 value code for that
variable will be substituted in the output file. See Section 4.3.1.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.

D-12
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.

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.

D-13
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.

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 LOCATION 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.

D-14
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.

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.

D-15
 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 chronological day was computed as the earliest
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.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 site-
specific 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.

D-16
E75 There was an error converting the latitude and longitude in the control 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.

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.

D-17
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 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.

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).
D-18
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 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.

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).

D-19
Appendix E. Processing NWS data from magnetic tape

Extracting data from magnetic tape as it pertains to the AERMET command language is
discussed in this appendix. This discussion is primarily for users who run AERMET on
computer platforms that can access magnetic tape drives, such as Digital Equipment
Corporation's VAX computers. There is no attempt to describe the system control language
required to mount tapes and assign file names. The user is directed to the appropriate system
user's manuals for such information.

The only data that is considered here is the National Weather Service data; no attempt is
made to read site-specific data directly from magnetic tape. When running AERMET on a
computer that can access a magnetic tape drive, the user only needs to be aware of a few
changes and additions to the AERMET command language. These modifications have to do
with the DATA keyword for the SURFACE and UPPERAIR pathways.

E.1 SURFACE pathway

Recall the syntax of the keyword statement:

Syntax: DATA archive_filename file_format factor [type]

Type: Mandatory (Stage 1), Nonrepeatable

where the archive_filename is the name of the file and must conform to the naming conventions
appropriate to the computing platform. The maximum length of the archive_filename is 48
characters. For processing data from tape, the archive_filename is the "name" of the tape,
however that name is specified or defined for the computing platform. For example, the name
of the tape on a VAX is defined in the system control language that is used to mount the tape on
the tape drive.

An additional data format is accessible when working with magnetic tapes. AERMET
can process the TD-3280 format available from NCDC. This format is an element-based format
in which the data for an entire day is reported one element (weather variable) at a time. To
E-1
process NWS hourly surface observations in this format, the parameter 3280VB or 3280FB is
specified for the file_format. The suffixes VB and FB refer to variable-length and fixed-length
block records, respectively. For variable-length data, each logical record contains one station's
hourly data values for one meteorological element (weather variable) for as many hourly values
as occur in the day. For fixed-length data, each logical record contains one station's hourly data
values for on meteorological element for 24 hourly values representing one full day of
observations. Specification of this suffix depends on how the data were ordered from NCDC.
The data are archived at NCDC in the variable-length format and usually supplied to the user in
that format, but the user can request NCDC to supply the data in the fixed-length format.

In addition to the TD-3280 format, AERMET can process the CD-144 data discussed in
Section 2.0 and Section 3.0 if it is received on magnetic tape. The file_format for this data
format is CD144FB, just as if the data are on disk, where the FB indicates that there is a fixed
number of characters per logical record. There is no variable-length block option for the CD-
144 data format.

The parameter factor defines the number of logical records per physical record (or
blocking factor), i.e., the number of logical records to process before reading from the tape
again. The specification of this factor depends, in part, on the data request submitted to the
NCDC. For the TD-3280 format, this factor is 1. For the CD-144 data format, this factor is
usually 10. One logical record contains one hour of surface meteorological observations;
therefore, a factor of 10 indicates that there are 10 logical records, or 10 hours of data, per
physical record. If data on tape from NCDC are used, the blocking factor for the particular data
format must be specified correctly for AERMET to properly extract the data from magnetic
tape. Otherwise, an error reading the physical record may occur (for a factor that is too large) or
there will be skips in the data record (for a factor that is too small).

The type refers to whether the data on the tape are ASCII or EBCDIC. The default for
this field is ASCII. In this version of AERMET, EBCDIC is not functional; therefore,
processing data on an IBM mainframe is not an option.

E-2
E.2 UPPERAIR Pathway

The syntax for the DATA keyword statement for the UPPERAIR pathway is the same as
shown above for the SURFACE pathway. The discussion for the archive_filename on the
SURFACE pathway applies here as well.

The only upper air data format that AERMET currently processes, whether the data are on
diskette or magnetic tape, is the TD-6201 data series. For data on magnetic tape, the data are
usually ordered from NCDC as variable-length blocks. To process NWS twice-daily
soundings in this format, the file_format is specified as 6201VB. Each logical record in the
variable-length format contains the upper air observations from one station. Like the TD-3280
format, the user can request that the upper air data be supplied in the fixed-length format, in
which case the file format is specified as 6201FB, just as for data on diskette.
For the upper air data, the factor defines the number of logical records (soundings) per
physical record. As with the SURFACE pathway, this value specifies the number of logical
records to process before reading from the tape again. The specification of this factor depends,
in part, on the data request submitted to the NCDC.

As for the SURFACE pathway, the type refers to whether the data on the tape are ASCII
or EBCDIC. The default for this field is ASCII. In this version of AERMET, EBCDIC is not
functional; therefore, processing data on an IBM mainframe is not an option.

E.3 Data on diskette and tape

There may be occasions when the surface and site-specific data are on a personal
computer, but the upper air data are on magnetic tape on a mainframe. There are three options
to unite these three data types.

One option is to upload the AERMET source code to the second computing platform to
process the upper air data. However, there is some PC-specific code that would require
modification. The code has to do with the system date and time and opening files. The user

E-3
should consult the appropriate user's manual on what changes or additions to make for the
specific computing platform. Once the AERMET system is operational, the upper air data can
be processed from tape and then downloaded to the user's personal computer where the
remaining processing can be performed.

A second option involves the same operation as above - uploading the AERMET source
code - as well as uploading the surface and site-specific data and processing all the data on the
second computing platform.

The third option is the reverse of the first two options - download the upper air data to
the personal computer. The first step is to copy the data from the magnetic tape to a file on the
second computing platform's mass storage without changing the structure of the data. This file
of data can then be downloaded to the user's personal computer. However, the size of the file
may be a limitation. The user should first determine how much space is required on a personal
computer to store the file before downloading it. Some judicious and very careful editing to
remove unnecessary records may be necessary on the second computing platform before
downloading. Once on the user's personal computer, the file can be processed just as if the data
resided on magnetic tape because the structure of the data has not changed. If the user keeps in
mind that the structure is the same whether it is "strung out" on a tape or on a disk file, then
there should be no problem processing as if it is on tape. If the user did something to change the
structure during the copy process, editing process (if that became necessary) or download
process, AERMET may not be able to extract any data.

There is not be a preferred option, and there may be other viable options that have not
been explored. The user should choose whichever option is easiest to implement.

E-4
Appendix F. AERMET enhancements

In this appendix, possible enhancements to the AERMET meteorological preprocessor

are discussed. These enhancements include the use of the afternoon sounding to adjust the
daytime mixing height estimates, an objective scheme to estimate the Bowen ratio,
incorporating the effects of anthropogenic heat flux, and estimates of the urban mixing height.

F.1 Daytime mixing height adjustments

The mixing height computation currently in AERMET uses the morning (12Z) sounding
and the accumulated sensible heat flux to determine the growth of the convective boundary
layer. However, changes in the atmospheric sounding during the daytime hours are not
accounted for by this scheme. Half of all of the routine soundings now taken are ignored (i.e.,
the 00Z soundings). Mixing height predictions in the afternoon would be improved by using the
00Z soundings (in the United States) to adjust the computation of this height based upon the
morning sounding.

To implement such an enhancement, it is necessary to devise an objective algorithm to

find the height of an elevated inversion in the 00Z sounding. This algorithm should ignore any
shallow surface-based inversion that could have recently formed if the sounding is taken near or
after the hour of sunset. A search is performed for a height interval over which the potential
temperature gradient exceeds a user-specified gradient. The height interval examined should
probably span at least three sounding points so that a bad data point does not lead to a false
detection of the elevated inversion. A preliminary suggestion for the height interval is 200
meters. The potential temperature gradient that corresponds to an elevated inversion would be
expected to be at least as stable as isothermal.

Given that an estimate of the afternoon mixed layer height is available, AERMET would
then adjust the estimates obtained from the morning sounding and hourly sensible heat flux
estimates. If no determination of the afternoon mixing height from the 00Z sounding can be
made, then no adjustment would be made to the calculated values currently provided.

F-1
Otherwise, the afternoon maximum mixing height (at a time estimated to be at a point 75% of
the way between sunrise and sunset) would be assigned to the value obtained from the 00Z
sounding, and this value would be persisted until sunset. The adjustment of the mixing heights
before the time of the afternoon maximum would then be done linearly, with a zero adjustment
at the time of the first upward sensible heat flux in the morning, up to the required adjustment at
the time of the afternoon maximum to be consistent with the 00Z sounding. The adjustment
would be limited to a factor of two.

F.2 An objective determination of the Bowen ratio

In this version of AERMET, the user specifies a monthly daytime Bowen ratio, chosen
from one of three possible values representing the wet and dry extremes, or a typically normal
moisture value. These values are a function of the type of surface cover in the particular sector
for that month (see Section 5.0 for a discussion of wind direction sectors). The "dry" Bowen
ratio value represents a moisture deficit condition in which the vegetation is under stress. The
"normal" Bowen ratio reflects a condition of average rainfall, with sufficient moisture supplied
to the vegetative cover to support normal transpiration rates. The "wet" Bowen ratio condition
is one of excessive moisture, leading to extra evaporation from surface wetness in addition to
the normal transpiration rates. An assumption is made that in the long run, the loss of water to
the atmosphere by evaporation is roughly equal to the precipitation gained, and that the
appropriate vegetative cover to maintain this steady state is established. The values for the
Bowen ratio are chosen for each month as a function of the type of vegetation and its maturity
(e.g., leaves emerging in spring, full maturity in summer, or leaves dropping in autumn).

The specification of just one monthly value for the Bowen ratio results in poor temporal
variation. The moisture availability can fluctuate significantly within the month. The revised
algorithm described here assumes that AERMET is provided with the three moisture-dependent
Bowen ratio values for each month, reflecting extremes from wet to dry. The revised method
would select one of the values for each day as being the most appropriate.

F-2
 This new method for AERMET is based in concept on estimates of the daytime sensible
heat flux from standard meteorological measurements made by Holtslag et al. (1980). These
authors used a modified Priestly-Taylor (1972) model of the energy budget in which the
moisture availability (or the daytime Bowen ratio) was empirically found to be a function of the
rainfall in the previous 5 days at Cabauw in the Netherlands. This area features a grass cover of
approximately 8 cm in length. In the case of little or no rainfall, evaporation rates were
substantially reduced, with a correspondingly high Bowen ratio. During periods of normal
rainfall, evaporation rates typical of normal transpiration condition were found.

For AERMET, a decision concerning the choice of a wet, dry, or normal Bowen ratio
value is analogous to the choice of a moisture availability value by Holtslag et al. The decision
for each day would be based upon the previous five days' precipitation total as compared to an
average rainfall for the same five-day period. This average rainfall could be the 30-year average
or other appropriate period. Similar to the METPRO (Paine, 1987) technique, a five-day rainfall
amount that is at least twice the average will result in a "wet" designation. Rainfall less than
half the average will result in a "dry" designation. Amounts of rainfall in between these
extremes will earn a "normal" designation. For each day, a new running five-day total
precipitation total and average would be computed. The Bowen ratio determined with this
method will thus be subject to daily fluctuations. However, the Bowen ratio would be the same
value for the entire daytime period for any given day.

The required input data to AERMET would consist of hourly precipitation data (as
provided on the Solar and Meteorological Surface Observation Network (SAMSON) data,
monthly average precipitation, and the three monthly Bowen ratio values (dry, normal, wet).

F.3 Urban effects

AERMET uses an energy balance formulation to determine 1) whether stable or unstable

conditions are present, and 2) to quantitatively determine for unstable conditions the surface
heat flux and other boundary layer values. A simple formula, appropriate for rural areas, is

F-3
 Rn = Qh + Qe + Qg,

where
Rn is the net radiation,
Qh is the sensible heat flux,
Qe is the latent heat flux, and
Qg is the soil heat flux.

To date, Qg has been parameterized in AERMET as 0.1 Rn (after Holtslag and van
Ulden, 1983) and Qh and Qe are determined from an estimate of the daytime Bowen Ratio ( =
Qh/Qe). The sign of the net radiation is used to determine the sign of the Monin-Obukhov length.
This choice is important in AERMOD due to the selection of dispersion algorithms.

A more general expression for the energy balance accounts for anthropogenic heat flux
(Qa) as well as allowing G to be a variable fraction (cg) of Rn:

Rn + Qa = Qh + Qe + cg Rn,

The flux of heat into the ground during the daytime will be parameterized as a fraction
(range: 0 to 1.0) of the net radiation. Holtslag and van Ulden (1983) obtained a value of cg of
0.1 for a grass covered surface in the Netherlands. Oke (1982) indicates that typical ranges for
cg are 0.05 to 0.25 in rural areas, 0.20 to 0.25 in suburban areas, and 0.25 to 0.30 in urban
regions.

The anthropogenic heat flux can be neglected except in highly urbanized locations.
Table F-1. Average Anthropogenic Heat Flux (Qa) and Net Radiation (Rn) for Several Urban
Areas (from Oke, 1978), taken from Oke (1978), provides estimates for urban areas.

F-4
 Table F-1. Average Anthropogenic Heat Flux (Qa) and Net Radiation (Rn) for
Several Urban Areas (from Oke, 1978)
Population Per capita energy
Urban area/ Population density usage Qa Rn
latitude/period (x 106) (persons/km2) (MJx103/yr) (W/m2) (W/m2)
Manhattan (40°N)
annual 1.7 28,810 128 117 93
summer 40
winter 198
Montreal (45°N)
annual 1.1 14,102 221 99 52
summer 57 92
winter 153 13
Budapest (47°N)
annual 1.3 11,500 118 43 46
summer 32 100
winter 51 -8
Sheffield (53°N)
annual 0.5 10,420 58 19 56
West Berlin (52°N)
annual 2.3 9,830 67 21 57
Vancouver (49°N)
annual 0.6 5360 112 19 57
summer 15 107
winter 23 6
Hong Kong (22°N)
annual 3.9 3,730 34 4 ~11
Singapore (1°N) 0
annual 2.1 3,700 25 3 ~11
Los Angeles (34°N) 0
annual 7.0 2,000 331 21 108
Fairbanks (64°N)
annual 0.03 810 740 19 18

In addition to the anthropogenic heat flux, an accurate specification of the surface

roughness length appropriate for cities would have the effect of increasing the Monin-Obukhov
length to account for the near surface shear effects due to building obstacles. Representative
values for various urban environments are shown in Table F-2.

F-5
 Table F-2. Surface Roughness Length for Urban Environments (from Stull, 1988)
Environment Roughness length (meters)
Many trees and hedges, few buildings 0.2 - 0.5
Outskirts of towns 0.4
Center of small towns 0.6
Center of large towns and small cities 0.7 - 1.0
Center of large cities with tall buildings 1.0 - 3.0

F.4 Urban mixing heights

For urban areas, the additional heating due to anthropogenic sources creates a higher
convective mixed layer during the day. This effect will be accommodated in a future version of
AERMET by a higher sensible heat flux input to the modified Carson model. At night (when a
negative net radiation is measured or parameterized), a well-mixed layer is observed near the
surface over the built-up areas of cities of all sizes. This layer is caused by reduced upward
radiation due to the presence of buildings, as well as the anthropogenic heat flux. The depth of
the layer is observed to be on the order of 50-100 meters for small cities, 150-200 meters for
moderately large cities, and 300-400 meters over large cities. These observations are consistent
with a model proposed by Summers (1965):

1/2
ℎ𝑢𝑟𝑏𝑎𝑛 = {2 𝐻𝑎 𝑥 ⁄[𝑐𝑝 𝜌(𝑑𝜃⁄𝑑𝑧)]}
where

Ha is the anthropogenic heat flux,

x is the upwind fetch length over the urban area, and

dθ/dz is the vertical potential temperature gradient at the top of the mixed layer.

F-6
 In a future version of AERMET, Ha and x would be specified by the user as a function of
month and (in the case of x) by direction sector. The value of dϴ/dz would be derived from the
rural stable ϴ* value using boundary layer parameterizations.

F-7
Appendix G. 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, including:
a. corrections to the procedure for selecting which record to process for hours
with multiple records;

b. corrections to code for processing of sky cover fields;

c. 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);

d. code for initializing the "additional" character variable to avoid data fields
from previous hours being used; and

e. 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).

Version 06341 also introduced the 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 control file
input file from 80 to 132 characters, increase the maximum field length for

G-1
 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;
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;

G-2
 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 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;
G-3
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;
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
G-4
 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 (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;

G-5
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
(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 mixed-
mode 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 non-
Default/BETA ADJ_U* option associated with the BULKRN option.
Subroutine BULKRI was also modified to avoid an array subscript out-of-
bounds 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
G-6
 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) 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 delta-T/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 NAD-
OS, 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

G-7
 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
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

G-8
 representative upper air stations are used in conjunction with the UPPERAER
tool.
7. The seventh set of revisions, introduced with version 16216 of AERMET (see
Model Change Bulletin (MCB) #7 provided on the SCRAM AERMET webpage),
includes:
a. Modified subroutines MPFIN and SUBST to set RANDOM as the default
selection for the WIND_DIR variable under the METHOD option in Stage 3
for NWS wind directions. This is a change from prior versions of AERMET
in which the user had to include the RANDOM keyword under the
METHOD option in Stage 3 to apply the randomization scheme to NWS
wind directions. NORAND was the default in prior versions.
b. Modified subroutine UCALST to remove the code for adjusting USTAR if
CHEK .GT. 1 for the ADJ_U* option. Also incorporated a lower limit of
USTCR for USTAR based on Equation 26 of Qian and Venkatram (BLM,
2011).
c. Modified subroutine BULKRI to set a lower limit of 1.0m for the Monin-
Obukhov length (L) as one of the criteria for exiting the DO WHILE loop to
avoid NaN’s for USTAR in the surface output file for the ADU_U* option.
Subroutine BULKRI was also modified to use BETAM = 5.0 for the
ADJ_U* option instead of 4.7.
d. Modified subroutine MPMET to correct the FORMAT statement for
including the ‘BULKRN/MMIF’ string in the surface file header record.
8. The eighth set of revisions introduced with version 18081 of AERMET (See Model
Change Bulletin (MCB) #8 provided on the SCRAM AERMET webpage),
includes:
a. Modified program AERMET to allow the user to input the stage control
filename on the command line when calling AERMET. If no filename is
provided, AERMET looks for the default ‘aermet.inp’.
b. Modified subroutine BULKRI to set variables USTAR1, THSTR1, and OBU
to missing when _Z_OVER_L >-0.7, to avoid NaN’s in the AERMET output
files.
c. Modified subroutine SUBST, to correct the precipitation code to liquid or
frozen if the precipitation amount is greater than zero for National Weather
Service data. Previously, there was a mismatch in the code and precip
amounts.
d. Modified subroutine SFQASM to backspace file 70 to avoid trying to write
past end of file.

G-9
United States Office of Air Quality Planning and Standards Publication No. EPA-454/B-18-002
Environmental Protection Air Quality Assessment Division April, 2018
Agency Research Triangle Park, NC