USERS GUIDE FOR THE

AERMOD TERRAIN

PREPROCESSOR (AERMAP) 
 EPA-454/B-03-003

 October 2004

USER'S GUIDE FOR THE

AERMOD TERRAIN PREPROCESSOR (AERMAP)

U.S. ENVIRONMENTAL PROTECTION AGENCY

Office of Air Quality Planning and Standards

Emissions, Monitoring, and Analysis Division

Research Triangle Park, North Carolina 27711
iii

NOTICE

This user's guide has been reviewed by the Office of Air Qualtiy Planning and Standards,

U.S. Environmental Protection Agency, and has been approved for publication. Mention of trade

names, products, or services does not convey, and should not be interpreted as conveying official

EPA approval, endorsement, or recommendation.

The following trademarks appear in this guide:

UNIX is a registered trademark of The Open Group

Linux is a registered trademark of Linus Torvalds

Visual Fortran is a registered trademark of Compaq Computer Corporation

Pentium is a registered trademark of Intel, Inc.

IBM is a registered trademark of International Business Machines.

Windows is a registered trademark of Microsoft Corporation.

WINZIP is a registered trademark of Nico Mak Computing, Inc.
iv

PREFACE

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

Meteorological Society (AMS), has developed a new air quality dispersion model, the

AMS/EPA Regulatory Model (AERMOD). AERMOD is a modeling system which contains: 1)

an air dispersion model, 2) a meteorological data preprocessor called AERMET, and 3) a terrain

data preprocessor called AERMAP. This user’s guide focuses on the AERMAP portion of the

AERMOD modeling system.

This User's Guide for the AMS/EPA Regulatory Model Terrain Pre-processor

(AERMAP), provides technical descriptions and user instructions. Receptor and source

elevation data from AERMAP output is formatted for direct insertion into an AERMOD control

file. The elevation data are used by AERMOD when calculating air pollutant concentrations.
v

ACKNOWLEDGMENTS

The User's Guide for AERMAP has been prepared by Pacific Environmental Services,

Inc., Research Triangle Park, North Carolina. This effort was funded by the U.S. Environmental

Protection Agency under Contract Numbers 68D30032 and 68D30001, with Russell F. Lee and

Warren D. Peters as Work Assignment Managers. This user’s guide has been modified by Peter

Eckhoff of the U.S. Environmental Protection Agency, Research Triangle Park, North Carolina.

We are grateful to the staff of the United States Geological Survey for their helpful

suggestions and understanding of the complex relationships between the various datum standards

and their ability to convey that understanding for our programming purposes.

We also appreciate the National Geodetic Survey for posting their NADCON program to

the internet. Without NADCON, we would have had a tremendously difficult time in writing a

program to convert geographical coordinates between NAD 27 and NAD 83. 
vi

CONTENTS

PREFACE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . iv

ACKNOWLEDGMENTS ...................................................... v

FIGURES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . viii

TABLES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ix

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

1.1 OVERVIEW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-1

1.2 INPUT DATA REQUIREMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1-2

1.3 COMPUTER HARDWARE REQUIREMENTS . . . . . . . . . . . . . . . . . . . . . . . . . . 1-5

2.0 OVERVIEW OF THE AERMAP TERRAIN PREPROCESSOR . . . . . . . . . . . . . . . . . . . 2-1

2.1 BASIC CONCEPTS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

2.1.1 Horizontal Datums . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-1

2.1.2 Modeling Domain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-4

2.1.3 Sources and Receptors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-7

2.1.4 Terrain Data Files . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-8

2.2 KEYWORD/PARAMETER APPROACH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-10

2.3 AN EXAMPLE AERMAP INPUT FILE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-11

2.3.1 Selecting Preprocessing Options - CO Pathway . . . . . . . . . . . . . . . . . . 2-12

2.3.2 Specifying a Receptor Network - RE Pathway . . . . . . . . . . . . . . . . . . . 2-15

2.3.3 Specifying the Output File - OU Pathway . . . . . . . . . . . . . . . . . . . . . . . 2-16

2.4 RUNNING AERMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-17

2.5 SIZE LIMITATIONS AND CREATING A NEW EXECUTABLE . . . . . . . . . . 2-20

3.0 DETAILED KEYWORD REFERENCE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

3.1 OVERVIEW . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-1

3.2 CONTROL PATHWAY INPUTS AND OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 3-2

3.2.1 Title Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-2

3.2.2 Options for Elevated Terrain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3
vii

3.2.3 Flagpole Receptor Height Option . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-3

3.2.4 Terrain Data Type Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-4

3.2.5 Terrain Data File Names Specifications . . . . . . . . . . . . . . . . . . . . . . . . . 3-4

3.2.6 Domain Extent Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-5

3.2.7 Anchor Location Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-6

3.2.8 To Run or Not to Run - That is the Question . . . . . . . . . . . . . . . . . . . . . . 3-8

3.3 SOURCE PATHWAY INPUTS AND OPTIONS (OPTIONAL) . . . . . . . . . . . . . 3-9

3.4 RECEPTOR PATHWAY INPUTS AND OPTIONS . . . . . . . . . . . . . . . . . . . . . . . 3-9

3.4.1 Defining Networks of Gridded Receptors . . . . . . . . . . . . . . . . . . . . . . . 3-10

3.4.1.1 Cartesian Grid Receptor Networks. . . . . . . . . . . . . . . . . . . . . 3-10

3.4.1.2 Polar Grid Receptor Networks. . . . . . . . . . . . . . . . . . . . . . . . . 3-15

3.4.2 Using Multiple Receptor Networks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-18

3.4.3 Specifying Discrete Receptor Locations . . . . . . . . . . . . . . . . . . . . . . . . 3-19

3.4.3.1 Discrete Cartesian Receptors. . . . . . . . . . . . . . . . . . . . . . . . . . 3-19

3.4.3.2 Discrete Polar Receptors. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3-20

3.4.3.3 Discrete Cartesian Receptors for EVALFILE Output. . . . . . . 3-21

3.5 OUTPUT PATHWAY INPUTS AND OPTIONS . . . . . . . . . . . . . . . . . . . . . . . . 3-22

4.0 TECHNICAL DESCRIPTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-1

4.1 DETERMINING RECEPTOR HEIGHT SCALES . . . . . . . . . . . . . . . . . . . . . . . . 4-1

4.2 DIGITAL ELEVATION MODEL (DEM) DATA . . . . . . . . . . . . . . . . . . . . . . . . . 4-2

4.3 DATA MANIPULATION BY AERMAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4-17

4.4 DETERMINING RECEPTOR (SOURCE) ELEVATIONS . . . . . . . . . . . . . . . . 4-18

5.0 REFERENCES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5-1

APPENDIX A. ALPHABETICAL KEYWORD REFERENCE . . . . . . . . . . . . . . . . . . . . . . . A-1

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

APPENDIX C. EXPLANATION OF ERROR MESSAGE CODES . . . . . . . . . . . . . . . . . . . . C-1

C.1 INTRODUCTION . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . C-1

C.2 THE OUTPUT ERROR LOG MESSAGE SUMMARY . . . . . . . . . . . . . . . . . . . . C-1

C.3 DESCRIPTION OF THE DETAILED MESSAGE LAYOUT . . . . . . . . . . . . . . . C-2

C.4 DETAILED DESCRIPTION OF THE ERROR/MESSAGE CODES . . . . . . . . . C-4
viii

FIGURES

Figure Page

2-1. DEPICTION OF THE OVERLAP AND VOID AREAS AREAS CAUSED BY USING

DEM FILES WITH DIFFERENT DATUMS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-3

2-2. RELATIONSHIP AMONG THE DEM FILES, THE DOMAIN, SOURCES AND

RECEPTORS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-5

2-3. RELATIONSHIP OF RECEPTOR SLOPE LINE TO DEM TERRAIN NODES

AND THE DEM AND DOMAIN BOUNDARIES . . . . . . . . . . . . . . . . . . . . . . . . . . . 2-6

2-4. EXAMPLE AERMAP OUTPUT FILE FOR THE SAMPLE PROBLEM . . . . . . . . . 2-20

4-1. STRUCTURE OF A 7.5-MINUTE DEM DATA FILE . . . . . . . . . . . . . . . . . . . . . . . . 4-4

4-2. STRUCTURE OF A 1-DEGREE DEM DATA FILE . . . . . . . . . . . . . . . . . . . . . . . . . . 4-6

C-1. EXAMPLE OF AN AERMAP MESSAGE SUMMARY . . . . . . . . . . . . . . . . . . . . . . . C-2
ix

TABLES

Table Page

3-1. DATUM SWITCHES FOR ANCHOR LOCATION . . . . . . . . . . . . . . . . . . . . . . . . . . 3-7

4-1. DEM DATA ELEMENTS - LOGICAL RECORD TYPE A . . . . . . . . . . . . . . . . . . . . 4-7

4-2. DEM DATA ELEMENTS - LOGICAL RECORD TYPE B . . . . . . . . . . . . . . . . . . . 4-15

B-1. DESCRIPTION OF CONTROL PATHWAY KEYWORDS . . . . . . . . . . . . . . . . . . . . B-2

B-2. DESCRIPTION OF CONTROL PATHWAY KEYWORDS AND

PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-3

B-3. DESCRIPTION OF SOURCE PATHWAY KEYWORDS . . . . . . . . . . . . . . . . . . . . . B-5

B-4. DESCRIPTION OF SOURCE PATHWAY KEYWORDS AND PARAMETERS . . . B-6

B-5. DESCRIPTION OF RECEPTOR PATHWAY KEYWORDS . . . . . . . . . . . . . . . . . . . B-7

B-6. DESCRIPTION OF RECEPTOR PATHWAY KEYWORDS AND

PARAMETERS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . B-8

B-7. DESCRIPTION OF OUTPUT PATHWAY KEYWORDS . . . . . . . . . . . . . . . . . . . . B-11

B-8. DESCRIPTION OF OUTPUT PATHWAY KEYWORDS AND PARAMETERS . . B-12
1-1

1.0 INTRODUCTION

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

Meteorological Society (AMS), has developed a new air quality dispersion model, the

AMS/EPA Regulatory Model (AERMOD). AERMOD is designed to calculate air pollutant

concentrations in all types of terrain, from flat prairie to complex mountainous situations. 

AERMOD does not process its own terrain. A preprocessor program, AERMAP, has been

developed to process this terrain data in conjunction with a layout of receptors and sources to be

used in AERMOD control files. 

Terrain data is available, in the United States, from the United States Geological Survey

(USGS) and commercial sources in the form of computer terrain elevation data files. The data

have been standardized to several map scales and data formats. AERMAP has been designed to

process several of these standardized data formats. AERMAP produces terrain base elevations

for each receptor and source and a hill height scale value for each receptor. AERMAP outputs

the elevation results in a format that can be directly inserted into an AERMOD control file.

The remainder of this section provides an overall introduction to the AERMAP terrain

preprocessor including the basic input data and the hardware requirements. In Section 2, a brief

tutorial demonstrates the fundamental requirements to run AERMAP, while in Section 3, a

detailed description of each of the keywords is presented. A discussion of the technical aspects

of obtaining the hill height scale is presented in Section 4.

1.1 OVERVIEW

Regulatory dispersion models applicable for simple to complex terrain situations require

information about the surrounding terrain. With the assumption that terrain will affect air quality

concentrations at individual receptors, AERMAP first determines the base elevation at each

receptor and source. For complex terrain situations, AERMOD captures the essential physics of
1-2

dispersion in complex terrain and therefore needs elevation data that convey the features of the

surrounding terrain. In response to this need, AERMAP searches for the terrain height and

location that has the greatest influence on dispersion for each individual receptor. This height is

the referred to as the hill height scale. Both the base elevation and hill height scale data are

produced by AERMAP as a file or files which can be directly inserted into an AERMOD input

control file.

1.2 INPUT DATA REQUIREMENTS

There are two basic types of input data that are needed to run AERMAP. First,

AERMAP requires an input runsteam file that directs the actions of AERMAP through a set of

options, and defines the receptor and source locations. The structure and syntax of an AERMAP

input runsteam file is based on the same pathways and keyword structures as in the control

runsteam files for AERMOD.

Second, AERMAP needs standardized computer files of terrain data. The data is

available in three distinct formats. There is the Digital Elevation Model (DEM) format which

follows the old USGS “Blue Book” standard (see Chapter 4.2). There is the newer Spatial Data

Transfer Standard (SDTS) which formats the DEM and other associated data in metadata form. 

Finally there is the National Elevation Dataset (NED) data which is constantly updated and is

available in several formats for importing into widely used commercial software packages such

as ARCGRID, GridFloat, and BILS. Of these data formats and standards, AERMAP is

programmed to read only the USGS Blue Book format. SDTS, XYZ, and NED data has to be

converted to the Blue Book format. A SDTS and a XYZ conversion program is provided with

AERMAP. Direct input of NED data into AERMAP is being explored.

The Blue Book format has been copied directly into Chapter 4.2. It consists of an overall

header followed by terrain profiles which consist of location based sub headers and evenly

spaced terrain elevation points called nodes. Each DEM file covers a section of land based on
1-3

latitude and longitude coordinates. These data files are obtainable through several commercial

internet sites and the USGS. Several sites, as of this writing, are offering free downloads of the

USGS’s SDTS formatted DEM data files. Data in the old “native” DEM format are still

available. This note has appeared on the USGS web site as of 09 September, 2004: 

http://edc.usgs.gov/geodata/

“The USGS has two options for acquiring 1:24,000-Scale (7.5-minute) Digital

Elevation Model data.

1) The original DEM 7.5 minute tiled data available only in Spatial Data Transfer

Standard (SDTS) form is available at no cost via downloads from the GeoComm

International Corporation at http://gisdatadepot.com/dem and from MapMart.com

at http://www.mapmart.com , and from Advanced Topographic Development and

Images (ATDI) at http://www.atdi-us.com. (See disclaimer).

2) The National Elevation Dataset (NED) is the result of the maturation of the

USGS effort to provide 1:24,000-scale Digital Elevation Model (DEM) data for

the conterminous U.S. and 1:63,360-scale DEM data for Alaska in a seamless

form. Available data formats include ArcGrid, Floating Point, and BILS....” 

DEM data can be obtained in several different scales and horizontal data spacing

resolutions. Currently AERMAP can process both the 7.5-minute and 1-degree, Blue Book

formatted, DEM data scales with any uniform distance between nodes. AERMAP is no longer

limited to spacings of 30 meters or 3 arc-seconds, respectively. The 1-degree DEM files are

available through the Internet and via anonymous FTP from the USGS Internet site at

http://edc.usgs.gov/products/elevation.html. The 7.5-minute DEM data may be purchased from

the USGS or one of the internet sites noted above. Users should check the USGS website for the

current availability status of these data.
1-4

There are three levels of quality for DEM data. It is recommended that Level 1 data not be used

and that Level 2 or Level 3 data be used. The level of quality has been incorporated into the

DEM main header as Data Element 3. AERMAP prints this value in its output file. The user can

view this value in the DEM file using a text editor. This value (eg. 1, 2, or 3) is found in the

main header record and has a Fortran format of I6 which begins at the 145th byte and ends at the

150th byte.

According the USGS Blue Book Data User’s Guide 5, 1993: “Level 2 DEM’s are

elevation data sets that have been processed or smoothed for consistency and edited to remove

identifiable systematic errors. DEM data derived from hypsographic and hydrographic data

digitizing, either photogrammetrically or from existing maps, are entered into the Level 2

category after a review on a DEM Editing System. An RMSE of one-half contour interval is the

maximum permitted. There are no errors greater than one contour interval in magnitude. The

DEM record C contains the accuracy statistics acquired during quality control.” Level 3 DEM’s

have a maximum permitted RMSE of one-third of the contour interval. There are no errors

greater than two-thirds contour interval in magnitude.

According the USGS Blue Book : “All 1-degree DMA Data Terrain Elevation Data Level

1's (DTED-1's) have been classified as Level 3 because the hypsographic information, when

plotted at 1:250,000 scale, is consistent with the planimetric features normally found on

1:250,000-scale topographic maps. Inconsistencies may exist, but these are regarded as isolated

cases to be tempered by the 90-percent confidence level for the overall product. NOTE: The

USGS classification of “level 3" for 1-degree DEM’s is not to be confused with the DMA’s

“DTED level 1.” In the DMA, the term [ed. DTED] level is related to the spatial resolution of

the data and not to the source of the data.”

The 1-degree DEM data are produced by the Defense Mapping Agency (DMA) in

1-degree by 1-degree units that correspond to the east or west half of 1:250,000 scale USGS

topographic quadrangle map series. These data are complete and available for the entire
1-5

contiguous United States, Hawaii, and portions of Alaska, Puerto Rico and the Virgin Islands. A

file consists of a regular array of elevations referenced horizontally on the latitude/longitude

coordinate system of the World Geodetic System (WGS). The array consists of profiles of

terrain elevations, where a profile is a series of elevation points, or nodes, arranged from south to

north for one longitude. Each profile for the 1-degree data has a constant number of elevation

points. The horizontal spacing between each data point is 3 arc-seconds - the east-west distance

is therefore latitude dependent and corresponds to about 70 - 90 meters for the North American

continent. The elevations are expressed in meters. 

1.3 COMPUTER HARDWARE REQUIREMENTS

The current revision to the AERMAP terrain preprocessor was developed on an

IBM-compatible personal computer (PC) using Compaq Visual Fortran Compiler (Version 6.6). 

AERMAP has been designed to run on a PC with a Pentium class or higher central processing

unit (CPU) chip, a minimum of 64 MB of RAM, and Windows 95 or higher Windows operating

system. However, the program was written to be Fortran compliant and therefore should be

recompilable on other types of computer systems such as DOS, UNIX, or Linux-based systems. 

The amount of hard disk drive storage space required for a particular application will

depend on the number and type of raw terrain (DEM) data files required to encompass the study

