### ADDENDUM

USER'S GUIDE FOR THE

AERMOD METEOROLOGICAL PREPROCESSOR

(AERMET)

(EPA

- 454/B

- 03

- 002
, November 2004)

U.S. ENVIRONMENTAL PROTECTION AGENCY Office of Air Quality Planning and Standards Air Quality Assessment Division Research Triangle Park, North Carolina 27711

June 2015ii PREFACE

This document provides updated user instructions for the AERMOD meteorological

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

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

AE RMET User’s Guide (EPA, 2004).iii CONTENTS

1.0 INTRODUCTION

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

................................ ................................ ...... 1

2.0 USER INSTRUCTIONS

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

................................ ................................ ............................ 12
2.2 UP PER AIR SOUNDING SELECTION

................................ ................................ ...... 14 2.2.1 Adjusting the Default Sounding Window

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

................................ ............................. 17
2.3 PROCESSING OF ASOS DATA

................................ ................................ .................. 18
2.3.1 Use of 1

- minute ASOS Wind Data

................................ ................................ ............ 19 2.3.2 Threshold Wind Speed for 1

- minute ASOS Winds

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

................................ ........................... 22 2.3.4 Identifying ASOS Observations

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

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

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

............................. 26
2.4 DEFINING THE ONSITE FILE STRUCTURE

– READ AND FORMAT

............... 27
2.5 SPECIFYING ONSITE MEASUREMENT HEIGHTS

................................ .............. 32
2.6 SECONDARY SITE SURFACE CHARACTERISTICS

................................ ............ 33
2.7 REVISED SURFACE FILE FORMAT TO SUPPORT AERMOD DEPOSITION
ALGORITHMS

................................ ................................ ................................ ............ 36
2.8 BETA OPTION FOR ADJU STING USTAR UNDER LOW WIND/STABLE
CONDITIONS

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

........ 38

3.0 REFERENCES

................................ ................................ ................................ .................. 41

APPENDIX A. FUNCTIONAL KEYWORD/PARAMETER REFERENCE

.................. A

- 1

APPENDIX B. VARIABLE NAMES AND DEFAULT QA VALUES

.............................. B

- 1

APPENDIX C. DATA FILE FORMATS

................................ ................................ ........... C

- 1

APPENDIX D. FUNCTIONAL KEYWORD/PARAMETER REFERENCE

.................. D

- 11 1.0 INTRODUCTION

This document provides user instructions for revisions to the AERMOD meteorological

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

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

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

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

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

1.1 OVERVIEW OF AERMET REVISIONS

Several sets of AERMET revisions are included in this Addendum :

1. The first set of revisions

, introduce d with version 06341 of AERMET, includes

m

odifications to address several problems associated with extraction and processing
of National Weather Service (NWS), Federal Aviation Administration (FAA), or
other airport data in the Integrated Surface Hourly D a ta (a.k.a., ISHD, ISH, ISD,

TD

- 3505) format ; inclusion of an optional station elevation parameter on the LOCATION keyword for the UPPERAIR, SURFACE, ONSITE, and METPREP pathways; and modifications to use a single executable file, AERMET.EXE, to perform all three stages of processing, replacing the STAGE1N2.EXE and STAGE3.EXE files (additional information is provided in Model Change Bulletin (MCB) #1 provided on the SCRAM AERMET webpage); and

2. T he second set of revisions

, introduced with version 11059 of AERM ET (additional information is provided in Model Change Bulletin (MCB) #2 provided on the SCRAM AERMET webpage), includes:

a. further enhancements to the use of user

- specified station elevations for surface stations to substitute for missing station pressure;

b. enhancements to increase the maximum record length for the runstream input file from 80 to 132 characters, increase the maximum field length for filenames from 48 to 96, and allow use of double quotes (“) as field delimiters for filenames to support filen ames with embedded spaces;

c. enhancements to the selection of upper air sounding to support applications of AERMOD beyond the U.S., and including an option to select the most appropriate sounding based on local sunrise;2 d. enhancement to allow the use of hour ly averaged winds derived from 1

- minute ASOS wind data (TD

- 6405);

e. adjustment of ASOS

- based wind speeds (including winds derived from 1

- minute ASOS data) to account for reported ASOS wind speeds being truncated (rather than rounded) to whole knots;

f. enhanc ements to the error handling and reporting related to processing ONSITE data, including an option to use ‘FREE’ format to read the data and the option to specify missing data codes and upper/lower bounds for ONSITE data as REAL variables;

g. an option/requir ement to specify a secondary set of surface characteristics for
use when NWS winds are substi tuted for missing on

- site winds; and

h. enhancements to utilize on

- site precipitation and relative humidity data, if
available.

3. The third set of revisions, introduced with version 12345 of AERMET (additional information is provided in Model Change Bulletin (MCB) #3 provided on the SCRAM AERMET webpage), includes:

a. Modified subroutine DOCLDS to correct for errors that result when blank spaces occur between the cloud cover and ceiling height fields for HUSWO surface data. Also modified DOCLDS to no longer accept invalid ASOS cloud cover codes for HUSWO surface data. These bug fixes should not affect
results for HUSWO surface data that w ere extracted from the HUSW O CD, but could affect results significantly for applications using surface data that
were reformatted to the HUSWO format from another data format;

b. Modified subroutine CBLHT to correct an error in the calculation of the convective mixing height. Previous versions of AERMET may have underestimated convective mixing heights, and in turn the convective velocity scale (w*), due to this error. The magnitude of the errors would tend to be larger for cases where the vertical temperature profile based on the upper air sounding was based on fewer sounding levels. However, due to the widespread nature of these convective mixing height errors, AERMOD modeling results are likely to be affected to some degree by this AERMET bug fix in most cases. The magnitude and direc tion of changes in AERMOD model results due to this convective mixing height bug fix will vary depending on the resolution of the upper air data and the characteristics of the
sources and terrain included in the AERMOD model application;

c. Modified subroutin es CBLHT, MPPBL, MPMET, and SETUP to check for ONSITE mixing heights (OSMIX) in the determination of data completeness, and adjusted warning messages to account for possible presence of both
ONSITE m ixing heights and UPPERAIR data;

d. Added a new THRESH_1MIN keyword to Stage 3 processing. This optional keyword allows the user to specify a threshold wind speed below which winds3 reported in the 1

- minute ASOS data processed through AERMINUTE, if in use, are considered calm. There is no default value; however, a w arning message will be generated if the user

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

- specified threshold is less than zero or greater than 1.0;

e. Incorporated a new "BETA" option to adjust u* (usta r) for low wind speed
stable conditions, based on Qian and Venkatram ( 2011 ) . The new option is selected by including the METHOD STABLEBL ADJ_U* keyword on the METPREP pathway in the Stage 3 input file. The ADJ_U* "BETA" option is
considered to be a non

- Def ault option and is therefore subject to the alternative model provisions in Section 3.2 of Appendix W (40 CFR Part 51). Users should coordinate with the appropriate reviewing authority regarding the procedures and requirements for approval of this BETA opt ion for regulatory modeling applications. Use of this option also requires the user to include the BETA option on the CO MODELOPT keyword in the AERMOD input file;

f. The value used to adjust ASOS wind speeds to account for bias due to wind speeds being trun cated to whole knots was modified to include three significant digits (from 0.26 m/s to 0.257 m/s, based on 0.5 kt). This
modification avoids potential for mis characterization of calm vs. non

- calm due to precision issues associated with the truncation adju stment u nder the new THRESH_1MIN option; and

g. Modified subroutine GETFSL to issue a non

- fatal warning instead of a fatal error message when the UA station ID specified on the UA LOCATION keyword does not match the UA station ID in the data file. This change will accommodate substitutions for missing UA soundings using data from other representative UA stations, and will document when such substitutions were made in the Stage 1 report file. Since all convective hours will be missing on days when the UA sound ing is missing, this will allow users to minimize the number of missing hours in the AERMET

- processed surface file due to missing UA soundings, while maintaining a record of when such substitutions were made and identifying which alternative sites were use d.

4. The fourth set of revisions, introduced with version 13350 of AERMET (additional information is provided in Model Change Bulletin (MCB) #4 provided on the SCRAM AERMET webpage), includes:

a. Modified subroutine UCALST to incorporate AECOM's recommended
corrections to theta

- star under the ADJ_U* Beta option;
b. Modified subroutine MPMET to correct assignment of time

- zone adjustment (ZONE) to be based on the upper air time

- zone (UALST) for cases where both upper

- air data and ONSITE mixing heights are availab le;4 c. Modified subroutine SBLHT to correct the coefficient for the mechanical mixing height from 2300 to 2400 based on the original Venkatram reference (BLM, 2009);
d. Modified subroutine MPPBL to correct the initialization of the NO_SKY variable for missing on

- site cloud cover to use the OSTSKY(2) value based on the missing data code input by the user, instead of a value of 99. This error
could have resulted in on

- site cloud cover being flagged as missing inapp ropriately in previous versions;

e. Modified subroutin e O3NEXT to remove the conversion of delta

- T values to lapse rate values (delta

- T/delta

- z) before calling subroutine REALQA, which compares the value to upper and lower bounds based on delta

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

- T
values out

- of

- ra nge; f. Modified subroutine RDISHD to correct the processing of ASOS cloud cover
data based on the GA1

- GA6 codes to avoid inadvertently assigning a missing
code to the ASKY variable. Also modified subroutine RDISHD to move the
check for hour 0 (zero) later in the processing in order to avoid using a "special" ISHD observation that occurs on the hour instead of a "non

- special" observation that occurs earlier;

g. Modified subroutine MPFIN to include additional error checkin g and reporting regarding the completeness of the surface c haracteristics arrays. Errors in processing user

- specified surface c haracteristics (i.e., not generated by AERSURFACE) may have occurred in previous versions;
h. Modified several subroutines to allow the use of on

- site mixing heights only (OSMIX), without requiring upper air data. In these cases, the LOCATION keyword on the METPREP pathway should be used to specify the time zone adjustment from local time to GMT, since the time zone specified on the ONSITE pathway is likely to be for local time. Otherwise, AERMET would assume GMT as local time and results would be incorrect (unle ss local time actually was GMT);
i. Modified subroutine MPPBL to correct the error message associated with missing station pre ssure (FORMAT 1022) which was also used for missing sky cover data. A new FORMAT statement (1021) was added for use with missing station pressure. Also removed several FORMAT statements in
MPPBL that were not used. j. Modified subroutine BULKRI to incorporat e a modified Bulk Richardson Number approach under the ADJ_U* Beta option, based on Luhar and Rayne r (2 009). As with the ADJ_U* Beta option incorporated in UCALST for applications which do not employ the BULKRN option, this method is
considered a non

- DFAU LT option requiring approval as an alternative model for use in regulatory applications.
k. Modified subroutines MPPBL, SUBST, VRCARD, and MPTEST to include substitutions for missing cloud cover data and/or missing ambient temperature by interpolating across 1 or 2

- hour gaps in the input data. New subroutines5 (GETCCVR and GETTEMP) were also created to facilitate this enhancement. The default option is for AERMET to apply the substit ut ion for both missing cloud cover and temperature, unless the user has specif ied both SURFACE and ONSITE data. New options have been added to the METHOD keyword on Stage 3 that allow the user to disable the cloud cover and/or temperature
substitution (s) in cases where only SURFACE or ONSITE data are available,
or to activate the o ptions in cases where both SURFACE and ONSITE data
are available. Subroutines MPMET and MPOUT were also modified to include approp r iate flags in the surface output file indicating when these options have been utilized.
5. The fifth set of revisions, introduce d with version 14136 of AERMET (additional information is provided in Model Change Bulletin (MCB) #5 provided on the SCRAM AERMET webpage), includes:

a. Modified subroutines SUBST and MPPBL to correct potential issues associated with the options introduced in version 13350 to substitute for missing cloud cover (CCVR) and/or temperature (TEMP) by linear interpolation across 1 or 2

- hour gaps . This included an error that may have resulted in substituted CCVR values larger than 10 based on in and which may have r esulted in NaN (“not a number”) for some calculated variables ; Issues with CCVR substitutions may also have occurred for applications using ONSITE meteorological data only, with ONSITE net radiation (NRAD) or with solar radiation (INSO) and delta

- T (D T01) data using the Bulk Richardson Number (BULKRN) option. In these cases AERMET calculates equivalent cloud cover values that are included in the surface output file, but
no substitutions for mi ssing values should be included;
b. Modified subroutine SUBST to remove the initialization of the GOT_OSTMP logical variable to .FALSE. for the current hour. The GOT_OSTMP variable is assigned a value in subroutine GETTEMP prior to the call to subroutine SUBST. This error may have affected calculations of station pressure and relative humidity for applications with ONSITE data, including relative humidity values greater than 100 for applications wi th both SURFACE and ONSITE data;

c. Modified subroutine GETTEMP to reinitialize the LTZMAX4T variable to
.TRUE. within the hour loop, indicating that the maximum height for ONSITE temperature had not been reached yet. The ONSITE temperature may have been incorrectly interpreted as being missing in version 13350 for some cases;
d. Modified subroutines GETTEMP and SUBST to ensure that substitutions for missing ONSITE temperature data are only based on values from the same measurement level if multiple levels of temperature are available.

e. Modified subroutine MPPBL to address issues associated with the selection of the appropriate up per air sounding time. This includes use the INT function instead of NINT when assigning ‘MyZone’ to determine the reference sounding time based on the longitude of the location for the default option. Subroutine MPPBL was also modified to use an integer variable6 ( ICHRND_UASRISE ) instead of a real variable ( CHRND_UASRISE ) for assigning the ‘START_WINDOW’ when the UASELECT SUNRISE option
is used.
f. Modified subroutines FLOPEN and WRTCRD to use STATUS='REPLACE' instead of STATUS='SCRATCH' when opening the DEV 70 and DEV75 "temporary" files to store the header records in the ".IQA", ".OQA", and MERGE data files that contain information for reprocessing of input options during subsequent stages of AERMET processing. This modification
addresses issues that were en countered where AERMET was not able to locate the 'SCRATCH' files when applying a 64

- bit version of AERMET.

g. Modified subroutines SUMHF and SUNDAT to eliminate integer/real mixed

mode calculations in summing the hourly heat fluxes, and in calculating
sunris e/sunset times and solar elevation angles.
h. Modified subroutine BULKRI to include the THSTAR adjustment for low solar elevation angles under the original BULKRN method and for the non

Default/BETA ADJ_U* option associated with the BULKRN option.
Subroutine BULKRI was also modified to avoid an array subscript out

- of

bounds error in cases where the iterative approach does not converge within the specified loop limits.
i. Modified subroutine MPFIN to include additional error handling and reporting associated with processing of surface characteristics j. Modified subroutines VRCARD, SUBST, MPPBL, and MPOUT to allow users to disable substitutions for missing CCVR and/or TEMP data that are based on persistence for hours 23 and 24. Additional flags have been added to
the surface output file to identify when this option is applicable. These changes also allow users to specify either the NO_SUB or NOTSUB keyword
to disable TEMP substitutions.
k. Subroutine OSDTCD was modified to include logical variables to identify the
availab ility of ONSITE data for ambient temperature, solar radiation/insolation, cloud cover, net radiation, delta

- T, and/or mixing heights. Several other subroutines were modified, including MPPBL, MPMET, MPFIN, and MPTEST to track whether substitutions for miss ing temperature and/or cloud cover should be implemented by default, based on whether only ONSITE data or only SURFACE data are available for a given parameter. Cloud cover and temperature substitutions were not implemented by default in
v13350 if both SUR FACE and ONSITE data were available, irrespective of whether the substituted parameter was included in both SURFACE and ONSITE data inputs. Version 14134 will apply CCVR and/or TEMP substitutions by default if the parameter is only included in the SURFACE or ONSITE data. However, the user options to disable substitutions are still
available.
l. Modified subroutines MPPBL, SUBST, and EQ_CCVR to address potential
issues with the use of ONSITE solar radiation and delta

- T data in lieu of cloud cover (utilizing the delta

- T based Bulk Richardson Number (BULKRN)7 method for stable conditions) or if delta

- T/BULKRN is being applied with ONSITE or NWS cloud cover. These modifications were focused especially on the transition from nighttime stable conditions (controlled by delta

T/BULKRN) and daytime convective conditions (controlled by solar radiation data). The BULKRN/delta

- T method will be used if valid delta

- T and
ONSITE wind data are available and if the delta

- T lapse rate is stable, or if the
cloud cover or insolatio n data is missing, or if the cloud cover is an "equivalent" cloud cover derived from solar radiation data when the solar elevation angle is less than the critical elevation angle for convective
conditions

. The critical solar elevation angle was also modif ied to use an average of the previous 24

- hours of temperature data (with at least 75% data capture), instead of a default value of 288 K, for hours when the temperature is missing. An assumption of 5/10 cloud cover is also used in the calculation
of critic al solar elevation angle for hours when cloud cover is missing. Since the model will not compute concentrations for these hours due to missing temperature and/or cloud cover the effect of these changes on modeled concentrations is likely to be minimal. Fu rthermore, this approach should provide a reasonable estimate of early morning heat fluxes, and treating these hours as missing in terms of heat flux could result in the entire convective portion of the day being missing

m. Subroutine EQ_CCVR was modified to account for cases when the clear sky insolation value, QRNOT, is less than or equal to 0. The equivalent CCVR is
set to 0 in these cases.

n. Modified subroutines MPMET, MPFIN, MPOUT, and AERSURF to track and report the use of MMIF

- generated inputs, in the for m of pseudo

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

- ONSITE and
UPPERAIR data. The use of MMIF

- generated inputs is gleaned from information in the AERSURF input file of surface characteristics if it is used in Stage 3. The use of MMIF data is flagged in the header record of the surface file and by the use of the 'MMIF

- OS' flag instead of the hourly NAD

OS, ADJ

- SFC, etc., flags associated with ONSITE and/or SURFACE data. Subroutines MPMET, MPFIN, and MPOUT were also modified to trac k and report the use of the Bulk Richardson Number (BULKRN) option based on
delta

- T measurements, in lieu of cloud cover

, for stable conditions. For applications using the BULKRN option, the header record of the surface file will include the 'BULKRN' flag . An additional 'MMIF' flag will be included if the BULKRN option is associated with use of MMIF data

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

- digit WBAN, instead of an 8

- digit number with 3 leading 0's, for processing upper
ai

r data in the 6201 format. Checks have also been included to identify issues that may occur when users specify the 6201VB (TD

- 6201 variable

- length block) format for upper air data.

p. Modified subroutine GETFSL to read the WMO number from upper air data
in t he FSL format, in addition to reading the WBAN, and assign the WMO8 number to the BUF08(1) variable if WBAN = '99999' to support non

- US applications.

q. Modified subroutines SETUP, MPPROC, OSCARD, MRCARD, WRTCRD,
and HEADER to allow re

- processing of the XDATE S information from the MERGE file header records. This information is included in the Stage 3 report, unless the user has specified XDATES in the Stage 3 input file. Also modified subroutine MERGE to use a consistent form for reporting the extract
dates i n the report file s across all three stages. S ubroutine CHROND was modified to fully support 4

- digit years and subroutine XDTCRD was modified
to use 4

- digit years for extract dates in the report files instead of 2

- digit years

. 6. The s ixth set of revisions, i ntroduced with version 15181 of AERMET (see Model Change Bulletin (MCB) #6 provided on the SCRAM AERMET webpage),
includes:

a. Modified subroutines UCALST and MPPBL to incorporate a constant value of THSTAR of 0.08, full inclusion of the displacement height, and a modified
formulation for Monin

- Obukhov length for the ADJ_U* option based on Qian and Venkatram ( BLM, v138, 2011) . Su broutine UCALST was also modified to adjust USTAR for wind speeds below the “critical” wind speed.
b. Modified subroutine BULKRI to correct the calculation of CDN to use ZREF(IHR)/Z0(IHR) instead of Z2/Z0(IHR). Subroutine BULKRI was also
modified to use BETA M = 0.5 for the ADJ_U* option instead of 0.47.

c. Modified subroutine BULKRI to incorporate additional refinements to the ADJ_U* Beta option in conjunction with the Bulk Richardson Number (BULKRN) option, based on Luhar and Raynor (BLM, v132, 2009), including a more refined method for calculating THSTAR, and extending its applicability for very stable/low wind conditions.
d. Modified subroutine MERGE to include the year in the Stage 2 table of Daily Output Statistics.

e. Subroutine GET620 was modified to issue a mes sage if the UALOC in the upper data file does not match UALOC specified on the LOCATION keyword. This allows users to track when data from alternative representative upper air stations are used in conjunction with the UPPERAER tool.

AERMET is designed to be run as a three

- stage process (see Figure 1

- 1 of the AERMET

User’s Guide ) and to operate on three basic types of data

– NWS , FAA or other hourly surface

observations, NWS twice

- daily upper air soundings, and data collected from an on

- site

measurement pr ogram such as from an instrumented tower

. The first stage of AERMET

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

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

- hour

pe riods and writes these data to an intermediate file. The third and final s tage reads the merged9 data file, develops the necessary boundary layer parameters for dispersion calculations by

AERMOD , and outputs AERMOD

- ready meteorological data files

.

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

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

weather observations, typically but not exclusively from airports

. Also, AERMET defines the

ONSITE pathway for inputting hourly surface observations taken from an on

- site, or site

- specific

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

was modified in April 2003 to use the term ‘site

- specific’ in place o f ‘on

- site,’ recognizing that

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

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

- site’

are not automatically precluded from being considered representative. As a result, the terms ‘on

site’ and ‘site

- specific’ are used interchangeably in the AERMET User’s Guide and Addendum.

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

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

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

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

three stages, a nd the program is run by entering ‘ AERME T’ at a ‘DOS’ command prompt, or by

double

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

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

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

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

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

Note that all AERMET output filenames are user

- specified. As currently configured, AERMET

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

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

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

preparation). Since stage 1 processing is designed to support QA of raw input data, stage 1 may10 involve some iteration if data problems are encountered. Prior to ru nning AERMET one should

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

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

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

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

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

Integrated Surface Hourly Data (a.k.a., ISHD, ISH, ISD, TD

- 3505) format included :

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

m

ultiple records ;

• corrections to code for processing of sky cover fields ;

@ ECHO OFF

rem RUNAERMET filename

rem T his is a DOS utility program for use in running the meteorological rem preprocessor, AERMET. The program is run from the DOS prompt using rem the following syntax:

rem where: RUNAERMET is entered 'as is' and
rem filenam e is the name of the input file

:START
IF '%1' == '' GOTO END

IF EXIST %1 GOTO COPY ECHO Error locating input file

GOTO STOP

:COPY
COPY %1 AERMET.INP ECHO Proceed with processing

PAUSE

AERMET

GOTO STOP

:END

ECHO ..

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

ECHO ..
ECHO RUNAERMET filename

ECHO .. ECHO where: RUNAERMET is entered 'as is' ECHO filename is the name of the input file

ECHO ..

ECHO ..11 • addition of code for identifying "variable" winds , introduced on July 1, 1996, with adoption of the METAR reporting standard, with valid wind speed but missing wind direction (formerl y flagged as calms) ;

• code for initializing the "additional" character variable to avoid data fields from previous hours being used ; and

• code for handling mixed

- format ISHD data files with full and condensed archival formats (note that ‘condensed’ format re fers to ISHD data without the location and elevation fields on each record, which is not the same as the ‘abbreviated’ format for ISHD data, which is not supported by AERMET).

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

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

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

AERMET User’s Guide provided below in Appendix B.

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

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

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

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

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

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

2.1 STATION ELEVATIONS

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

above mean sea

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

SURFACE, and ONSITE pathways in the Stage 1 control file

, and the METPREP pathway in the

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

when processing ISHD data on the SURFACE pathway and all other occurrences of user

specified station elevations were ignored. Beg inning with version 11059, AERMET was revised

to make full use of user

- specified station elevations for the SURFACE and ONSITE pathways to

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

the UPPERAIR pa thway. The LOCATION keyword has also been removed from the

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

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

- specified

elevation will be ign ored and processing will continue

. AERMET will also issue a warning

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

pathway.

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

summarized b elow:

1. A non

- fatal warning message will occur if the station elevation is encountered on
the LOCATION keyword on the UPPERAIR (Stage 1) pathway, or if the LOCATION keyword is included on the METPREP (Stage 3) pathway, but the inputs will be ignored and processing will continue

.
2. The station elevation is allowed as an optional argument on the LOCATION keyword for the SURFACE and ONSITE pathways in Stage 1

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

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

user

- specified station elevation is used, if available.

4. If the station elevation is not specified on the SURFACE pathway and is not in the raw surface data input file for Stage 1, the n 0 meters (sea

- level) is used for the
SURFACE station elevation.

5

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

- level) is used for the ONSITE station elevation.

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

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

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

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

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

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

sea

- level pres sure and station elevation, depending on the source of ambient temperature data:

1. If ONSITE temperature data is used, then:

a. Use ONSITE station pressure, if available;

b. Adjust ONSITE sea

- level pressure to ONSITE station elevation, if provided on
the LOCATION keyword in the ONSITE pathway;

c. Adjust NWS/FAA station pressure to ONSITE station elevation, if station elevation is available for both the SURFACE and ONSITE data;

d. Adjust NWS/FAA sea

- level pressure to ONSITE station elevation, if ONSITE
station elevation is provided;

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

f. Adjust NWS/FAA sea

- level pressure to SURFACE station elevation, if available;

g. Estimate station pressure based on standard atmosphere using ONSITE station elevation, if available;

h. Estimate station pressure based on standard atmosphere using SURFACE station elevation, if available;

i. Assign ONSITE sea

- level pressure to station pressure if no ONSITE station elevation is available;14 j. Assign SURFACE sea

- level pressure to station pressure i f no SURFACE station elevation is available; or

k. Assign standard sea

- level pressure of 1013.25 mb to station pressure.

2. If SURFACE temperature data is used, then:

a. Use SURFACE station pressure, if available;

b. Adjust SURFACE sea

- level pressure to SURFACE statio n elevation, if provided on the LOCATION keyword in the SURFACE pathway or in the SURFACE data file;

c. Adjust ONSITE station pressure to SURFACE station elevation, if station elevation is available for both the SURFACE and ONSITE data;

d. Adjust ONSITE sea

- leve l pressure to SURFACE station elevation, if SURFACE station elevation is provided;

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

f. Adjust ONSITE sea

- level pressure to ONSITE station elevation, if available;

g. Estimate station pressure based on standard atmosphere using SURFACE station elevation, if available;

h. Estimate station pressure based on standard atmosphere using ONSITE station elevation, if available;

i. Assign SURFACE sea

- level pressure to station pressure if no SURFACE station elevation is available;

j. Assign ONSITE sea

- level pressure to station pressure if no ONSITE station elevation is available; or

k. Assign standard sea

- level pressure of 1013.25 mb to st ation pressure.

2.2 UPPER AIR SOUNDING SELECTION

The AERMET meteorological preprocessor was originally developed to work with NWS

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

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

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

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

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

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

0000 GMT (or 00Z) sounding. Originally, AERMET was designed to automatica lly select the15 12Z sounding , consistent with the primary focus of the AERMOD model development to support

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

vary slightly , AERMET also defined a d efault “soundin g window” of ±1 hour, i.e., AERMET

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

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

AERMET is being applied.

The world is divide d into 24 time zones

, but most zones do not follow a straight north

south line of longitude (see Figure 2

- 1). As a result, the time zone adjustment parameter on the

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

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

for a n appropriate sounding for all locations based on the longitude entered on the LOCATION

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

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

nearest integer. For example, 156.76° West yields a time zone of

- 10 (in keeping with the

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

zone is

- 9 for the entire state but the state actually spans pseudo

- zones

- 9,

- 10, and

- 11 based on

longitude. This is not an uncommon occurrence.

Table 2

- 1 shows which default sounding AERMET will use based o n the longitude

dependent ‘pseudo’ time zone (note that time zones

- 12 and +12 refer to the same zone). The

values shown in the table are also shown across the top of Figure 2

- 1. A sounding time of

- 12

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

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

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

Table 2

- 1 . Sounding Selection by Time Zone

Time Zone

- 12

- 11

- 10

- 9

- 8

- 7

- 6

- 5

- 4

- 3

- 2

- 1 0
Sounding

- 12 12 12 12 12 12 12 12 12 00 00 00 00

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

-- Sounding 00 00 00 00 00 00 00

- 12

- 12

- 12

- 12

- 12

--

2.2.1 Adjusting the Default Sounding Window

By default, AERMET uses a 1

- hour window before and after the preferred sounding time

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

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

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

Type: Optional, Non

- repeatable

where w indow_begin represents the beginning of the sounding window and w indow_end

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

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

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

the sounding. The default sounding window would be input as: UAWINDOW

- 1 +1 (note that

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

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

fewer after, the following could be used: UAWINDOW

- 5 +2. To force AERMET to accept

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

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

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

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

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

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

the 9Z sounding.

2.2.2 Option to Select Sounding Based on Sunrise

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

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

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

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

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

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

(equivalent to UAWINDOW

- 6 +2)

. As with the sounding window for the default selection in

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

that is 4 hours before sunrise is preferred, and selected, over a sounding that is 1 hour after18 sunrise.

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

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

as follows:

Syntax: METHOD UASELECT SUNRIS(E)

Type: Optional, Non

- repeatable

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

the user can expand or contract the search window for the SUNRIS option (

- 6 to +2 hours by

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

same in both cases:

Syntax: UAWINDOW w indow_begin window_end

Type: Optional, Non

- repeatable

where w indow_begin represents the beginning of the sounding window and w indow_end

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

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

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

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

sounding at 0600 vs. a sounding at 0700.

2.3 PROCESSING OF ASOS DATA

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

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

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

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

1992 to replace the traditional observer

- based system for collecting and reporting weather data19 with an automated system. As of 2010, there were over 900 ASOS sta tions located at airports

across the U.S. The transition from the observer

- based system to an automated system has

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

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

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

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

2.3.1 Use of 1

- minute ASOS Wind Data

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

Climatic Data Center (NCDC) began routinely archiving 1

- minute ASOS wind data (TD

- 6405),

beginning with data for January 2000 for first

- order NWS ASOS stations, and beginning with

data for March 2005 for all other ASOS stations. The 1

- minute ASOS wind data files include

the 2

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

overlapping 2

- minute averages for an hour. By con trast, the standard archives of surface

observations based on ASOS include a single 2

- minute average wind speed, usually reported

within 10 minutes before the hour. The values included in the 1

- minute ASOS wind data files

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

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

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

1

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

The use of hourly

- averaged wind speed and direction provides a more appropriate input

for the AERMOD dispersion model than a single 2

- minute average. Utilizing wind data for the

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

variable (with a non

- missing wind speed up to 6 knots, but missing wind direction) based on a

single 2

- minute average will be filled in with hourly averages derived from the 1

- min ASOS

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

- minute

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

done for the standard observations which are reported to the nearest 10 degrees.20 Beginning with version 11059, AERMET has been updated to accept hourly averages of

wind speed and wind direction derived from 1

- minute ASOS wind observations available from

NCDC at ftp://ftp.ncdc.noaa.gov/pub/ data/asos

- onemin/. The hourly

- a verag ed wind speed and

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

- minute ASOS wind

data processor, AERMINUTE (EPA, 2010)

. Hourly

- averaged wind speed and direction data

derived from 1

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

“1

- minute ASOS wind data.”

The 1

- minute ASOS wind data are read by AERMET during the Stage 2 merge
processing. AERMET is instructed to include these data in the merged output by adding the

ASOS1MIN keyword followed by the filename of the 1

- minute ASOS wind data file on the

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

ASOS1MIN file_name

When provided, 1

- minute ASOS wind data can be used to substitute for missing ONSITE wind

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

data are not included. To substitute for missing on

- site winds or replace standard SURFACE

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

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

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

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

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

1. ONSITE winds,

2. 1

- min ASOS winds; then

3. standard SURFACE winds.21 Neither NWS nor 1

- min ASOS wind data will be used to substitute for missing onsite wind data

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

control file.

Wind speeds from 1

- minute ASOS wind data files are extracted and merged during Stage

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

date, and if the 1

- minute ASOS wind date precede the commission date the reference wind speed

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

details).

2.3.2 Threshold Wind Speed for 1

- minute ASOS Winds

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

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

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

have virtually no starting threshold. As a result, the hourly

- averaged winds processed through

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

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

threshold for site

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

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

- minute

ASOS data than would be required for a s ite

- specific monitoring program, beginning with

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

-

minute ASOS data.

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

for the user to specify a threshold wind speed for the 1

- minute data. This threshold value only

applies to the hourly averaged winds derived from 1

- minute data and does not apply to the

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

foll owing syntax:22 Syntax: THRESH_1MIN threshold_speed

Type: Optional, Non

- repeatable

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

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

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

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

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

based on the specified threshold value.

2.3.3 Adjustment to Truncated ASOS Wind Speeds

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

all ASOS

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

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

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

NWS surface data formats ; and 2) hourly

- averaged wind speed and direction derived from

1

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

.

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

processing to wind speeds substituted from 1

- minute ASOS wind data as well as thos e

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

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

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

following format:

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

AERMET, and identify whether the wind speed was adjusted, a two

- part code is appended to the

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

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

is encoded as either “ OS ”

, “SFC” , or “ A1 ” to indicate the use of ONSITE

, SURFACE, or

1

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

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

2.3.4 Identifying ASOS Observations

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

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

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

commission date of the ASOS equipment for the Weather

- Bureau

- Army

- Navy ( WBAN ) number

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

- or 4

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

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

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

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

temporarily converted to LST and the 1

- 24 hour convention, then the converted date is compared

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

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

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

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

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

- 23 hour

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

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

ASOS hour.24 For those NWS surface formats that include a data field to indicate that measurements

were made with ASOS instrumentation (HUSWO, TD

- 3280 , and in some cases ISHD ), a

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

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

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

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

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

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

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

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

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

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

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

the ASOS commission list within AERMET (see Table A

- 6 for a descripti on of the DATA

keyword format).

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

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

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

applied in Stage 3

. Since 1

- minute ASOS wind data are presumed to be ASOS by definition, the

ASOS flag is not included on the 1

- minute ASOS wind data in the merge file.

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

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

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

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

these files, a fatal error is issued and processing is aborted. Therefore, version 11059 of25 AERMET , or later, will not process surface extraction or merge files generated with an

earlier version of AERMET.

2.3.5 Validation of NWS Surface Format by Active Date Range

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

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

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

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

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

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

and AERMET results based on process ing reformatted data should be used with caution

.

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

surface file

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

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

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

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

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

- 3280 are

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

**Table 2** 

**- 2.**  **Format Active Dates**

NWS Surface Format Start Date End Date

CD

- 144

--- 12/31/1995

HUSWO 1/1/1990 12/31/1995

ISHD

--- ---

SAMSON 1/1/1961 12/31/1990

SCRAM 1/1/1984 12/31/1992

TD

- 3280

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

A nother validation was incorporated in to AERMET , beginning with version 11059, to

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

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

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

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

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

- 144,

HUSWO, SCRAM, and TD

- 3280). Whe n the WBAN number from the control file is found to

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

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

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

international ly for which a WBAN number has not be assigned

.

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

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

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

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

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

a fatal error will only be issued and processing aborted if a mismatch occurs between two non

missing (i.e., not ‘99999’) WBAN numbers . For th e ISHD format, the validation is applied to

the 5

- digit ID stored in posit ions 11

- 15 on each record. The first non

- missing (not ‘99999’)

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

2.3.7 ASOS Cloud Cover from SCR AM and SAMSON Set to Missing

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

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

over the validity of the representation of ASOS clo uds in these older pre

- ASOS formats. For this27 reason, AERMET was modified (beginning with version 11059) to set opaque and total cloud

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

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

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

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

SCRAM

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

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

SCRAM format.

2. 4 DEFINING THE ONSITE FILE STRUCTURE

– READ AND FORMAT

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

meteorological processor is to specify the inputs necessary to read and process site

- specific, or

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

w ide range of site

- specific meteorological variables, including wind, temperature and turbulence

data from a multi

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

site

- specific data being input to AERMET. Also, since AERMET w as written using the Fortran

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

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

process for defining ONSITE meteorologi cal inputs for AERMET, including enhancements

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

better error handling and reporting if problems are encountered.

The key to reading site

- specific meteorological data co rrectly in AERMET is to define

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

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

which defines the list and order of var iables prese nt on a data record; and 2) the FORMAT

keyword, which defines the format of the data on each record

. As noted above, t hese two

statements together operate much like reading or writing data in a Fortran program. The syntax28 and type of these two keywords are as follows :

Syntax: READ record_index osname 1 osname 2

... osname n

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

Syntax: FORMAT record_index Fortran_format

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

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

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

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

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

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

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

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

The osname 1, osname 2, ... osname n fields on the READ keyword are the variable names

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

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

B

- 3a for “s calar” (single

- level) variables and Table B

- 3b for “vector” (multi

- level) variables.

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

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

with version 11059, user’s can specify ‘FREE’ (without quotes and not case

- sensitive) for the

Fortran_format to indicate that the variables for a particular data record should be read as free

formatted data, in accordance with Fortran language st andards. Free

- formatted, also called list

directed data, are read as a list of values which are separated by at least one blank space or by a

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

the Fortran FORMAT explicitly for other data records. The FREE format option may simplify29 the process of specifying the READ and FORMAT inputs for some users, but still requires an

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

The structure and format of the site

- specific data is reasonably flexible, but subject to the

following restrictions:

(1) The data for one observation period can be spread across several records (up to 50) , but the records for one data period must be contigu ous;

(2) The same variables must appear for all observation periods , even if the values for those variables are missing for certain hours ;

(3 ) The ONSITE data file must be an ASCII text file and it must be in a form that can be read using Fortran FORMAT statements or as FREE format;

( 4 ) The date and time information for each observation must be on the first record of the period; these may occur in any order within the first record, and are read as
INTEGER format (Fortran ‘I’ format or FREE format) ;

(5 ) The (non

- date) data variables on the READ keywords must be a subset of those listed in Appendix B, Tables B

- 3a and B

- 3b , and are read as REAL format (Fortran ‘F’ or ‘E’ format or as FREE format) ;

(6 ) Using an ‘F’ or ‘E’ (REAL) Fortran format specifier to read a date/time variable will cause an AERMET runtime error; and using an ‘I’ (INTEGER) format specifier to read a data variable will also cause an AERMET runtime error.

When specifying the multi

- level variables, such as wind or temperature observations

from an instrumented tower, the variable name is composed of a two

- character prefix that

identifies the atmospheric quantity and a two

- character (numeric) suffix that identifies the level.

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

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

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

appear at three levels but temperature only at tw o levels. However, multi

- level data must be

entered in ascending height order. More details regarding options and requirements for30 specifying measurement heights for ONSITE data processed through AERMET are provided in

Section 2.5.

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

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

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

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

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

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

• The Fortran I format specifier for integer constants consists of ‘I’ followed by the width of the data field, such that a format of ‘I4’ will read a 4

- character data string as
an i nteger number;

• A read error will be generated if a non

- numeric character (other than a leading ‘+’ or

‘

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

• The Fortran F format specifier for real constants consists of ‘ F’ followed by the width of the field and number of places after the decimal point (F w

. d ), such that a format of
‘F5.2’ will read a 5

- character data string, including the decimal, as a real number, with 2 places after the decimal point;

• Data being read as real constants using the ‘F’ format specifier are not required to include decimal places within the data string; however, users must be aware of the rules for assigning values using the F edit descriptor in such cases:

o If the data string includes a decimal place, then the value assigned to the REAL variable will reflect the number of decimal places specified; e.g., reading the string ’10.23’ as F5.2, F5.1, or F5.0 will all assign the value 10.23 to the variable.

o However, if the data string does not include a decimal point the number of decimal places assigned will be based on the F format specifier, such that reading the string ‘ b 1023’ (where ‘ b ’ represents a blank) as F5.2, F5.1, or F5.0 will assign the values 10.23, 102.3, and 1023. to the variable, respec tively.

• Data being read as REAL constants using the ‘FREE’ format option will reflect the values as specified in the data file, such that a string of ‘10.23’ will be assigned a value of 10.23, whereas a string of ‘1023’ will be assigned a value of 1023;

• R eading date variables as INTEGER constants using the ‘FREE’ format option will not result in a read error if a decimal (‘.’) occurs within the data field being read, but any data after the decimal point will be ignored, such that a data field of ‘4.8’ will be31 read as an INTEGER value of 4. However, any other non

- numeric character in the data field (other than a leading ‘+’ or ‘

- ‘) will result in a Fortran read error.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

format option or using ‘F w .0’ as the Fortran format specifier may avoid the issu e described

above.

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

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

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

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

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

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

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

code used by AERMET (shown in Table B

- 3). AERMET will process the “missing” value as

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

missing indicators that differ from the default using the RANGE keyword on the ONSITE32 pathway, and the QA audit statistics on values exceeding the upper and lower bounds may also

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

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

an amount larger than one half the range defined by UPPER

- LOWER, which may flag this issue

in some cases.

Not all of the variables present in the site

- specific data file need to be read. Any

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

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

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

the data file. Also, users should note that:

Λ the same format used to read the original site

- specific data file is also used to write

the QA output (QAOUT) file.

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

corresponding blank fields and/or blank lines.

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

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

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

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

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

runstream file and avoiding introducing errors on these two keywords.

2. 5 SPECIFYING ONSITE MEASUREMENT HEIGHTS

AERMET provides two options for specifying the measurement heights for the multi

level profile data input through the ONSITE pathway. One option is to explicitly specify the

measurement heights within the input data file, using the ‘HTnn’ variable on the READ33 ke yword, where ‘HT’ refers to the height variable and ‘nn’ refers to the level at which the

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

level, up to the highest level (see Table B

- 3). With this option the ‘HTnn’ variables would need

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

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

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

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

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

multi

- level dat a for that observation period will be set as missing.

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

specifying measurement heights for multi

- level profile data. The syntax and type for the

OSHEIGHTS keyword are as follo ws :

Syntax: OSHEIGHTS height1 height2

... heightn

Type: Optional if height information is provided in the data; otherwise mandatory (Stage 1), Repeatable, Reprocessed

The height1

, height2

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

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

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

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

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

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

be used to rectify the problem.

2 .6 SECONDARY SITE SURFACE CHARACTERISTICS

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

characteristics (primary and secondary) in the METPREP pathway of the Stage 3 control file34 when the SUBNWS option is specified and both ONSITE and SURFACE data are provided

(includ ing 1

- minute ASOS wind data). If either ONS ITE data or SURFACE data are omitted,

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

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

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

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

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

without the requi ring the user to copy

- and

- paste the results into the AERMET input file. The

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

Syntax: AERSURF primary_surfchar_filename

AERSURF2 secondary _surfchar_filename

Type: Optional, Non

- repeatable

where primary_surfchar_filename and secondary _surfchar_filename refer to the names of the

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

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

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

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

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

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

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

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

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

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

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

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

characteristics to the METPREP pathway:35   Primary**  **Surface Characteristics**

**FREQ_SECT frequency number_of_sectors SECTOR sector_index beginning_direction ending_direction** 
**SITE_CHAR frequency_index sector_index albedo Bowen roughness**

  Secondary Surface Characteristics** 

**FR EQ_SECT2 frequency number_of_sectors**  **SECTOR2 sector_index beginning_direction ending_direction**
**SITE_CHAR2 frequency_index sector_index albedo Bowen roughness**

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

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

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

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

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

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

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

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

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

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

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

characteristics is required. If both onsite data and NWS surface data (including 1

- minute ASOS)

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

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

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

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

NWS surface file or 1

- minute ASOS wind data file are substituted for missing or calm on site

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

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

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

values must be included to maintain consistency in the formats for reading the data.36 2. 7 REVISED SURFACE FILE FORMAT TO SUPPORT AERMOD DEPOSITION
ALGORITHMS

Beginning with version 06341, the AERMET program includes additional meteorological

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

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

humidity, surface pressure, and cloud cover. These additional variables are automatically

included after the standard variables for each hour, and do not require any additional user input.

The precipitation data needed for wet de position calculations in AERMOD can be obtained from

ONSITE data, or from SURFACE data in the SAMSON, HUSWO or ISHD (TD

- 3505) formats

currentl y supported by AERMET (EPA, 2004 ). A description of the revised surface file format

is provided below:

The AERME T Surface File

Header record:

READ( ) latitude, longitude, UA identifier, SF identifier, OS identifier, Version date

FORMAT (2(2X,A8), 8X,' UA_ID: ',A8, ' SF_ID: ',A8, ' OS_ID: ',A8, T85, 'VERSION:',

A6 )

where latitude = latitude specified in Stage 1 for primary surface station
longitude = longitude specified in Stage 1 for primary surface station
UA identifier = station identifier for upper air data; usually the WBAN
number used to extract the data from an archive data set
SF identifier = station identifier for hourly surface observations; usually
the WBAN number used in extracting the data
OS identifier = site

- specific identifier

Version date = AERMET version date; this date also appears in the banner on each page of the summary reports

Note that the ‘ ??_ID: ’ fields in the FORMAT statement above include two spaces before the 2

- character pathway ID and one space after the colon.37 Data records:

READ( ) year, month, day, j_day, hour, H, u * , w * , VPTG, Zic, Zim, L, z o , B o , r, W s , W d , z ref , temp, z temp , ipcode, pamt, rh, pres, ccvr , WSADJ

FORMAT (3(I2,1X), I3,1X, I2,1X, F6.1,1X, 3(F6. 3,1X), 2(F5.0,1X), F8.1,1X, F7.4 ,1X, 2(F6.2,1X), F7.2,1X, F5.0, 3(1X,F6.1), 1X,I 5, 1X,F6.2, 2(1X, F6.0), 1X, I5, 1X, A7 )

where j_day = Julian day

H = sensible heat flux (W/m 2 )

u * = surface friction velocity (m/s)

w * = convective velocity scale (m/s)

VPTG = vertical potential temperature gradient above Zic (K/m)

Zic = height of convectively

- generated boundary layer (m)

Zim = height of mechanic ally

- generated boundary layer (m)

L = Monin

- Obukhov length (m)

z 0 = surface roughness length (m)

B 0 = Bowen ratio

r = Albedo

W

s = reference wind speed (m/s)

W

d = reference wind direction (degrees)

z ref = reference height for wind (m)

temp = reference temperature (K)

z temp = reference height for temperature (m) ipcode = precipitation type code (0=none, 11=liquid, 22=frozen, 99=missing)

pamt = precipitation amount (mm/hr)

rh = relative humidity (percent)

pres = station pressure (mb)

ccvr = cloud cover (tenths)

WSADJ = wind speed adjustment and data source flag

2. 8 BETA OPTION FOR ADJUSTING USTAR UNDER LOW WIND/STABLE
CONDITIONS

Beginning with version 12345, the AERMET program includes a non

- Default BETA38 option in Stage 3 processing to adjust the surface friction velocity (u* or ustar) for low wind

speed stable conditions, based on Qian and Venkatram (2011). The option is selected by

including the METHOD STABLEBL ADJ_U* keyword on the METPREP pathway in th e Stage

3 input file. In addition, beginning with version 13350, AERMET has incorporated a new

ADJ_U* option for applications that utilize the Bulk Richardson Number (BULKRN) option for

estimating the stable boundary layer u* using low

- level temperature di fference (delta

- T) data

based on Luhar and Rayne r (2009)). The syntax of the ADJ_U* BETA option is as follows:

Syntax: METHOD STABLEBL ADJ_U*

Type: Optional, Non

- repeatable

The ADJ_U* "BETA" option is considered to be a non

- Default option and is therefore

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

Users should coordinate with the appropriate reviewing authority regarding the pro cedures and

requirements for approval of this BETA option for regulatory modeling applications. Although

AERMET does not include a regulatory default switch, u se of this option also requires the user

to include the BETA option on the CO MODELOPT k eyword i n the AERMOD input file.

2. 9 SUBSTITUTIONS FOR MISSING CLOUD COVER AND TEMPERATURE

Beginning with version 13350, the AERMET program includes substitutions for missing

cloud cover and temperature data based on linear interpolatio n across gaps of 1 or 2 hours.

Linear interpolation across short gaps is a reasonable approach for these variables since ambient

temperatures tend to follow a diurnal cycle and do not vary significantly from hour to hour, and

AERMOD is relatively insensiti ve to hourly fluctuations in cloud cover, especially during

convective hours since the heat flux is integrated across the day. Furthermore, g aps of 1 or 2

hours for these parameters near the early morning transition to a convective boundary layer may

resu lt in all convective hours for that day being missing.

The cloud cover and temperature substitutions are applied by default, unless the

application involves both NWS and ONSITE surface data. However, beginning with version39 14134, substitutions will be applied by default if the parameter is only available for one type of

data (NWS or ONSITE). For example, for cases with ONSITE data that includes temperature

data but no cloud cover data, the cloud cover substitutions will be applied to the NWS data by

de fault, but the temperature substitutions will not be applied unless the user specifies the TEMP

SUB_TT option on the METHOD keyword in Stage 3. O ptions have also been incorporated in

AERMET during Stage 3 that allow users to disable cloud cover and/or te mperature

substitutions, irrespective of the type(s) of data being processed . These Stage 3 options also

allow users to activate these substitutions for cases with both NWS and ONSITE data; however

this could result in substitutions based on interpolation between NWS and ONSITE values on

either side of the gap

. As noted above, t he substitutions are based on linear interpolation across gaps of 1 to 2

hours

. I nterpolations are only made based on non

- interpolated values on both sides of the data

gap. In ad dition, beginning with version 14134 substitutions for missing ONSITE temperature

data are only applied for values from the same measurement level, if mul t i

- level temperature

data are available. Valid data available for hours 23 and 24 of the previous day are used to

substitute for missing data for hours 1 and 2. However, since AERMET has not been modified

to read ahead to extract data for the next day, substitutions for missing data for hour 24 (and hour

23 if hour 24 is also missing) are based on persistence

. The options for users to disable or activate the cloud cover (CCVR) and temperature

(TEMP) substitutions are included under the METHOD keyword in Stage 3. Beginning with

version 14134 , AERMET also allows users to disable interpolations for hours 23 and 24 that are

based on persistence for CCVR, TEMP or both. The syntax of these option s is as follows:40 Syntax: METHOD CCVR SUB_CC (activates CCVR substitutions)

or
METHOD CCVR NO_SUB (disables CCVR substitutions)

or
METHOD CCVR NOPERS (disables CCVR substitutions for
hours 23 and 24 that are based on persistence)

--------------------------------------------------------------------------------- METHOD TEMP SUB_TT (activates TEMP substitutions)

or

METHOD TEMP NOTSUB (disables TEMP substitutions)

or
METHOD TEMP NOPERS (disables TEMP substitutions for
hours 23 and 24 that are based on persistence)

Type: Optional, Non

- repeatable (for a given option of CCVR of TEMP)41 3.0 REFERENCES

EPA, 1997 : Analysis o f t he Affect o f ASOS

- Derived Meteorological Data on R efined Modeling . EPA

- 4 54/R

- 97

- 014 . U.S. Environmental Protection Agency, Research Triangle Park, North Carolina 27711.

EPA, 2000. Meteorological Monitoring Guidance for Regulatory Modeling Applications. EPA

454/R

- 99

- 005. Office of Air Quality Planning & Standards, Research Triangle Park, NC. (PB 2001

- 103606)

EPA , 200 4 : User = s Guide for the AERMOD Meteorological Prepro cessor (AERMET ). EPA

454/ B

- 0 3

- 002 . U.S. Environmental Protection Agency, Research Triangle Park, North
Carolina 27711.

EPA , 200 8: AERSURFACE User’s Guide

. EPA

- 454/B

- 08

- 001 . U.S. Environmental Protection Agency, Research Triangle Park, North Carolina 27711.

EPA, 2010 : AERMINUTE User = s Instructions . EPA

- Draft . U.S. Environmental Protection Agency, Research Triangle Park, North Carolina 27711.

Luhar, A.K.

, and K. N. Rayne r, 2009 : “ Methods to Estimate Surface Fluxes of Momentum and Heat from Routine Weather Observations for Dispersion Applications under Stable
Stratification ”, Boundary

- Layer Meteorology

, 132

, 437

– 454.

NOAA, 2003: ASOS Product Improvement Implementat ion Plan (Addendum III) For Ice Free
Wind . National Oceanic and Atmospheric Administration, National Weather Service, Silver Spring, Maryland 20910. http://www.nws.noaa.gov/op s2/Surface/documents/IFW030515A.pdf

NOAA, 2008: Cup & Vane Wind Data Processing Within ASOS . National Oceanic and Atmospheric Administration, National Weather Service, Silver Spring, Maryland 20910. http://www.nws.noaa.gov/ops2/Surface/documents/IFWS_BelfordWS_comparison.pdf

Qian, W., and A. Venkatram, 2011: "Performance of Steady

- State Dispersion Models Under
Low Wind

- Speed Conditions", Boundary Layer Meteorology

, 138 , 475

- 491.

Venkatram, A., 1980: Estimating the Monin

- Obukhov length in the stable boundary layer for dispersi on calculations. Bound.Layer Meteor., 19, 481

- 485.A

- 1 APPENDIX A. FUNCTIONAL KEYWORD/PARAMETER REFERENCE

This appendix provides a functional reference for the keywords and parameters used

by the input runstream files for AERMET. The keywords are organized by functional

pathway and within each pathway the order of the keywords is alphabetical, excluding the

k eyword that identifies the start of a pathway . The pathways used by AERMET are as

follows, including the applicable AERMET processing stages and the in the order in which

they appear in the tables that follow:

JOB

- for specifying overall JOB control o ptions (all stages) ; UPPERAIR

- for processing NWS UPPER AIR data (Stages 1 and 2) ; SURFACE

- for processing NWS hourly SURFACE data (Stages 1 and 2) ; ONSITE

- for processing ONSITE meteorological data (Stages 1 and 2) ; MERGE

- to MERGE the three data types into one file , including
1

- minute ASOS wind data, if available (Stage 2) ; METPREP

- for MET eorological data PREP aration for use in a dispersion
Model (Stage 3)

.

Two types of tables are provided for each pathway. The first tab le lists all of the

keywords for that pathway, identifies each keyword as to its type (either mandatory or

optional, either repeatable or non

- repeatable, and if it is reprocessed), and provides a brief

description of the function of the keyword. The secon d type of table, which may take up

more than one page, describes each parameter in detail.

The following conventions are used in these tables. The parameter names are intended

to be descriptive of the input variable being represented. Square brackets ar ound a parameter

indicate that the parameter is optional for that keyword. The default that is used when an

optional parameter is left blank is explained in the discussion for that parameter.

Beginning with version 11059, the maximum record length for th e AERMET

runstream input file has been increased from 80 to 132 characters. Another important

enhancement introduced with version 11059 of AERMET, which applies across all pathways,

is that the maximum field length for filenames has been increased from 48 to 96 and the useA

- 2 of double quotes (“) as field delimiters for filenames is allowed to support filenames with

embedded spacesA

- 3 TABLE A

- 1

DESCRIPTION OF JOB PATHWAY KEYWORDS

Keyword Type Description

JOB Optional,
Non

- repeatable Start of JOB pathway

. This statement is optional if the statements associated with this block appear first in the input control file.

CHK_SYNTAX Optional, Non

repeatable Flag indicating that only the syntax of the input statements should be checked for errors, i.e., no data are processed.

MESSAGES Mandatory, Non

repeatable Identifies the warning/error messages file.

REPORT Optional, Non

repeatable Identifies the general report file.

TABLE A

- 2

DESCRIPTION OF KEYWORD PARAMETERS FOR THE JOB PATHWAY

Keyword Parameters

CHK_SYNTAX <none>

MESSAGES message_filename

where: message_filename The name of the file where all source

- code

- generated messages are
written

REPORT summary_filename

where: summary_filename The name of the file where AERMET writes a summary of all preprocessor activity for the current runA

- 4 TABLE A

- 3

DESCRIPTION OF UPPERAIR KEYWORDS

Keyword Type Description

UPPERAIR Mandatory,
Non

- repeatable Start of UPPERAIR pathway

.

AUDIT Optional, Repeatable Identify variables to be audited. These are in addition to any automatically audited variables.

DATA Mandatory, Non

- repeatable

, Reprocessed File name of raw upper air data.

EXTRACT Mandatory, Non

- repeatable File name of extracted upper air data.

LOCATION Mandatory, Non

- repeatable, Reprocessed Site ID and location information. Required only for extraction processing.

MODIFY Optional, Non

- repeatable, Reprocessed Flag indicating corrections should be made to the sounding data
when extracted. See ' 5 for a discussion of these corrections

NO_ MISSING Optional, Repeatable Identifies those variables to QA and summarize the messages only; detailed message identifying the violation and date is suppressed

QAOUT Mandatory, Non

- repeatable File name of upper air data for quality assessed output/ merge input

RANGE Optional, Repeatable, Reprocessed Set new upper and lower bounds and missing values for QA of
the variable listed.

XDATES Mandatory, Non

- repeatable Inclusive dates identifying the period of time to extract from the
archive data file.A

- 5 TABLE A

- 4

DESCRIPTION OF KEYWORD PARAMETERS FOR THE UPPERAIR PATHWAY

Keyword Parameter(s)

AUDIT uaname1 ... uanameN

where: uaname1 ... uanameN Name(s) of variables that are to be tracked and reported during quality assessment (as defined in Table B

- 1 of Appendix B).

DATA archive_filename file_format

where: archive_filename

file_format The name of the file containing the archive of upper air data

Archive file format; valid parameters are: 6201FB (TD

- 6201 fixed

- length blocks)

or 6201VB (TD

- 6201 variable

- length blocks)

or FSL for data retrieved from National Climatic Data Center (NCDC) web site. Also available on the ‘Radiosonde Data of
North America’ CD

- ROM.

NOTE: The blocking factor and data type (ASCII or EBCDIC) parameters are no longer supported by AERMET, beginning with version 11059. The default values for these parameters are 1 for blocking factor and ASCII for data type. AERMET will issue a warning messa ge if these parameters are included in on the DATA keyword.

EXTRACT extracted_data_filename

where: extracted_data_
filename Name of the output file for data extracted from an archive data file and the name of the input file for upper air data QAA

- 6 TABLE A

- 4, continued

DESCRIPTION OF KEYWORD PARAMETERS FOR THE UPPERAIR PATHWAY

Keyword Parameter(s)

LOCATION site_id lat(long) long(lat) [tadjust]

where: site_id

lat(long)

long(lat)

[tadjust] Site identifier for which data are to be processed.

Station latitude (or longitude) in decimal degrees with the suffix N for sites north of the equator, S for sites south of the equator (or W for sites west of Greenwich, E for sites east of Greenwich).

Station longitude (or latitude) in decimal degrees with the suffix W for sites west of Greenwich, E for sites east of Greenwich (or N for sites north of the equator, S for sites south of the equator).

An integer used to convert the time reported in the database to local
Standard time. For standard upper

- air data reported in Greenwich Mean Time (GMT), the value is the same as the time zone for the station (e.g., a value of 5 for the Eastern time zone).

NOTE: Beginning with version 11059, the optional station elevation parameter is no lon ger supported on the UPPERAIR pathway.

MODIFY <none>

NO_MISSING uaname1

. . . uanameN

where: uaname1 .

. .

. . . uanameN Suppresses missing data messages for the upper air variables specified, as defined in Appendix B; the number of time s the variable is missing
is not tallied

QAOUT q a_output_filename

where: qa_output_ filename Name of the output file from the QA/input to merge dataA

- 7 T ABLE A

- 4, continued

DESCRIPTION OF KEYWORD PARAMETERS FOR THE UPPERAIR PATHWAY

Keyword Parameter(s)

RANGE uaname lower_bound <[=] upper_bound missing_indicator

where: uaname

lower_bound

<[=]

upper_bound

missing_indicator Variable name, as defined in Table B

- 1

Minimum value of the valid range of values for uaname

Exclude (<) or include (<=) the lower and upper bounds (the endpoints) in the QA

Maximum value of the valid range of values for uaname

Value to indicate the value is missing

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

YB/MB/DB

[TO]

YE/ME/DE Beginning year, month and day to extract; the slash (/) between each part of the date field is required; there can be no blanks in this parameter

Optional; used to make this record more readable

Ending year, month and day to extract; the slash (/) between each part of the date field is required; the re can be no blanks in this parameterA

- 8 TABLE A

- 5

DESCRIPTION OF SURFACE PATHWAY KEYWORDS

Keyword Type Description

SURFACE Mandatory, Non

- repeatable Start of SURFACE pathway

.

ASOS1MIN Optional, Non

- repeatable File name for 1

- minute ASOS wind data to be merged in Stage 2

AUDIT Optional, Repeatable Identify variables to be audited. These are in addition to any automatically audited variable.

DATA Mandatory, Non

- repeatable

, Reprocessed Input file name of raw surface data.

EXTRACT Mandatory, Non

- repeatable File name of extracted surface data.

LOCATION Mandatory, Non

- repeatable, Reprocessed Site ID and location information.

NO_MISSING Optional, Repeatable Identifies those variables to QA and summarize the messages only; detailed message identifying the violation and date is suppressed.

QAOUT Mandatory, Non

- repeatable File name for hourly surface data for quality assessed output/merge input.

RANGE Optional, Repeatable, Reprocessed Set new upper and lower bounds and missing values for QA of
the variable listed.

XDATES Mandatory, Non

- repeatable Inclusive dates identifying the period of time to extract from the
archive data file.A

- 9 TABLE A

- 6

DESCRIPTION OF KEYWORD PARAMETERS FOR THE SURFACE PATHWAY

Keyword Parameter(s)

ASOS1MIN asos1min_filename

where: asos1min_filename Filename for hourly

- averaged wind speed and direction derived from
1

- minute ASOS wind data (TD

- 6405), to be merged in Stage 2

AUDIT sfname1 ... sfnameN

where: sfname1 ...
... sfnameN Name(s) of variables that are to be tracked and reported during quality assessment (as defined in Table B

- 2 of Appendix B).

DATA archive_filename file_format [ASOS]

where: archive_filename

file_format

[ASOS] The name of the file containing the archive of hourly surface observations

Archive file format; valid parameters are:
CD144

or SCRAM

or SAMSON (data retrieved from SAMSON CD

- ROM)

or 3280VB and 3280FB

or HUSWO (data retrieved from HUSWO CD

- ROM;
assumes metric units )

or ISHD (data in the full archival TD

- 3505 format)

Optional parameter to indicate that ISHD data are from an Automated Surface Observing System (ASOS) site. This para meter is only allowed with the ISHD file format, and instructs AERMET to apply the wind speed truncation adjustment to all hours (see Section 2.3.2). Beginning with version 11059, AERMET includes a table of ASOS commission dates, which is used to identify whether surface data input to AERMET are from an ASOS site. The optional ‘ASOS’ parameter for ISHD data should only be used if the data are known to be from an ASOS site which is not included in the ASOS
station list within AERMET.

NOTE: The blocking fa ctor and data type (ASCII or EBCDIC) parameters are no longer supported by AERMET, beginning with version 11059. The default values for these parameters are 1 for blocking factor and ASCII for data type. AERMET will issue a warning message if these param eters are included on the DATA keyword.A

- 10 TABLE A

- 6, continued

DESCRIPTION OF KEYWORD PARAMETERS FOR THE SURFACE PATHWAY

Keyword Parameter(s)

EXTRACT extracted_data_filename

where: extracted_data_
filename Name of the output file for data extracted from an archive data file

LOCATION site_id lat(long) long(lat) [tadjust] [elevation]

where: site_id

lat(long)

long(lat)

[tadjust]

[elevation] Site identifier for which data are to be processed.

Station latitude (or longitude) in decimal degrees with the suffix N for sites north of the equator, S for sites south of the equator (or W for sites west of Greenwich, E for sites east of Greenwich).

Station longitude (or latitude) in decimal d egrees with the suffix W for sites west of Greenwich, E for sites east of Greenwich (or N for sites north of the equator, S for sites south of the equator).

An integer used to convert the time reported in the database to local
Standard time. For most surf ace databases, the value is 0. For TD

- 3505 (ISHD) data, which is reported in GMT, the value is the same as the time zone for the station (e.g., a value of 5 for the Eastern time zone).

Station elevation (m above sea

- level) ; default of 0m if omitted.

NO_MISSING sf name1

. . . sf nameN

where: sf name1 .

. .

. . . sf nameN Suppresses missing data messages for the surface variables specified, as defined in Appendix B; the number of time s the variable is missing is
not tallied

QAOUT qa_output_filename

where: qa_output_filename Name of the output file from the QA/input to merge data

RANGE sfname lower_bound <[=] upper_bound missing_indicator

where: sfname

lower_bound

<[=]

upper_bound

missing_indicator Variable name, as defined in Table B

- 2

Minimum value of the valid range of values for sfname

Exclude (<) or include (<=) the lower and upper bounds in the QA

Maximum value of the valid range of values for sfname

Value to use to indicate the observed variable is missingA

- 11 TABLE A

- 6, continued

DESCRIPTION OF KEYWORD PARAMETERS FOR THE SURFACE PATHWAY

Keyword Parameter(s)

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

where: YB/MB/DB

[TO]

YE/ME/DE Beginning year, month and day to extract; the slash (/) between each part of the date field is required; there can be no blanks in this parameter

Optional; used to make this record more readable

Ending year, month and day to extract; the slash (/) between each part of the date field is required; there can be no blanks in this parameterA

- 12 TA BLE A

- 7

DESCRIPTION OF ONSITE PATHWAY KEYWORDS

Keyword Type Description

ONSITE Mandatory, Non

- repeatable Start of ONSITE pathway

.

AUDIT Optional, Repeatable Identify variables to be audited. These variables are in addition to any automatically audited variables.

DATA Mandatory, Non

- repeatable

, Reprocessed Input file name of site

- specific data.

DELTA_TEMP Optional, R epeatable, Reprocessed Define heights (meters) for temperature differences.

FORMAT Mandatory, Repeatable, Reprocessed FORTRAN format for reading one site

- specific data record.

LOCATION Mandatory, Non

- repeatable, Reprocessed Site ID and location information.

NO_MISSING Optional, R epeatable Identifies those variables to QA and summarize the messages only; detailed message identifying the violation and date is suppressed.

OBS/HOUR Optional * , Non

- repeatable Number of observations each hour.

* Mandatory only if the observations are more frequent than once per hour.

OSHEIGHTS Optional *

, R epeatable, Reprocessed Define heights of the site

- specific measurements.

* Mandatory if the heights are not defined in the data file.A

- 13 Table A

- 7, continued

DESCRIPTION OF ONSITE PATHWAY KEYWORDS

Keyword Type Description

QAOUT Mandatory, Non

- r epeatable File name of site

- specific data for quality assessment output/merge input

RANGE Optional, Repeatable, Reprocessed Set new upper and lower bounds and missing values for QA of
the variable listed.

READ Mandatory, Repeatable, Reprocessed Defines the name and order of variables as they appear in the
site

- specific DATA file.

THRESHOLD Mandatory, Non

- repeatable, Reprocessed Sets the minimum wind speed (meters/second) below which
the wind is treated as calm.

XDATES Optional, Non

- repeatable Inclusive dates for data processing.A

- 14 TABLE A

- 8

DESCRIPTION OF KEYWORD PARAMETERS FOR THE ONSITE PATHWAY

Keyword Parameter(s)

AUDIT osname1

. . . osnameN

where: osname1 .

. .

. . . osnameN Name(s) of variables, as defined in Table B

- 3 of Appendix B, that are to
be tracked during the quality assessment

DATA Filename

where: Filename The name of the file containing the ONSITE data

DELTA_TEMP index lower_height upper_height

where: index

lower_height

upper_height Index for the i th temperature difference measurement

Lower measurement height for the i th temperature difference

Upper measurement height for the i th temperature difference

FORMAT record_index Fortran_format

where: record_index

Fortran_format Specifies the record # in the ONSITE data to which the Fortran format
refers ; linked to record_index on corresponding READ keyword

The Fortran format used to read the ONSITE data record :
May be defined using a Fortran format specifier or as free

- formatted (also called list

- directed) data using the optional ‘FREE’ parameter (without quotes and not case

- sensitive). The Fortran format specifier must include open and close parentheses and must fit within the record length of the runstream image (up to 132 characters includ ing keyword and record index), and may include embedded spaces. Note that date variables are read as INTEGER format (Fortran ‘I’ format) and all other data variables are read as REAL format (Fortran ‘F’ or ‘E’ format). Using an ‘F’ or ‘E’ format specifier to read date variables or ‘I’ format specifier to read other data variables
will cause an AERMET runtime error. See Section 2.4 for a more detailed discussion of the READ and FORMAT keywords.A

- 15 TABLE A

- 8, continued

DESCRIPTION OF KEYWORD PARAMETERS FOR THE ONSITE PATHWAY

Keyword Parameter(s)

LOCATION site_id lat(long) long(lat) [tadjust] [elevation]

where: site_id

lat(long)

long(lat)

[tadjust]

[elevation] Site identifier for which data are to be processed.

Station latitude (or longitude) in decimal degrees with the suffix N for sites north of the equator, S for sites south of the equator (or W for sites west of Greenwich, E for sites east of Greenwich).

Station longitude (or latitude) in decimal degrees with the suffix W for si tes west of Greenwich, E for sites east of Greenwich (or N for sites north of the equator, S for sites south of the equator).

An integer used to convert the time reported in the database to local Standard time. For most onsite databases, the value is 0.

Station elevation (m above sea

- level) ; default of 0m if omitted.

NO_MISSING osname1

. . . osnameN

where: osname1 .

. . osnameN Suppresses missing data messages for the ONSITE variables specified, as defined in Appendix B; the number of time the variable is missing is not
tallied

OBS/HOUR n_obs

where: n_obs Number of time periods per hour the ONSITE data are reported; for example if the data are recorded every 15 minutes, then n_obs = 4. Maximum value is 12, corresponding with 5

- minute averages. If OBS/HOUR is not specified, AERMET will assume 1 observation per
hour.

OSHEIGHTS height1 ... heightN

where: height1

. . . heightN Heights of the ONSITE data measurements; can be used to specify heights if they are not in cluded in the data file . Must be in ascending order from lowest to highest height. If the OSHEIGHTS keyword is specified and
h eights are also defined in the data file, the OSHEIGHTS input will be used and values in the data file (HT01, HT02, etc.) will be ignored. See Section 2.5 for a more detailed discussion about specifying measurement heights.A

- 16 TABLE A

- 8, continued

DESCRIPTION OF KEYWORD PARAMETERS FOR THE ONSITE PATHWAY

Keyword Parameter(s)

QAOUT qa_output_filename

where: qa_output_ filename File name of the quality assessment output/merge input.

RANGE osname lower_bound <[=] upper_bound missing_indicator

where: osname

lower_bound

<[=]

upper_bound

missing_indicator Variable name, as defined in Table B

- 3.

Minimum value of the valid range of values for osname.

D etermines whether to include (<=) or exclude (< ) the lower and upper bounds in the range of acceptable values Exclude (<) or include (<=) the lower and upper bounds (the endpoints) in the QA

.

Maximum value of the valid range of values for osname.

Value to use to indicate the value is missing.

NOTE : Beginning with version 11059, AERMET allows the use of
REAL values for lower_bound , upper_bound, and missing_indicator.

READ record_index osname1

. . . osnameN

where: record_index

osname1 ...
osnameN L inks the list of variables named on this keyword statement to a Fortran format defined on a FORMAT keyword statement. While the corresponding Fortran format specifier must fit within a single record in the runstream input file (up to 132 characters total per record), multiple READ keywo rds can be used to list variables for a single read by repeating the same record_index.

Specifies the list and order of variables in the ONSITE data file that are to be read. See Appendix B for ONSITE variable names.

See Section 2.4 for a more detailed discussion of the READ and FORMAT keywords.A

- 17 TABLE A

- 8, continued

DESCRIPTION OF KEYWORD PARAMETERS FOR THE ONSITE PATHWAY

Keyword Parameter(s)

THRESHOLD threshold_wind_speed

where: threshold_ wind_speed Minimum valid wind speed for the ONSITE measurements; cannot exceed 1.0 ms

- 1

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

where: YB/MB/DB

[TO]

YE/ME/DE Beginning year, month and day to QA; the slash (/) between each part of the date field is required; there can be no blanks in this parameter.

Optional; used to make this record more readable.

Ending year, month and day to QA; the slash (/) between each part of the date field is required; there can be no blanks in this parameter.A

- 18 TABLE A

- 9

DESCRIPTION OF MERGE PATHWAY KEYWORDS

Keyword Type Description and Usage

MERGE Mandatory, Non

- repeatable Start of MERGE pathway

.

OUTPUT Mandatory, Non

- repeatable File identifier for merged data.

XDATES Optional, Non

- repeatable Inclusive dates for data processing. If omitted, the earliest date
found in the data is used as the beginning date and the ending date is 367 days later. However, AERMET can MERGE multi

- year data files if the XDATES keyword is specified.

TABLE A

- 10

DESCRIPTION OF KEYWORD PARAMETERS FOR THE MERGE PATHWAY

Keyword Parameter(s)

OUTPUT merged_data_filename

where: merged_data_filename Name of the output file from STAGE 2.

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

where: YB/MB/DB

[TO]

YE/ME/DE Beginning year, month and day to merge; the slash (/) between each part of the date field is required; there can be no blanks in this parameter.

Optional; used to make this record more readable.

Ending year, month and day to merge; the slash (/) between each part of the date field is required; there can be no blanks in this

par ameter.A

- 19 TABLE A

- 11

DESCRIPTION OF METPREP PATHWAY KEYWORDS

Keyword Type Description and Usage

METPREP Mandatory, Non

- repeatable Start of METPREP pathway

.

AERSURF Optional, Non

- repeatable Specify file name for primary surface characteristics, such as output file from AERSURFACE; contains FREQ_SECT, SECTOR, and SITE_CHAR keyword inputs.

AERSURF2 Optional, Non

- repeatable Specify file name for secondary surface characteristics, such as output file from AERSURFACE; inputs in the AERSURF2 file are interpreted as secondary site characteristics, and may contain FREQ_SECT2, SECTOR2, and SITE_CHAR2 keyword inputs, or FREQ_SECT, SECTOR, and SITE_CHAR keywords. This allows users to include data from an AERSURFACE output file as secondary site characteristics without having to edit the file to change the keywords.

DATA Mandatory, Repeatable Input filename of merged data.

FREQ_SECT Mandatory, Repeatable, Reprocessed Number of surface characteristics by wind direction sector and time period for the primary location . Must precede SECTOR and SITE_CHAR statements, and also must precede secondary site keywords, if provided.

FREQ_SECT 2 Conditiona l *

, Repeatable, Reprocessed Number of surface characteristics by wind direction sector and time period for the secondary location

.
* Must be specified if both ONSITE and NWS winds are included, and must precede SECTOR 2 and SITE_CHAR 2

statements

.

LOCATION If UPPERAIR data are available (with or without ONSITE mixing heights):

OBSOLETE

Beginning with AERMET version 13350, if ONSITE mixing heights are used
without UPPERAIR data:

Mandatory, Non

- repeatable The LOCATION keyword under the METPREP pathway in Stage 3 is no longer used by AERMET

, unless ONSITE mixing heights are used without any UPPERAIR data

.

For applications with UPPERAIR data, s unrise for CBL height calculations is based on the primary surface station location in Stage 1; either the ONSITE pathway, if available, or the SURFACE pathway. A warning message will be generated in
these cases if the LOCATION keyword is included under the METPREP pathway, and the METPREP inputs will be ignored.

For applications with only ONSITE mixing heights, without UPPERAIR data, the LOCATION keyword under the METPREP should be used to specify the conversion from GMT

to LST

.

METHOD Conditional *

, Repeatable Specify processing methodology used for a particular variable.

* whether or not this keyw ord is mandatory depends on the

processing to be perfo rmed and the types of data included in the merged databaseA

- 20 TABLE A

- 11 , continued

DESCRIPTION OF METPREP PATHWAY KEYWORDS

Keyword Type Description and Usage

MODEL Optional, Non

- repeatable Name of model for which data are processed. Default:
AERMOD

NWS_HGT Conditiona l * , Non

- repeatable NWS instrument height, in meters, for the specified variable.

* Mandatory if METHOD REFLEVEL SUBNWS is specified

SECTOR Mandatory, Repeatable, Reprocessed Defines a wind direction sector in degrees for the primary
location . See also FREQ_SECT and SITE_CHAR.

SECTOR 2 Conditional** , Repeatable, Reprocessed Defines a wind direction sector in degrees for the secondary
location . See also FREQ_SECT 2 and SITE_CHAR 2

.

SITE_CHAR Mandatory, Repeatable, Reprocessed Define the direction

- dependent surface characteristics of albedo, Bowen ratio, and surface roughness length (meters) for the primary location . See also FREQ_SECT and SECTOR.

SITE_CHAR 2 Conditional * * , Repeatable, Reprocessed Define the direction

- dependent surface characteristics of albedo, Bowen ratio, and surface roughness length (meters) for the secondary location . See also FREQ_SECT 2 and SECTOR 2

.

THRESH_1MIN Optional, Non

- repeatable Option to specify a wind speed threshold for winds derived from
1

- minute ASOS wind data processed through AERMINUTE.

UAWINDOW Optional, Non

- repeatable Specifies the time window to use for selecting upper air sounding.

XDATES Optional, Non

- repeatable Inclusive dates for data processing.

* * Surface characteristics for the secondary site (SECTOR2 and SITE_CHAR2) are required for applications with

ONSITE data and with the REFLEVEL SUBNWS option under the METHOD keyword to substitute for missing ONSITE wind data

.A

- 21 TABLE A

- 12

DESCRIPTION OF KEYWORD PARAMETERS FOR THE METPREP PATHWAY

Keyword Parameter(s)

AERSURF

AERSURF2 primary_surfchar_filenam (for primary surface data location)

secondary_surfchar_filenam (for optional secondary surface data location)

where: primary_surfchar_f
ilenam

secondary_surfchar _filenam The name of the file containing the surface characteristic inputs for the primary surface data location (FREQ_SECT, SECTOR, and SITE_CHAR keywords)

The name of the file containing the surface characteristic inputs for the secondary surface data location ( FREQ_SECT2, SECTOR2, and SITE_CHAR2 keywords)

DATA merged_data_filename

where: merged_data_ _filename The name of the file containing the merged NWS and, if any, site

- specific
data

FREQ_SECT

FREQ_SECT2 frequency number_of_sectors (for primary surface data location)

frequency number_of_sectors (for optional secondary surface data location)

where: frequency

number_of_

sectors Specifies how often the surface characteristics change; valid parameters

are:

MONTHLY

- every calendar month

SEASONAL

- where the seasons are defined as: Spring = March, April, May Summer = June, July, August Autumn = September, October, November Winter = December, January, February

ANNUAL

- constant for the entire year

Specifies the number of wind direction sectors by which the surface characteristics varyA

- 22 TABL E A

- 12, continued

DESCRIPTION OF KEYWORD PARAMETERS FOR THE METPREP PATHWAY

Keyword Parameter(s)

LOCATION site_id lat(long) long(lat) [tadjust] [elevation]

where: site_id

lat(long)

long(lat)

[tadjust]

[elevation] Site identifier for which data are to be processed.

Station latitude (or longitude) in decimal degrees with the suffix N for sites north of the equator, S for sites south of the equator (or W for sites west of Greenwich, E for sites east of Greenwich).

Station longitude (o r latitude) in decimal degrees with the suffix W for sites west of Greenwich, E for sites east of Greenwich (or N for sites north of the equator, S for sites south of the equator).

An integer used to convert the time reported in the database to local Standard time. For standard upper

- air data reported in Greenwich Mean Time (GMT), the value is the same as the time zone for the station (e.g., a value of 5 for the Eastern time zone).

Station elevation (m above sea

- level); default of 100m if omitted.
Not e: The optional station elevation on the UPPERAIR pathway is currently not used by AERMET.

NOTE : The LOCATION keyword under the METPREP pathway is obsolete for applications that include UPPERAIR data

, and inputs will be ignored ; however, applications that use only ONSITE mixing heights, without UPPERAIR data, should still use the LOCATION keyword under the METPREP pathway to specify the conversion from GMT to LST

.A

- 23 METHOD atmos_variable option

where: atmos_variable

option Identifies the variable that will be processed :

UASELECT

– selecting upper air sounding.
WIND_DIR

– process ing of NWS wind directions.

REFLEVEL

– substitution of NWS data

STABLEBL

– specify option for SBL processing
ASOS_ADJ

– adjustment of ASOS wind speeds for truncation

CCVR

– option to substitute for missing cloud cover

TEMP

– option to substitute for missing temperature

Processing options:

For UASELECT , valid parameters are: SUNRIS(E)

– select upper air sounding based on local sunrise

For WIND_DIR ( not applicable to 1

- min ASOS data) , valid parameters are:

NORAND

– leave NWS wind directions to the nearest 10 o (default)

or RANDOM

– randomize NWS wind directions.

For REFLEVEL , valid parameters are:

SUBNWS

– allows substitution of NWS data for missing ONSITE wind and/or temp data (other parameters automatically substituted);
NOTE : this option must be used if no ONSITE data are provided.

For STABLEBL , valid parameters are:

BULKRN

– Bulk Richardson N umber

- This option requires on site measurements of temperature difference.
ADJ_U*

– Non

- Default/BETA option to adjust U* (surface friction velocity) for low wind/stable conditions. For applications without the BULKRN option, the ADJ_U* option is based on Qian and Venkatram (2011). For applications with the BULKRN option, the ADJ_U* option is based on Luhar and Rayner ( 2009 ).

For ASOS_ADJ , valid parameters are: NO_ADJ

– do not adjust ASOS wind speeds for truncation

.

For CCVR , valid parameters are:
SUB_CC

– s elect option to substitute for missing cloud cover
NO_SUB

– disable option to substitute for missing cloud cove r NOPERS

– disable sub s for hrs 23 and 24 based on persistence

For TEMP , valid parameters are:
SUB_TT

– select option to substitute for missing temperature

NO T SUB

– disable option to substitute for missing temperature ( NO_SUB can also be used for TEMP )

NOPERS

– disable sub s for hrs 23 and 24 based on persistence

NOTE: The CCVR and TEMP substitutions are used by default, unless the application involves both NWS and ONSITE surface data

, or only ONSITE
data with NRAD or with INSO data and the BULKRN option

. S ubstitutions
can be disabled

, and can also be activated for cases with both NWS and
ONSITE data by specifying the appropriate parameters. S ubstitutions are based on linear interpola tion across gaps of 1 to 2 hours, unless the missing
data are for hours 23 or 24

, where persistence is assumed. Interpolations are only made based on non

- interpolated v alues on both sides of the data gap.A

- 24 TABLE A

- 12, continued

DESCRIPTION OF KEYWORD PARAMETERS FOR THE METPREP PATHWAY

Keyword Parameter(s)

MODEL model_name

where: model_name Name of the dispersion model which uses the output files generated by AERMET. Allowable names are:

AERMOD

NWS_HGT variable_name instrument_height

where: variable_name

instrument_height Weather variable that requires an instrument height to be defined;
valid names are:

WIND (to specify anemometer height)

Height of the instrument above ground , in meters.

OUTPUT parameter_filename

where: parameter_ filename Name of the output file from STAGE 3, with one record per hour

PROFILE profile_filename

where: profile_name Name of the output file containing multi

- level onsite data , or single level wind and temperature data from NWS site

SECTOR

SECTOR2 sector_index beginning_direction ending_direction (for primary data location)

sector_index beginning_direction ending_direction ( for optional secondary data location)

where: sector_index

beginning_

direction

ending_direction Index that links a specific set of site characteristics to a specific wind

sector.

Specifies the beginning wind direction of the sector, and is considered a part of this sector.

Specifies the ending wind direction of the sector, and is NOT considered a part of the sector

NOTE: T he end of one sector must be the same as the beginning of
the next sector.A

- 25 TABLE A

- 12, continued

DESCRIPTION OF KEYWORD PARAMETERS FOR THE METPREP PATHWAY

Keyword Parameter(s)

SITE_CHAR

SITE_CHAR2 frequency_index sector_index albedo Bowen roughness (for primary data location)

frequency_index sector_index albedo Bowen roughness (for secondary data location)

where: frequency_index

sector_index

albedo

Bowen

roughness Index of the time period for which the surface characteristics apply;

for ANNUAL on FREQ_SECT keyword, valid values: 1 (for the entire year)

for MONTHLY on FREQ_SECT keyword, valid values: 1 ... 12 (corresponding to each month of the year)

for SEASONAL on FREQ_SECT keyword, valid values: 1 = Winter = December, January, February 2 = Spring = March, April, May
3 = Summer = June, July, August 4 = Autumn = September, October, November

Sector corresponding to direction from which the wind is blowing.

Albedo for the frequency index and sector index specified.

Bowen ratio for the frequency index and sector index specifie d.

Surface roughness for the frequency index and sector index specified.

THRESH_1MIN threshold_speed

where: threshold_speed T hreshold wind speed in m/s for wind speeds derived from 1

- minute ASOS wind data processed through the AERMINUTE program

. If the user specifies a threshold speed greater than 0.5 m/s, a warning is issued by AERMET. If a threshold wind speed greater than 1.0 m/s is specified, AERMET considers this a fatal error, will issue an error message and will not process data through Stage 3.

UAWINDOW window_begin window_end

where: window_begin

window_end Beginning of the sounding window, entered as the number of hours relative to the preferred sounding time (12Z, 00Z or

- 12Z for the default selection; or local sunrise for the UASELECT SUNRIS option)

Ending of the sounding window entered as the number of hours relative to the preferred sounding time

NOTE: A negative number indicates the number of hours before the reference sounding (or sunrise) , and a positive number indicates the number of hours after the sounding (or sunrise)

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

- 26 where: YB/MB/DB

[TO]

YE/ME/DE Beginning year , month and day to process; a slash (/) between each part of the date field is required; with no blanks

Optional; used to make this record more readable

Ending year, month and day to process; a slash (/) between each part of the date field is required; with no blanksB

- 1 APPENDIX B

. VARIABLE NAMES AND DEFAULT QA VALUES

This appendix lists the variable names for each type of data and provides a short

description of and the units for each variable, and gives the default bounds and missing value

codes. This information is presented in the tables (Tables B

- 1, B

- 2, B

- 3a, and B

- 3b) that

follow, with each table divided into the following fields:

Variable Name

This is the four

- character name that can be used on RANGE, AUDIT, and READ statements. An asterisk (*) indicates that the variable is automatically included in the QA for the path and need not be specified on an AUDIT record in the control file.

Description and Units

A brief description of each variable and the units follow the name. For UPPERAIR and SURFACE, real variables are stored as integers, in which case the units include a multiplier, such as *10 or *100, in order to maintain additional significant digits. For example, if the units are ° C*10, then 1.5 ° C is stored and referenced as 15.

Type of Check

The ty pe of check determines whether to include (<=) or exclude (<) the lower and upper bounds in the range of acceptable values, and can be changed on a RANGE

statement for specific variables

.

Missing Value Code

The missing value code is the value that AERMET interprets to mean that a value is not present. It is also the value written/stored by AERMET when the variable is not present
or cannot be calculated.

Bounds

The last two fields are the lower and upper bounds that determine the interval of acceptable va lues. The value of the variable is accepted if it lies within this interval, where the endpoints are either included or excluded according to the Type of Check. Note that the multiplier, if present, must also be applied to these values.B

- 2 TABLE B

- 1

VARIA BLE AND QA DEFAULTS FOR THE UPPERAIR VARIABLES

**Variable**

**Name Description**  **Units Type**  ***** **Missing**
**Indicator Lower** 
**Bound Upper** 
**Bound**

UAPR Atmospheric pressure millibars *10 < 99999 5000 10999

UAHT Height above ground meters <= 99999 0 5000

UATT Dry bulb temperature oC *10 < 9990 350 +350

UATD Dew point temperature oC *10 < 9990 350 +350

UAWD Wind direction degrees from north <= 999 0 360

UAWS Wind speed meters/second *10 < 9990 0 500

UASS Wind speed shear (m/s)/(100 meters) <= 9999 0 5

UADS Wind direction shear degrees/(100 meters) <= 9999 0 90

UALR Temperature lapse rate oC /(100 meters) <= 9999 2 5

UADD Dew point deviation oC /(100 meters) <= 9999 0 2

* Type determines whether to include (<=) or exclude (<) the lower and upper bounds in the range of acceptable values, and can be changed on a RANGE statement.B

- 3 TABLE B

- 2

VARIABLE AND QA DEFAULTS FOR THE SURFACE VARIABLES

**Variable**

**Name Description**  **Units Type**  **Missing**
**Indicat or**  **Lower**
**Bound Upper** 
**Bound**

PRCP Precipitation amount millimete rs*100 <=

- 9 0 25400

SLVP † Sea level pressure millibars *10 < 99999 9000 10999

PRES Station pressure m illibars*10 < 99999 9000 10999

CLHT Ceiling height k ilometers*10 <= 999 0 300

TSKC Total//opaque sky cover tenths//tenths <= 9999 0 1010

ALC1 a Sky cond//height, level 1 code//hundredths ft <= 09999 0 07300

ALC2 a Sky cond//height, level 2 code//hundredths ft <= 09999 0 07300

ALC3 a Sky cond//height, level 3 code//hundredths ft <= 09999 0 07300

ALC4 b Sky cond//height, level 4 code//hundredths ft <= 09999 0 07850

ALC5 b Sky cond//height, level 5 code//hundredths ft <= 09999 0 07850

ALC6 b Sky cond//height, level 6 code//hundredths ft <= 09999 0 07850

PWVC Present weather (vicinity) <= 9999 0 9800

PWTH Precipitation type <= 9999 0 9800

ASKY c ASOS Sky condition tenths <= 99 0 10

ACHT d ASOS Ceiling kilometers *10 <= 999 0 888

HZVS Horizontal visibility kilometers*10 <= 99999 0 1640

TMPD * Dry bulb temperature oC *10 < 999

- 300 360

TMPW Wet bulb temperature o C*10 < 999

- 650 350

DPTP Dew

- point temperature o C*10 < 999

- 650 350

RHUM Relative humidity whole percent <= 999 0 100

WDIR * Wind direction tens of degrees <= 999 0 36

WSPD * Wind speed meters/second *10 <= 999 0 500

* Automatically included in audit report.

† A value < 800 in CD144 files is converted to SLVP/10.0 + 1000.0
// The two variables have been combined to form one variable; the missing value flags, as well as the upper and lower bounds have also been concatenated.

a ASOS sky condition (code table) and height (hundredths of feet) for levels 1

- 3

b ASOS sky condition (code table) and height (hundredths of feet) for levels 4

- 6 (for augmented sites)

c ASOS sky condition (tenths), derived from layer data

.

d ASOS ceiling (kilometers *10), derived from layer data.B

- 4 TABLE B

- 3a

VARIABLE AND QA DEFAULTS FOR THE ONSITE ( SITE

- SPECIFIC )
SINGLE

- VALUE AND DATE/TIME VARIABLES

**Variable**

**Name Description**  **Units Type**  ***** **Missing**
**Indicator Lower** 
**Bound Upper** 
**Bound**

HFLX Surface heat flux watts/square meter <

- 999

- 100 800

USTR Surface friction velocity meters/second <

- 9 0 2

MHGT Mixing height meters < 9999 0 4000

ZOHT Surface roughness length meters < 999 0 2

SAMT Snow amount centimeters <= 999 0 250

PAMT Precipitation amount centimeters <= 999 0 25

I NSO Insolation watts/square meter < = 9999 0 1250

NRAD Net radiation watts/square meter < 999

- 100 800

DT01 Temperature diff.(U

- L)1 °C < 9

- 2 5

DT02 Temperature diff.(U

- L)1 °C < 9

- 2 5

DT03 Temperature diff.(U

- L)1 °C < 9

- 2 5

US01 User's scalar #1 user's units < 999 0 100

US02 User's scalar #2 user's units < 999 0 100

US03 User's scalar #3 user's units < 999 0 100

PRCP Precipitation millimeters *100 <=

- 9 0 25400

SLVP Sea level pressure millibars*10 < 99999 9000 10999

PRES Station pressure millibars*10 < 99999 9000 10999

CLHT Ceiling height kilometers*10 <= 999 0 300

TSKC Sky cover (total or opaque) tenths <= 99 0 10

OSDY Day <=

- 9 1 31

OSMO Month <=

- 9 1 12

OSYR Year <=

- 9 0 99

OSHR Hour <=

- 9 0 24

OSMN Minutes <=

- 9 0 60

1 (U

- L) indicates (upper level)

- (lower level).

* Type determines whether to include (<=) or exclude (<) the lower and upper bounds in the range of acceptable values, and can be changed on a RANGE statement.

Note: Shaded parameters are not currently used in AERMET.B

- 5 TABLE B

- 3b

VARIABLE AND QA DEFAULTS FOR THE ONSITE ( SITE

- SPECIFIC )
MULTI

- LEVEL VARIABLES

**Variable**

**Name Description**  **Units Type**  **Missing**
**Indicator Lower** 
**Bound Upper** 
**Bound**

HTnn Height meters < 9999 0 4000

SAnn Std. dev. horizontal wind degrees < 99 0 35

SEnn Std. dev. vertical wind degrees < 99 0 25

SVnn Std. dev. v

- comp. of wind meters/second < 99 0 3

SWnn Std. dev. w

- comp. of wind meters/second < 99 0 3

SUnn Std. dev. u

- comp. of wind meters/second < 99 0 3

TTnn* Temperature °C < 99

- 30 40

WDnn* Wind direction degrees from north <= 999 0 360

WSnn* Wind speed meters/second < = 99 0 50

VVnn Vertical wind component meters/second < 999 0 5

DPnn Dew

- point temperature °C < 99

- 65 35

RHnn Relative humidity whole percent <= 999 0 100

V1nn User's vector #1 user's units < 999 0 100

V2nn User's vector #2 user's units < 999 0 100

V3nn User's vector #3 user's units < 999 0 100

‘ nn ’ in variables HT to V3 refers to the level at which the observation was taken; e.g., TT01 is the temperature at the first level and WS02 is wind speed at

the second level.

* Automatically included in audit report.

Note: Shaded parameters are not currently used in AERMET.C

- 1 APPENDIX C. DATA FILE FORMATS

This appendix describes the format of the data files created by AERMET. This includes

the EXTRACT and QA files of NWS upper air and surface data, the merged file, and the

OUTPUT and PROFILE files that will be input to AERMOD. It does not describe the QA file

for site

- specific data since this file is written with the same user

- specified format used to read

the original site

- specific file.

The format of the files is given in terms of the FORTRAN READ statements that must

be used to input the data for each observation. Variable names shown in capital letters

correspond to those given in Appendix B. Variable names shown in lower case italics are

"local" variables that do not correspond to any in Appendix B.

C.1 UPPER AIR SOUNDINGS

Each upper air sounding in both the EXTRACT and QA files is composed of two parts:

(1) an identifying header record consisting of the year, month, day, hour, and the numbe r of

sounding levels; and (2) a sounding record composed of pressure, height above ground level,

temperature, dew

- point temperature, wind speed, and wind direction, which is repeated for each

level.

Upper air header record:

READ( ) year, month, day, hour, # levels

FORMAT (1X, 4I2, I5)

where hour is expressed in local standard time (LST) and # levels is the number of levels in this

sounding. If no soundings were extracted or there are no levels to the data, then # levels is

zero.C

- 2 Upper air soundi ng level data (if # levels > 0), repeated # levels times.

READ( ) UAPR, UAHT, UATT, UATD, UAWD, UAWS

FORMAT (6(1X,I6))

where UAPR = atmospheric pressure (millibars), multiplied by 10

UAHT = height above ground level (meters)

UATT = dry bulb temperature ( ° C), multiplied by 10

UAWD = wind direction (degrees from north)

UAWS = wind speed (meters/second), multiplied by 10

All values on the upper air pathway are written as integers. Several of the values were multiplied

by 10, as noted above, to retain one significant digit after the decimal point prior to rounding the

result to the nearest whole number. The values are divided by 10 prior to any usage in Stage 3.

C.2 SURFACE OBSERVATIONS

Each hourly surface observation in both the EXTRACT and QA files is written as two

records. As with the upper air data, all values are reported as integers with several variables

multiplied by 10 or 100 to retain significant digits. Several of the variables are two variables

combined and stored as one integer value. These are recognized by the // in the variable name

and units below.

The first record of a surface observation is written as follows:

READ( ) year, month, day, hour , PRCP, SLVP, PRES, CLHT, TSKC,

C2C3, CLC1, CLC2, CLC3, CLC4

FORMAT (1X, 4I2, 4(1X,I5), 6(1X,I5.5))

where hour = hour in LSTC

- 3 PRCP = precipitation amount (millimeters), multiplied by 1000

SLVP = sea level pressure (millibars), multiplied by 10

PRES = station pressure (mi llibars), multiplied by 10

CLHT = cloud ceiling height (kilometers), multiplied by 10

TSKC = sk y cover, total//opaque (tenths// tenths)

C2C3 = sky cover, 2//3 layers (tenths// tenths)

CLC n = sky condition// coverage, layer n = 1,2,3,4 (

- - // tenths)

The second record of a surface observation is written as follows:

READ( ) CLT1, CLT2, CLT3 , CLT4, PWTH, HZVS, TMPD, TMPW,

DPTP, RHUM, WDIR, WSPD , ASOSFLG

FORMAT (8X, 5(1X,I5.5), 7(1X,I5) ,2X,A1 )

where CLT n = cloud type//height, n =1,2,3,4 (

- - //kilometers), multiplied by 10

PWTH = present weather, liquid//frozen (no units, see codes below)

HZVS = horizontal visibility (kilometers), multiplied by 10

TMPD = dry bulb temperature ( ° C), multiplied by 10

TMPW = wet bulb temperature ( ° C), multiplied by 10

DPTP = dew

- point temperature ( °C) , multiplied by 10

RHUM = relative humidity (percent)

WDIR = wind direction (tens of degrees from north)

WSPD = wind speed (meters/second), multiplied by 10

ASOSFLG = flag indicating whether observ ation is ASOS (‘A’) or

non

- ASOS (‘N’)

All reports of sky conditions (CLC n ), cloud types or obscuring phenomena (CLT n ) and

present weather (PWTH) are stored using the TD

- 3280 numeric codes. This requires converting

the appropriate variables in the CD

- 144 formatted file as a part of the extraction process. Since

SCRAM uses the same convention, this discussion applies to that format as well. The following

tables relate the TD

- 3280 codes to the CD

- 144 codes. Overpunch characters in the tables belowC

- 4 fo r the CD

- 144 formats are represented by an ASCII character, which also appears in the data

file. An “ n.e. ” indicates that there is “ no equivalent ” in the CD

- 144 format. Only weather

producing liquid and/or frozen precipitation are reported in the PWTH va riable.C

- 5 TABLE C

- 1

SKY CONDITIONS

TD

- 3280 CD

- 144 Description of Sky Conditions

00
01
02
03
04
05
06
07
08
09 0
1
2
4
5
7
8
X or

- Blank clear or less than 0.1 coverage thin scattered 0.1 to 0.5 coverage scattered 0.1 to 0.5 coverage thin broken 0.6 to 0.9 coverage broken 0.6 to 0.9 coverage thin overcast 1.0 coverage overcast 1.0 coverage obscuration 1.0 coverage partial obscuration <1.0 coverage
unknown

TABLE C

- 2

CLOUD TYPES

TD

- 3280 CD

- 144 Description of Cloud Types

00
11
12
13
14
15
16
17
18
19
21
22
23
24
28
29
32
35
37
39 0
4

n.e.

K

n.e.

3
2
M
5
N
6
O
7

n.e.

P

n.e

8

n.e.

9
R none cumulus towering cumulus
stratus fractus
stratus cumulus lenticular
stratus cumulus

stratus cumulus fractus
cumulonimbus
cumulonimbus mammatus
altostratus
nimbostratus
altocumulus
altocumulus lenticular
altocumulus castellanus
altocumulus mammatus
cirrus
cirrocumulus lenticular
cirrostratus
cirrocumulus

TABLE C

- 3C

- 6 OBSCURING PHENOMENA

TD

- 3280 CD

- 144 (cols. 30, 31) Description of Obscuring Phenomena

01
03
04
05
06
07
30
36
44
45
48
50
60
70
76
98 6
3
1
2
4
4
5
5
3
1
2

n.e.

n.e.

n.e.

n.e. X or

- blowing spray
smoke and haze
smoke
haze
dust blowing dust blowing sand blowing snow ground fog fog ice fog
drizzle
rain

snow ice crystals obscuring phenomena other than fog (prior to 1984)

The code definitions for present weather conditions (PWTH) are presented below. They

are divided into nine general categories that are subdivided into specific weather conditions.

Dashes in a field indicate that there is no definition for that code. The 8

- digit CD

- 144 format for

weather conditions is converted to the 2

- digit TD

- 3280 categories. Up to two different types of

weather may be stored in the PWTH variable in AERMET; howe ver, only weather producing

liquid (codes 20

- 39) and/or frozen (codes 40

- 69) precipitation are retained in the PWTH variable

as liquid//frozen precipitation. The SAMSON codes for present weather are identical to the

TD

- 3280 codes.C

- 7 TABLE C

- 4

PRESENT WEAT HER

TD

- 3280 CD

- 144 (col. 24) Thunderstorm, Tornado, Squall

10
11

12
13
14
15
16
17
18
19 1
2

3
5

n.e.

n.e.

n.e.

n.e.

n.e.

n.e. thunderstorm

- lightning and thunder
severe thunderstorm

- frequent intense lightning and thunder report of tornado or water spout light squall moderate squall heavy squall
water spout funnel cloud
tornado
unknown

TD

- 3280 CD

- 144 (col. 25) Rain, Rain Shower, Freezing Rain

20
21
22
23
24
25
26
27
28
29 1
2
3
4
5

6
7
8
9

n.e. light rain
moderate rain heavy rain light rain showers
moderate rain showers heavy rain showers light freezing rain moderate freezing rain heavy freezing rain
unknown

TD

- 3280 CD

- 144 (col. 26) Rain Squall, Drizzle, Freezing Drizzle

30
31
32
33
34
35
36
37
38
39 n.e.

n.e.

n.e

4
5
6
7
8
9

n.e. light rain squalls moderate rain squalls heavy rain squalls light drizzle
moderate drizzle heavy drizzle light freezing drizzle moderate freezing drizzle heavy freezing drizzle
unknownC

- 8 TABLE C

- 4, continued

PRESENT WEATHER

TD

- 3280 CD

- 144 (col. 27) Snow, Snow Pellets, Ice Crystals

40
41
42
43
44
45
46
47
48
49 1
2
3
4
5

6

n.e.

8

n.e.

n.e. light snow
moderate snow heavy snow light snow pellets moderate snow pellets heavy snow pellets light snow crystals moderate snow crystals heavy snow crystals
unknown

TD

- 3280 CD

- 144 (col 28) Snow Shower, Snow Squalls, Snow Grains

50
51
52
53
54
55
56
57
58
59 1
2
3

n.e.

n.e.

n.e.

7
8
9

n.e. light snow showers
moderate snow showers heavy snow showers light snow squalls moderate snow squalls heavy snow squalls light snow grains moderate snow grains heavy snow grains
unknown

TD

- 3280 CD

- 144 (col. 29) Sleet, Sleet Shower, Hail

60
61
62
63
64
65
66
67
68
69 n.e.

n.e.

n.e.

n.e.

5

n.e.

8

n.e.

n.e.

n.e. light ice pellet showers moderate ice pellet showers heavy ice pellet showers light hail
moderate hail heavy hail light small hail
moderate small hail heavy small hail
unknownC

- 9 TABLE C

- 4, continued

PRESENT WEATHER

TD

- 3280 CD

- 144 (col. 30) Fog, Blowing Dust, Blowing Sand

70
71
72
73
74
75
76
77
78
79 1
2
3
4
5

n.e.

n.e.

n.e.

n.e.

n.e. fog ice fog ground fog blowing dust blowing sand heavy fog glaze heavy ice fog heavy ground fog
unknown

TD

- 3280 CD

- 144 (col. 31) Smoke, Haze, Blowing Snow, Blowing Spray, Dust

80
81
82
83
84
85
86
87
88
89 1
2
3
4
5

6

n.e.

n.e. smoke
haze
smoke and haze
dust blowing snow blowing spray
dust storm

- -

- - unknown

TD

- 3280 CD

- 144 (col. 29) Ice Pellets, Hail Showers, Small Hail/Snow Pellet Showers, Fog

90
91
92
93
94
95
96
97
98
99 1
2
3

n.e. light ice pellets moderate ice pellets heavy ice pellets hail showers (begins July 1996)
small hail/ sn ow pellet showers (begins7/ 96) partial fog (begins 7/ 96) patches fog (begins 7/ 96) low drifting snow (begins 7/ 96)

- - unknownC

- 10 C.3 MERGE OUTPUT

The merged data file contains a block of records that are the cumulative header records of

all input files to Stage 2. These records are followed by blocks of records for each day of

observations. Each block of records contains a header record identifying how many records

there are in the block for each of the three types of data present. Each block is subdivided into

three blocks of records, where each sub

- block contains all of the observations for that day for a

particular type of data.

The records within a block are written with an 8(I8,1X) format, except for the multi

- level

site

- specific records that are written with a 6(F14.6,1X) format. The 22 NWS surface variables,

plus the date and time, for each hour are split across four records. Al so, if there are more than

eight single

- level or six multi

- level variables on a particular READ statement, then these records

will also be divided across more than one record.

Daily Master Header Record

READ( ) year, month, day, j_day, n_ua, n_sfc, n_os

FORMAT (7(I8,1X))

where j_day = the Julian date for year/month/day

.

n_ua = number of NWS upper air observations.

n_sf c = number of NWS surface observations.

n_os = number of site

- specific observations.

Upper Air Records

Upper air data are stored in th e same order as in upper air extract/QA files (see D.1).

Surface RecordsC

- 11 For each hour, there is a header record with the year, month, day and hour followed by

three data records. The 22 variables are written in the same order as shown in D.2, with a

ma ximum of 8 variables per record.

Site

- specific Records

Single

- level Variables

These are written in the same order and on multiple records just as they were given on the

READ statements, but using an 8(I8,1x) format instead of that given on the corresponding

FORMAT statements.

Multi

- level Variables

Like the single

- level variables, these are also written in the same order and on multiple

records just as they were given on the READ statements, but using a 6(F14.6,1x) format.

C.4 AERMOD FILES

Two files are produced for input to the AERMOD dispersion model. The surface

OUTPUT contains observed and calculated surface variable, one record per hour. The PROFILE

file contains the obse rvations made at each level of a site

- specific tower, or the one level

observations taken from NWS data, one record per level per hour. The contents of these files

can also be written to the general report by including a LIST statement in the METPREP block.C

- 12 SURFACE OUTPUT

Header record :

READ( ) latitude, longitude, UA identifier, SF identifier, OS identifier, Version date

FORMAT (2(2X,A8), 8X,' UA_ID: ',A8, ' SF_ID: ',A8, ' OS_ID: ',A8, T85, 'VERSION:', A6 )

where latitude = latitude specified in Stage 1 for primary surface st ation
longitude = longitude specified in Stage 1 for primary surface station
UA identifier = station identifier for upper air data; usually the WBAN
number used to extract the data from an archive data set
SF identifier = station identifier for hourly surface observations; usually
the WBAN number used in extracting the data
OS identifier = site

- specific identifier

Version date = AERMET version date; this date also appears in the banner on each page of the summary reports

Note that the ‘ ??_ID: ’ fields in the FORMAT statement above include two spaces before the 2

- character pathway ID and one space after the colon.

Data records:

READ( ) year, month, day, j_day, hour, H, u * , w * , VPTG, Zic, Zim, L, z o , B o , r, W s , W d , z ref , temp, z temp , ipcode, pamt, rh, pres, ccvr , WSADJ

FORMAT (3(I2,1X), I3,1X, I2,1X, F6.1,1X, 3(F6. 3,1X), 2(F5.0,1X), F8.1,1X,
F7.4 ,1X, 2(F6.2,1X), F7.2,1X, F5.0, 3(1X,F6.1), 1X,I 5, 1X,F6.2, 2(1X, F6.0), 1X, I5, 1X, A7 )

where j_day = Julian day

H = sensible heat flux (W/ m 2 )

u * = surface friction velocity (m/s)

w * = convective velocity scale (m/s)

VPTG = vertical potential temperature gradient above Zic (K/m)

Zic = height of convectively

- generated boundary layer (m)

Zim = height of mechanically

- generated boundary layer (m)

L = Monin

- Obukhov length (m)

z 0 = surface roughness length (m)

B 0 = Bowen ratio

r = AlbedoC

- 13 W

s = reference wind speed (m/s)

W

d = reference wind direction (degrees)

z ref = reference height for wind (m)

temp = reference temperature (K)

z temp = reference height for temperature (m) ipcode = precipitation type code (0=none, 11=liquid, 22=frozen, 99=missing)

pamt = precipitation amount (mm/hr)

rh = relative humidity (percent)

pres = station pressure (mb)

ccvr = cloud cover (tenths)

WSADJ = w ind speed adjustment and data source flag

When site

- specific data are included in the data base, the definition of the reference

height wind speed and direction are subject to the following restrictions:

• the wind speed, W s , must be greater than or equal to the site

- specific data threshold wind speed;

• the measurement height must be at or above 7*z 0 , where z 0 is the surface roughness length;

• the height must be less than or equal to 100 meters;

If AERMET is run only with NWS data, i.e. no site

- specif ic data are in the data base,

then the restrictions above do not apply and the reference winds are taken to be the NWS winds

independent of the height at which the winds were measured.

Ambient air temperature is subject to a similar, but less restrictive, selection process:

• the measurement height must be above z 0 ; and

• the height must be less than or equal to 100 meters.C

- 14 PROFILE OUTPUT

READ( ) year, month, day , hour , height, top, WD nn , WS nn , TT nn , SA nn , SW nn

FORMAT (4(I2,1X), F 7 .1,1X, I1,1X, F 7.1,1X, F8 .2,1X, F8.2,1X, F8.2,1X, F8 .2)

where, height = measurement height (m)
top = 1, if this is the last (highest) level for this hour , or 0 otherwise
WD nn = wind direction at the current level (degrees)
WS nn = wind speed at the current level (m/s)
TT nn = temperature at the current level ( ° C)
SA nn = σ θ (degrees)
SW nn = σ w (m/s)D

- 1 APPENDIX D

. SUMMARY OF MESSAGES

During the processing of the runstream input and data files, AERMET writes messages to

the file defined through the MESSAGES keyword on the JOB pathway. Each message has the

form:

n block a1n1n2 ssssss: message

where

n = counter, date (in the form yymmdd), or blank

block = program block name

a1n1n2 = message code

ss ssss: = subroutine name in which the message was generated

message = message (limited to 48 characters)

The counter n is either the sequence number of the keyword statement generating the message,

zero when irrelevant, the Julian day plus the hour of an observation with a QA violation or the

number of observations when processing is completed. If it is a sequence number, it may be

relative to either the current runstream file or to the header statements of a file.

The message code is composed of a letter (a1) and a 2 digit code (n1n2). The letter can

be one of the following:

E Indicates a fatal error; if the error occurs during processing of keyword statements, the remaining statements are processed for syntax on ly. If the error occurs during the processing of data, processing ceases for the run.

W Indicates a potential problem that the user should check. Runstream and data processing continues.

I Provides information on the status of the processing; these messa ges report on the progress of an AERMET run.

Q Indicates a quality assessment violation; a value for a variable was either outside the interval defined by the upper and lower bounds or it was missing.D

- 2 The 2 digit codes are grouped into general categories corresponding to the processing in

Stages 1, 2, and 3. These categories are:

00

– 29 Input statement processing, file header and general processing that is applicable to all pathways;

30

– 39 Upper air sounding processing (Stage 1);

40

– 49 Surface obser vation processing (Stage 1);

50

– 59 On

- site observation processing (Stage 1);

60

– 69 Merge processing (Stage2);

70

– 89 Stage 3 processing

These codes only provide an indication of the processing (runstream or data) that was occurring.

They cannot completely specify the reason for the message. Further explanation is left to the 48

character message.

D.1 INTERPRETING ERROR MESSAGES

AERMET can generate many messages in a single run. This section discusses the

interpretation of a few of the error messages.

Anyone who has written software knows that a single syntax error in the source code can

generate several error messages when the program is compiled. AERMET also may generate

several error messages for an error in a runstream. The following is an example of such a

situation that could occur in defining the surface characteristics in Stage 3.

Runstream fragment for the METPREP pathway:

FREQ_SECT ANNUAL 1

SECTOR 1 0 360

CHARS 1 1 0.250 0.750 0.006D

- 3 The message file would contain something l ike:

16 METPREP E03 ST3SET: KEYWORD UNKNOWN: CHARS

METPREP I19 ST3SET: "END OF FILE" ON UNIT 5 AFTER RECORD #

16

METPREP E29 MPTEST: EXPECTED 1 SITE_CHAR KEYWORD; 0 PROCESSED

METPREP E29 MPTEST: ERROR FOR PERIOD 1, SECTOR 1

The correct keyword was not used to define the surface characteristics: CHARS instead of

SITE_CHAR. As each runstream record is processed, AERMET checks to make sure that it

conforms to all the rules of syntax. The first message indicates that an unknown keyword was

detected (by s ubroutine ST3SET) at record 16 in the runstream. Once the runstream is

completely processed, as noted by the "END OF FILE" message, AERMET checks to be sure it

has enough information to process the data. It is during this portion of the setup processing, in

subroutine MPTEST, that AERMET detects additional problems. Based on the FREQ_SECT

keyword, AERMET expected a single SITE_CHAR keyword (annual, one sector covering all

wind directions) to define the surface characteristics, but it did not find any val id SITE_CHAR

keywords (third message). The final message indicates that there was some kind of error with

the first period for sector 1 and is tied to the third message.

One might argue that the number of error messages is excessive for such a minimal

co nfiguration for the surface characteristics. Remember that there can be up to 12 SECTOR

keywords and 144 SITE_CHAR keywords, so AERMET provides the user with additional

information to assist in identifying the exact location of the problem.

Another err or that causes multiple error messages occurs when a pathway is misspelled.

Depending on the location in the runstream, AERMET reports it as an unknown

pathway/keyword (the syntax and structure of the runstream makes it impossible to determine

which). Si nce the pathway is not correctly defined, the keywords that follow it would be

reported as invalid for the previous pathway.

Another error that a user could introduce is a misspelling of an input data file name.

AERMET opens and processes file headers, if any, before processing any data. If a nonexistentD

- 4 file is opened, the file is created and is 0 bytes long. If there is cri tical information that is to be

reprocessed from the header records of the correctly spelled file, then AERMET will not find

that information in the incorrectly spelled file and report an error. Unfortunately, the message

resulting from such an error is m isleading. There is no way to recognize a 'zero

- length' file using

ANSI

- standard Fortran at the point AERMET checks for sufficient information to process the

data. For example, in merging data, if the input file name for the site

- specific data (specified on
the keyword QAOUT) is misspelled, then AERMET creates the (misspelled) file, reads from the

file (and immediately encounters an end of file), and reports that there are no READ/FORMAT

keywords to define the data structure.

Most error messages are re asonably straightforward to interpret. However, from these

few examples, one can see that is may take a little more than a casual glance at the message file

if AERMET detects any errors during setup.

In the discussion of the error messages, the term >dec ode= (or a variant) is used. In

Fortran, this term means that the program is translating data and transferring data between

variables in internal storage rather than transferring data from an external file to variables. The

term >internal read= may also be seen in this context.

D.2 RUNSTREAM A ND FILE HEADER PROCESSING, 00

– 2 9

Any messages that pertain to the setup of a run are included in this category.

ERRORS

E00 Reserved

- this code is used to report internal programming errors.

E01 AERMET was no t able to read a record in the runstream.

E02 Error defining the pathway

- the conditions that may result in this error are: 1) Subr.FDPATH, in a call to subr.GETWRD, was not able to determine the pathway for the runstream record number indicated; 2) Inva lid pathway for the stage of processing;D

- 5 3) Duplicate pathway specified. The message identifies which condition was encountered.

E03 Error defining a keyword

- the conditions that may result in this error are: 1) The keyword did not match any of the 26 keywords recognized by AERMET. This error is independent of pathway; 2) The keyword is not valid for the pathway; 3) The keyword was duplicated for the pathway; only selected keywords are repeatable. The message identifies which condition was encountered. See the tables in Appendix A for the list of keywords by pathway.