area. A single 7.5-minute DEM file requires about 1.1 MB of space, while a single 1-degree

DEM file requires about 10 MB of space. Additional hard disk drive space will be needed to

store 7.5 minute SDTS formatted DEM data which requires about 110KB of space per file. 

SDTS data needs to be converted to the old DEM format. Each conversion of an SDTS

file produces a natively formatted DEM file of about 1.1 MB. A conversion program,

SDTS2DEM, is located on the Support Center for Regulatory Air Models web site at

http://www.epa.gov/scram0001 as part of the AERMAP package.
1-6

AERMAP processes a 100 km x 100 km domain which includes about 80 7.5-minute

DEM files and 360 receptors in less than 32 minutes on 733 MHz Pentium III computer. 

AERMAP processes the 80 DEM files in about 5 minutes and processes the 360 receptors in

about 26.5 minutes.
2-1

2.0 OVERVIEW OF THE AERMAP TERRAIN PREPROCESSOR

This section presents the basic concepts, including the keyword approach, of the

AERMAP preprocessor used in generating the runsteam (control) file and a short tutorial on

creating a simple AERMAP run. 

2.1 BASIC CONCEPTS

AERMAP relies on the Universal Transverse Mercator (UTM) coordinate system to

identify the location of sources and receptors. This coordinate system is one method of

portraying the meridians and parallels of the earth's surface on a flat plane. The UTM system is

comprised of zones, with each zone being 6° of longitude in width. Zones are numbered from

1-60 eastward from the 180 degree International Dateline meridian at 6-degree intervals of

longitude. UTM zones 11-19 cover the contiguous United States (US DOI, 1993).

2.1.1 Horizontal Datums

The Earth is a slightly flattened sphere often referred to as an oblate ellipsoid or spheroid. 

There are many mathematical methods and measurements that have been used to define the

shape of the earth (USGS,1987). The three most prevalent methods for the United States are the

Clarke 1866 spheroid, the World Geodetic Systems (WGS) of 1972 and 1984, and Geodetic

Reference System (GRS) of 1980. Projections of latitude and longitude have been placed on

each one of these spheriod/reference systems. The projections are called datums. The North

American Datum (NAD) of 1927, projected on the Clarke 1866 spheroid, was created using a

triangulation method centered on Meades Ranch, Kansas. Beginning with NAD 83 and WGS

72, the projections are Earth-centered. The NAD of 1983 is based on terrestrial and satellite data

while WGS 72 and WGS 84 are based on satellite data. NAD 83 and WGS 84 are almost

identical with no appreciable differences. For all practical purposes they are considered the
2-2

same for AERMAP applications. Here are some common ellipsoid/reference system names and

the datums associated with them:

 1. CLARKE 1866 

 a. NAD27 datum

 b. OLD HAWAIIAN datum

 c. PUERO RICAN datum

 d. GUAM datum

 2. GRS80/WGS84 

 a. NAD83 datum

 b. WGS84 datum

 3. WGS72

 a.WGS72 datum

In layman’s terms, this means that a location on Earth will have different coordinates depending

upon the datum used to define that location.

Since two or more different datums can exist for each of the two DEM scales (1-degree

and 7.5-minute) used in AERMAP, datum conversion was added to AERMAP. Datum

conversion from NAD 27 to NAD 83 is performed using the National Geodetic Survey’s

NADCON software version 2.1. The main NADCON algorithms have been incorporated into

AERMAP. NADCON is designed to convert coordinates in the Continental United States

(CONUS), Old Hawaiian, Puerto Rico (and Virgin Islands), and four Alaskan datums to NAD 83

using 7 pairs of respective conversion parameter files that have LAS and LOS file extensions. 

These files need to be loaded along with the AERMAP executable. These files are used to

convert receptors and sources coordinates of the old datum of the areas mentioned above to NAD

83. The files are included with the AERMAP package on the SCRAM web site,

(http://www.epa.gov/scram001/). NADCON is used only with the 7.5-minute DEM files. 
2-3

In DEM files, same node coordinates.

On earth, different locations.

DEM #4

NAD 27

DEM #7

NAD 27

DEM #8

NAD 27

DEM #5

NAD 83

DEM #9

NAD 27

DEM #6

NAD 27

Overlap area between DEM files 

 with two different datums (eg NAD 27 & 83)

No DEM coverage (Void) area between DEM files 

 with two different datums (eg NAD 27 & 83)

Void Area

The datum of the anchor point is enter at the end of the ANCHOR keyword statement. 

For applications outside the NADCON coverage area, the user needs to enter “0". Inside one of

the areas above, the user needs to enter the number representing the datum for the ANCHOR

point. By selecting “0", no conversions will be done.

 

Datum conversion for the 1-degree data, from WGS 72 to GRS 80 / WGS 84, is not

performed. Differences between the datums of around 7 meters are found in the arctic near

Alaska and increase to around 17 meters in the tropics near Puerto Rico. Considering the

differences are less than the approximate 93 meters between the 1-degree nodes, the conversion

is considered inconsequential.

The difference in 7.5 minute DEM based horizontal datums can have an effect on

receptor and source elevation points. The location of a point in one datum will be different from

the location of a point under another datum (see Figure 2-1). 

FIGURE 2-1 DEPICTION OF THE OVERLAP AND VOID AREAS CAUSED BY USING 

 DEM FILES WITH DIFFERENT DATUMS
2-4

For 7.5 minute DEM files of different datums, the datum coordinate difference for a given point

in the CONUS can be close to zero in the Great Lakes region to more than 100 meters in the

Pacific Northwest and down in Florida. In Hawaii, the difference is more than 300 meters. 

Since adjacent 7.5 minute DEM files have common map corners with each other (stated in

latitude and longitude), the use of DEM files with different datums can shift a map so that gaps

and overlaps occur between the adjacent DEM files as depicted in Figure 2-1. Receptors can fall

into these gaps and overlaps.

From the NADCON subroutine in AERMAP, a 7.5-minute DEM coordinate shift from

NAD27 to NAD83 is calculated for each receptor and source. The shift is applied in both

directions so that each point has coordinates under both datums. This way, if the ANCHOR

point is NAD 83, coordinates shifted to NAD 27 can be used with NAD 27 elevation files. 

AERMAP then determines the single closest DEM elevation value in each quadrant to the

northwest, northeast, southeast and southwest of the receptor or source. These four elevations

are weighted by distance to the receptor to estimate an elevation for that receptor (See Section

4.4 for equations). The resulting value is the elevation that is written to file for inclusion into an

AERMOD input file. The source elevation is calculated the same way.

2.1.2 Modeling Domain

The AERMAP terrain preprocessor requires the user to define a modeling domain. A

modeling domain is defined as the area that contains all the receptors and sources being modeled

with a buffer to accommodate any significant terrain elevations. This domain can span over

multiple UTM zones and multiple adjacent DEM files provided by the user. The domain can be

specified either in the UTM or the latitude/longitude coordinate system. The preprocessor

converts the domain coordinates to the units of the DEM data, i.e., UTM when using 7.5-minute 
2-5

Source

data and latitude/longitude when using the 1-degree data. The domain must be a quadrilateral in

the same orientation as the DEM coordinates. Figure 2-2 illustrates the relationship among the

DEM data files, the domain, and receptors. 

FIGURE 2-2 RELATIONSHIP AMONG THE DEM FILES, THE DOMAIN, SOURCES AND

RECEPTORS

Significant terrain elevations include all the terrain that is at or above a 10% slope from

each and every receptor (See Chapter 4.1 for a more detailed discussion). Additional DEM files

may be needed to calculate the hill height scale for each receptor and the domain may need to be

expanded to include all significant nodes. It is up to the user to assure all such terrain nodes are

covered (See Figure 2-3).
2-6

Mandatory inclusion of DEM terrain nodes above

 10% slope from each and every receptor. 

 Nodes must be inside Domain.

Receptor

10% Slope from receptor

Horizontal

elevation

levels

DEM terrain nodes

excludable when 

below 10% slope

When a DEM terrain node

breaks through the 10%

slope, additional DEM files

are required and the domain

needs to be expanded to 

include this node.

FIGURE 2-3. RELATIONSHIP OF RECEPTOR SLOPE LINE TO DEM TERRAIN NODES

AND THE DEM AND DOMAIN BOUNDARIES

During setup processing AERMAP checks all of the sources and receptors specified to

ensure that they lie within the domain and within the area covered by the DEM files. AERMAP

generates a fatal error message and will stop before calculating elevations when:

1) a receptor or source is found to lie outside the domain,

2) a receptor or source is found to lie outside of the DEM files. 

If the domain extends beyond the area covered by the DEM data, further processing will

continue provided no fatal error messages are generated from the above two conditions. Smaller

domains and fewer DEM files can decrease processing time. Appropriate error messages are

produced if the domain corners do not lie within a DEM file or the receptors are outside the

DEM files.
2-7

2.1.3 Sources and Receptors

The receptors are specified in the AERMAP terrain preprocessor in a manner identical to

the AERMOD dispersion model. AERMAP allows the user to specify discrete receptors as well

as Cartesian and polar grid networks. However, there are some special considerations for

AERMAP.

In AERMOD, when specifying discrete polar receptors, it is necessary to specify the

position of a “source” relative to which the receptor is assigned. The locations of these sources

can be specified on the optional source pathway (see Section 3.3). 

All the source and receptor coordinates are referenced to a set of local coordinates which

are called ANCHOR coordinates. The ANCHOR coordinates are referenced to a set of UTM

coordinates. The datum of the referenced UTM coordinates needs to be specified on the

ANCHOR input line. This datum value will be used by the program to align the various sources

and receptors coordinates to the node coordinates of the individual DEM files. In cases where

the datums are different, the source and receptor coordinates will be shifted accordingly. A “0"

datum specification, needs to be used by international users or in the cases where the DEM files

do not have a datum stated. This will cause the program to use the coordinates as found. There

will be no shifting of coordinates due to datum differences. Fourteen conversion files for the 7.5

minute DEM data are needed if “0" is not used. These files cover coordinate shifts for the

Continental United States (CONUS), Alaska, Hawaii, Guam, Puerto Rico and the Virgin Island.

The modeling domain can cross UTM zones. However, if the receptor locations are

specified in UTM coordinates, then they must all be referenced to the same UTM zone. When

using 7.5-minute DEM data, AERMAP will check for zone changes in the receptor network, and

adjust the coordinates accordingly.
2-8

The user has the option of having AERMAP determine the terrain or base elevations for

the receptors from the DEM data or to provide the receptor elevations. This option is set in the

COntrol pathway. If the user requests AERMAP to determine the receptor base elevations from

the DEM file(s) and provides the receptor elevations as well, the program will ignore the user

input elevations. AERMAP determines the receptor elevation of each of the receptors by a

distance-weighted two-dimensional interpolation of the elevation values at the four nearest DEM

nodes surrounding the receptor location (See section Section 4.4 for equations.). The same

procedure is applied to source elevations if source locations are identified.

If the user provides the receptor elevations, AERMAP will use these elevations rather

than extracting them from the digital data. Note that the DEM files are required even if the user

is providing the receptor heights because the DEM data are used to obtain the hill height scale

for each receptor. If the user specifies the receptor elevations, they can be entered in either feet,

meters, or decimeters. The output receptor elevations will always be in meters. If the user

indicates that receptor heights are provided but does not have the receptor heights in the input

file, then a height of 0 meters is written to the output file and a warning message will be

generated.

2.1.4 Terrain Data Files

The appropriate 7.5-minute and 1-degree DEM file(s) can be obtained from the USGS or

from commercial sites on the internet. If more than one DEM file is required, then each DEM

file specified in the input runstream must have at least one other DEM file adjacent to it

otherwise the isolated DEM file(s) will be flagged. AERMAP prints to the output file an array

of DEM files and lets the user know that a DEM file is missing from the array by stating “No

Map Present” in place of a DEM map name. This makes it easier for the user to troubleshoot for

misspelled DEM map names, errant or missing DEM files. 
2-9

When designing a study and planning to download the required terrain data, keep several

things in mind. A 1-degree DEM file or a 7.5 minute DEM file (with node spacing of 10

meters), can be as large as 10 MB. AERMAP creates an additional temporary binary file

corresponding to each DEM file which can also be as much as 6 Mb each in size, depending on

the size of the domain. A 7.5-minute DEM file, with 30 meter node spacing, can be as large as

1.2 MB but only covers 1/64th of the same area as a 1-degree DEM file. Approximately 80 to 90

7.5-minute DEM files are needed for a study outward to 50 kilometers from a source.

The new Spatial Data Transfer Standard (SDTS) is being promoted by the USGS to

eventually replace the old “native” DEM files. The SDTS files are available on the internet and

can be found zipped in a “tar” format. Each SDTS file contains over a dozen files that are used

to reconstitute the SDTS data back into the old “native” DEM format. The “native” format is

read directly by AERMAP. To reconstitute a DEM file: 1) unzip the SDTS file, 2) un-“tar” the

files, 3) use SDTS2DEM to convert the SDTS files back to the native DEM format. A batch file,

DEMFILZ.BAT, was constructed and is available on the EPA web site, SCRAM, for

reconstituting DEM files. The DEMFILZ is not fully automatic and requires some responses to

batch file prompts. Detailed information and instructions are part of DEMFILZ batch file

coding.

The USGS offered DEM data files are in a UNIX-compressed format and must be

uncompressed with a utility that can work with UNIX files. These programs are widely

available as shareware and freeware programs. One example is the WINZIPTM program from

Nico Mak Computing, Inc. The uncompressed file does not include record delimiters that are

recognized by the Windows Operating System, and therefore may not be used directly with

AERMAP. For Windows users only, the utility program CRLF.EXE, included with AERMAP,

adds a carriage return and line feed to the end of each record in the uncompressed DEM data file

to create a DOS-compatible file. To use this utility, start the Command Prompt and simply type

CRLF followed by the input file name and output file name (without the DOS redirection
2-10

symbols, “<“, ”>”). The output file is now ready to use in AERMAP. This process is for files

that are already in the old “native” DEM format.

2.2 KEYWORD/PARAMETER APPROACH

The input runsteam file needed to run the AERMAP preprocessor is based on an

approach that uses descriptive keywords and parameters, and allows for a flexible structure and

format. A brief overview of the approach is provided here. A complete description of this

approach can be found in the AERMOD User's Guide (EPA, 1998).

The input runsteam file is divided into four functional "pathways." These pathways are

identified by two-character identifiers at the beginning of each record in the runsteam. The

pathways for AERMAP are:

CO - for specifying overall job COntrol options;

SO - for specifying the SOurce location information (optional);

RE - for specifying the REceptor information; and

OU - for specifying the OUtput file information.

The optional source pathway may be used to specify source locations for the purpose of

extracting source elevations from the DEM data and/or for specifying the origin of discrete or

gridded polar receptors.

Each line, or image, in the input runsteam consists of a pathway identifier, an eightcharacter keyword and a parameter list. The keywords and parameters that make up an input

runstream file can be thought of as a command language through which the user communicates

with the preprocessor what is to be accomplished for a particular run. The keywords specify the

type of option or input/output data and the parameters following the keyword define the specific

options or actual file names.
2-11

There are several rules of syntax for structuring an input runstream. Briefly, they are:

1) All inputs for a particular pathway must be contiguous;

2) Each record in the runstream file must be 132 characters or less, which includes

the pathway, the keyword and any parameters;

3) Alphabetic characters can be input as either upper or lower case because

AERMAP converts all character input to upper case internally (except for the title

parameters and filenames);

4) Several keywords are mandatory and must be present in every runstream file;

5) With a few exceptions, the order of the keywords is not critical;

6) Blank lines can be used to improve readability; asterisks in the first two columns

(the pathway field) identify the record as a comment.

2.3 AN EXAMPLE AERMAP INPUT FILE

This section describes the three required pathways that constitute an AERMAP input file

-- the control (CO) pathway, the receptor (RE) pathway, and the output (OU) pathway. The

optional source (SO) pathway is described in Section 3.3.
2-12

2.3.1 Selecting Preprocessing Options - CO Pathway

The mandatory keywords for the CO pathway are listed below. These keywords

primarily control file types and names and the definition of the modeling domain. A complete

discussion of all keywords is in Section 3 and a listing of all keywords is provided in Appendix

B.

STARTING - Indicates the beginning of inputs for the pathway; this keyword is

mandatory on each of the pathways.

TITLEONE - A user-specified title line (up to 68 characters) that will appear on

each page of the printed output file (an optional second title line is

also available with the keyword TITLETWO).

DATATYPE - specifies the type of raw terrain data being supplied to the

preprocessor. 

DATAFILE - Identifies the raw terrain files being supplied in this run.

DOMAINXY or - Defines the extent of the domain in UTM (meters) or

DOMAINLL Lat/Long (decimal degrees).

ANCHORXY - Defines the relationship between the user-coordinate system and

the UTM coordinate system.

RUNORNOT - A special keyword that tells the program whether to run the full

preprocessor executions or not. If the user selects not to run, then

the input runstream file will be processed and any input errors

reported, but no calculations will be made.
2-13

CO STARTING

 TITLEONE A Simple Example Problem for the AERMAP Preprocessor

 DATATYPE DEM1

 DATAFILE CHATT-W.DEM

 DOMAINXY 620000.0 3920000.0 16 625000.0 3925000.0 16

 ANCHORXY 0.0 0.0 622500 3922500 16 1 

 RUNORNOT RUN

CO FINISHED

FINISHED - Indicates that the user is finished with the inputs for this pathway;

this keyword is also mandatory on the other pathways.

The order of the keywords within this pathway is not critical, although the intent of the

input runstream file may be easier to decipher if a consistent and logical order is followed. It is

suggested that users follow the order in which the keywords are presented in Section 3, unless

there is a clear advantage to doing otherwise.

A minimal but complete runstream file for the CO pathway may look something like this:

The first and last keywords identify the beginning and end of the COntrol pathway. The

TITLEONE keyword provides a means of entering information about the run that will be

included as a comment card in the output file. The parameter field for the TITLEONE keyword

should not be in quotation marks. The preprocessor reads whatever appears in columns 13 - 80

of the TITLEONE record as the title field, without changing the lower case to upper case letters. 

Leading blanks are therefore significant if the user wishes to center the title within the field. 

Similar rules apply to the optional TITLETWO keyword.

In the current version, two types of raw terrain DATATYPE are allowed -- the

7.5-minute and 1-degree DEM data. In this example, 1-degree DEM data is being used, which is

identified by the parameter DEM1. The extent of the domain can be specified in one of two

ways -- DOMAINXY or DOMAINLL -- depending on whether the user specifies the domain

extent in UTM coordinates (DOMAINXY) or longitude/latitude coordinates (DOMAINLL). In
2-14

this example, UTM coordinates are specified, with the southwest corner of the domain at 620000

Easting (E) and 3920000 Northing (N) in zone 16, while the northeast corner of the domain is at

625000 E and 3925000 N in zone 16. NOTE: Since longitude increases from east to west over

North America, the domain is defined by the southeast and northwest corners when DOMAINLL

is used.

The ANCHORXY keyword specifies the relationship between the coordinate system

employed by the user to define source and receptor locations and the UTM coordinate system. 

The data provided on the ANCHORXY keyword are used to convert the source and receptor

locations to UTM coordinates by AERMAP. If the UTM coordinate system is used for receptor

locations, then the x- and y-coordinates for the point used to anchor the two systems are the

same. In this example, the origin of a user-specified system (0.0, 0.0) is anchored to a point with

UTM coordinates of 622500E, 3922500N in Zone 16. The entered datum value is 1 which

indicates the anchor point is referenec to NAD 27.

The only remaining mandatory keyword for the CO pathway is RUNORNOT. If the user

is unsure about the syntax or operation of keywords or parameters, or is setting up a complex

runstream file to run for the first time, it may be useful to set the preprocessor NOT to run. With

this parameter set, AERMAP simply reads and analyzes the entire input file and reports any

errors or warning messages that are generated. All of the inputs are summarized in the output

file for the user to review just as if the parameter was set to RUN. Once the input file has been

debugged using these descriptive error/warning messages, then the RUNORNOT switch can be

set to RUN, as is done in this example.