E04 Incomplete or superfluous information for a keyword. See the tables in Appendix A for the syntax of the keyword.

E05 This may indicate an invalid combination of processing options o r problems with the merge file headers.

E06 The parameter associated with a keyword is in error. This error can be generated for multiple reasons. For example, if AERMET could not match a variable name on a keyword with the list of valid variable names, then this error code is used. Also, if
AERMET has a ‘decoding’ error, then this code is used. A parameter on a keyword statement is not within bounds, is not known, or does not match any of the valid secondary keywords or parameters for this keyword.

E 07 An error occurred in subroutine GETWRD or an error condition was returned to the calling routine. This subroutine retrieves the value of a field, whether it be a pathway, keyword, or parameter field, for additional processing.

E08 Error opening a file or the file name was previously specified for another file that is already open.

E12 Processing cannot be completed because a required keyword statement for the specified block is either missing or in error.

E15 A problem was encountered with the site

- s pecific surface characteristics defined in Stage
3. P ossible error s include that the keywords were not specified in the correct order , or that surface characteristics for the secondary location are missing with the SUBNWS option (beginning with version 11 059) . While most keywords can appear in any order for a pathway, the surface characteristics must appear in a particular order. See Section 4.7.7 for a discussion of the keywords.

E19 The chronological day was not computed correctly from the year, month and day (in SUBR.CHROND); or the year, month and day was not computed correctly from the chronological day (in SUBR.ICHRND).D

- 6 E20 Error reading a header record from a file (including temporary files). This error could occur while reading through the header records of a file in an attempt to locate the first
data record.

E21 Error writing a header record to a file.

E22 End of file encoun tered reading and existing file’ s header records. This condition indicates that there are no data to process.

E23 Error re

- reading an existing file ’ s header records written that had been written to an output file.

E24 Error conditions were detected for the JOB pathway; this message is issued during the final check after the setup processing.

E25 Error conditions we re detected for the UPPERAIR pathway; this message is issued during the final check after the setup processing.

E26 Error conditions were detected for the SURFACE pathway; this message is issued during the final check after the setup processing.

E27 Erro r conditions were detected for the ONSITE pathway; this message is issued during the final check after the setup processing.

E28 Error conditions were detected for the MERGE pathway; this message is issued during the final check after the setup processing

.

E29 Error conditions were detected for the METPREP pathway; this message is issued during the final check after the setup processing.

WARNINGS

W0 2 The input runstream record exceeds the maximum number of characters of 132. This may result in errors p rocessing the runstream file. The message also includes a portion of the information beyond column 132, out to column 500.

W0 3 Beginning with version 11059, the LOCATION keyword is no longer valid on the METPREP pathway in Stage 3, and the information on the METPREP LOCATION keyword will be ignored. The location used for determining sunrise for convective mixing height calculatio ns is the primary surface station location in Stage 1, i.e., the ONSITE location if available, otherwise the SURFACE location.D