Since the pathway ID is required to begin in column 1 (see Section 2.4.8 of the

AERMOD user's guide for a discussion of this restriction), the preprocessor will assume that the

previous pathway is in effect if the pathway field is left blank, as has been done in this example

for all runstream images between the STARTING and FINISHED keywords. The preprocessor

will do the same for blank keyword fields, which will be illustrated in the next section.
2-15

RE STARTING

 GRIDPOLR POL1 STA

 POL1 ORIG 0.0 0.0

 POL1 DIST 100. 200. 300. 500. 1000.

 POL1 GDIR 36 10. 10.

 POL1 END

RE FINISHED

In addition to these mandatory keywords on the CO pathway, the user may select

optional keywords to specify whether or not receptor terrain elevations need to be generated or

whether they are supplied (the default is to generate terrain elevations) and to allow the use of

receptor heights above ground-level for flagpole receptors. These options are described in more

detail in Section 3.

2.3.2 Specifying a Receptor Network - RE Pathway

In this section, our example will illustrate the use of a single polar receptor network

centered on the origin of the user-specified coordinate system, perhaps the stack location. Other

options available on the REceptor pathway include specifying a Cartesian grid receptor network,

and specifying discrete receptor locations in either a polar or a Cartesian system. These other

options are described in more detail in Section 3.

For this example, a polar network with receptors located at five downwind distances for

every 10-degree flow vector around a source is specified. The RE pathway for this example is:

The GRIDPOLR keyword can be thought of as a "sub-pathway," in that all of the

information for a particular polar network must be in contiguous records. Note, too, that there is

a set of secondary keywords, including something that looks like a STArting and ENDing that

identify the start and end of the sub-pathway. The order of secondary keywords within the

sub-pathway is not critical, similar to the primary pathways. Each image in this sub-pathway

must be identified with a network ID (up to eight alphanumeric characters), in this case it is

"POL1." The “POL1" coordinates are referenced back to the ANCHOR point. Multiple
2-16

networks may be specified in a single preprocessor run. The preprocessor waits until the END

secondary keyword is encountered before processing begins. Other secondary keywords that

may be used include terrain heights for receptors on elevated terrain or flagpole receptor heights

if those options are being exercised by the user. The use of these optional secondary keywords is

described in detail in Section 3.4.

For this example, the ORIG secondary keyword specifies the location of the origin, in

(X,Y) coordinates, for the polar network being defined. The ORIG keyword is optional, and the

program will default to an origin of (0.0, 0.0) if it is omitted. This is with respect to the

ANCHOR coordinates. The DIST keyword identifies the distances in meters along each

direction radial (flow vector) at which the receptors are located. In this example, there are five

distances. More receptors could be added by adding values to the input image or by repeating

the DIST secondary keyword with the additional distances. The GDIR keyword specifies that

the program will Generate DIRection radials for the network. In this example, there are 36

directions, beginning with the 10-degree flow vector (the first parameter) and incrementing

every 10 degrees clockwise (the last parameter). As a result, there are 36 directions * 5

distances, or 180 receptors for this example. Rather than let AERMAP generate the direction

radials, the user may elect to define Discrete DIRection radials instead by using the DDIR

keyword in place of the GDIR keyword (see Section 3.4.1.2).

2.3.3 Specifying the Output File - OU Pathway

The RECEPTOR keyword on the output pathway is used to specify the output filename

for the receptor data generated by AERMAP. For this example, the output pathway may look

like this:
2-17

OU STARTING

 RECEPTOR AERMAP.OUT

OU FINISHED

where AERMAP.OUT is the name of the file that will contain the receptor data, including

receptor elevations and height scales, generated by AERMAP. The AERMAP.OUT file may

then be included in a runstream for the AERMOD model. If the optional source pathway is used

to specify source locations and terrain elevations are extracted from the DEM data, then the

output filename for the source location data would be specified using the SOURCLOC keyword

on the OU pathway (see Section 3.5).

2.4 RUNNING AERMAP

Now that we have a complete and error-free runstream input file, we are ready to run the

preprocessor and review the results. The PC-executable file for AERMAP available on the

EPA's Support Center for Regulatory Air Models (SCRAM) website on the Internet

(www.epa.gov/scram001) opens the runstream input and output message files without the need

to "redirect" the I/O on the command line using the DOS redirection symbols '<' and '>'. The

command line to run the sample problem might look something like this on the PC:

C:\>AERMAP

AERMAP assumes that the input runstream input file is named AERMAP.INP. AERMAP.OUT

is opened as the output message file containing an echo of the input runstream and a listing of

any warning or error messages generated by AERMAP. As described in Section 2.3.3, the

filename for the data file containing the terrain elevations and height scales for all of the

receptors is specified within the input runstream on the output pathway. The DOS prompt is

represented by the characters "C:\>", but may appear different on different machines, depending

on how the user configures his/her system. The important points are that the AERMAP
2-18

executable file must be in the directory from which you are attempting to run the program. The

input file must be located in the directory from which the program is being executed. The output

file is written to the directory from which the program is being executed. Also needed are the 7

*.LAS and the 7 *.LOS files that are needed by the NADCON subroutine for converting the 7.5-

minute datums to NAD 83. These 14 files need to be in the same subdirectory as the AERMAP

executable.

When AERMAP is executed, an update on the status of processing is displayed on the PC

monitor. AERMAP first indicates that the setup information in the input runstream file is being

processed, followed by initializing the terrain data, and then displays the receptor number

currently being processed. If the preprocessor stops after completing the setup processing, then

either the RUNORNOT parameter was set to NOT, or a fatal error was encountered during the

setup processing. The user should review the message file (AERMAP.OUT in this example) to

determine why AERMAP was unsuccessful, correct the input and rerun AERMAP.

Any error message generated by the operating system rather than AERMAP is displayed

on the screen and not written to the message file. One such message might be that there is

insufficient memory available to run the program. Handling of system error messages may

require some knowledge of user’s operating ssytem whether it be Windows, Unix, Linux, DOS,

MAC, etc. Sometimes the meaning of the message is obvious. Sometimes they can be obscure.

The message file specified on the command line will always be generated by the program

which will contain any error, warning or diagnostic messages that were generated during the run. 

By default, the program will echo each line of the input runstream file to the message file to

provide a convenient record of the inputs as originally read into the preprocessor. However, for

some applications, the length of the input runstream file may be too cumbersome to include the

entire set of inputs at the beginning of each output file. This situation may happen, for example,

if a large number of discrete receptor locations are used. For this reason, the user is provided

with the option to "turn off" the echoing of the input file at any point within the runstream file. 
2-19

This is accomplished by entering the keywords "NO ECHO" in the first two fields anywhere

within the runstream file. In other words, place NO in the pathway field, followed by a space

and then ECHO. None of the input runstream images after the NO ECHO will be echoed to the

output file. Thus, a user may choose to place NO ECHO after the Control pathway in order to

keep the control options echoed, but suppress echoing the rest of the input file.

If the original input file might be lost or destroyed, use of the NO ECHO option would

not be a wise choice. If the NO ECHO is omitted, the original runstream (input) data are echoed

to the message file. The runstream data can be copied to another filename and used as an input

file to reproduce that particular application. The data are echoed at the beginning of this file and

AERMAP keys on the "RE FINISHED" image to stop processing the runstream file.

The output data file specified on the output pathway of the input runstream contains the

receptor pathway as entered by the user in the input file with the addition of the receptor terrain

elevations (if requested) and receptor height scales as calculated by AERMAP. This output data

file can now be used for the REceptor pathway of an AERMOD input file. Several header

records are included in the output data file to identify the version of AERMAP used to generate 

the file and other information useful for interpreting the results. An example of the AERMAP

output file for the sample problem is shown in Figure 2-4.
2-20

** AERMAP - VERSION 98022

** A Simple Example Problem for the AERMAP Preprocessor

** 

** A total of 1 1-degree DEM files were used

** DOMAINXY 620000.0 3920000.0 16 625000.0 3925000.0 16

** ANCHORXY 0.0 0.0 622500 3922500 16 1

** Terrain heights were extracted by default

RE ELEVUNIT METERS

 GRIDPOLR POL1 STA

 POL1 ORIG 0.0 0.0 

 POL1 DIST 100. 200. 300. 500. 1000.

 POL1 GDIR 36 10. 10. 

 GRIDPOLR POL1 ELEV 1 465.97 451.61 426.67 416.84 535.88

 GRIDPOLR POL1 ELEV 2 462.35 443.92 416.04 403.33 491.90

 GRIDPOLR POL1 ELEV 3 458.98 437.87 408.39 392.52 451.40

 GRIDPOLR POL1 ELEV 4 456.31 431.12 401.68 377.89 407.62

 GRIDPOLR POL1 ELEV 5 453.52 424.67 398.19 360.74 358.05

 GRIDPOLR POL1 ELEV 6 450.14 420.11 394.95 345.67 336.48

 GRIDPOLR POL1 ELEV 7 447.18 417.53 390.88 341.64 337.38

 GRIDPOLR POL1 ELEV 8 444.76 413.26 387.52 341.08 369.71

 GRIDPOLR POL1 ELEV 9 442.99 410.57 383.17 340.11 403.53

 .

 .

 .

 GRIDPOLR POL1 HILL 1 548.00 547.00 547.00 536.00 539.00

 GRIDPOLR POL1 HILL 2 548.00 547.00 547.00 547.00 547.00

 GRIDPOLR POL1 HILL 3 548.00 547.00 547.00 547.00 547.00

 GRIDPOLR POL1 HILL 4 548.00 547.00 547.00 547.00 547.00

 GRIDPOLR POL1 HILL 5 548.00 548.00 547.00 547.00 540.00

 GRIDPOLR POL1 HILL 6 548.00 548.00 547.00 547.00 540.00

 GRIDPOLR POL1 HILL 7 548.00 548.00 548.00 547.00 548.00

 GRIDPOLR POL1 HILL 8 548.00 548.00 548.00 548.00 536.00

 GRIDPOLR POL1 HILL 9 548.00 548.00 548.00 548.00 536.00

 .

 .

 .

 GRIDPOLR POL1 END

FIGURE 2-4 EXAMPLE OF AN AERMAP OUTPUT FILE FOR THE SAMPLE PROBLEM

2.5 SIZE LIMITATIONS AND CREATING A NEW EXECUTABLE

AERMAP was rewritten using allocatable arrays. Therefore, the only limitation may be

if users want to store large number of DEM files on their hard drives.

AERMAP was written to Fortran 90 standards. A user should be able to recompile

AERMAP for different operating systems without having to change any of the underlying source
2-21

code. See Appendix D for a listing of compiler option settings for compiling AERMAP with

Compaq Visual Fortran.
3-1

3.0 DETAILED KEYWORD REFERENCE

This section of the AERMAP User's Guide provides a detailed reference for all of the

input keyword options for the AERMAP preprocessor. The information provided in this section

is more complete and detailed than the information provided in Section 2. Since this section is

intended to meet the needs of experienced modelers who may need to understand completely

how particular options are implemented in the preprocessor, the information for each keyword

should stand on its own. This section assumes that the reader has a basic understanding of the

keyword/parameter approach used by the AERMOD model and the AERMAP preprocessor for

specification of input options and data. Novice users should first review the contents of Section

2 or the AERMOD User's Guide in order to obtain that understanding.

3.1 OVERVIEW

The information in this section is organized by function, i.e., the keywords are grouped

by pathway, and are in a logical order based on their function within the preprocessor. The order

of keywords presented here is the same as the order used in the functional keyword reference in

Appendix B, and the Quick Reference section at the end of the volume. The syntax for each

keyword is provided, and the keyword type is specified - either mandatory or optional and either

repeatable or non-repeatable. Unless noted otherwise, there are no special requirements for the

order of keywords within each pathway, although the order in which the keywords are presented

here and in Appendix B is recommended. Any keyword which has special requirements for its

order within the pathway is so noted following the syntax and type description.

The syntax descriptions in the following sections use certain conventions. Parameters

that are in all capital letters and underlined in the syntax description are secondary keywords that

are to be entered as indicated for that keyword. Other parameters are given descriptive names to

convey the meaning of the parameter, and are listed with an initial capital letter. Many of the

parameter names used correspond to variable names used in the computer code of the
3-2

preprocessor. Parentheses around a parameter indicate that the parameter is optional for that

keyword. The default that is taken when an optional parameter is left blank is explained in the

discussion for that keyword.

3.2 CONTROL PATHWAY INPUTS AND OPTIONS

The COntrol pathway contains the keywords that provide the overall control of the

preprocessor run. These include the specification of the terrain data, the geographic extent of the

scenario, and others that are described below. The CO pathway must be the first pathway in the

runstream input file.

3.2.1 Title Information

There are two keywords that allow the user to specify up to two lines of title information. 

The title is included as comment cards in the output data file. The first keyword, TITLEONE, is

mandatory, while the second keyword, TITLETWO, is optional. The syntax and type for the

keywords are summarized below:

Syntax: CO TITLEONE Title1

CO TITLETWO Title2

Type: TITLEONE - Mandatory, Non-repeatable

TITLETWO - Optional, Non-repeatable

The parameters Title1 and Title2 are character parameters of length 68, which are read as a

single field from columns 13 to 80 of the input record. The title information is taken as it

appears in the runstream file without any conversion of lower case to upper case letters. If the

TITLETWO keyword is not included in the runstream file, then the second line of the title in the

output data file will appear blank.
3-3

3.2.2 Options for Elevated Terrain

The optional TERRHGTS keyword controls whether the receptor elevations and optional

source elevations should be extracted from the DEM data files or that the user-provided receptor

terrain elevations should be used. The syntax and type of the TERRHGTS keyword are

summarized below:

Syntax: CO TERRHGTS EXTRACT or PROVIDED

Type: Optional, Non-repeatable

where the EXTRACT secondary keyword instructs the preprocessor to determine the terrain

heights from the DEM data files provided by the user. The PROVIDED secondary keyword

forces the preprocessor to use the user-specified elevations that are entered on the receptor

pathway and optional source pathway. Any terrain heights that are entered on the receptor

pathway are ignored if EXTRACT terrain option is specified, and a non-fatal warning message is

generated. The default option is to EXTRACT receptor elevations if no TERRHGTS keyword is

present in the input runstream.

3.2.3 Flagpole Receptor Height Option

The FLAGPOLE keyword specifies that receptor heights above local ground level (i.e.

flagpole receptors) are allowed on the REceptor pathway. The FLAGPOLE keyword may also

be used to specify a default flagpole receptor height other than 0.0 meters. The syntax and type

of the FLAGPOLE keyword are summarized below:

Syntax: CO FLAGPOLE (Flagdf)

Type: Optional, Non-repeatable
3-4

where Flagdf is an optional parameter to specify a default flagpole receptor height. If no

parameter is provided, then a default flagpole receptor height of 0.0 meters is used. Any flagpole

receptor heights that are entered on the Receptor pathway are ignored if the FLAGPOLE

keyword is not present on the Control pathway, and a non-fatal warning message is generated. 

In this case, the flagpole receptor heights are not included in the output file from AERMAP.

3.2.4 Terrain Data Type Specifications

The DATATYPE keyword is needed to specify the type of the raw terrain data being

provided to the preprocessor. The current version of AERMAP accepts either the 1-degree DEM

data or the 7.5-minute DEM data. The syntax and type of the keyword are summarized below:

Syntax: CO DATATYPE DEM1 or DEM7

Type: Mandatory, Non-repeatable

where the secondary keyword DEM1 specifies that 1-degree DEM data will be used, and DEM7

specifies that 7.5-minute DEM data will be used. Only one type of DEM data may be used in a

given AERMAP run.

3.2.5 Terrain Data File Names Specifications

The DATAFILE keyword is needed to specify the names of the raw terrain data being

provided to the preprocessor. The keyword is repeatable so that multiple raw terrain file names

can be specified. The maximum allowable number of files is determined by the NDEM

parameter in the computer code. The syntax and type of the keyword are summarized below:

Syntax: CO DATAFILE filename

Type: Mandatory, Repeatable
3-5

If the specified file is not found on the computer, the program will generate a fatal error message.

3.2.6 Domain Extent Specifications

The DOMAINXY or the DOMAINLL keyword is used to define the geographic extent of

the domain that includes all the receptors and sources specified in this run and within which the

raw terrain data points will be included in calculation of the receptor height scales. Either of the

two keywords may be used to specify the domain extent. The DOMAINXY keyword allows the

user to specify the domain in UTM coordinates while the DOMAINLL keyword allows the user

to specify it in the World Geodetic System (latitude / longitude). The syntax and type of the

keywords are summarized below:

Syntax: CO DOMAINXY Xdmin Ydmin Zonmin Xdmax Ydmax Zonmax

CO DOMAINLL Lonmin Latmin Lonmax Latmax

Type: Mandatory, Non-repeatable

For the DOMAINXY keyword, Xdmin, Ydmin and Zonmin are the UTM Easting coordinate,

UTM Northing coordinate and the UTM zone for the lower left (southwest) corner of the

domain; Xdmax, Ydmax and Zonmax are the UTM Easting coordinate, UTM Northing

coordinate and the UTM zone for the upper right (northeast) corner of the domain. The UTM

coordinates are specified in meters. For the DOMAINLL keyword, Lonmin and Latmin are the

longitude and latitude in decimal degrees for the lower right (southeast) corner of the domain;

Lonmax and Latmax are the longitude and latitude in decimal degrees for the upper left

(northwest) corner of the domain. Note that longitude is entered first, followed by latitude. The

current version of AERMAP uses a positive value for west longitude. The DOMAIN

coordinates are not shifted for different NADs.
3-6

3.2.7 Anchor Location Specifications

The ANCHORXY keyword is used to relate the origin of the user-specified coordinate

system in the receptor grid to the UTM coordinate system. The user has the option of specifying

the receptor locations in either UTM coordinates or in some arbitrary user-specified coordinate

system. For any further processing of the terrain data, the preprocessor needs to determine the

location of the receptors in UTM coordinates. This is done with this keyword by specifying the

coordinates of anyone geographic location in the two coordinate systems. The syntax and type

of the keyword are summarized below:

Syntax: CO ANCHORXY Xauser Yauser Xautm Yautm Zautm Nada

Type: Mandatory, Non-repeatable

where Xauser and Yauser are the coordinates of any geographic location, typically the origin

(0,0), in the user coordinate system and Xautm, Yautm and Zautm are the UTM coordinates of

the same point in UTM Easting, Northing and Zone. If the user specifies the receptor locations

in UTM coordinates, the values of Xauser and Xautm will be identical, and so will those of

Yauser and Yautm. Nada represents the horizontal datum that was used to establish the anchor

point. Nada values range from 0 to 6. All receptor and source locations are referenced to this

point.

The following is a list of applicable Nada values and the datums Nada references. These

values follow the convention used in the USGS Blue Book and the list follows the convention

used in the DEM file headers all except for the use of “0" (zero). In Table 4-1, which was

extracted from the Blue Book, also lists these codes under Data Element 27. Ellipsoid and

spheroid are often used interchangeably in the literature.
3-7

NADA Description

0 No conversion between NAD 27 and NAD 83 for the DEM nodes, receptors, or

sources, and for international use.

1 North American Datum of 1927 (based on Clarke 1866 ellipsoid). 

 Shift to NAD83 (DEM7)

2 World Geodetic System of 1972 (based on WGS 72 ellipsoid). 

 No shift (DEM1)

3 World Geodetic System of 1984* (“identical” to the GRS 80 ellipsoid). 

 No Shift (DEM1)

4 North American Datum of 1983* (based on WGS 80 ellipsoid) 

 No shift (DEM7)

5 Old Hawaii Datum (based on Clarke 1866 ellipsoid but not NAD 27)

 Shift to NAD83 (DEM7)

6 Puerto Rico/ Virgin Island Datum (based on Clarke 1866 ellipsoid)

 Shift to NAD83 (DEM7)

TABLE 3-1. DATUM SWITCHES FOR ANCHOR LOCATION

* Note: The GRS80 and WGS84 ellipsoids are considered to be the same. 

Actually, there is a very small difference in the flattening which results in the

semi-minor axis, b, being different by 0.0001 meters. There is no known

application for which this difference is significant. The WGS84 and NAD83

datum are considered the same for all practical purposes.

NADCON is used to convert from NAD 27, Old Hawaiian, or Puerto Rico datums to NAD83

and vice versa. 

Internal to the AERMAP model, a datum code is read from each DEM header and all 7.5

minute data are converted to NAD 83. NADCON produces the shift values in both meters and

degrees, minutes, seconds that are added to the receptor and source. NADCON is only called for
3-8

converting 7.5-minute DEM coordinates from one datum to another. There are additional

parameter files required which have the *.LAS and *.LOS extensions for the CONUS, Hawaii,

Puerto Rico/Virgin Islands, Alaska and three Alaskan Island Groups (St. George, St. Paul, and 

St. Lawrence). These 14 files need to be included in the same subdirectory as the AERMAP

input file. 

Note: For international users, setting Nada to “0" will bypass NADCON and the

need to enter any parameter files.

The two 1-degree datums, WGS 72 and WGS 84, are both Earth-centric datums. The

difference in point locations varies with latitude from about 7 meters for areas north of Alaska to

about 17 meters for areas near 20 degrees north latitude. With a node spacing of approximately

90 meters, the difference between the two 1-degree datums is thought to be inconsequential. No

conversions are done between the two datum types.

 3.2.8 To Run or Not to Run - That is the Question

Because of the error handling and the "defensive programming" that has been employed

in the design of the AERMAP model, it is intended that the program will read through all of the

inputs in the runstream file regardless of any errors or warnings that may be encountered. If a

fatal error occurs in processing of the runstream information, then further program calculations

will be aborted. Otherwise, the program will attempt to run. Because of the great many options

available in the AERMAP preprocessor, and the potential for wasted resources if a large run is

performed with some incorrect input data, the RUNORNOT keyword has been included on the

Control pathway to allow the user to specify whether to RUN the preprocessor and perform all of

the calculations, or NOT to run and only process the input runstream data and summarize the

setup information. The syntax and type of the RUNORNOT keyword are summarized below:
3-9

Syntax: CO RUNORNOT RUN or NOT

Type: Mandatory, Non-repeatable

3.3 SOURCE PATHWAY INPUTS AND OPTIONS (OPTIONAL)

The optional SOurce pathway is used to define source locations for the purpose of

generating source elevations from the DEM data and/or for identifying the origins of discrete

polar receptors. There is only one keyword available on the source pathway, besides

STARTING and FINISHED. The syntax and type of the LOCATION keyword are summarized

below:

Syntax: SO LOCATION Srcid Srctyp Xs Ys (Zs)

Type: Mandatory if using Discrete Polar Receptors,

Mandatory if using source ID for origin of polar grid, Repeatable

where Srcid is an alphanumeric source ID of up to eight characters, Srctyp is the source type,

which is identified by one of the secondary keywords - POINT, VOLUME, AREA,

AREAPOLY, or AREACIRC, Xs and Ys are the x-coordinate (East) and y-coordinate (North) of

the source location in meters, and Zs is the optional source elevation in meters above mean sea

level. This keyword is mandatory if any discrete polar receptors are being used or if a source ID

is used to specify the origin for a polar grid. The keyword can be repeated up to a maximum

number of sources whose value is determined by the NSRC parameter in the computer code.

3.4 RECEPTOR PATHWAY INPUTS AND OPTIONS

The REceptor pathway contains keywords that define the receptor information for a

particular run. The RE pathway contains keywords that allow the user to define Cartesian grid

receptor networks and/or polar grid receptor networks, with either uniform or non-uniform grid

spacing, as well as discrete receptor locations referenced to a Cartesian or a polar system. The
3-10

program is initially setup to allow ten (10) gridded receptor networks of either (or both) types in

a single run, plus discrete receptors of either type, up to a maximum limit on the total number of

receptors. The limit on the total number of receptors in a given run is controlled by a Fortran

PARAMETER in the computer code (AERMAP.INC). The number of receptor networks

allowed is also controlled by a PARAMETER statement in AERMAP.INC, and may be easily

changed by the user and the program recompiled.

The default units for receptor elevations input to the AERMAP preprocessor are in

meters, however, the user may specify receptor elevations to be input in units of feet by adding

the optional RE ELEVUNIT FEET card immediately after the RE STARTING card. Regardless

of the input elevation units, AERMAP outputs all elevations in meters, and the RE ELEVUNIT

METERS card is added to the output file following the RE STARTING card.

3.4.1 Defining Networks of Gridded Receptors

Two types of receptor networks are allowed by the AERMAP preprocessor. A Cartesian

grid network, defined through the GRIDCART keyword, includes an array of points identified

by their x (east-west) and y (north-south) coordinates. A polar network, defined by the

GRIDPOLR keyword, is an array of points identified by direction and distance from a

user-defined origin. Each of these keywords has a series of secondary keywords associated with

it that are used to define the network, including any receptor elevations for elevated terrain and

flagpole receptor heights. The GRIDCART and GRIDPOLR keywords can be thought of as

"sub-pathways," since their secondary keywords include a STArt and an END card to define the

start and end of inputs for a particular network.

3.4.1.1 Cartesian Grid Receptor Networks.

Cartesian grid receptor networks are defined by use of the GRIDCART keyword. The

GRIDCART keyword may be thought of as a "sub-pathway," in that there are a series of
3-11

secondary keywords that are used to define the start and the end of the inputs for a particular

network, and to select the options for defining the receptor locations that make up the network. 

The syntax and type of the GRIDCART keyword are summarized below:

Syntax: RE GRIDCART Netid STA

 XYINC Xinit Xnum Xdelta Yinit Ynum Ydelta

 or XPNTS Gridx1 Gridx2 Gridx3 .... Gridxn, and

 YPNTS Gridy1 Gridy2 Gridy3 .... Gridyn

 ELEV Row Zelev1 Zelev2 Zelev3 ... Zelevn

 FLAG Row Zflag1 Zflag2 Zflag3 ... Zflagn

 END

Type: Optional, Repeatable

where the parameters are defined as follows:
3-12

Netid Receptor network identification code (up to eight alphanumeric

characters)

STA Indicates the STArt of GRIDCART inputs for a particular network,

repeated for each new Netid

XYINC

Xinit

Xnum

Xdelta

Yinit

Ynum

Ydelta

Keyword identifying uniform grid network generated from x and y

increments

Starting x-axis grid location in meters

Number of x-axis receptors

Spacing in meters between x-axis receptors

Starting y-axis grid location in meters

Number of y-axis receptors

Spacing in meters between y-axis receptors

XPNTS

Gridx1

Gridxn

Keyword identifying grid network defined by a series of discrete x

and y coordinates (used with YPNTS)

Value of first x-coordinate for Cartesian grid (m)

Value of 'nth' x-coordinate for Cartesian grid (m)

YPNTS

Gridy1

Gridyn

Keyword identifying grid network defined by a series of discrete x

and y coordinates (used with XPNTS)

Value of first y-coordinate for Cartesian grid (m)

Value of 'nth' y-coordinate for Cartesian grid (m)

ELEV

Row

Zelev

Keyword to specify that receptor elevations follow (optional)

Indicates which row (y-coordinate fixed) is being input (Row=1

means first, i.e., southmost row)

An array of receptor terrain elevations (m) for a particular Row

(default units of meters may be changed to feet by use of RE

ELEVUNIT keyword), number of entries per row equals the number of

x-coordinates for that network

FLAG

Row

Zflag

Keyword to specify that flagpole receptor heights follow

(optional)

Indicates which row (y-coordinate fixed) is being input (Row=1

means first, i.e., southmost row)

An array of receptor heights (m) above local terrain elevation for

a particular Row (flagpole receptors), number of entries per row

equals the number of x-coordinates for that network

END Indicates the END of GRIDCART inputs for a particular network,

 repeated for each new Netid
3-13

The ELEV and FLAG keywords are optional inputs, and are only needed if elevated

terrain or flagpole receptor heights are to be provided. If the ELEV keyword is used and the

preprocessor is being run with the TERRHGTS option set to EXTRACT (see Section 3.2.2), then

the elevated terrain height inputs will be ignored by the preprocessor, and a non-fatal warning

message will be generated. If the TERRHGTS option is set to PROVIDED, and no elevated

terrain heights are entered, the elevations will default to 0.0 meters, and warning messages will

also be generated. If the FLAG keyword is used and the FLAGPOLE option has not been

specified on the CO pathway (see Section 3.2.3), then the flagpole data will be ignored when the

output receptor data are generated. If the FLAGPOLE option is selected, and the FLAG

keyword is not used, then the default flagpole height will be output with the receptor data.

The order of cards within the GRIDCART subpathway is not important, as long as all

inputs for a particular network are contiguous and start with the STA secondary keyword and

end with the END secondary keyword. It is not even required that all ELEV cards be

contiguous, although the input file will be more readable if a logical order is followed. The

network ID is also not required to appear on each runstream image (except for the STA card). 

The program will assume the previous ID if none is entered, similar to the use of continuation

cards for pathway and keywords. Thus, the following two examples produce the same 8 X 4

Cartesian grid network:
3-14

RE GRIDCART CAR1 STA

 XPNTS -500. -400. -200. -100. 100. 200. 400. 500.

 YPNTS -500. -250. 250. 500.

 ELEV -500. 8*10.

 FLAG -500. 8*10.

 ELEV -250. 8*20.

 FLAG -250. 8*20.

 ELEV 250. 8*30.

 FLAG 250. 8*30.

 ELEV 500. 8*40.

 FLAG 500. 8*40.

RE GRIDCART CAR1 END

RE GRIDCART CAR1 STA

RE GRIDCART CAR1 XPNTS -500. -400. -200. -100. 100. 200. 400. 500.

RE GRIDCART CAR1 YPNTS -500. -250. 250. 500.

RE GRIDCART CAR1 ELEV 1 10. 10. 10. 10. 10. 10. 10. 10.

RE GRIDCART CAR1 ELEV 2 20. 20. 20. 20. 20. 20. 20. 20.

RE GRIDCART CAR1 ELEV 3 30. 30. 30. 30. 30. 30. 30. 30.

RE GRIDCART CAR1 ELEV 4 40. 40. 40. 40. 40. 40. 40. 40.

RE GRIDCART CAR1 FLAG 1 10. 10. 10. 10. 10. 10. 10. 10.

RE GRIDCART CAR1 FLAG 2 20. 20. 20. 20. 20. 20. 20. 20.

RE GRIDCART CAR1 FLAG 3 30. 30. 30. 30. 30. 30. 30. 30.

RE GRIDCART CAR1 FLAG 4 40. 40. 40. 40. 40. 40. 40. 40.

RE GRIDCART CAR1 END

RE GRIDCART CAR1 STA

 XPNTS -500. -400. -200. -100. 100. 200. 400. 500.

 YPNTS -500. -250. 250. 500.

 ELEV 1 8*10.

 FLAG 1 8*10.

 ELEV 2 8*20.

 FLAG 2 8*20.

 ELEV 3 8*30.

 FLAG 3 8*30.

 ELEV 4 8*40.

 FLAG 4 8*40.

RE GRIDCART CAR1 END

The Row parameter on the ELEV and FLAG inputs may be entered as either the row

number, i.e., 1, 2, etc., or as the actual y-coordinate value, e.g., -500., -250., etc. in the example

above. The program sorts the inputs using Row as the index, so the result is the same. The

above example could therefore be entered as follows, with the same result:
3-15

RE GRIDCART CG1 STA

 XYINC -5000. 11 1000. -5000. 11 1000.

RE GRIDCART CG1 END

Of course, one must use either the row number or y-coordinate value consistently within each

network to have the desired result.

The following simple example illustrates the use of the XYINC secondary keyword to

generate a uniformly spaced Cartesian grid network. The resulting grid is 11 x 11, with a

uniform spacing of 1 kilometer (1000. meters), and is centered on the origin (0., 0.). No elevated

terrain heights or flagpole receptor heights are included in this example.

3.4.1.2 Polar Grid Receptor Networks.

Polar receptor networks are defined by use of the GRIDPOLR keyword. The

GRIDPOLR keyword may also be thought of as a "subpathway," in that there is a series of

secondary keywords that are used to define the start and the end of the inputs for a particular

network, and to select the options for defining the receptor locations that make up the network. 

The syntax and type of the GRIDPOLR keyword are summarized below:

Syntax: RE GRIDPOLR Netid STA

 ORIG Xinit Yinit,

 or ORIG Srcid

 DIST Ring1 Ring2 Ring3 ... Ringn

 DDIR Dir1 Dir2 Dir3 ... Dirn,

 or GDIR Dirnum Dirini Dirinc

 ELEV Dir Zelev1 Zelev2 Zelev3 ... Zelevn

 FLAG Dir Zflag1 Zflag2 Zflag3 ... Zflagn

 END

Type: Optional, Repeatable
3-16

where the parameters are defined as follows:

Netid Receptor network identification code (up to eight alphanumeric

characters)

STA Indicates STArt of GRIDPOLR inputs for a particular network, repeat

for each new Netid

ORIG

Xinit

Yinit

Srcid

Keyword to specify the origin of the polar network (optional)

x-coordinate for origin of polar network

y-coordinate for origin of polar network

Source ID of source used as origin of polar network

DIST

Ring1

Ringn

Keyword to specify distances for the polar network

Distance to the first ring of polar coordinates

Distance to the 'nth' ring of polar coordinates

DDIR

Dir1

Dirn

Keyword to specify discrete direction radials for the polar network

First direction radial in degrees (1 to 360)

The 'nth' direction radial in degrees (1 to 360)

GDIR

Dirnum

Dirini

Dirinc

Keyword to specify generated direction radials for the polar

network

Number of directions used to define the polar system

Starting direction of the polar system

Increment (in degrees) for defining directions

ELEV

Dir

Zelev

Keyword to specify that receptor elevations follow (optional)

Indicates which direction is being input

An array of receptor terrain elevations for a particular direction

radial (default units of meters may be changed to feet by use of RE

ELEVUNIT keyword), number of entries per radial equals the number

of distances for that network

FLAG

Dir

Zflag

Keyword to specify that flagpole receptor heights follow (optional)

Indicates which direction is being input

An array of receptor heights above local terrain elevation for a

particular direction (flagpole receptors)

END Indicates END of GRIDPOLR subpathway, repeat for each new Netid

The ORIG secondary keyword is optional for the GRIDPOLR inputs. If omitted, the

program assumes a default origin of (0.,0.,) in x,y coordinates. The ELEV and FLAG keywords
3-17

RE GRIDPOLR POL1 STA

 DIST 100. 300. 500. 1000. 2000.

 GDIR 36 10. 10.

RE GRIDPOLR POL1 END

are also optional inputs, and are only needed if elevated terrain or flagpole receptor heights are to

be provided. If elevated terrain is being provided, then the ELEV inputs are needed for each

receptor. If the ELEV keyword are used and the program is being run with the TERRHGTS

option set to EXTRACT (see Section 3.2.2), then the elevated terrain height inputs will be

ignored by the preprocessor, and a non-fatal warning message will be generated. If the

TERRHGTS option is set to PROVIDED and no elevated terrain heights are entered, the

elevations will default to 0.0 meters, and warning messages will also be generated. If the FLAG

keyword is used and the FLAGPOLE option has not been specified on the CO pathway (see

Section 3.2.3), then the flagpole data will be ignored when the output receptor data are

generated. If the FLAGPOLE option is selected, and the FLAG keyword is not used, then the

default flagpole height will be output with the receptor data.

As with the GRIDCART keyword described above, the order of cards within the

GRIDPOLR subpathway is not important, as long as all inputs for a particular network are

contiguous and start with the STA secondary keyword and end with the END secondary

keyword. It is not even required that all ELEV cards be contiguous, although the input file will

be more readable if a logical order is followed. The network ID is also not required to appear on

each runstream image (except for the STA card). The program will assume the previous ID if

none is entered, similar to the use of continuation cards for pathway and keywords.

The following example of the GRIDPOLR keyword generates a receptor network

consisting of 180 receptor points on five concentric distance rings centered on an assumed

default origin of (0.,0.). The receptor locations are placed along 36 direction radials, beginning

with 10. degrees and incrementing by 10. degrees in a clockwise fashion.
3-18

RE GRIDPOLR POL1 STA

 ORIG 500. 500.

 DIST 100. 300. 500. 1000. 2000.

 DDIR 90. 180. 270. 360.

 ELEV 90. 5. 10. 15. 20. 25.

 ELEV 180. 5. 10. 15. 20. 25.

 ELEV 270. 5. 10. 15. 20. 25.

 ELEV 360. 5. 10. 15. 20. 25.

 FLAG 90. 5. 10. 15. 20. 25.

 FLAG 180. 5. 10. 15. 20. 25.

 FLAG 270. 5. 10. 15. 20. 25.

 FLAG 360. 5. 10. 15. 20. 25.

RE GRIDPOLR POL1 END

Another example is provided illustrating the use of a non-zero origin, discrete direction radials

and the specification of elevated terrain and flagpole receptor heights:

As with the GRIDCART keyword described earlier, the user has the option of specifying the

radial number (e.g. 1, 2, 3, etc.) on the ELEV and FLAG inputs, or the actual direction

associated with each radial.

3.4.2 Using Multiple Receptor Networks

For some modeling applications, the user may need a fairly coarsely spaced network

covering a large area to identify the area of significant impacts for a plant, and a denser network

covering a smaller area to identify the maximum impacts. To accommodate this modeling need,

the AERMAP preprocessor allows the user to specify multiple receptor networks in a single run.

The user can define either Cartesian grid networks or polar networks, or both. With the use of

the ORIG option in the GRIDPOLR keyword, the user can easily place a receptor network

centered on the facility being permitted, and also place a network centered on another

background source known to be a significant contributor to high concentrations. Alternatively,

the polar network may be centered on a receptor location of special concern, such as a nearby

Class I area.
3-19

As noted in the introduction to this section, the program initially allows up to 10 receptor

networks in a single run. This limit can be changed by modifying the Fortran PARAMETER

statement in the AERMAP.INC file and recompiling the program. There are also limits on the

number of distances or directions (or the number of x-points and the number of y-points for

Cartesian grids) that can be specified for each network. These are initially set to 100 distances

or x-points and 100 directions or y-points. These limits are also controlled by Fortran

PARAMETER statements in AERMAP.INC, and may be modified.

3.4.3 Specifying Discrete Receptor Locations

In addition to the receptor networks defined by the GRIDCART and GRIDPOLR

keywords described above, the user may also specify discrete receptor points for modeling

impacts at specific locations of interest. This may be used to model critical receptors, such as

the locations of schools or houses, nearby Class I areas, or locations identified as having high

concentrations by previous modeling analyses. The discrete receptors may be input as either

Cartesian x,y points (DISCCART keyword) or as polar distance and direction coordinates

(DISCPOLR keyword). Both types of receptors may be identified in a single run. In addition,

for discrete polar receptor points the user specifies the source location used as the origin for the

receptor on the SO LOCATION card (see Section 3.3).

3.4.3.1 Discrete Cartesian Receptors.

Discrete Cartesian receptors are defined by use of the DISCCART keyword. The syntax

and type of this keyword are summarized below:

Syntax: RE DISCCART Xcoord Ycoord (Zelev) (Zflag)

Type: Optional, Repeatable
3-20

where the Xcoord and Ycoord parameters are the x-coordinate and y-coordinate (m),

respectively, for the receptor location. The Zelev parameter is an optional terrain elevation (m). 

The Zflag parameter is the optional receptor height above ground (m) for modeling flagpole

receptors. All of the parameters are in units of meters, except for Zelev, which defaults to meters

but may be specified in feet by use of the RE ELEVUNIT keyword. Note that the output

elevations will always be in meters, regardless of input units.

If neither the elevated terrain option (Section 3.2.7) nor the flagpole receptor height

option (Section 3.2.8) are used, then the optional parameters are ignored if present. If only the

elevated terrain height option is used (no flagpoles), then the third parameter (the field after the

Ycoord) is read as the Zelev parameter. If only the flagpole receptor height option is used (no

elevated terrain), then the third parameter is read as the Zflag parameter. If both options are

used, then the parameters are read in the order indicated for the syntax above. If the optional

parameters are left blank, then default values will be used. The default value for Zelev is 0.0,

and the default value for Zflag is defined by the CO FLAGPOLE card (see Section 3.2.8). Note: 

If both the elevated terrain and flagpole receptor height options are used, then the third parameter

will always be used as Zelev, and it is not possible to use a default value for Zelev while entering

a specific value for the Zflag parameter.

3.4.3.2 Discrete Polar Receptors.

Discrete polar receptors are defined by use of the DISCPOLR keyword. The syntax and

type of this keyword are summarized below:

Syntax: RE DISCPOLR Srcid Dist Direct (Zelev) (Zflag)

Type: Optional, Repeatable

where the Srcid is the alphanumeric source identification for one of the sources defined on the

SO pathway which will be used to define the origin for the polar receptor location. The Dist and
3-21

Direct parameters are the distance in meters and direction in degrees for the discrete receptor

location. Degrees are measured clockwise from north. The Zelev parameter is an optional

terrain elevation for the receptor. The unit of Zelev is in meters, unless specified as feet by the

RE ELEVUNIT keyword. The Zflag parameter is the optional receptor height above ground

(meters) for modeling flagpole receptors.

If neither the elevated terrain option (Section 3.2.7) nor the flagpole receptor height

option (Section 3.2.8) is used, then the optional parameters are ignored if present. If only the

elevated terrain height option is used (no flagpoles), then the third parameter (the field after the

Ycoord) is read as the Zelev parameter. If only the flagpole receptor height option is used (no

elevated terrain), then the third parameter is read as the Zflag parameter. If both options are

used, then the parameters are read in the order indicated for the syntax above. If the optional

parameters are left blank, then default values will be used. The default value for Zelev is 0.0,

and the default value for Zflag is defined by the CO FLAGPOLE card (see Section 3.2.8). Note: 

If both the elevated terrain and flagpole receptor height options are used, then the fourth

parameter will always be used as Zelev, and it is not possible to use a default value for Zelev

while entering a specific value for the Zflag parameter.

3.4.3.3 Discrete Cartesian Receptors for EVALFILE Output.

The EVALCART keyword is used to define discrete Cartesian receptor locations, similar

to the DISCCART keyword, but it also allows for grouping of receptors, e.g., along arcs. It is

designed to be used with the EVALFILE option of AERMOD. The syntax and type for the

EVALCART keyword are summarized below:

Syntax: RE EVALCART Xcoord Ycoord Zelev Zflag Arcid (Name)

Type: Optional, Repeatable
3-22

where the Xcoord and Ycoord parameters are the x-coordinate and y-coordinate (m),

respectively, for the receptor location. The Zelev parameter is the terrain elevation (m) for the

receptor. The Zflag parameter is the receptor height above ground (m) for modeling flagpole

receptors. All of the parameters are in units of meters, except for Zelev, which default to meters

but may be specified in feet by use of the RE ELEVUNIT keyword. Note that the output

elevations will always be in meters, regardless of the input units. The Arcid parameter is the

receptor grouping identification, which may be up to eight characters long, and may be used to

group receptors by arc. The Name parameter is an optional name field that may be included to

further identify a particular receptor location. The Name parameter is ignored by the

preprocessor program and the AERMOD model.

3.5 OUTPUT PATHWAY INPUTS AND OPTIONS

The OUtput pathway is used to define filenames for the receptor and optional source

location output data. There are only two keywords available on the output pathway, besides

STARTING and FINISHED, one for receptor output data and the other for source location

output data. The syntax and type of the RECEPTOR keyword are summarized below:

Syntax: OU RECEPTOR Recfil

Type: Mandatory, Non-repeatable

where Recfil specifies the filename (up to 60 characters) for the receptor output data.

The syntax and type of the SOURCLOC keyword are summarized below:

Syntax: OU SOURCLOC Srcfile

Type: Optional, Non-repeatable
3-23

where Srcfil specifies the filename (up to 60 characters) for the source location output data. The

SOURCLOC keyword must be specified if the runstream contains a source pathway and the user

specifies that terrain heights are to be extracted from the DEM data.
4-1

4.0 TECHNICAL DESCRIPTION

This section describes the technical details of the AERMAP preprocessor. This is meant

to give the user a better understanding of the working of this preprocessor.

4.1 DETERMINING RECEPTOR HILL HEIGHT SCALES

For applications involving elevated terrain, the AERMOD model requires a hill height

scale which is used to calculate the critical dividing streamline height, Hcrit, for each receptor. 

The primary purpose of the AERMAP terrain preprocessor is to determine the hill height scale

(hc) for each receptor, based on the following procedure: 

1. Read the header record of each DEM file named in the runstream (input) and retain the

“highest elevation” value found in each record.

2. Determine and store the elevation height for each receptor (and source).

3. For each receptor, use the receptor elevation height as the initial controlling hill height

scale.

4. Search for the controlling hill height in the DEM file in which the receptor is located. 

This is done by calculating the slope between the receptor and each node based on

respective distance and elevation difference ( See Figure 2-3). If the slope is 10% or

greater, the DEM node elevation is compared to the controlling hill height scale. If

higher, the controlling hill height scale is replaced by the node elevation value as the new

controlling hill height scale. All the nodes within the DEM file that are within the

DOMAIN are searched.
4-2

5. Using the respective highest elevation value of each remaining DEM file,

calculate the slope between the receptor and the nearest point on each of the

remaining DEM files. Use the respective highest elevation and the receptor

elevation to calculate an initial slope. If the initial slope is greater than 10% for a

particular DEM file, use the steps in procedure 4 to search for a controlling hill

height in this DEM file. If a higher value is found, update the controlling hill

height.

6. Repeat Procedure 5 until all applicable DEM files have been searched for a controlling

hill height scale for each receptor.

4.2 DIGITAL ELEVATION MODEL (DEM) DATA

The USGS distributes DEM data in several scales from the 1-degree series at a scale of

1:250,000 down to the 7.5-minute series at a scale of 1:24,000. AERMAP can process any of

these scales. However, AERMAP has not been programmed to process more than one scale at a

time nor has it been yet tested using more than one basic quadrangle size (eg 7.5 x 18 minutes,

7.5 x 15 minutes, 7.5 x 11.5 minutes, and 7.5 x 10 minutes) as found in the State of Alaska. 

Outside of Alaska, the normal block size for a 7.5-minute series file is 7.5 x 7.5 minutes. It is

preferred that the user use the 7.5-minute data whenever possible. The 1-degree DEM series

provides coverage in 1 X 1-degree blocks; two such files provide the same coverage as a

standard 1:250,000-scale map series quadrangle. The 1-degree data also has different block size

for the State of Alaska and like the 7.5-minute series, the block sizes are dependent upon the

latitude. The 1-degree block sizes are discussed below.

A 7.5-minute DEM has the following characteristics:

• The data consist of a regular array of elevations referenced horizontally in the

UTM coordinate system.
4-3

• The unit of coverage is a 7.5-minute quadrangle.

• The data are ordered from south to north in profiles that are ordered from west to

east.

• The data are stored as profiles in which the horizontal spacing of the elevations

along and between each profile is either 10 or 30 m.

• The profiles do not always have the same number of elevations (nodes) because

of the variable angle between the quadrangle's true north and the grid north of the

UTM coordinate system.

• Elevations for the continental U.S. are either meters, feet, decimeters, or decifeet

referenced to mean sea level. DEM's of low-relief terrain or generated from

contour maps with intervals of 10 ft (3 m) or less are generally recorded in feet. 

DEM's of moderate to high-relief terrain or generated from maps with terrain

contour intervals greater than 10 ft are generally recorded in meters. A rare few

are in decifeet or decimeters.

Profiles for 7.5-minute DEM.’S are generated by using a UTM Cartesian coordinate

system as a base. The profiles are clipped to the straight-line intercept among the four

geographic corners of the quadrangle -- an approximation of the geographic map boundary as

shown in Figure 4-1.
4-4

FIGURE 4-1 STRUCTURE OF A 7.5-MINUTE DEM DATA FILE

 The UTM coordinates of the four corners (i.e., Pt 1, Pt 2, Pt 3 and Pt 4 in Figure 4-1) of the 7.5-

minute DEM's are listed in the type A (header) record, data element 11. The UTM coordinates

of the starting points of each profile are listed in the type B record (profiles), shown in Table 4-2,

data element 3. Because of the variable orientation of the quadrilateral in relation to the UTM

coordinate system, profiles intersect the east and west boundaries of the quadrangle, as well as

the north and south boundaries, as shown in Figure 4-1. In addition, 7.5-minute DEM's have

profile easting values that are continuous from one DEM to the adjoining DEM only if the

adjoining DEM is contained within the same UTM zone. This is illustrated in Figure 4-1 with

the use of non-filled in circles outside the border of the quadrangle. The non-filled in circles

represent nodes located in adjacent DEM files.Note: the spacing in the x and y directions can

also be 10 meters as well as the stated 30 meters. Finer resolutions may exist in the future and

AERMAP should be able to process them.
4-5

The 1-degree DEM data has the following characteristics (U.S. Dept. of Interior, 1993):

• The data consist of a rectangular array of elevations referenced horizontally on

the geographic (latitude/longitude) coordinate system (Figure 4-2).

• The unit of coverage is a 1-degree by 1-degree block. Elevation data on the

integer degree lines (all four sides of the DEM file) correspond with the same

node elevations of the surrounding eight DEM blocks. Four blocks are located on

the DEM sides and four DEMs have a common point in the corners.

• Elevations are in meters relative to mean sea level.

• The data are ordered from south to north in profiles that are ordered from west to

east.

• Spacing of the elevations along each profile is 3 arc-seconds. The first and the

last data points are the integer degrees of latitude. A profile, therefore, contains

1201 elevations.

• Spacing between profiles varies by latitude; however, the first and last data points

are at the integer degrees of longitude. For the contiguous United States, the

spacing is 3 arc-seconds. Between 50 degrees N and 70 degrees N, the spacing is

6 arc-seconds. For the remainder of Alaska, north of 70 degrees N the spacing is

9 arc-seconds.
4-6

FIGURE 4-2 STRUCTURE OF A 1-DEGREE DEM DATA FILE FOR THE LOWER

LATITUDES

There are two types of records in the DEM files. The first is a header record consisting

of general information about the DEM data file. This record appears only once in the file and is

always the first record. The second record type contains the elevation data along each profile. 

This second record is repeated for each profile. The structure of these two record types are

described in Tables 4-1 and 4-2, respectively. A complete description of the record structure is

in a publication issued by the USGS (U.S. Dept. of Interior, 1993) and available on the Internet.
4-7

Table 4-1. DEM Data Elements - Logical Record Type A (File Header)

_______________________________________________________________________________________________________________________________________

 Type Physical Record Format 

 Data (FORTRAN ASCII Starting Ending CommentElement Notation) Format byte byte_______________________________________________________________________________________________________________________________________ 1 File name ALPHA A40 1 40 DEM quadrangle name.

Free Format Text ALPHA A40 41 80 Free format descriptor field, conta

digital process such as digitizing i

widths, etc.

Filler --- --- 81 135 Process Code ALPHA A1 136 Code 1=GPM

 2=Manual Profile 3=DLG2DEM (includes any DCTOG or LINETRACE) 4=DCASS

 2 MC origin code ALPHA A4 141 144 Mapping Center origin Code. Val

MCMC, RMMC, FS, GPM2.

 3 DEM level code INTEGER*2 I6 145 150 Code 1=DEM-1

 2=DEM-2 3=DEM-3

 4 Code defining INTEGER*2 I6 151 156 Code 1=regular

elevation pattern 2=random is reserved for(regular or random) future use.
4-8

Table 4-1. DEM Data Elements - Logical Record Type A (continued)

_______________________________________________________________________________________________________________________________________

 Type Physical Record Format 

 Data (FORTRAN ASCII Starting Ending CommentElement Notation) Format byte byte_______________________________________________________________________________________________________________________________________ 5 Code defining INTEGER*2 I6 157 162 Code 0=Geographic

ground planimetric 1=UTMreference system 2=State plane

Code 0 represents the geographic 1-degree DEM's. Code 1 represencoordinate system for 7.5-minute D

 6 Code defining INTEGER*2 I6 163 168 Codes for State plane and UTM co

zone in ground zones for 7.5-minute DEM's. Codplanimetric is set to zero for 1-degree DEM's.reference system

 7 Map projection REAL*8 15D24.15 169 528 Definition of parameters for vario

parameters All 15 fields of this element are se

ignored.

 8 Code defining unit INTEGER*2 I6 529 534 Code 0=radians

of measure for 1=feet

ground planimetric 2=meterscoordinates through- 3=arc-secondsout the file Normally set to code 2 for 7.5-min

3 for 1-degree DEM's.
4-9

Table 4-1. DEM Data Elements - Logical Record Type A (continued)

_______________________________________________________________________________________________________________________________________

 Type Physical Record Format 

 Data (FORTRAN ASCII Starting Ending CommentElement Notation) Format byte byte_______________________________________________________________________________________________________________________________________ 9 Code defining unit of measure INTEGER*2 I6 535 540 Code 1=feet

for elevation coordinates 2=meters

throughout the file Normally code 2, meters, for 

7.5-minute and 1-degree DEM's.

 10 Number (n) of sides in the polygon INTEGER*2 I6 541 546 n=4.

which defines the coverageof the DEM file

 11 A 4,2 array con- REAL*8 4(2D24.15) 547 738 The coordinates of the quadrangle

taining the ground corners are ordered in a clockwisecoordinates of the direction beginning with thefour corners for southwest corner, in units specifiethe DEM in data element 8.

 12 A two-element array containing REAL*8 2D24.15 739 786 The values are in the unit of

minimum and maximum measure given by data element 9 ielevations for the DEM this record.

 13 Counterclockwise angle (in radians) REAL*8 D24.15 787 810 Set to zero to align

from the primary axis of ground with the coordinate system specifi

planimetric reference to the primary in element 5.axis of the DEM local reference system

Table 4-1. DEM Data Elements - Logical Record Type A (continued)
4-10

_______________________________________________________________________________________________________________________________________

 Type Physical Record Format 

 Data (FORTRAN ASCII Starting Ending CommentElement Notation) Format byte byte_______________________________________________________________________________________________________________________________________ 14 Accuracy code for INTEGER*2 I6 811 816 Code 0=unknown accuracy

elevations 1=accuracy informatio

 in logical record type 

 15 A three-element array REAL*4 3E12.6 817 852 These elements are usually 

of DEM spatial resolu- 7.5-minute DEM's, and 2,2tion for x, y, z. Units of 3, 3, 1 for 1-degree DEM's.measure are consistent 2, 1, 1 for high resolution Dwith those indicated by data 3, 2, 1 for low resolution D

 elements 8 and 9 in this 7.5 minute DEM’s will eve

record To geographics, i.e., 1, 1 ,1

 16 A two-element array containing INTEGER*2 2I6 853 864 When the row value m is se

the number of rows and columns (m,n) n value describes the numbof profiles in the DEM columns in the DEM file. R

are set to m=16, n=16.

Note: Old format stops here--------------------------------------------------------------------------------------------------------------------------------------------------------------------
4-11

Table 4-1. DEM Data Elements - Logical Record Type A (continued)

_______________________________________________________________________________________________________________________________________

 Type Physical Record Format 

 Data (FORTRAN ASCII Starting Ending CommentElement Notation) Format byte byte_______________________________________________________________________________________________________________________________________ 17 Largest primary INTEGER*2 I5 865 869 Present only if two or more

contour interval primary intervals exist.

 18 Source contour INTEGER*1 I1 870 Corresponds to the units of 

interval units largest primary contour inte

0=N.A., 1=feet, 2=meters.

 19 Smallest primary INTEGER*2 I5 871 875 Smallest or only primary co 20 Source contour INTEGER*1 I1 876 Corresponds to the units of 

interval units smallest primary contour in

1=feet, 2=meters.
4-12

Table 4-1. DEM Data Elements - Logical Record Type A (continued)

_______________________________________________________________________________________________________________________________________

 Type Physical Record Format 

 Data (FORTRAN ASCII Starting Ending CommentElement Notation) Format byte byte_______________________________________________________________________________________________________________________________________ 21 Data source date INTEGER*2 I4 877 880 YYMM two-digit year and two-di

MM = 00 for source having year o

 22 Data inspection/ INTEGER*2 I4 881 884 YYMM two-digit year and two-di

revision date

 23 Inspection/ ALPHA*1 A1 885 "I" or "R"

revision flag

 24 Data validation INTEGER*1 I1 886 0= No validation performed. 

flag

1=TESDEM (record C added) no  tative test (no DEM Edit System 2=Water body edit and TESDEM 3=DES (includes water edit) no qu4=DES with record C added, qual level 1 DEM.5=DES and TESDEM qualitative  levels 2 and 3 DEM's.
4-13

Table 4-1. DEM Data Elements - Logical Record Type A (continued)

_______________________________________________________________________________________________________________________________________

 Type Physical Record Format 

 Data (FORTRAN ASCII Starting Ending CommentElement Notation) Format byte byte_______________________________________________________________________________________________________________________________________ 25 Suspect and void INTEGER*1 I2 887 888 0=none

area flag

1=suspect areas2=void areas3=suspect and void areas

 26 Vertical datum INTEGER*1 I2 889 890 1=local mean sea level

2=National Geodetic Vertical

 Datum 1929 (NGVD 29)

3=North American Vertical

 Datum 1988 (NAVD 88)
4-14

Table 4-1. DEM Data Elements - Logical Record Type A (continued)

_______________________________________________________________________________________________________________________________________

 Type Physical Record Format 

 Data (FORTRAN ASCII Starting Ending CommentElement Notation) Format byte byte_______________________________________________________________________________________________________________________________________ 27 Horizontal datum INTEGER*1 I2 891 892 1=North American Datum 1927 (N

2=World Geodetic System 1972 (W3=WGS 844=NAD 835=Old Hawaii Datum6=Puerto Rico Datum7=NAD 83 Provisional (shifts in horizontal coordinates are  computed, but old DEM nodes are not resampled)

 28 Data Edition INTEGER*2 I4 893 896 01-99 Primarily a DMA specific f 29 Percent Void INTEGER*2 I4 897 900 If element 25 indicates a void, this 

the percentage of nodes in the file 

_______________________________________________________________________________________________________________________________________
4-15

Table 4-2. DEM Data Elements - Logical Record Type B (Data Record)

_______________________________________________________________________________________________________________________________________

 Type Physical Record Format 

 Data (FORTRAN ASCII Starting Ending CommentElement Notation) Format byte byte__________________________________________________________________________________________________________________________________________ 1 A two-element array INTEGER*2 2I6 1 12 The row/column numbers 

containing the row may range from 1 to m and

and column identifi- 1 to n. The row number is normalcation number of the set to 1. The column identificatio

DEM profile con- is the profile sequence number.tained in thisrecord

 2 A two-element array INTEGER*2 2I6 13 24 The first element in the field corre

containing the number to the number of rows and column(m, n) of elevations of nodes in this profile. The seconin the DEM profile element is set to 1, specifying 1 co

 3 A two-element array REAL*8 2D24.15 25 72 See Figures 4-1 and 4-2.

containing the ground planimetric coordinates (X,Y) of the first elevation in the profile

 4 Elevation of local REAL*8 D24.15 73 96 The values are in the units of

datum for the measure given by data element 9,

profile logical record type A.

 Table 4-2. DEM Data Elements - Logical Record Type B (continued)
4-16

__________________________________________________________________________________________________________________________________________

 Type Physical Record Format 

 Data (FORTRAN ASCII Starting Ending CommentElement Notation) Format byte byte__________________________________________________________________________________________________________________________________________ 5 A two-element array REAL*8 2D24.15 97 144 The values are in the unit of 

of minimum and measure given by data element 9 i

maximum elevations logical record type A.for the profile

 6 A m,n array of INTEGER*2 mn(I6) 6x(146 or 170) A value in this array would be 

elevations for the 146 = max for multiplied by the spatial resolutionprofile. Elevations first block. 170 = max value and added to the elevation oare expressed in for subsequent blocks local elevation datum for the elemunits of resolution this record) to obtain the elevation 

__________________________________________________________________________________________________________________________________________
4-17

4.3 DATA MANIPULATION BY AERMAP

The AERMAP preprocessor creates a direct access binary file and an index file for each DEM

file containing only that portion of the DEM file that falls within the user-specified domain. These

files are temporary, and enable the program to determine the elevation at a DEM node very efficiently. 

For example, if four adjacent DEM files are specified and a domain is defined as shown in Figure 2-1,

then AERMAP will produce four direct access binary files, one for each DEM file, containing a subset

of the terrain elevation data that lies within the domain (files 1, 2, 3 and 4 in Figure 2-1). The

elevations in the direct access files are stored in meters. The order of the elevation points in these files

will be the same as that of the original DEM file except that the coordinates of the baseline of the

profile and the number of nodes in the profiles might be different. The new values for the baseline

location and number of nodes are written to the index file corresponding to each DEM file. The

program creates the direct access files using the same name as the DEM file but with an extension of

'DIR'. Similarly the index file corresponding to a DEM file will be the same file name but with an

extension of 'IDX'. These files are deleted when the program ends.

If 7.5 minute DEM data are used and Nada is not set to zero, AERMAP will convert NAD 27

data to NAD 83. This will assure that all the receptors, sources, and elevations are using the same

geodetic reference (i.e. NAD83). Otherwise, some of the elevations extracted could be more than 100

meters in error in the horizontal as depicted in Figure 4-3. This is because of the difference in

geodetic reference. The NAD 27 datum is based on a mathematical representation of the earth while

the NAD 83 data is based on satellite and earth-centric data. This creates physical location differences

when coordinate system are laid on top of the theoretic representation of the earth to where the DEM

datasets will have noticeable overlaps and/or no coverage areas between adjacent DEM maps (See

Figure 2-3). In other words, even though each adjacent map may have the same corner coordinates

with the same latitude and longitude, the underlying point with respect to the earth may be different by

more than 100 meters. It may also reside between maps where there are no closeby elevation

nodes.
4-18

4.4 DETERMINING RECEPTOR (SOURCE) ELEVATIONS

If the user requests the preprocessor to extract the receptor (and optional source) elevations

from the DEM data using the CO TERRHGTS EXTRACT card, or if the CO TERRHGTS

keyword is omitted, the following procedure is used to determine the elevation:

• For each receptor, the program searches through the DEM data index files to

determine the two profiles (longitudes or eastings) that straddle this receptor.

• For each of these two profiles, the program then searches through the nodes in the

index file to determine which two rows (latitudes or northings) straddle the

receptor. 

• The program then calculates the coordinates of these four points and determines the

DEM direct access file and the record numbers that correspond to these points.

• It reads the elevations for these four points from the appropriate direct access file.

• If there are less than four points, the program will search the other adjacent DEM

files following the above steps. The program will retain the closest node found in

the northwest, northeast, southeast, and southwest quadrants. The quadrants’

common point is the receptor location. Distances to, and the elevations of these

DEM nodes are retained.

• A 2-dimensional distance-weighted interpolation is used to determine the elevation 

at the receptor location based on the elevations at the four nodes. The weighting

equation is: 
4-19

Weighing Factor (w) = 1/dist1 + 1/dist2 + 1/dist3 + 1/dist4. 

Elevation = elev1/(dist1*w) + elev2/(dist2*w) + elev3/(dist3*w) + elev4/(dist4*w) 

 where w is the weighting factor.

When 7.5-minute DEM data are used, a receptor or source location may fall outside the range of

the profiles but remain inside a DEM file boundaries (see Figure 4-1) or they may fall between

the DEM files when the DEM files are from different datums. Elevations for all receptors or

sources located near the edges of a DEM file are assigned values based on the nodes that are

closest to the receptor or source location and may include elevations from two or more DEM files.
5-1

5.0 REFERENCES

Cimorelli, A.J., Perry, S.G., Venkatram, A., Weil, J.C., Paine, R.J., Wilson, R.B., Lee, R.F., Peters,

W.D., Brode, R.W., Paumier, J.O., 2004: AERMOD: Description of Model Formulation.

EPA-454/R-03-004, U.S. Environmental Protection Agency, Research Triangle Park, North

Carolina 27711.

Environmental Protection Agency, 1995: Industrial Source Complex (ISC3) Dispersion Model 

User's Guide - Volume II. EPA-454/B-95-003b, U.S. Environmental Protection Agency,

Research Triangle Park, North Carolina 27711.

Environmental Protection Agency, 1998: Revised Draft User's Guide for the AMS/EPA Regulatory

Model - AERMOD. U.S. Environmental Protection Agency, Research Triangle Park, North

Carolina 27711.

Environmental Research and Technology, 1987: User's Guide to the Rough Terrain Diffusion Model

(RTDM), Rev. 3.20. ERT Document No. P-D535-585. Environmental Research and

Technology, Inc., Concord, MA. (NTIS No. PB 88-171467)

Perry, S.G., D.J. Burns, L.H. Adams, R.J. Paine, M.G. Dennis, M.T. Mills, D.J. Strimaitis, R.J.

Yamartino and E.M. Insley, 1989: User's Guide to the Complex Terrain Dispersion Model

Plus Algorithms for Unstable Situations (CTDMPLUS) Volume 1; Model Description and

User Instructions. EPA Publication No. EPA-600/8-89-041. U.S. Environmental Protection

Agency, Research Triangle Park, NC. (NTIS No. PB 89-181424)

U.S. Department of the Interior, 1993: Digital Elevation Models Data User's Guide 5 (“Blue Book”),

U.S. Geological Survey, Earth Science Information Center.

U.S. Geological Survey, 1987: Map Projections - A Working Manual, U.S. Geological Survey Professional Paper 1

U.S. National Geodetic Survey, NADCON - North American Datum Conversion Utility,

http://www.ngs.noaa.gov:80/TOOLS/Nadcon/Nadcon.html
A-1

APPENDIX A. ALPHABETICAL KEYWORD REFERENCE

This appendix provides an alphabetical listing of all of the keywords used by the

AERMAP preprocessor. Each keyword is identified as to the pathway for which it applies, the

keyword type (either mandatory or optional, and either repeatable or non-repeatable), and with a

brief description of the function of the keyword. For a more complete description of the

keywords, including a list of associated parameters, refer to the Detailed Keyword Reference in

Section 3 or the Functional Keyword/Parameter Reference in Appendix B.
A-2

Keyword Path Type Keyword Description

ANCHORXY CO M - N Relates the origin of the user-specified coordinate system for

receptors to the UTM coordinate system

DATAFILE CO M - R Specifies the names of the raw terrain data being provided to

the preprocessor

DATATYPE CO M - N Specifies the type of the raw terrain data being provided to

the preprocessor

DISCCART RE O - R Defines the discretely placed receptor locations referenced to

a Cartesian system

DISCPOLR RE O - R Defines the discretely placed receptor locations referenced to

a polar system

DOMAINLL CO M - N Allows the user to specify the domain extent in the latitude /

longitude coordinate system

DOMAINXY CO M - N Allows the user to specify the domain extent in the UTM

coordinate system

ELEVUNIT SO

RE

O - N

O - N

Defines the input units for the source elevations (SO

pathway) or receptor elevations (RE pathway)

EVALCART RE O - R Defines discrete Cartesian receptors for use with EVALFILE

output

FINISHED ALL M - N Identifies the end of inputs for a particular pathway

FLAGPOLE CO O - N Specifies whether to accept receptor heights above local

terrain (m) for use with flagpole receptors, and allows for a

default flagpole height to be specified

GRIDCART RE O - R Defines a Cartesian grid receptor network

GRIDPOLR RE O - R Defines a polar receptor network

LOCATION SO O - R Specifies the location of sources

RECEPTOR OU M - N Specifies the output filename for the receptor data

RUNORNOT CO M - N Identifies whether to run program or process setup

information only

SOURCLOC OU O - N Specifies the output filename for the source location data

STARTING ALL M - N Identifies the start of inputs for a particular pathway

TERRHGTS CO O - N Controls whether the receptor elevations should be extracted

from the terrain data or that the user-provided receptor

elevations should be used

TITLEONE CO M - N First line of title for output

TITLETWO CO O - N Optional second line of output title
B-1

APPENDIX B. FUNCTIONAL KEYWORD/PARAMETER REFERENCE

This appendix provides a functional reference for the keywords and parameters used by the

input runstream files for the AERMAP preprocessor. The keywords are organized by functional

pathway, and within each pathway the order of the keywords is based on the function of the keyword

within the preprocessor. The pathways used by the preprocessor are as follows, in the order in which

they appear in the runstream file and in the tables that follow:

CO - for specifying overall job COntrol options; and

SO - for specifying SOurce location information (optional);

RE - for specifying REceptor information; and

OU - for specifying OUtput file information.

The pathways and keywords are presented in the same order as in the Detailed Keyword Reference in

Section 3, and in the Quick Reference at the end of the manual.

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 and either repeatable

or non-repeatable), and provides a brief description of the function of the keyword. The second type

of table presents the parameters for each keyword, in the order in which they should appear in the

runstream file where order is important, and describes each parameter in detail.

The following convention is used for identifying the different types of input parameters. 

Parameters corresponding to secondary keywords which should be input "as is" are listed on the tables

with all capital letters (they are underlined in the table). Other parameter names are given with an

initial capital letter and are not input "as is." In all cases, the parameter names are intended to be

descriptive of the input variable being represented, and they often correspond to the Fortran variable

names used in the preprocessor code. Parentheses around a parameter indicate that the parameter is

optional for that keyword. The default that is taken when an optional parameter is left blank is

explained in the discussion for that parameter.
B-2

TABLE B-1

DESCRIPTION OF CONTROL PATHWAY KEYWORDS

CO Keywords Type Keyword Description

STARTING M - N Identifies the start of CONTROL pathway inputs

TITLEONE M - N First line of title for output

TITLETWO O - N Optional second line of title for output

TERRHGTS O - N Controls whether the receptor elevations should be extracted

from the user-provided terrain data or that the user-provided

receptor terrain elevations should be used

FLAGPOLE O - N Specifies whether to accept receptor heights above local

terrain (m) for use with flagpole receptors, and allows for

default flagpole height to be specified

DATATYPE M - N Specifies the type of the raw terrain data being provided to

the preprocessor

DATAFILE M - R Specifies the names of the raw terrain data being provided to

the preprocessor

DOMAINLL M1 - N Allows the user to specify the domain extent in the latitude

/ longitude coordinate system

DOMAINXY M1 - N Allows the user to specify the domain extent in the UTM

coordinate system

ANCHORXY M - N Relates the origin of the user-specified coordinate system

for receptors to the UTM coordinate system

RUNORNOT M - N Identifies whether to run program or process setup

information only

FINISHED M - N Identifies the end of CONTROL pathway inputs

Type: M - Mandatory

O - Optional

N - Non-Repeatable

R - Repeatable

1) Either the DOMAINLL or the DOMAINXY keyword must be used.
B-3

TABLE B-2

DESCRIPTION OF CONTROL PATHWAY KEYWORDS AND PARAMETERS

Keyword Parameters

TITLEONE Title1

 where: Title1 First line of title for output, 

character string of up to 68 characters

TITLETWO Title2

 where: Title2 Second line of title for output, 

character string of up to 68 characters

TERRHGTS EXTRACT or PROVIDED

 where: EXTRACT

PROVIDED

Instructs the preprocessor to determine the terrain heights

from the DEM data files provided by the user (default)

Forces the preprocessor to use the user-specified receptor

elevations that are entered on the receptor pathway (also

applies to source elevations specified on the optional

source pathway)

FLAGPOLE (Flagdf)

 where: Flagdf Default value for height of (flagpole) receptors above

local ground level, a default value of 0.0 m is used if

this optional parameter is omitted

DATATYPE DEM1 or DEM7

 where: DEM1

DEM7

Specifies that 1-degree DEM Data will be used

Specifies that 7.5-minute DEM data will be used

DATAFILE Demfil 

 where: Demfil Identifies the name of the DEM data file

DOMAINLL Lonmin Latmin Lonmax Latmax

 where: Lonmin

Latmin

Lonmax

Latmax

Longitude in decimal degrees for the lower right (SE)

corner of the domain

Latitude in decimal degrees for the lower right (SE) corner

of the domain

Longitude in decimal degrees for the upper left (NW) corner

of the domain

Latitude in decimal degrees for the upper left (NW) corner

of the domain

DOMAINXY Xdmin Ydmin Zonmin Xdmax Ydmax Zonmax

 where: Xdmin

Ydmin

Zonmin

Xdmax

Ydmax

Zonmax

UTM East coordinate for the lower left (SW) corner of the

domain in meters

UTM North coordinate for the lower left (SW) corner of the

domain in meters

UTM Zone for the lower left (SW) corner of the domain

UTM East coordinate for the upper right (NE) corner of the

domain in meters

UTM North coordinate for the upper right (NE) corner of the

domain in meters

UTM Zone for the upper right (NE) corner of the domain
B-4

TABLE B-2

DESCRIPTION OF CONTROL PATHWAY KEYWORDS AND PARAMETERS (Cont’d)

ANCHORXY Xauser Yauser Xautm Yautm Zautm

 where: Xauser

Yauser

Xautm

Yautm

Zautm

Nada

The X coordinate of any geographic location (typically the

origin 0,0) in the user coordinate system in meters

The Y coordinate of any geographic location (typically the

origin 0,0) in the user coordinate system in meters

The UTM East coordinate of the same geographic location

specified as Xauser,Yauser in meters

The UTM North coordinate of the same geographic location

specified as Xauser,Yauser in meters

The UTM Zone of the same geographic location corresponding

to Xautm, Yautm

The datum from which the Xautm, Yautm coordinates were

drawn

RUNORNOT RUN or NOT

 where: RUN

NOT

Indicates to run full preprocessor calculations

Indicates to process setup data and report errors,

 but to not run full preprocessor calculations
B-5

TABLE B-3

DESCRIPTION OF SOURCE PATHWAY KEYWORDS

SO

Keywords

Type Keyword Description

STARTING M - N Identifies the start of SOURCE pathway inputs

LOCATION M - R Identifies source locations for use in extracting source 

elevations 

and/or to define the origin of discrete polar receptors

FINISHED M - N Identifies the end of SOURCE pathway inputs
B-6

TABLE B-4

DESCRIPTION OF SOURCE PATHWAY KEYWORDS AND PARAMETERS

Keyword Parameters

LOCATION Srcid Srctyp Xs Ys (Zs)

 where: Srcid

Srctyp

Xs

Ys

Zs

Alphanumeric source ID, up to eight characters

Source type: POINT, VOLUME, AREA, AREAPOLY, AREACIRC

x-coordinate (Easting) of source location, corner for AREA,

vertex for AREAPOLY, center for AREACIRC (m)

y-coordinate (Northing) of source location (m)

Optional z-coordinate of source location (elevation above

mean sea level in meters)
B-7

TABLE B-5

DESCRIPTION OF RECEPTOR PATHWAY KEYWORDS

RE Keywords Type Keyword Description

STARTING M - N Identifies the start of RECEPTOR pathway inputs

ELEVUNIT O - N Defines input units for receptor elevations (defaults to

meters), must be first keyword after RE STARTING if used.

GRIDCART O1 - R Defines a Cartesian grid receptor network

GRIDPOLR O1 - R Defines a polar receptor network

DISCCART O1 - R Defines the discretely placed receptor locations referenced

to a Cartesian system

DISCPOLR O1 - R Defines the discretely placed receptor locations referenced

to a polar system

EVALCART O1 - R Defines discrete Cartesian receptor locations for use with

EVALFILE output option 

FINISHED M - N Identifies the end of RECEPTOR pathway inputs

1) At least one of the following must be present: GRIDCART, GRIDPOLR,

DISCCART, DISCPOLR, or EVALCART. Multiple receptor networks can be

specified in a single run, including both Cartesian and polar, up to

an overall maximum controlled by the NREC parameter.
B-8

TABLE B-6

DESCRIPTION OF RECEPTOR PATHWAY KEYWORDS AND PARAMETERS

Keyword Parameters

ELEVUNIT METERS or FEET

 where: METERS

FEET

Specifies input units for receptor elevations of

 meters

Specifies input units for receptor elevations of feet

 Note: This keyword applies to receptor elevations

 only.

GRIDCART Netid STA

 XYINC Xinit Xnum Xdelta Yinit Ynum Ydelta

 or XPNTS Gridx1 Gridx2 Gridx3 .... GridxN, and

 YPNTS Gridy1 Gridy2 Gridy3 .... GridyN

 ELEV Row Zelev1 Zelev2 Zelev3 ... ZelevN

 FLAG Row Zflag1 Zflag2 Zflag3 ... ZflagN

 END

 where: Netid

STA

XYINC

Xinit

Xnum

Xdelta

Yinit

Ynum

Ydelta

XPNTS

Gridx1

GridxN

YPNTS

Gridy1

GridyN

ELEV

Row

Zelev

FLAG

Row

Zflag

END

Receptor network identification code (up to eight 

alphanumeric characters)