- 7 W04 Too many fields are included on the DATA keyword. Beginning with version 11059 some fields on the DATA keyword are no long er supported. This also applies to the station elevation on the DATA keyword for UPPERAIR data.

W06 Value on an input statement may be unreasonable, but processing continues with this
value.

W15 Two sets of surface characteristics specified when only on e set is needed. The secondary set will be ignored.

W19 The specified ONSITE data variable is currently not used by AERMET.

W 20 Auditing a variable for QA is disabled for the ONSITE variable specified. The variable appeared on an AUDIT keyword statement but did not appear with any READ keywords.

W 21 OSHEIGHTS keyword and HTnn height variables are both defined for ONSITE data

. The OSHEIGHTS keyword will be used to define measurement heights and the HTnn variables will be ignored.

W22 The OSMN variable for ONSITE observation minute is specified on the READ keyword, but OBS/HOUR = 1. The OSMN variable will be ignored

.

INFORMATIONAL

I19 End of file encountered on the input runstream file.

I25 No data are to be extracted, QA'd, or merged for UPPERAIR pa thway.

I26 No data are to be extracted, QA'd, or merged for SURFACE pathway.

I27 No data are to be QA'd or merged for ONSITE pathway.

D.3 UPPER AIR PROCESSING, 30

– 39