Indicates STArt of GRIDCART subpathway, repeat for

 each new Netid

Keyword identifying grid network generated from

 x and y increments

Starting local x-axis grid location in meters

Number of x-axis receptors

Spacing in meters between x-axis receptors

Starting local y-axis grid location in meters

Number of y-axis receptors

Spacing in meters between y-axis receptors

Keyword identifying grid network defined by a series

 of x and y coordinates

Value of first x-coordinate for Cartesian grid

Value of 'nth' x-coordinate for Cartesian grid

Keyword identifying grid network defined by a series

 of x and y coordinates

Value of first y-coordinate for Cartesian grid

Value of 'nth' y-coordinate for Cartesian grid

Keyword to specify that receptor elevations follow

Indicates which row (y-coordinate fixed) is being

 input

An array of receptor terrain elevations for 

 a particular Row

Keyword to specify that flagpole receptor heights

 follow

Indicates which row (y-coordinate fixed) is being

 input

An array of receptor heights above local terrain

 elevation for a particular Row (flagpole receptors)

Indicates END of GRIDCART subpathway, repeat for each

 new Netid
B-9

TABLE B-6 (CONT.)

DESCRIPTION OF RECEPTOR PATHWAY KEYWORDS AND PARAMETERS

GRIDPOLR Netid STA

 ORIG Xinit Yinit,

 or ORIG Srcid

 DIST Ring1 Ring2 Ring3 ... RingN

 DDIR Dir1 Dir2 Dir3 ... DirN,

 or GDIR Dirnum Dirini Dirinc

 ELEV Dir Zelev1 Zelev2 Zelev3 ... ZelevN

 FLAG Dir Zflag1 Zflag2 Zflag3 ... ZflagN

 END

 where: Netid

STA

ORIG

Xinit

Yinit

Srcid

DIST

Ring1

RingN

DDIR

Dir1

DirN

GDIR

Dirnum

Dirini

Dirinc

ELEV

Dir

Zelev

FLAG

Dir

Zflag

END

Receptor network identification code (up to eight

 alphanumeric characters)

Indicates STArt of GRIDPOLR subpathway, repeat for

 each new Netid

Optional keyword to specify the origin of the polar

 network (assumed to be at x=0, y=0 if omitted)

local x-coordinate for origin of polar network (m)

local y-coordinate for origin of polar network (m)

Source ID of source used as origin of polar network

Keyword to specify distances for the polar network

Distance to the first ring of polar coordinates (m)

Distance to the 'nth' ring of polar coordinates (m)

Keyword to specify discrete direction radials for the

 polar network

First direction radial in degrees (1 to 360)

The 'nth' direction radial in degrees (1 to 360)

Keyword to specify generated direction radials for

 the polar network

Number of directions used to define the polar system

Starting direction of the polar system

Increment (in degrees) for defining directions

Keyword to specify that receptor elevations follow

Indicates which direction is being input

An array of receptor terrain elevations for a

 particular direction radial

Keyword to specify that flagpole receptor heights

 follow

Indicates which direction is being input

An array of receptor heights above local terrain

 elevation for a particular direction (flagpole

 receptors)

Indicates END of GRIDPOLR subpathway, repeat for each

 new Netid
B-10

TABLE B-6 (CONT.)

DESCRIPTION OF RECEPTOR PATHWAY KEYWORDS AND PARAMETERS

DISCCART Xcoord Ycoord (Zelev) (Zflag)

 where: Xcoord

Ycoord

Zelev

Zflag

local x-coordinate for discrete receptor location (m)

local y-coordinate for discrete receptor location (m)

Elevation above sea level for discrete receptor

 location (optional), used only for ELEV terrain

Receptor height (flagpole) above local terrain

 (optional), used only with FLAGPOLE keyword

DISCPOLR Srcid Dist Direct (Zelev) (Zflag)

 where: Srcid

Dist

Direct

Zelev

Zflag

Specifies source identification for which discrete

 polar receptor locations apply (used to define the

 origin for the discrete polar receptor)

Downwind distance to receptor location (m)

Direction to receptor location, in degrees clockwise

 from North

Elevation above sea level for receptor location

 (optional), used only for ELEV terrain

Receptor height (flagpole) above local terrain

 (optional), used only with FLAGPOLE keyword

EVALCART Xcoord Ycoord Zelev Zflag Arcid (Name)

 where: Xcoord

Ycoord

Zelev

Zflag

Arcid

(Name)

local x-coordinate for discrete receptor location (m)

local y-coordinate for discrete receptor location (m)

Elevation above sea level for discrete receptor

 location (optional), used only for ELEV terrain

Receptor height (flagpole) above local terrain

 (optional), used only with FLAGPOLE keyword

Receptor arc ID used to group receptors along 

 an arc or other grouping (up to eight characters)

Optional name for receptor (up to eight characters)
B-11

TABLE B-7

DESCRIPTION OF OUTPUT PATHWAY KEYWORDS

OU Keywords Type Keyword Description

STARTING M - N Identifies the start of OUTPUT pathway inputs

RECEPTOR M - N Identifies the output filename for receptor data

SOURCLOC O - N Identifies the output filename for source location data

FINISHED M - N Identifies the end of OUTPUT pathway inputs
B-12

TABLE B-8

DESCRIPTION OF OUTPUT PATHWAY KEYWORDS AND PARAMETERS

Keyword Parameters

RECEPTOR Recfil

 where: Recfil Specifies output filename for receptor data (up to 60

characters)

SOURCLOC Srcfil

 where: Srcfil Specifies output filename for source location data (up

to 60 characters)
C-1

APPENDIX C. EXPLANATION OF ERROR MESSAGE CODES

C.1 INTRODUCTION

The AERMAP preprocessor uses a "defensive programming" approach to eliminate as much as

possible of the user's work in debugging the input runstream file. Also, a great deal of effort has been

made to eliminate the possibility of run time errors, such as "divide by zero," and to point out

questionable input data.

Message Summary: The AERMAP preprocessor outputs a summary of messages to the

message file specified on the command line. This message table gives the number of messages of

each type, together with a detailed list of all the fatal errors and warning messages. During setup

processing, if no errors or warnings are generated, then the program simply reports to the user that

"SETUP Finishes Successfully."

C.2 THE OUTPUT ERROR LOG MESSAGE SUMMARY

There are two message summaries provided in the message file generated by the AERMAP

preprocessor. The first one is located after the echo of input runstream file images. This summary

will take one of two forms, depending on whether any fatal error or non-fatal warning messages were

generated, and also depending on whether the option to RUN or NOT to run was selected on the CO

RUNORNOT card. If there are no errors or warnings generated during the setup processing, and the

RUN option was selected, then the program simply reports that "SETUP Finishes Successfully." If

any fatal errors or warning messages were generated during the setup processing, or if the option

NOT to run was selected, then a more detailed summary is provided. This summary provides a

message count for each type of message, and a detailed listing of each fatal error and warning message

generated. The second message summary table is located at the very end of the message file, and it

sums up the messages generated by the complete preprocessor run - both setup processing and

run-time processing.
C-2

*** Message Summary For The AERMAP Preprocessor Setup ***

 --------- Summary of Total Messages ---------

A Total of 0 Fatal Error Message(s)

A Total of 0 Warning Message(s)

A Total of 0 Information Message(s)

 ******** FATAL ERROR MESSAGES ********

 *** NONE ***

 ******** WARNING MESSAGES ********

 *** NONE ***

 ***********************************

 *** SETUP Finishes Successfully ***

 ***********************************

An example of a setup processing message summary is shown in Figure C-1.

FIGURE C-1. EXAMPLE OF AN AERMAP MESSAGE SUMMARY

C.3 DESCRIPTION OF THE DETAILED MESSAGE LAYOUT

Two types of messages can be produced by the program during the processing of input

runstream images and during preprocessor calculations. These are described briefly below:

• Errors that will halt any further processing, except to identify additional error

conditions (type E); and

• Warnings that do not halt processing but indicate possible errors or suspect conditions

(type W).

The messages have a consistent structure which contains the pathway ID, indicating which

pathway the messages are generated from; the message type followed by a three-digit message

number; the line number of the input runstream image file for setup messages; the name of the module

(e.g. the subroutine name) from which the message is generated; a detailed message corresponding to

the message code; and an 8-character simple hint to help the user spot the possible source of the

problem.
C-3

CO E100 8 EXPATH: Invalid Pathway Specified. The Troubled Pathway is FF

PW Txxx LLLL mmmmmm: MESSAGE Hints 

Hints to help you determine the nature 

of errors (keyword, pathway where the 

error occurs,...etc.) (73:80) 

Detailed message for this code (22:71)

Name of the code module from which the 

message is generated (14:19)

The line number of the input runstream image

file where the message occurs (9:12)

Numeric message code (a 3 digit number) (5:7) 

Message type (E, W, I) (4:4)

Pathway ID (CO or RE) (1:2)

The following is an example of a detailed message generated from the CO pathway:

The message syntax is explained in more detail below (values in parentheses give the column numbers

within the message line for each element):

The two message types are identified with the letters E (for errors) and W (for warnings). A detailed

description of each of the message codes currently used in the program is provided in the next section.
C-4

C.4 DETAILED DESCRIPTION OF THE ERROR/MESSAGE CODES

INPUT RUNSTREAM IMAGE STRUCTURE PROCESSING

This type of message indicates problems with the basic syntax and/or structure of the input

runstream image. Typical messages include errors like "Missing mandatory keyword", "Illegal

Keyword", ..., etc. If a fatal error of this kind is detected in a runstream image, a fatal error message is

written to the message file and any attempt to process data is prohibited, although the remainder of the

runstream file is examined for other possible errors. If a warning occurs, data may still be processed,