Any messages that pertain to the UPPERAIR pathway and issued after the input

statements are processed are in this category. A word of caution: if a problem requires

examining the unprocessed TD

- 6201 (archive) data, be very careful if you edit the file with a text

editor. Some editors could potentially modify the structure, render ing the file unreadable by

AERMET. A better option would be to use a file viewer that cannot alter a file.D

- 8 ERRORS

E30 An error occurred computing the chronological day number.

E31 No soundings were extracted and there were no errors that did not allow AERMET to extract any of the soundings specified in the runstream. Compare the station ID and the dates in the runstream to the station and dates in the input data file.

E32 An error occurred reading a block of data. A block of data contains all or part of a single sounding. Depending on the data structure of the archive data (fixed

- or variable

- length block), there can be up to 2876 characters in one block of data. An error reading a block is considered severe enough to stop processing the upper air d ata since the nature of the error cannot be ascertained very easily. The user will have to carefully examine the data
to determine the cause of the error.

E33 An error was encountered decoding the portion of the block that contains the station
identifie r and date group, or an error occurred decoding a level of data in the sounding. In the former case, AERMET will stop processing the upper air data. In the latter case, AERMET will allow up to five such errors decoding sounding levels before processing o f upper air data ceases. If AERMET cannot decode a sounding level, then it continues to
the next level.

E34 The first character of the station ID is blank in the archive data file, indicating that the entire field likely is blank in the file. In the arc hive file, the station ID is supposed to fill
the entire 8

- character field, with leading 0's to fill out the field if the ID is shorter than eight characters. Either the process of reading the data is no longer synchronized with the data, or the station I D field is not what AERMET expects.

E35 At least one sounding was extracted, but error(s) occurred that did not allow AERMET to finish extracting all the soundings specified in the runstream.

E36 No soundings were extracted and error(s) occurred that did not allow AERMET to extract any of the soundings specified in the runstream.

E38 An error occurred while reading a sounding during the QA process. The data in the input file for QA should alread y be in a standard AERMET format (see Appendix C.1), but
AERMET was unable to read the data from the file. Since AERMET reads and writes one sounding at a time, check the output file to see where the error occurred (the sounding after the last one in the file being written by the QA process).

WARNINGSD

- 9 W33 Error decoding a level of data, but the maximum number of errors allowed (five) has not
been exceeded.

W3 4 Surface elevation (elevation of the first sounding level) is missing or less than zero. The

s ounding levels in the archive file are reported as height above mean sea level. AERMET adjusts all soundings to be referenced relative to the local elevation rather than sea level. If AERMET cannot determine the surface elevation because it is missing (o r below mean sea level), then this message is issued. Once the surface elevation is determined, that elevation is used to adjust all subsequent soundings.