although the inputs should be checked carefully to be sure that the condition causing the warning does

not indicate an error.

100 Invalid Pathway Specified. The pathway ID should be a 2 character string. It should be one of

the following: CO for control pathway or RE for receptor pathway. Its position is normally

confined to columns 1 and 2 (1:2) of the input runstream file. However, the program does

allow for a shift of the entire input runstream file of up to 3 columns. If the inputs are shifted,

then all input records must be shifted by the same amount. The invalid pathway is repeated at

the end of the message.

105 Invalid Keyword Specified. The keyword ID should be an 8-character string. Its position is

normally confined to columns 4 to 11 (4:11) of the input runstream file. However, the program

does allow for a shift of the entire input runstream file of up to 3 columns. If the inputs are

shifted, then all input records must be shifted by the same amount. There should be a space

between keyword ID and any other data fields. For a list of valid keywords, refer to Appendix

A or Appendix B. The invalid keyword is repeated at the end of the message.

110 Keyword is Not Valid for This Pathway. The input keyword is a valid 8-character string, but it

is not valid for the particular pathway. Refer to Appendix A, Appendix B or Section 3 for the

correct usage of the keyword. The invalid keyword is repeated at the end of the message.

115 Starting and Finishing Statements do not match. Only One STARTING and one FINISHED

statement, respectively, is allowed at the very beginning and the very end of each pathway

block. Check the position and frequency to make sure the input runstream file meets the

format requirement. The pathway during which the error occurs is included at the end of the

message.

120 Pathway is Out of Sequence. The pathways are not input in the correct order. The correct

order is CO, SO (optional), RE, and OU for the AERMAP preprocessor. The offending

pathway is given as a hint.

125 Missing FINISHED Statement - Runstream file is incomplete. One or more FINISHED

statements are missing. 
C-5

130 Missing Mandatory Keyword. To run the program, certain mandatory keywords must present

in the input runstream file. For a list of mandatory keywords, see Appendix A or Appendix B. 

For more detailed information on keyword setup, see the description of message code 105. 

The missing keyword is included with the message.

135 Duplicate Non-repeatable Keyword Encountered. More than one instance of a non-repeatable

keyword is encountered. For a list of non-repeatable keywords, see Appendix A or Appendix

B. The repeated keyword is included with the message.

140 Invalid Order of Keyword. A keyword has been placed out of the acceptable order. The order

for most keywords is not critical, but the relative order of a few keywords is important for the

proper interpretation of the input data. The keyword reference in Section 3 identifies any

requirements for the order of keywords. The keyword that was out of order is included with

the message.

152 ELEVUNIT card must be first for this pathway. The ELEVUNIT card must be the first noncommented card after STARTING when used on the RE pathway. This requirement is made

in order to simplify reviewing runstream files to determine the elevation units used for sources

and receptors.

153 Cannot use obsolescent CO ELEVUNIT card with RE ELEVUNIT card.

160 Duplicate ORIG Secondary Keyword for GRIDPOLR. Only one origin card may be specified

for each grid of polar receptors. The network ID for the affected grid is included with the

message.

170 Invalid Secondary Keyword for Receptor GRID. The network ID for the affected grid is

included with this message. Refer to Appendix B for the correct syntax of secondary keywords.

175 Missing Secondary Keyword END for Receptor Grid. The END secondary keyword is

required for each grid of receptors input by the user (keywords GRIDCART and GRIDPOLR). 

It signals the end of inputs and triggers the processing of data for that particular network.

180 Conflicting Secondary Keyword for Receptor Grid. Two incompatible secondary keywords

have been input for the same grid of receptors, e.g. GDIR and DDIR for the keyword

GRIDPOLR, where GDIR specifies to generate directions with uniform spacing, and DDIR

specifies that discrete, non-uniform directions are being specified.

185 Missing Receptor Keywords. No Receptors Specified. Since none of the RE pathway

keywords are mandatory, a separate error check is made to determine if any of the RE

keywords are specified. At least one of the following keywords must be present: GRIDCART,

GRIDPOLR, DISCCART, DISCPOLR, or EVALCART.
C-6

PARAMETER SETUP PROCESSING

This type of message indicates problems with processing of the parameter fields for the

runstream images. Some messages are specific to certain keywords, while others indicate general

problems, such as an invalid numeric data field. If a fatal error of this kind is detected in a runstream

image, a fatal error message is written to the message file and any attempt to process data is

prohibited, although the remainder of the runstream file is examined for other possible errors. If a

warning occurs, data may still be processed, although the inputs should be checked carefully to be sure

that the condition causing the warning does not indicate an error.

200 Missing Parameter(s). No options were selected for the indicated keyword. Check Appendix

B for the list of parameters for the keyword in question.

201 Not Enough Parameters Specified For The Keyword. Check if there are any missing

parameters following the indicated keyword. See Appendix B for the required keyword

parameters.

202 Too Many Parameters Specified For The Keyword. Refer to Appendix B or Section 3 for the

list of acceptable parameters.

203 Invalid Parameter Specified. The inputs for a particular parameter are not valid for some

reason. Refer to Appendix B or Section 3. The invalid parameter is included with the

message.

205 No Option Parameter Setting. Forced by Default to: No setting was specified for a particular

parameter. Refer to Appendix B or Section 3 for the correct parameter usage. The default

setting is specified with the message.

206 Two or more DEM types exist. Check IPLAN values. The program detected more than one

type of DEM file. As an example, the program found a 1-degree and a 7.5-minute DEM file. 

The program can only have one type of DEM file.

207 No Parameters Specified. Default Values Used For. The keyword for which no parameters are

specified is included with the message. Refer to Appendix B or Section 3 for a discussion of

the default condition.

208 Illegal Numerical Field Encountered. The program may have encountered a non-numerical

character for a numerical input, or the numerical value may exceed the limit on the size of the

exponent, which could potentially cause an underflow or an overflow error.

209 Negative Value Appears For A Non-negative Variable. The affected variable name is provided

with the message.

212 END Encountered Without (X,Y) Points Properly Set. This error occurs during setting up the

grid of receptors for a Cartesian Network. This message may occur for example if

X-coordinate points have been specified without any Y-coordinate points for a particular

network ID.
C-7

213 NOT USED CURRENTLY - ELEV Input Inconsistent With Option: Input Ignored.

214 ELEV Inputs Inconsistent With Option: Defaults Used. This message occurs when the user

does not input elevated terrain heights for receptors when the TERRHGTS option is

PROVIDED. The program assumes that the missing terrain heights are at 0.0 meters for those

receptors and proceeds with ELEV terrain modeling.

215 FLAG Inputs Inconsistent With Option: Input Ignored. This message occurs when the user

inputs receptor heights above ground for flagpole receptors when the FLAGPOLE keyword

option has not been specified. The input flagpole heights are ignored in the program

calculations.

216 FLAG Inputs Inconsistent With Option: Defaults Used. This happens when the user does not

input receptor heights above ground for flagpole receptors when the FLAGPOLE keyword

option has been specified. The program assumes that the missing flagpole heights are equal to

the default value specified on the CO FLAGPOLE card. If no default height is specified on the

FLAGPOLE card, then a default of 0.0 meters is assumed.

217 More Than One Delimiter In A Field.

218 Number of (X,Y) Points Not Match With Number Of ELEV Or FLAG. Check the number of

elevated terrain heights or flagpole receptor heights for the gridded network associated with

the indicated line number in the runstream file.

219 Number Of Receptors Specified Exceeds Maximum. The user has specified more receptors on

the RE pathway than the program array limits allow. This array limit is controlled by the

NREC PARAMETER specified in the AERMAP.INC file. The value of NREC is provided

with the message.

220 Missing Origin (Use Default = 0,0) In GRIDPOLR. This is a non-fatal warning message to

indicate that the ORIG secondary keyword has not been specified for a particular grid of polar

receptors. The program will assume a default origin of (X=0, Y=0).

221 Missing Distance Setting In Polar Network. No distances have been provided (secondary

keyword DIST) for the specified grid of polar receptors.

222 Missing Direction Setting In Polar Network. Missing a secondary keyword (secondary

keyword GRIR or DDIR) for the specified grid of polar receptors.

223 Missing Elevations or Flagpole Fields. No data fields have been specified for the indicated

secondary keyword.

224 Number of Receptor Networks Exceeds Maximum. The user has specified more receptor

networks of gridded receptors on the RE pathway than the program array limits allow. This

array limit is controlled by the NNET PARAMETER specified in the AERMAP.INC file. The

value of NNET is provided with the message.

225 Number of X-Coords Specified Exceeds Maximum. The user has specified more X-coordinate

values for a particular grid of receptors than the program array limits allow. This array limit is

controlled by the IXM PARAMETER specified in the AERMAP.INC file. The value of IXM

is provided with the message.
C-8

226 Number of Y-Coords Specified Exceeds Maximum. The user has specified more Y-coordinate

values for a particular grid of receptors than the program array limits allow. This array limit is

controlled by the IYM PARAMETER specified in the AERMAP.INC file. The value of IYM

is provided with the message.

227 No Receptors Were Defined on the RE Pathway. Either through lack of inputs or through

errors on the inputs, no receptors have been defined.

228 Default(s) Used for Missing Parameters on Keyword. Either an elevated terrain height or a

flagpole receptor height or both are missing for a discrete receptor location. Default value(s)

will be used for the missing parameter(s).

229 Too Many Parameters - Inputs Ignored on Keyword. Either an elevated terrain height or a

flagpole receptor height or both are provided when the corresponding option has not been

specified. The unneeded inputs are ignored.

232 Number of Specified Sources Exceeds Maximum. The user has specified more sources than

the array limits allow. This array limit is controlled by the NSRC PARAMETER specified in

the AERMAP.INC file. The value of NSRC is provided with the message.

250 Duplicate XPNT/DIST or YPNT/DIR Specified for GRID. One of the grid inputs, either an

X-coordinate, Y-coordinate, polar distance range or polar direction, has been specified more

than once for the same grid of receptors. This generates a non-fatal warning message.

252 Duplicate Receptor Network ID Specified. A network ID for a grid of receptors (GRIDCART

or GRIDPOLR keyword) has been used for more that one network.

254 Number of Receptor Arcs Exceeds Maximum. The user has input more than the number of

receptors arcs specified by the NARC PARAMETER in the AERMAP.INC file. The value of

NARC is provided with the message.

SETUP DATA AND QUALITY ASSURANCE PROCESSING

This type of message indicates problems with the actual values of the parameter data on the

input runstream image. The basic structure and syntax of the input card is correct, but one or more of

the inputs is invalid or suspicious. These messages include quality assurance checks on various

preprocessor inputs. Typical messages will tell the consistency of parameters and data for the setup

and run of the program. If a fatal error of this kind is detected in a runstream image, a fatal error

message is written to the message file and any attempt to process data is prohibited. If a warning

occurs, data may or may not be processed, depending on the processing requirements specified within

the runsteam input data.

300 Receptor Not Inside Domain. This is a fatal error generated when one of the receptors

specified in the RE pathway lies outside the domain specified on the CO pathway. The

receptor number is given with the message.
C-9

305 Source Not Inside Domain. This is a fatal error generated when one of the source locations

specified in the SO pathway lies outside the domain specified on the CO pathway. The source

number is given with the message.

310 Domain Coordinate is NOT Inside a DEM File. This is a fatal error generated when one of the

domain coordinates lies outside the range of data covered by the DEM files included on the

CO pathway. 

320 DEM File Does Not Exist. This is a fatal error generated when one of the DEM data files

specified on the CO pathway is not found.

330 Receptor is Not Inside a DEM File. This is a fatal error generated when one of the receptors

lies outside all of the DEM files specified by the user. The receptor number is included with

the message.

335 Source is Not Inside a DEM File. This is a fatal error generated when one of the source

locations lies outside all of the DEM files specified by the user. The source number is

included with the message.

340 No Terrain File Adjacent to This One. This is a fatal error generated when one of the DEM

data files is found to not be adjacent to any of the other data files specified. The DEM file

number is reported, and the file number represents the order of the file in the runstream.

350 Number of Nodes Exceeds Maximum. The number of nodes specified for a given profile

exceeds the maximum number set by the MAXNOD parameter in AERMAP.INC. The profile

number is specified with the message.

360 Latitude Specified on DOMAINLL Exceeds 60 Degrees. This is a non-fatal warning message

issued if a latitude of greater than 60 degrees is specified for the domain on the DOMAINLL

card. It may indicate that the order of longitude and latitude are reversed on the input data.

370 DATATYPE Card Does Not Match DEM Data File. The message indicates that the type of

DEM data, as determined from the file header record, for the file number specified does not

match the type specified on the DATATYPE card.

375 Specified Source ID Has Not Been Defined Yet. The message indicates that the user attempts

to use a source ID on a keyword before defining this source ID on a SO LOCATION card. It

could indicate an error in specifying the source ID, an omission of a LOCATION card, or an

error in the order of inputs.

377 Duplicate LOCATION Card Specified for Source. There can be only one LOCATION card for

each source ID specified. The source ID is included with the message.

380 This Input Variable is Out-of-Range. The indicated value may be too large or too small. Use

the line number to locate the card in question, and check the variable for a possible error.
C-10

RUNTIME MESSAGE PROCESSING, 400-499

This type of message is generated during the preprocessor run. Setup processing has been

completed successfully, and the message is generated during the performance of calculations. If a

fatal error of this kind is detected during model execution, a fatal error message is written to the

message file and any further processing of the data is prohibited. The rest of the data file(s) will be

read and quality assurance checked to identify additional errors. If a warning occurs, data will still be

processed.

410 Receptor Location Outside Range of Profiles. This is a non-fatal warning message indicating

that a receptor location falls near the edge of a 7.5-minute DEM file and is outside the range of

the data profiles. If receptor elevations are being extracted from the DEM data, the nodes from

the nearest profile are used for this receptor.

420 Source Location Outside Range of Profiles. This is a non-fatal warning message indicating

that a source location falls near the edge of a 7.5-minute DEM file and is outside the range of

the data profiles. If source elevations are being extracted from the DEM data, the nodes from

the nearest profile are used for this source.

INPUT/OUTPUT MESSAGE PROCESSING

This type of message is generated during the preprocessor input and output. Typical messages

will tell the type of I/O operation (e.g., opening, reading or writing to a file), and the type of file. If a

fatal error of this kind is detected in a runstream image, a fatal error message is written to the message

file and any attempt to process data is prohibited. If a warning occurs, data may or may not be

processed, depending on the processing requirements specified within the runsteam input data.

500 Fatal Error Occurs During Opening of the Data File. The file specified can not be opened

properly. This may be the runstream file itself, or one of the DEM input data files. This may

happen when the file called is not in the specified path, or an illegal filename is specified. 

Refer to the line number included in the error message to identify which file caused the error. 

If no errors are found in the filename specification, then this message may also indicate that

there is not enough memory available to run the program, since opening a file causes a buffer

to be opened which takes up additional memory in RAM.

505 File is Already in Use, Cannot be Opened. The specified data file is already in use and could

not be opened. This error may indicate that a duplicate data filename has been specified.

510 Fatal Error Occurs During Reading of the File. File type is incorrect, or illegal data field

encountered. Check the indicated file for possible problems. For a DEM data file, be sure that

file has been converted to a DOS-compatible format using the CRLF.EXE program (provided
C-11

with the AERMAP package). As with error number 500, this message may also indicate that

there is not enough memory available to run the program if no other source of the problem can

be identified.

520 Fatal Error Occurs During Writing to the File. Similar to message 510, except that it occurs

during a write operation.

550 DEM File Conflict for Specified DEM File Number. This error indicates a conflict in the

specification of DEM data files. It may be caused by entering a duplicate filename for a DEM

file.

580 End-of-File Reached Trying to Read a Data File. The AERMAP preprocessor has

unexpectedly encountered an end-of-file trying the read the indicated file. Check the data file

for the correct filename.
D-1

TECHNICAL REPORT DATA

(Please read Instructions on reverse before completing)

1. REPORT NO.

 EPA-454B-03-003

2. 3. RECIPIENT'S ACCESSION NO.

4. TITLE AND SUBTITLE

Users Guide for the AERMOD Terrain Preprocessor (AERMAP)

5. REORT DATE

 October 2004

6. PERFORMING ORGANIZATION CODE

7. AUTHOR(S) 8. PERFORMING ORGANIZATION REPORT NO.

9. PERFORMING ORGANIZATION NAME AND ADDRESS

See below. 10. PROGRAM ELEMENT NO.

11. CONTRACT/GRANT NO.

12. SPONSORING AGENCY NAME AND ADDRESS

U.S. Environmental Protection Agency

Office of Air Quality Planning and Standards

Emissions Monitoring and Analysis Division

Research Triangle Park, NC 27711

13. TYPE OF REPORT AND PERIOD COVERED

Final technical report. Supplement A

14. SPONSORING AGENCY CODE

EPA/200/04

15. SUPPLEMENTARY NOTES

16. ABSTRACT This document is a users guide for the terrain preprocessor component (called AERMAP)

for the air dispersion model called AERMOD. In addition to providing detailed instructions on how to set up

and run the preprocessor, there is a brief description of the technical approach on which AERMAP is based.

17. KEY WORDS AND DOCUMENT ANALYSIS

a. DESCRIPTORS b. IDENTIFIERS/OPEN ENDED TERMS c. COSATI Field/Group

 AERMOD, AERMAP, TERRAIN, PREPROCESSOR Air Pollution models

18. DISTRIBUTION STATEMENT

 Release Unlimited 19. SECURITY CLASS (Report) Unclassified 21. No of pages 107

20. SECURITY CLASS (Page) Unclassified 22. PRICE

EPA Form 2220-1 (Rev. 4-77) PREVIOUS EDITION IS OBSOLETE
D-2

United States Office of Air Quality Planning and Standards PublicEnvironmental Protection Emissions Monitoring and Analysis Division Agency Research Triangle Park, NC