W35 The process of decoding the levels of data in a sounding failed at the first level. It is
like ly that only a header record is present in the output file from the extract process. The user will have to examine the input data more closely to determine the cause of the problem.

W36 The first level of FSL upper air data is not the correct type and wa s skipped.

INFORMATIONAL AND QA

I30 Beginning UPPERAIR data processing.

I31 Data modifications for upper air soundings is enabled. See Section 5 for a discussion of
these modifications.

I32 With the data modifications enabled, a level of data was deleted or modified from a sounding.

I39 End of file was encountered on the input file.

Q34 A vertical gradient cannot be computed at because at least one of the heights are missing.

Q35 The difference between the reported height and recomputed height e xceeds 50 meters.

Q36 The heights have not been recomputed due to missing data.

Q37 A lower bound quality assessment violation for the variable indicated.

Q38 An upper bound quality assessment violation for the variable indicated.

Q39 The data value fo r this period and variable is missing.

D.4 S URFACE OBSERVATIONS PROCESSING, 40

– 49D

- 10 Any messages that pertain to the SURFACE pathway and issued after the input

statements are processed are in this category.

ERRORS

E40 An error occurred computing the chronological day number.

E41 An end of file was encountered in the input file and no hourly observations were extracted. Compare the station ID and dates in the runstream to the station and dates in the input file to determine if there is a mismatch.

E 42 The maximum number of errors allowed reading a block of data from the archive data
file has been exceeded. The limit is five errors.

E43 An internal read (decode) failed while trying to resolve the station ID or date group in the archive input data.

E44 The first character of the station ID is blank in the archive data file, indicating that the entire field likely is blank. Check the input file and make sure the file structure conforms to the format specified on the DATA card (e.g., if CD144 is speci fied on the DATA keyword, then the format of the file is the 80

- character per observation format).

E45 No data fields useful to AERMET were defined when data were retrieved from the SAMSON CD. AERMET expects that the data the user retrieved from the SAM SON CD contains information that is required to calculate boundary layer parameters. This message is issued during the setup phase of the processing.

E46 An error occurred converting the variable ID number in a SAMSON input file from a string to an inte ger. The second record of the data retrieved from the SAMSON CD contains a list of integers that correspond to the weather variables that appear in the file. The integers range from 1 through 21. Without a correct interpretation of these integers,
AERME T cannot process the data.

E47 The station ID in the SAMSON file does not match the station ID on the LOCATION keyword. See also E41; since the SAMSON data are processed slightly differently than the CD144 and SCRAM formats, a separate message is issued when no data are retrieved.
E48 An error was encountered while reading the hourly observation from the QA input file. Since AERMET reads and writes one observation at a time, check the output file to see where the error occurred (the observation after the last one in the file being written by the QA process).D

- 11 WARNINGS

W4 0 SURFACE data is outside the valid range of dates for the specified data format, and cloud cover will be set to missing for ASOS records

.

W4 1 Cloud cover set to missing for ASOS observations from reformatted SURFACE file format outside the valid date range for the format, for SAMSON and SCRAM data

.

W42 Error reading/decoding the hourly observations, but the maximum number of errors
allowed was not exceeded.

W43 An error occurred decoding an overpunch character  the missing valu variable will be substituted in the output file. See Section 4.3.1 for a discussion on overpunches. The number of the overpunch is reported (there are 35 overpunches possible, but AERMET does not examine all of them), and the table in Section 4.3.1.1 can be used to identify the position in the record that caused the error.

W44 A problem occurred with extracting SURFACE data in the HUSWO format

.

W4 5 AERMET has encountered a second set of SAMSON header records (the records beginning with the tilde (~)). These header records are not processed and the extraction of hourly surface observations stops.

W4 6 Various messages related to SURFACE station elevations, whether specified by the user

o r included in the SURFACE data file

.

W47 Various messages related to consistency checks between SURFACE station ID specified by the user and station ID included in the SURFACE data file

.

W4 8 Various messages associated with ISHD data

.

W4 9 Various messa ges regarding the processing of the ASOS commissioning date and the ASOS data flags

.

INFORMATIONAL AND QA

I40 Processing of the SURFACE data can begin.

I 4 1 Cloud cover set to missing for ASOS observations from reformatted SURFACE file
format outside the valid date range for the format, for SAMSON and SCRAM data; first 24 occurrences are issued as warnings (W41)

.

I45 Message related to precipitation accumulation for SAMSON data.D

- 12 I47 The SAMSON data identified with this message were modeled rather tha n observed when the data were imprinted on the CD.

I48 Report number of records extracted.

I49 End of file was encountered on the input file.

Q47 A lower bound quality assessment violation for the variable indicated.

Q48 An upper bound quality assessm ent violation for the variable indicated.

Q49 The data value for this period and variable is missing.

D.5 ON SITE DATA PROCESSING, 50

– 59

Any messages that pertain to the ONSITE pathway and issued after the input statements

are processed are in this c ategory.

ERRORS

E50 Error reading an input file header.

E51 Error reading input file header record. This message would occur only if a file is QA ’ d
more than once since there isn ’ t an extract process for site

- specific data and there usually

aren ’ t any headers in the site

- specific data file prior to the first time the data are QA ’ d.

E52 The maximum number of errors allowed reading/decoding the input data has been
exceeded. The limit is five errors.

E53 Error writing data to the output file define d on the QAOUT keyword statement.

E54 The observations are not sequential in time.

E55 The number of observations exceeds the number expected for the hour (by default, 1 or the value specified on the OBS/HOUR keyword statement).

E56 End of file on th e input data was encountered before a complete observation (block of records) was read.D

- 13 E5 7 A duplicated observation period was found in the ONSITE data

.

E59 A gap of more than 1 year was found in the ONSITE data.

WARNINGS

W 50 The measurement heights for ONSITE data vary within the data period processed

.

W 5 1 No station elevation specified on the ONSITE LOCAITION keyword. Users are encouraged to specify station elevation for use in substitution hierarchy for missing station pressure

.

W52 Various messages related to reading ONSITE date records

.

W55 Total ONSITE precipitation is based on less than the half the number of values for subhourly data.

W59 A data gap occurred within the ONSITE data file.

INFORMATIONAL

I55 The number of subhourly ONSI TE values is less than the minimum to calculate an hourly

average.

I59 An end of file was encountered on the input file.

Q57 A lower bound quality assessment violation for the variable specified (for more than one observation per hour, this check is mad e after the subhourly values have been averaged).

Q58 An upper bound quality assessment violation for the variable specified (for more than one observation per hour, this check is made after the subhourly values have been averaged).

Q59 The data value fo r this variable and observation period is missing.

D.6 MERGE PROCESSING, 60

– 69

Any messages pertaining to merging the three data types and issued after the input

statements are processed are in this category.D

- 14 ERRORS

E60 Error computing the chronological day from Julian day and year.

E61 Error computing the Julian day and year from the chronological day.

E62 Error reading the UPPERAIR data.

E63 Error reading the SURFACE data.

E64 Error reading the ONSITE data.

E65 Error writing the ONSIT E QA ’ d data to the OUTPUT file.

E66 Error processing an input file's headers.

E67 No data to merge

- either the merge program or the setup have determined that there are no data to merge. AERMET will ‘ merge ’ data even if there is only one type of data ( upper air, surface, or site

- specific), but since no data are available to merge processing
will aborted.

E68 The ASOS flag is missing or invalid in the SURFACE QAOUT file. This could indicate that the QAOUT file is from an old version of AERMET, prior to version 11059 when the ASOS flag was added to the QAOUT file.

WARNINGS

W66 Various messages regarding the use of 1

- minute ASOS wind data

.

W69 Message regarding non

- standard MERGE, e.g., UA and OS data only, or SF and OS data only

.

INFORMATIONAL

I66 The WBAN for the 1

- minute ASOS wind data matches the WBAN for the SURFACE
data.

I67 No XDATES statement  the beginning available date on the three pathways, and the ending chronological day was computed as the beginning day + 367. Without an XDATES keyword, AERMET has no knowledge of what data are in the input file(s), therefore, the zeroes are displayed in the report file for the dates to merge.D

- 15 D.7 STAGE 3 PROCESSING, 70

– 89

Any messages that pertai n to Stage 3 processing and issued after the input statements are

processed are in this category.

ERRORS

E70 Error reading the master header from the merged data file for the Julian day shown. In the merged data file, there is a master header that prece des the data for each 24

- hour
block of data. AERMET was unable to read this record.

E71 There was an end

- of file or error encountered reading the merged upper air data.

E72 There was an end

- of file or error encountered reading the merged hourly surface
observations.

E73 There was an end

- of file or error encountered reading the merged site

- specific data.

E74 Th e data are not on a 1

- to

- 24 hour clock. This message can appear for surface or site

specific data. Although the program to merge the data shoul d write the data on a 1

- to

- 24 hour clock, there appears to be an hour outside this window, possibly an hour labeled 0.

E75 There was an error converting the latitude and longitude in the runstream file from
character to numeric.

E76 The hour in the mer ged data is defined as missing. For an unknown reason, the value for
the hour was set to

- 9 in the merged data file.

E77 Bad wind sector specified (this is a second check on the wind direction sector).

E78 Upper air station location is blank

.

E79 Error occurred assigning met variables in SUBST for hour

.

E80 Input data are incomplete , either no UA data and no OS mixing heights, or no SURFACE
data and no ONSITE data.

E81 ASOS flag is invalid , check the MERGED data.

E89 Error assigning location for Stage 3 based on SURFACE location or ONSITE location, could indicate a programming flaw.D

- 16 E90 Error getting surface roughness; could indicate a programming flaw.

E91 Missing sky cover in subroutine NETRAD; could indicate a programming flaw.

WARNINGS

W70 The LST to GMT conversion appears to be incorrect. Based on the longitude provided, the (elementary) computation of the time zone does not agree with the conversion parameter (tadjust) on the LOCATION keyword.

W72 The upper air sounding cannot be ext ended because

- the maximum number of levels are in the sounding;

- the top of the sounding is too low (< 600 meters);

- could not identify two levels with which to calculate the potential temperature gradient required to extend the sounding.

W73 Convect ive boundary layer parameters not computed because

- no upper air data, especially the 12Z sounding, reported on this day

- other data required for the computation of the daytime planetary boundary layer height are missing.

W76 A minimum value of 0.001 m/ s has been assigned to w*, since it was calculated to be less
than 0.001.

W78 Calculated value for density is out of range (relative to lower and upper bounds specified at the point this check is made).

W79 Site

- specific mixing heights are in the data base, but are missing for the hour; AERMET will calculate the mixing height.

W81 The reference wind speed from the NWS data are above the threshold wind speed but less
than 2 1⁄2 *σ v,min ( where σ v,min = 0.2 m s

- 1 ). This condition is not likely to occur unl ess 1

- minute ASOS wind data are used, since the minimum wind speed routinely reported by
NWS is 3 knot s (about 1 .5 m s

- 1 ), excluding calm winds.

W82 The default pressure of 1013.25 mb is being used since there were no site

- specific or NWS pressure reporte d.

W83 Anem ometer height from ASOS list differs from user

- spe cified height.

W86 Delta

- T height range may not be appropriate for BULKRN method.D

- 17 W98 The data period for 1

- minute ASOS wind data predates 2000, the earliest data period
available for 1

- minute ASOS data.

INFORMATIONAL

I70 Hour 23 data was swapped in for hour 24 data for NWS surface data.

I71 Cloud clover is missing for a nighttime hour or both cloud cover (NWS) and net radiation (site

- specific) are missing for a daytime hour, prohibiting cal culation of all boundary layer parameters in AERMET.

I 77 Net radiation is negative during a daytime hour or positive during the nighttime (relative to sunrise and sunset).

I 7 8 Sky cover is missing for a stable hour, no SBL estimates are calculated.

I79 The end of the processing window, defined by the XDATES statement for the METPREP block, was encountered or, if no window was specified, the end of file was encountered.

I 80 The conditions that produce this message are: 1) The reference wind speed from the site

- specific data are above the threshold wind speed but less than 2 1⁄2 *σ v,min ( where σ v,min = 0.2 m s

- 1 ), or 2) The reference wind speed height is above 7z 0 but below 20z 0 , where z 0 is the surface roughness length. See the Site

- specific Meteorological Program Guidance (EPA, 1987) for additional discussion on specifying the height to use in calculating boundary layer parameters.

I81 In defining the reference wind speed, there were n o site

- specific winds that met the
criteria and 1

- minute ASOS or standard NWS winds were used for the reference wind speed.

I82 In defining the reference temperature, there was no site

- specific temperature that met the criteria and NWS temperature was use d for the reference wind speed.

I83 In defining the station pressure, there was no site

- specific pressure and NWS winds were used for the reference wind speed. This message is seen only if the user indicates that there is pressure in the data base.

I85 Only the ONSITE reference temperature will be used, rather than the full profile of ONSITE temperatures, because the reference ONSITE wind is missing.

I86 BULKRN option for delta

- T was not use d due to missing ONSITE wind data.D

- 18 I87 The reference wind spee d is missing for the specified hour.

I88 The external file of surface characteristics for the AERSURF or AERSURF2 keyword was successfully opened.

I98 The data period for 1

- minute ASOS wind data predates 2000, the earliest data period
available for 1

- min ute ASOS data; the first 24 occurrences are issued as warnings (W98).