|
CALPUFF FAQs Answers
1.1.1 When might I consider using a puff model instead of a plume model?
The EPA has proposed the use of CALPUFF for applications involving long-range transport,
which is typically defined as transport over distances beyond 50 km. Therefore, the use of
CALPUFF for EPA regulatory applications involving transport distances of less than 50 km
requires approval by the relevant reviewing authorities. As described in Section 7.2.8 of the EPA's
proposed Guideline on
Air Quality Models, the CALPUFF model may also be used in special cases involving complex
flows on a case-by-case basis with concurrence from the reviewing authorities.
From a technical standpoint, while a puff model may be used for most applications where a plume model is appropriate, the
additional resources involved in application of a puff model may not always be justified. The technical
decision on whether a puff model is more appropriate for a particular application than a plume
model should be based on considerations of whether the straight-line, steady-state assumptions
on which a plume model is based are valid. This may include considerations of the transport
distances, as well as the potential for temporally and/or spatially varying flow fields due to
influences of complex terrain, non-uniform land use patterns, coastal effects, and stagnation
conditions characterized by calm or very low wind speeds with variable wind directions. For
cases involving a high degree of spatial variability of the flow within the boundary layer, such as
upslope or downslope flows or flows along a winding river valley, the straight-line, steady-state
assumption may not be valid beyond even a few kilometers, and a puff model may be more
appropriate. Another consideration in deciding whether a puff or plume model is more
appropriate for a particular application is whether the full spatial and temporal distribution of
pollutant impacts is important, such as when using the model results for a risk assessment, or
whether the results are to be used for a criteria pollutant analysis where the only the peak of the
concentration distribution is important, regardless of time or space.
BACK TO FAQs
1.1.2 I have input control file from an earlier version of CALPUFF, and want to use it
with the most recent version. Will my control file be compatible with the new
version? If not, what changes will I need to make to the inputs?
The new version of CALPUFF (and its pre- and post-processors) include certain revisions to the
algorithms and associated changes to the variables and variable names. Some variables have
been added to the new version, while some others have been dropped. Therefore, input control
files from older versions, especially the earlier versions of CALPUFF (versions 3 and older), may
not be compatible with the latest version of the model, and should be updated.
The best way to change the input control file is via the Graphical User Interface (GUI). The
GUI's for the three main modules of the system, i.e., CALMET, CALPUFF and CALPOST, will
read the input control files from previous versions of the model, and incorporate any changes to
it. Obsolete variables are either discarded or mapped into current variables. New variables are
filled with default values. Since there may be significant differences between the latest version
and some of the earlier versions of the model, it is strongly recommended that the user select the
"Sequential" input option under the "Input" menu item within each GUI. This will ensure that the
necessary changes are made to each input group within the input control file.
For the preprocessors for which no GUI is currently available, the user should make the
necessary changes to the individual control files via an ASCII text editor. Sample control files
are provided in the demonstration for each processor.
BACK TO FAQs
1.1.3 Explain the rules for formatting the input option files for the different programs
that make up the CALPUFF modeling system. Is the order of inputs in the input
option file important?
The inputs for the CALPUFF modeling system can be created either through the graphical user
interface (GUI) available on the CALPUFF download page, or through the use of an ASCII text
editor. Use of the GUI will ensure that the input control files for the CALMET, CALPUFF and
CALPOST programs will be properly formatted. The GUI system also creates the ASCII text
files (i.e., input control files) used to run the modeling system, i.e., the CALMET.INP,
CALPUFF.INP and CALPOST.INP files. When using a text editor, the rules for formatting the
input control files are described in the applicable user's guide. The rules provide considerable
flexibility on the formatting of the control file and allow for use of extensive documentation of
the options selected through comments within the file. The input control files created by the GUI
incorporate extensive self-documenting statements that describe the various input options and,
where applicable, list the default values for the options. While these documentation statements
are not required, they provide useful information especially when using a text editor to modify an
input file. The user should note that although the input control file is limited to 132 characters
per line, continuation lines are allowed. Also, there is a limit of 70 characters on the filenames
(including the path) specified within the input control file.
The selected options are delimited within the control file by exclamation marks (!), along with
the option name, e.g., the following string specifies the selection of the option for ISC-type of
terrain adjustment: ! MCTADJ = 1 !. With the exception of the first three lines of the input
control files (which are treated as run titles), any information outside the exclamation marks is
considered documentation and ignored by the model during execution. Therefore, the users may
add additional comments within the input control file as needed to describe the inputs. Note,
however, that each time the input control file is modified using the GUI, all user comments are
deleted, and the documentation in the input control file reverts to the standard self-documenting
statements written by the GUI.
The input control file for each program is organized into a number of Input Groups and Subgroups, and
these must appear in order within the input file. Within each Input Group or Subgroup, the order of inputs
is not important. Each Input Group must end with an Input Group terminator that consists of the
word END between two delimiters, i.e., !END!. If the terminator is missing, or if it is out of place, the model
will not find a match between the current variable name read from the control file and the dictionary of
variable names for the current group or subgroup, and report this as a fatal error.
BACK TO FAQs
1.1.4 What is the maximum file size for CALMET/CALPUFF data, and is this limit
compiler dependent?
The maximum file size for CALMET/CALPUFF data on Windows-based PCs (Windows
95/98/NT) is approximately 2.1 gigabytes (231 bytes), and is dependent on both the operating
system and the compiler. On a Unix system, there is no specific limit on file sizes. Larger file
sizes may be obtained when applying the CALMET/CALPUFF system on work stations under
operating systems using 64-bit addressing, but the file limit may also depend on the compiler for
work stations.
Note that CALMET will process a simulation that results in a file larger than the size limit
without reporting an error. However, the CALMET.DAT file will contain an end-of-file (EOF)
once it reaches the limit of 2.1 GB. CALMET fields for periods that would have been written
after this point are not available to CALPUFF (or PRTMET). In this case, multiple CALMET
simulations are needed, as CALPUFF allows the data to be "broken" into several files of less than the
limit, e.g., twelve monthly CALMET.DAT files for a full-year run.
BACK TO FAQs
1.1.5 What criteria do I use to determine whether I should use UTM or Lambert
Conformal coordinates for my application of CALPUFF?
The decision on whether to use UTM or Lambert Conformal coordinates for a particular
CALPUFF application depends on the size and latitude of the modeling domain, and on whether
the use of UTM coordinates will result in enough distortion to significantly affect the results.
The degree of distortion introduced by the UTM projection will increase with the size of the
domain and with increasing latitude. For applications in the middle latitudes, the distortion due
to use of UTM coordinates will generally become significant for modeling domains exceeding
200 kilometers on a side. Lambert Conformal coordinates take into account the curvature of the
earth, and may be used for most applications of CALPUFF in the middle latitudes (30 to 60
latitudes), regardless of the size of the domain. For most applications in the US and Canada, the
coordinate system is generally not an issue, and the users prefer the UTM coordinate system over
the Lambert Conformal system.
BACK TO FAQs
1.1.6 How are calm hours treated by the CALMET/CALPUFF modeling system, and if I
have a large number of calm hours for one of my surface stations should I be
concerned about how it will influence the results?
The CALMET/CALPUFF modeling system has the ability to model calm hours by simulating
stagnant puffs. Due to a zero wind speed, stagnant puffs are not dispersed via advection, but may
still undergo turbulence-related dispersion. Furthermore, even if the measured wind speed is
zero, CALPUFF accounts for other possible flow components, e.g., puff transport caused by
divergence or slope flow. Therefore, the model will calculate concentrations for calm hours.
Given that light wind, stable conditions are often worst case for many types of sources, it is
possible that for a given application the calm hours may result in the overall highest impacts.
Although calm hours are common at some locations, the user is advised to closely examine any data
containing a large number of calm hours. Among the first things to look at is the geographic
location of the surface station to determine if calm hours are a frequent occurrence in that
area. Other things to examine are whether, (1) there were any instrument problems or
malfunctions, (2) the instrument type or the measurement threshold were more amenable to
recording calm hours, and (3) the location of the wind instrument is such that it is obstructed by
any structure or terrain feature. As in any modeling application, the representativeness of the
meteorological data to the region being modeled, including the likelihood of excessive occurrences of
calm hours, must be ascertained.
BACK TO FAQs
1.1.7 I want to use CALMET/CALPUFF for a local-scale application involving complex
flows. I also want the initial guess wind field to reflect mesoscale features, but do
not have MM5 data available for the time period of interest. What options are
available?
The CALMET/CALPUFF modeling system currently includes the capability to incorporate
3-dimensional prognostic meteorological data from the MM5 model into the processing of
meteorological data through CALMET. This is most commonly accomplished by using the
MM5 data as the initial guess for the wind field in CALMET. If MM5 data are not readily
available for a particular application, one option is to run the MM5 model for the domain and
time period of interest. However, proper application of the MM5 model requires both
appropriate computer resources as well as MM5 expertise. Interfaces to
other types of prognostic data, such as AVN, ETA, and RAMS, are currently under development
so that additional options will be available in the future. If suitable prognostic data are not
available, the next best option would normally be to use all representative upper air data that are
readily available for the domain to create a spatially-varying initial guess wind field.
BACK TO FAQs
1.1.8 What are the considerations in developing wind field characterizations (NWS+MM data,
NWS data only, MM data only) and what are the effects of these alternatives
on modeling results?
In developing wind fields, the user must start with an initial guess field (see
Section 2.7, 2 of the FAQ) which is then refined by
CALMET based on local meteorological, terrain and land use data. The initial
guess field is adjusted for local terrain and land use effects to generate a Step 1 wind field, and
then further refined using local National Weather Service (NWS) observations to create the final
Step 2 wind field. To date, the use of MM (MM4 or MM5) data as input into CALMET as the initial
guess wind field, which is then blended together with available NWS hourly weather observations, has
provided at least as good, and often better, results than use of NWS data alone. Preliminary
tests of using only MM data to drive the entire CALMET analysis have not provided consistent results,
and is thus considered the least desirable approach.
Generally, the use of MM data as the initial guess field will improve the overall wind field
characterization. As an alternate, the MM data can be used in CALMET as the Step 1 wind field
or even as observations used in refining the Step 1 wind field. When used
as the Step 1 wind field, the MM data are assumed to already contain the significant terrain
effects and are not adjusted further. When the MM data are used as the Step 1 wind field or as
observations, the user can specify how much weight to assign to MM data as compared to the
NWS data by specifying weighting factors in an optional external WT.DAT file read by
CALMET. See Section 2.2.3 of the CALMET user's guide for details on the various options available for using the MM data
and how to assign the weighting factors.
Although the use of MM data will improve model performance in many cases, the users should
examine the data to ensure that the grid spacing used in creating the data is adequate for their
application and the winds appropriately characterize the mesoscale flows within the modeling
domain. Poorly characterized data may adversely affect the model performance. For example,
the 1990 MM4 data available from the National Climatic Data Center (NCDC) contain data on
an 80-km grid spacing, which may not provide sufficient resolution for all applications.
BACK TO FAQs
1.1.9 Can CALMET/CALPUFF be used to simulate land/sea breeze circulations, and
what special considerations exist for such an application?
A version of the CALMET/CALPUFF modeling system is currently under development
including algorithms that will generate land/sea breeze circulations if conditions are favorable
based on empirical parameterizations. For the current version of CALMET, if significant
mesoscale circulations are present, such as land/sea breezes, then the use of prognostic mesoscale
meteorological data, such as MM5 or RAMS, to initialize the wind field in CALMET is
encouraged. Due to the sparsity of upper air stations, it is unlikely that observations alone will
capture the important characteristics of such circulations. However, care should be exercised to
ensure that the mesoscale data are of sufficient resolution to capture the circulations, e.g., 80-kilometer MM4 data are probably not adequate for such an application.
BACK TO FAQs
1.1.10 What are the considerations in applying CALPUFF to simulate visibility and
deposition impacts on a Class I area?
The first consideration is the distance from the source to the subject Class I area. This distance
plays a role in determining whether the visibility-related calculations performed by CALPUFF
are appropriate for the particular application. The CALPUFF model calculates the change in
light extinction caused by a source (or group of sources) as part of the regional haze calculations.
The change in light extinction is used as an indicator of visibility degradation at large distances
from the source (i.e., after a long range transport of the plume), where a distinct plume may not
be discernible against the background, but could likely alter the appearance of the background. The threshold distance for long range
transport has been identified in the Interagency Workgroup on Air Quality Modeling (IWAQM)
Phase II report as 50 km from the source.
The second consideration is the type of meteorological data to be used in the analysis. The
type of meteorological data depends upon whether the CALPUFF model is applied in its refined
mode or the screening mode. In the refined mode, CALPUFF requires the use of the CALMET
meteorological model. Consult the CALMET section of the FAQ page for guidance on supported data
formats and other considerations (BACK TO FAQs). In the
screening mode, CALPUFF accepts meteorological data in an extended ISC ASCII format prepared by
the CPRAMMET or the EPA's PCRAMMET meteorological preprocessors. For deposition and visibility
calculations, these preprocessors require input of surface station data in either CD144, SAMSON
or HUSWO format, and upper air (mixing height) data in the same format as available on the
EPA's SCRAM website. For further
guidance on the application of the CALPUFF screening mode, consult the
Federal Land Managers' Air
Quality Related Values Workgroup (FLAG, December 2000) document.
The third consideration is accounting for chemical transformations that occur during plume
transport. The CALPUFF model contains algorithms to calculate the conversion of SO2
to sulfates and NOx to nitrates. The
IWAQM Phase II report
recommended the use of the MESOPUFF II scheme. Another available method is the RIVAD
scheme. For differences between these two schemes, see
Section 3.3, 6 of the FAQ. These methods require
the user to select additional species to be modeled, e.g., sulfates (SO4), nitrates
(NO3) and nitric acid (HNO3). They also require the input of background
ozone and ammonia concentrations. Note that although the CALPUFF model provides default values
for background concentrations, values specific to the Class I area being modeled are
recommended given the sensitivity of the model to these parameters. For visibility calculations,
site-specific relative humidity data are also recommended in the post processing step using
CALPOST. Consult the FLAG 2000
document for further guidance.
BACK TO FAQs
1.1.11 Are there any applications for which I should select the option "Do not check
selections against regulatory guidance" under the CALPUFF Run Information on
the GUI?
The option to check a number of the CALPUFF configuration selections for
compliance with regulatory guidance is presently designed for Long-Range
Transport (LRT) applications. These applications are typically associated
with modeling impacts in distant Class I areas. The selections that
are checked include the type of meteorological data used, the presence of
chemical transformation and removal, several aspects of the dispersion
rates used, terrain adjustment, near-source treatment of transitional
rise, stacktip downwash, and partial penetration of elevated inversions.
These checks are consistent with the current regulatory LRT guidance.
One or more of these checks may be inappropriate for other (non LRT)
applications, and so the regulatory guidance option should not be selected
in those cases. For example, a near-field application with complex flows
may not require the chemical transformation module, or the depletion
modules, and will therefore not pass the regulatory guidance check.
In all cases, the configuration should conform to procedures
agreed upon with the reviewing agencies (e.g., via a modeling protocol).
BACK TO FAQs
1.1.12
What extra steps are needed to compile a model or processor on a PC using a
FORTRAN compiler other than the Lahey F95 compiler used for the distribution
executables?
The CALPUFF system and associated processors are FORTRAN 95 codes largely
developed on the PC, and tested/debugged using the Lahey F95 FORTRAN compilers.
FORTRAN compilers differ in the level of code evaluation (syntax rules, etc.)
performed while compiling, and in how such evaluation checks are configured. One
compiler may by default return a fatal error when compiling a code that passed
another compiler without incident, or with a non-fatal warning message. Utilities
provided by the platform also frequently differ, which can affect the calls that
are used for processing system dates and times, for example.
Compiling a code using a 'new' compiler typically requires modifying
non-conforming usages in the code (these are detected by the compiler),
reconfiguring the compiler directives where appropriate to remove restrictions
that do not affect the operation of the code, and substituting calls to system
subroutines that make the executable platform-specific.
Compiler-Specific Statements
The CALPUFF system code has isolated compiler and platform-specific statements
in just a few subroutines . These subroutines are placed at the end of the
CALUTILS.FOR file, and contain statements for several popular compilers. Two
processors also contain compiler-specific settings in the PARAMS include-file.
The code, as distributed in the BETA-Test, is configured for the Lahey F95
FORTRAN compiler so that the alternate statements for other compilers are
inactive (they appear as comments). If the Lahey F77, Microsoft or COMPAQ DF90
compilers are used, the blocks identified for Lahey F95 should be commented,
and the corresponding blocks for Lahey F77, Microsoft or COMPAQ DF90 should
be activated (de-commented).
Subroutines that contain compiler-specific settings are:
CALMET -- datetm, undrflw, comline
CALPUFF -- datetm, undrflw, comline
CALPOST -- comline
POSTUTIL -- comline
These 3 subroutines (datetm,underflw, and comline) are located at the end of
the CALUTILS program, which is called by and compiled along CALMET, CALPUFF,
CALPOST, and POSTUTIL. Provided the 3 subroutines are adequately modified for
the specific compiler/platform, the same modified CALUTILS can be used to compile
CALMET, CALPUFF, CALPOST and POSTUTIL (but needs to be copied in each code directory
before compilation).
For the geophysical preprocessors, the parameter files that contain
compiler-specific setting are:
No changes are needed in other codes.
Compiler Configuration Examples
Optimization should generally be avoided, unless you can readily demonstrate
that such optimizations have no effect on the results produced.
Lahey/Fujitsu LF95
Compile and link with the code in one file (e.g., CALMET.FOR) using
the following options:
Options:
-nap -c -nchk -nchkglobal -dal
-ndbl -ndll -nf95 -fix -ng
-nin -ninfo -li -nlst -nlong
-maxfatals 50 -o0 -npause -nprivate -npca
-nquad -nsav -nstaticlink -stchk -tp
-trace -ntrap -w -winconsole -nwo
-nxref -zero
If you do not have enough memory (causing the compiler to abort),
try breaking the .FOR file into pieces, compiling each in turn to
create a number of .OBJ files. Then link these .OBJ files to make
the executable.
Compaq Digital FORTRAN
You will need to process the codes for CALMET, CALPUFF, CALPOST, and
POSTUTIL in two files, since the subroutine comline requires different
compiler directives. Cut the comline subroutine out of the FORTRAN file
and save it as COMLINE.FOR. Using CALPUFF as an example, compile everything
except comline with the command (enter on one command line):
df calpuff.for /compile_only /nologo /fpe:0 /fpscomp:general
/fpscomp:ioformat /fpscomp:logicals
/iface:nomixed_str_len_arg /iface:cref /optimize:0
/warn:nofileopt /traceback
Then compile comline (e.g. COMLINE.FOR) with the command (enter on one command line):
df comline.for /compile_only /nologo /fpe:0 /fpscomp:general
/fpscomp:ioformat /fpscomp:logicals /iface:cref
/optimize:0 /warn:nofileopt /traceback
Link the two .OBJ files with the command:
Lahey F77
Note that FORTRAN 77 compiled codes will normally not run with current
Windows operating systems. The use of FORTRAN 95 is normally required.
When compiling with FORTRAN 77, compile and link with the code in one file
(e.g., CALMET.FOR) using the following options:
OPTION DESCRIPTION OPTION DESCRIPTION
/n0 - Standard FORTRAN 77 IMPLICIT / L - Line-number traceback table
/n2 - Generate 387 constants and code / P - Protect constant arguments
/n4 - No 80486 optimizations / Q1 - Limit NDP stack entries
/n7 - Optimize inter-statement /nQ2 - No protected-mode RPC
/ A2 - Allocatable array checking /nQ3 - No real-mode RPC
/ B - Check array subscript Bounds / R - Remember local variables
/nC - Ignore nonstandard usage /nS - No SOLD file created
/nC1 - INTEGER constants 4 bytes /nT - INTEGER*4, LOGICAL*4 default
/ D - DIRECT files without headers /nV - Not VAX interpretation
/nH - No Hardcopy source listing / W - Display Warning messages
/ I - Check subprogram Interfaces /nX - No Xref listing
/nK - Generate 80x87 code /nZ1 - Better SOLD debugging
BACK TO FAQs
1.1.13
What extra steps are needed to compile CALMET and CALPUFF on
Unix/Linux systems?
The CALPUFF system and associated processors are FORTRAN 95 codes were developed
using the Lahey F95 FORTRAN compilers. With a few minor changes, outlined below, the
codes will run on a range of Unix and Linux platforms.
Compiling a code using a 'new' compiler typically requires modifying non-conforming
usages in the code (these are detected by the compiler), reconfiguring the compiler
directives where appropriate to remove restrictions that do not affect the operation
of the code, and substituting calls to system subroutines that make the executable
platform-specific.
The CALPUFF system code has isolated compiler and platform-specific statements
in just a few subroutines and contain statements for several popular compilers.
The code as distributed, is configured for the Lahey F95 FORTRAN compiler on PCs
so that the alternate statements for other compilers/platforms are inactive (they
appear as comments). If the code is compiled on Unix workstations or Linux machines,
the blocks identified for Lahey F95 should be commented, and the corresponding
blocks for Unix system compilers should be activated (de-commented). Furthermore,
the proper set of compilation flags have to be used.
For Unix/Linux, the only subroutine to modify is COMLINE, which is located
at the very end of the CALUTILS.FOR file. This subroutine is the command line
processing routine, which is a system-dependent function. CALUTILS.FOR is
distributed as part of the CALMET, CALPUFF, CALPOST and POSTUTIL codes.
DGI FORTRAN Compiler in Linux
Extensive testing on Linux multi-processors using the DGI FORTRAN compiler
consistently show identical results to those obtained on a PC with codes
compiled with the FORTRAN Lahey 95 compiler (as distributed on this website),
provided the relevant changes are made to the COMLINE subroutine in CALUTILS.FOR
and the proper set of compilation flags are used.
In order to compile CALMET or CALPUFF on a Linux machine with the DGI FORTRAN
compiler, one has first to modify the COMLINE subroutine in CALUTILS.FOR.
Specifically, the Lahey F95-specific calls should be commented while the platform
specific calls should be activated. For example, for Unix or Linux compilers, the
changes are as follows:
BEFORE CHANGE (Lahey):
c ------------------
c --- Lahey compiler
c ------------------
call getcl(ctext)
c ----------------
c --- Sun compiler
c ----------------
c *** numargs=IARGC()
c *** if(numargs.ge.1)then
c *** call GETARG(1,ctext)
c *** endif
AFTER CHANGE (DGI Compiler):
c ------------------
c --- Lahey compiler
c ------------------
c *** call getcl(ctext)
c ----------------
c --- Sun compiler
c ----------------
numargs=IARGC()
if(numargs.ge.1)then
call GETARG(1,ctext)
endif
Secondly, the compilation command line has to include the following
compilation flags, all of which are important to reproduce PC-Lahey95
results:
For CALMET (enter on one command line):
pgf90 -O0 -Kieee -Ktrap=fp -Msave -tp k8-32 -L/home/software/pgi/linux86/6.2/liblf
calmet.for -o calmet.x
For CALPUFF (enter on one command line):
pgf90 -O0 -Kieee -Ktrap=fp -Msave -tp k8-32 -L/home/software/pgi/linux86/6.2/liblf
calpuff.for -o calpuff.x
Note that the path to the compilation library (set here at
/home/software/pgi/linux86/6.2/liblf) might have to be modified to point to the
library folder on your machine.
BACK TO FAQs
1.2.1 I switched to another application while running the GUI, and when I came back it
was not on the same screen?
If you open another application while running the CALMET/CALPUFF/CALPOST GUI, the
operating system will lose focus on the active screen of the GUI if you return to it by clicking
on the taskbar icon. As a result, the GUI may appear to not be responding to the user. You can
return focus to the active screen of the GUI by pressing the Alt+Tab keys until the focus returns
to the active screen of the GUI, or simply select the other application again, then minimize it.
BACK TO FAQs
1.2.2 How can I control the default directory settings and the default file extension
settings?
In the graphical user interface (GUI) for each of the three modules, i.e., CALMET, CALPUFF
and CALPOST, the default directory can be specified by selecting "Change Directory" from the
"File" menu item of the main GUI screen. The specified directory is maintained as the default
directory until it is changed by the user.
Similarly, the default filenames and file extensions can be specified from the main GUI screen by
selecting "Default Filenames" or "Default Extensions" from the "Setup" menu item. The
specified filenames and extensions are maintained as defaults until changed by the user.
Note that the desired default directories, filenames and file extensions must be specified for each
module separately, and are not required to be the same for each module.
BACK TO FAQs
1.3.1 Where can I get a summary of the processing steps for long range transport
application of CALPUFF in screening mode?
The processing steps for a CALPUFF application in screening mode are, in general, the same as a
typical model application, with the exception that CALMET is not used to process the
meteorological data. The main components for this application are selection of meteorological
data from one representative surface and one representative upper air station, identification of
source data including pollutant emission rates, establishing a receptor network, and selecting the
appropriate modeling options. The following four steps summarize the screening application:
CPRAMMET (or EPA's PCRAMMET) - processes meteorological data into ISC ASCII
format, including the extended format necessary for deposition and visibility calculations. Note
that although the inputs for both CPRAMMET and PCRAMMET are exactly the same, there are some differences between the two preprocessors
which are discussed in Section 1.3, 5 of the FAQ.
CALPUFF - calculates hourly concentrations and deposition fluxes of each modeled pollutant and
creates binary files containing hourly concentration, deposition flux and visibility-related parameters
(relative humidity) for use in the postprocessing step.
POSTUTIL - combines the binary dry and wet deposition flux files created by CALPUFF into a single
total deposition file. It can also be configured to calculate the total nitrogen and total sulfur
deposition fluxes from NO2, nitrates, HNO3, SO2 and sulfates, and include them in the total deposition
file.
CALPOST - reads the binary concentration and deposition flux files to calculate pollutant- and
averaging period-specific concentrations and deposition fluxes. This processor also calculates the
light extinction associated with the modeled concentrations to assess visibility degradation.
The CALPUFF screening application is specifically designed to assess impacts at distant Class I
areas. The details of the specific options and considerations can be found in either the
Interagency Workgroup on
Air Quality Modeling (IWAQM) Phase II Report or the
Federal Land Managers' Air Quality Related Values Workgroup (FLAG, December 2000) document.
A step-by-step guide for creating the appropriate input files for CALPUFF, POSTUTIL and
CALPOST can be found in a document titled "Guide for Applying the EPA Class I Screening
Methodology with the CALPUFF Modeling System (September 2001)."
BACK TO FAQs
1.3.2 How many years of meteorological data should be used when applying CALPUFF in
a screening mode?
For a regulatory analysis, such as that supporting a permit to construct a source of air pollution,
the considerations regarding the length of meteorological period are similar when applying
CALPUFF in screening mode as when applying other models. The EPA's Guideline on Air
Quality Models prescribes the use of five continuous years of representative meteorological data.
Also, the Interagency Workgroup on Air Quality Modeling (IWAQM) demonstrated the year-to-year variability in CALPUFF screening impacts using a five-year meteorological period in their
Phase II report. Based on this demonstration, IWAQM also recommends that five years of
meteorological data should be used with CALPUFF in the screening mode in order to identify long-range transport
impacts that could reasonably be considered to be the highest.
BACK TO FAQs
1.3.3 Can I run CALPUFF with an ISC-type meteorological data file that contains five
years of data, or do I need to parse the file into separate years first?
The CALPUFF model allows the meteorological data file to contain more than one year of data. The user can select the run
period by specifying the starting time (year, month, day, hour) and the run length (in hours) in the
input control file. In the CALPUFF Graphical User Interface (GUI), this can be specified in the
"Run Information" screen. In the CALPOST GUI, this can be specified in the "Process Options"
screen. For example, in order to use the data for 1988 from a file that contains the five-year
period of 1986-90, the starting time would be 1988, 1, 1, 1 and the run length would be 8784
hours.
The user may wish to evaluate the benefit of running the entire five-year period in one CALPUFF
run against available computer resources. The benefit of a single five-year CALPUFF run is that
the puffs that are generated near the end of one year can be accounted for at the beginning of the
next year, rather than starting each year with a "clean" domain. Due to this benefit a single five-year run may be preferred over five individual one-year runs. However, this is only a benefit
when the meteorological data set is a continuous five-year period because puffs should not be
carried over across non-continuous years. Also, the user should evaluate whether sufficient
computer disk space is available to store output files which can be quite large for a single five-year run.
When running the entire five-year period in a single CALPUFF run, the user must also consider
the type of impacts being calculated by CALPOST to determine whether there is a need to
evaluate only one year at a time. For example, when calculating the overall highest short-term
concentrations (averaging period of 24 hours or less), the entire five-year period can be used in a
single CALPOST run, but it may not be appropriate for calculating the highest of the second-highest
impacts which are often required to be based on a year-by-year analysis. Similarly, the annual
average impacts are often required to be based on the highest out of the five one-year averages
(note that although the user can specify an 8760-hour average to calculate annual averages in
CALPOST, it is not appropriate when leap years are included in the five-year period).
There are some formatting considerations when creating a single meteorological data file
containing more than one year of data. The header record (which contains the stations IDs and
the year information) must appear only once at the beginning of the file, and not at the beginning
of each year. The year reflected in the header record must correspond to the first year of data in
the file. Also, the data records must appear in chronological order, starting with the earliest year
and ending with the most recent year.
BACK TO FAQs
1.3.4 Should I apply a non-zero
minimum mixing height when running CALPUFF in a screening mode? If not, how will very low mixing
heights affect my results?
The meteorological data files created by CPRAMMET (and by EPA's PCRAMMET) can
sometimes have unrealistically low mixing heights, especially during early morning hours
immediately after sunrise. This usually occurs because of the way hourly mixing heights are
calculated by these preprocessors when the atmospheric conditions at sunrise are stable. The
CALPUFF model allows the user to specify a minimum mixing height to use via the ZIMIN
parameter in the input control file. For long-range transport CALPUFF screening analyses, the current default value
for ZIMIN is 50 meters. During model execution, any mixing heights that are below ZIMIN are
set to the user-specified value for ZIMIN.
The effect of very low mixing heights on pollutant impacts depends mostly on the effective release
height of the emissions and the transport time to the receptors of interest. For emissions with a low
effective release height (e.g., a surface-based non-buoyant area source), a low mixing height would
limit vertical mixing and could result in high ground-level impacts if the transport time to the receptors
of interest is short. For emissions with a high effective release height (e.g., a tall stack or very
buoyant release), the plume would entirely penetrate a low mixing height and would result in very small
ground-level impacts if transport time to the receptors of interest is short. For long-range transport
(e.g., several hours transport time), the temporal variation in mixing height and dispersion
processes would mix emissions to the surface and through a considerable depth, and the use of a ZIMIN of
50 meters is reasonable.
BACK TO FAQs
1.3.5 Is there a difference between CPRAMMET and the EPA's PCRAMMET
meteorological preprocessors, and if so, when should I use CPRAMMET?
The CPRAMMET preprocessor is based on the EPA's PCRAMMET preprocessor, and the basic
data processing routines between the two are identical. Also, the input and output structures for
both the preprocessors are same. Therefore, in many cases either of these preprocessors can be
used for a CALPUFF screening application. However, the user should note that there are some
incompatibilities between the EPA's PCRAMMET and CALPUFF which may require the use of
CPRAMMET. These include:
- PCRAMMET will not produce extended ISCST3 meteorological record variables
required for running CALPUFF, including friction velocity, Monin-Obukhov length,
relative humidity and solar radiation, when input data are provided in the CD144 format.
PCRAMMET will produce these variables only when SAMSON or HUSWO
meteorological data are used. The extended record variable fields are left blank when
CD144 data are used. CPRAMMET, on the other hand, will produce the ISCST3
extended record variables, when using CD144 surface meteorological data as input.
- PCRAMMET will not report a solar radiation value when an observed value is missing
from the SAMSON or HUSWO datasets. Instead the solar radiation field is left blank.
CPRAMMET incorporates an estimate of solar radiation (based on the solar elevation
angle and cloud cover) when it is not reported in any of the meteorological input file
formats (CD144, SAMSON, or HUSWO).
BACK TO FAQs
2.1.1 What terrain elevation data formats are supported in TERREL?
The following data formats are supported by the TERREL terrain preprocessor:
- 1-degree DEM (USGS)
- 7.5-minute DEM (USGS). Note that the USGS 7.5-min SDTS format must be converted
to DEM format prior to use in TERREL.
- 30-second DEM (USGS)
- 30-second ARM3 (CALPUFF CD-ROM from NTIS). Although this option is available,
it is obsolete and therefore seldom used.
- 30-second Lambert azimuthal projection
- 7.5-minute DMDF (Alberta Environmental Protection, Canada)
- GTOPO30
- Generic latitude/longitude format (New Zealand format containing latitude, longitude and
elevation on each record in free format)
- Generic X, Y, Z format (each record contains X, Y and elevation in free format)
Note that the TERREL preprocessor typically calculates the average of elevations of all points
available within each grid cell. Therefore, in selecting the appropriate data format to use in
TERREL, it is necessary that each grid cell contain at least one point, and preferably as many
points as feasible. For example, for a cell size of 5 kilometers, the GTOPO30 format can be used
because it has a 900-meter resolution and will therefore provide at least 25 points per cell.
BACK to FAQs
2.1.2 Where can I go to get terrain heights and land use data?
Information on obtaining terrain and land use data is provided below. Please note that the
availability of these data on the world wide web is subject to change as new options become
available or existing websites are reorganized.
Terrain height and land use data are available for all of the United States at:
http://edcwww.cr.usgs.gov/doc/edchome/ndcdb/ndcdb.html. Select the '1:250K DEM' option
for 1-degree Digital Elevation Model (DEM) terrain data. The data can be accessed either
alphabetically by filename, corresponding to the name of the USGS 1:250,000 scale topographic
map, by state, or by a graphical interface. Each terrain file covers a 1-degree by 1-degree area
corresponding to the east or west half of a 1:250,000 scale topographic map.
To access land use data, select the 'LULC' option from the webpage referenced above. The
1:250K land use data can also be accessed by filename, by state, or by a graphical interface.
Each 1:250K land use file covers the full 1-degree (latitude) by 2-degree (longitude) area
corresponding to a 1:250,000 scale topographic map. If a particular land use file is indicated as
not available through the graphical interface, it may still be available through one of the other
options. Once you have identified a land use file for downloading, select the file entitled
'grid_cell.gz' (do not select the file called 'land use'), or if accessing by state, select the file
identified as 'grid_cell: compressed'.
The 1-degree DEM is available for all of the contiguous United States, Hawaii, and most of
Alaska. Elevations are in meters relative to mean sea level. Spacing of the elevations along and
between each profile is 3 arc-seconds with 1,201 elevations per profile. The east-west spacing is
therefore latitude dependent, varying from 70 to 90 meters for the North American continent.
The 1-degree DEM data have an absolute accuracy of 130 meters in the horizontal and 30 meters
vertically. In Alaska, the spacing and number of elevations per profile varies depending on the
latitudinal location of the DEM. Latitudes between 50 and 70 degrees north have spacings at 6
arc-seconds with 601 elevations per profile and latitudes greater than 70 degrees north have
spacings at 9 arc-seconds with 401 elevations per profile. The 1:250K land use data are gridded
with a 200 meter spacing referenced to the UTM coordinate system.
Higher resolution terrain height data are available for some of the United States at the URL
address of: http://edcwww.cr.usgs.gov/doc/edchome/ndcdb/ndcdb.html. Select the
'1:24K DEM' option, and follow the link for the free downloads available at the GeoComm
International Corporation website. The 1:24K DEM data, also referred to as 7.5-minute DEM
data, is available in the Spatial Data Transfer Standard (SDTS) format. The data must be
converted to the native DEM format before using the data with the TERREL preprocessor.
Information on converting the SDTS data to DEM format is available on the GeoComm
International Corporation website.
The DEM data for 7.5-minute units correspond to the USGS 1:24,000 and 1:25,000 scale
topographic quadrangle map series for all of the United States and its territories. Each
7.5-minute DEM is based on 30- by 30-meter data spacing with the Universal Transverse
Mercator (UTM) projection. Each 7.5- by 7.5-minute block provides the same coverage as the
standard USGS 7.5-minute map series. The 7.5-minute Alaska DEM data correspond to the
USGS 1:24,000 and 1:25,000 scale topographic quadrangle map series of Alaska by unit size.
The unit sizes in Alaska vary depending on the latitudinal location of the unit. The spacing
between elevations along profiles is 1 arc second in latitude by 2 arc seconds of longitude. The
desired accuracy standard for 7.5-minute DEM's is a vertical root-mean-square error (RMSE) of
7 meters in the vertical.
BACK to FAQs
2.1.3 The 1-degree and 7.5-minute terrain height and land-use data files are compressed
and have no record delimiters. How should we process these data files for use by
the CALMET utility programs running on IBM PC's?
Step 1. As you download the required data file downloads, rename the files to have no more
than 8 characters in the name, and give it a 'gz' extension (e.g. portland-e.gz might be renamed to
porte.gz).
Step 2. Decompress the USGS files. GZIP.EXE is used to decompress each of the files by
typing the following command for each file:
gzip -d filename [return]
where, filename is the name of the USGS compressed file including the extension (i.e., porte.gz).
The result of running gzip will be a file with the same name but no file extension (i.e., porte).
Step 3. Add record delimiters. Two programs are provided in the CALMET utilities:
DD_DEM.EXE and DD_CTG.EXE. DD_DEM is for processing the DEM data files, and
DD_CTG is for processing the land-use data files. You will need to process each file
downloaded and uncompressed by gzip, to add record delimiters.
dd_dem [return]
dd_ctg [return]
DD_DEM and DD_CTG prompt the user for the names of the input and output files, with no
other control options, and may be used on PCs to perform the function of the DD UNIX utility
described by the USGS documentation.
BACK TO FAQs
2.1.4 How will I know whether my terrain elevation data is sufficiently resolved (i.e.,
small enough grid size) for my specific application?
In making CALMET and CALPUFF modeling runs, the goal is to find the optimum balance
between the desire to make the grid size as large as feasible in order to reduce the run times and
file sizes, and the desire to make the grid size small enough that CALMET can characterize the
terrain effects on the wind field. The optimum grid spacing for a particular application will
depend on the size of the modeling domain and the complexity of the terrain within the domain.
There are some obvious checks one can make. For instance, if your application involves some
terrain features (hills, valleys, etc.), CALMET needs to have as least 5 (preferably 10) grids to
resolve each terrain feature. So if you have a valley of particular interest that is typically 5 km
wide, one might like to have a grid spacing of 0.5 to 1-km terrain and land-use data.
Graphical analyses may also prove helpful. Consider the following sequence to develop three
graphical analyses: 1) contour the gridded data at what you think will be your final resolution, say
2-km; 2) shift the origin of the grid by ½ of the grid scale (left or right, up or down), re-grid the
data using twice the original grid scale, and contour the terrain heights, and 3) using the same
grid origin as in the second case, re-grid the data using ½ the original grid scale as in the first
case, and contour the terrain heights. Compare the three plots to see how terrain features are
'appearing' and 'disappearing', and decide whether you are comfortable with your original grid
scale. One could repeat these three steps using a different initial grid scale, but we should also
remember that these results are subjective in nature, so try not to over-engineer this analysis.
Common sense and experience should prevail.
BACK TO FAQs
2.1.5 What do I do if my terrain data and/or meteorological domain cross different UTM
zones?
UTM zones cover a 6-degree longitudinal width. In the range of ±45o latitude, this corresponds
to a zone width (east-west direction) of approximately 470-670 km depending upon latitude
(with the greatest width at the equator). In general, these zone sizes are sufficiently large to
accommodate most CALPUFF domains, especially at lower latitudes. However, for applications
that involve long-range transport from sources located near the edge of a UTM zone, the
CALPUFF domain may extend into the adjacent UTM zone. In these cases the coordinates must
be referenced to the same UTM zone so that the model can appropriately calculate the relative
distance and direction between two points, e.g., between a source and a receptor. To accomplish
this, the latitudes and longitudes of all points can be forced to convert into UTM coordinates that
are referenced to the same zone with the help of a conversion utility such as UTMGEO. In cases
where only UTM coordinates and UTM zones are known, the UTMGEO utility can first convert
the UTM coordinates of all UTM zones into latitudes and longitudes, and then re-convert them to
UTM coordinates by referencing them to the same zone.
Note that the TERREL preprocessor will do the appropriate conversions of the UTM grid terrain
data. However, for source locations and meteorological data stations, the user must do the
conversions.
BACK TO FAQs
2.2.1 What land
use data formats are supported in CTG and PRELND1?
The following land use data formats are supported by the CTG and PRELND1 land use
preprocessors:
- CTG (USGS) - Composite Theme Grid (for US)
- Global Dataset (USGS) - for the entire world
- ARM3 - Must process using PRELND1.
Note that for preprocessing land use data, the use of CTG (i.e., CTGCOMP and CTGPROC) is
preferred over PRELND1. The ARM3 data, which require the use of PRELND1, are not readily
available, and are not recommended because they are very old compared to the Global dataset.
BACK TO FAQs
2.2.2 Where can I go to get terrain heights and land use data?
Information on obtaining terrain and land use data is provided below. Please note that the
availability of these data on the world wide web is subject to change as new options become
available or existing websites are reorganized.
Terrain height and land use data are available for all of the United States at the URL address of:
http://edcwww.cr.usgs.gov/doc/edchome/ndcdb/ndcdb.html. Select the '1:250K DEM' option
for 1-degree Digital Elevation Model (DEM) terrain data. The data can be accessed either
alphabetically by filename, corresponding to the name of the USGS 1:250,000 scale topographic
map, by state, or by a graphical interface. Each terrain file covers a 1-degree by 1-degree area
corresponding to the east or west half of a 1:250,000 scale topographic map.
To access land use data, select the 'LULC' option from the webpage referenced above. The
1:250K land use data can also be accessed by filename, by state, or by a graphical interface.
Each 1:250K land use file covers the full 1-degree (latitude) by 2-degree (longitude) area
corresponding to a 1:250,000 scale topographic map. If a particular land use file is indicated as
not available through the graphical interface, it may still be available through one of the other
options. Once you have identified a land use file for downloading, select the file entitled
'grid_cell.gz' (do not select the file called 'land use'), or if accessing by state, select the file
identified as 'grid_cell: compressed'.
The 1-degree DEM is available for all of the contiguous United States, Hawaii, and most of
Alaska. Elevations are in meters relative to mean sea level. Spacing of the elevations along and
between each profile is 3 arc-seconds with 1,201 elevations per profile. The east-west spacing is
therefore latitude dependent, varying from 70 to 90 meters for the North American continent.
The 1-degree DEM data have an absolute accuracy of 130 meters in the horizontal and 30 meters
vertically. In Alaska, the spacing and number of elevations per profile varies depending on the
latitudinal location of the DEM. Latitudes between 50 and 70 degrees north have spacings at 6
arc-seconds with 601 elevations per profile and latitudes greater than 70 degrees north have
spacings at 9 arc-seconds with 401 elevations per profile. The 1:250K land use data are gridded
with a 200 meter spacing referenced to the UTM coordinate system.
Higher resolution terrain height data are available for some of the United States at the URL
address of: http://edcwww.cr.usgs.gov/doc/edchome/ndcdb/ndcdb.html. Select the
'1:24K DEM' option, and follow the link for the free downloads available at the GeoComm
International Corporation website. The 1:24K DEM data, also referred to as 7.5-minute DEM
data, is available in the Spatial Data Transfer Standard (SDTS) format. The data must be
converted to the native DEM format before using the data with the TERREL preprocessor.
Information on converting the SDTS data to DEM format is available on the GeoComm
International Corporation website.
The DEM data for 7.5-minute units correspond to the USGS 1:24,000 and 1:25,000 scale
topographic quadrangle map series for all of the United States and its territories. Each
7.5-minute DEM is based on 30- by 30-meter data spacing with the Universal Transverse
Mercator (UTM) projection. Each 7.5- by 7.5-minute block provides the same coverage as the
standard USGS 7.5-minute map series. The 7.5-minute Alaska DEM data correspond to the
USGS 1:24,000 and 1:25,000 scale topographic quadrangle map series of Alaska by unit size.
The unit sizes in Alaska vary depending on the latitudinal location of the unit. The spacing
between elevations along profiles is 1 arc second in latitude by 2 arc seconds of longitude. The
desired accuracy standard for 7.5-minute DEM's is a vertical root-mean-square error (RMSE) of
7 meters in the vertical.
BACK TO FAQs
2.2.3 The 1-degree and 7.5-minute terrain height and land-use data files are compressed
and have no record delimiters. How should we process these data files for use by
the CALMET utility programs running on IBM PC's?
Step 1. As you download the required data file downloads, rename the files to have no more
than 8 characters in the name, and give it a 'gz' extension (e.g. portland-e.gz might be renamed to
porte.gz).
Step 2. Decompress the USGS files. GZIP.EXE is used to decompress each of the files by
typing the following command for each file:
gzip -d filename [return]
where, filename is the name of the USGS compressed file including the extension (i.e., porte.gz).
The result of running gzip will be a file with the same name but no file extension (i.e., porte).
Step 3. Add record delimiters. Two programs are provided in the CALMET utilities:
DD_DEM.EXE and DD_CTG.EXE. DD_DEM is for processing the DEM data files, and
DD_CTG is for processing the land-use data files. You will need to process each file
downloaded and uncompressed by gzip, to add record delimiters.
dd_dem [return]
dd_ctg [return]
DD_DEM and DD_CTG prompt the user for the names of the input and output files, with no
other control options, and may be used on PCs to perform the function of the DD UNIX utility
described by the USGS documentation.
BACK TO FAQs
2.2.4 What can go wrong when
processing land use data?
There are a few problems that may occur during the processing of land use data that users should
be aware of. The occurrence of these problems may depend upon the resolution of the land use
data relative to the resolution of the meteorological grid being used in CALMET. One potential
problem is the presence of power lines. Since the land use code for power lines falls under the
urban category, this may show up as a thin line of urban land use across part of the domain.
Since power lines are not well represented by urban dispersion options in the model, these
features should be removed from the land use data before processing the data in CALMET.
Another potential problem occurs because missing land use data are initially assigned as
large water bodies (land use datasets typically exclude over-ocean areas). Such missing data
should be filled based on land use patterns in neighboring grid cells, or through examination
of topographic maps of the area, before continuing with the processing. An actual body of
water, such as a lake or large river, may become discontinuous if the meteorological grid
spacing is too large relative to the resolution of the land use data. In this case, the
data should be modified to better reflect the continuity of the particular water body.
BACK TO FAQs
2.2.5 Explain the QA threshold for processing of land use data.
The QA threshold is designed to test for the number of data points available per cell. The default
threshold is set to 75%, i.e., any cell that has less than 75% of the average number of data points
available for all cells is flagged. The user can then investigate to determine if data are missing.
BACK TO FAQs
2.2.6 What do I do (or where do I go) if there is no land use data for my area of interest
from the USGS website?
Global land use data with a 1 kilometer resolution is available at the following url:
http://edcdaac.usgs.gov/glcc/glcc.html. Depending on the scale of the application,
this data may be appropriate if the USGS 1:250K land use data are not available. Also, if the
1:250K land use data are not available through the graphical interface on the USGS website, the
data may still be available through the option to select the data by filename or by state.
BACK TO FAQs
2.3.1 What upper air data formats are supported?
The following upper air data formats are supported by the READ62 preprocessor:
- TD-6201 (fixed block only).
- FSL (original format)
BACK TO FAQs
2.3.2 What are the considerations in selecting upper air sites a) for long-range transport
applications, and b) for complex flow applications.
For all types of applications, the minimum requirement is that at least one upper air station must
be selected. This is true even when using MM5 data. However, in a typical application, the user
should include all available upper air stations that are considered to be suitable. As a starting
point, all stations within the modeling domain should be selected. In addition, the next nearest
station outside the domain in each direction should be selected to help in the interpolation of data
up to the edge of the domain. Once the stations have been identified, the user should examine
the data for completeness. If significant amounts of data are found missing, the user must either
consider filling in the data in some suitable manner, or if there are large data gaps or no
suitable way to fill in the missing data, the user may consider excluding that station.
For complex flow applications which often involve significant terrain features, the representativeness of data is an important consideration. In
evaluating representativeness, the user should determine whether data are available at key
terrain elevations as might be anticipated as being needed for the application. Then the switches within CALMET can be adjusted to
either extract only the representative soundings from the data, or to weight each sounding based
on its representativeness for the specific application. (See FAQs on CALMET switch settings.)
BACK TO FAQs
2.3.3 How can I tell if critical upper air data are missing?
Read62 performs the following QA checks relevent to CALMET:
- flag data missing at bottom or top of sounding
- check that first layer is at ground
- flag if pressure increases with decreasing level number
- flag if elevation decreases with increasing level number
- flag WD < 0 or WD > 360 degrees
- flag WS < 0
- flag T < TMIN, T > TMAX (TMIN set at 175 K (-99 C, -146 F), TMAX set at 322 K (120 F))
- flag P < PMIN, P > PMAX in final sounding
- check for missing height (FSL format uses 32767 as missing value indicator)
- (NOTE: delta pressure & elevation checks exclude layers with missing data.)
The list file created by READ62 contains warning messages pointing to the missing
data. The user should carefully evaluate and address each warning message.
The user is advised to pay close attention to the first sounding level of each observation. The first
sounding is usually at the ground level. So, for example, if the first sounding is at a 150-meter
level, the ground elevation at the station would be 150 meters. If in a subsequent measurement
the soundings start at a higher elevation, it would indicate that the first level is missing.
BACK TO FAQs
2.3.4 How can I deal with missing soundings, e.g., if lowest levels are missing, or if the
soundings do not go high enough, or if complete soundings are missing?
The user should examine the warning messages in the READ62 list file to determine the type and
extent of missing data. If only certain parameters are missing, e.g., surface-level temperature,
then the data can be substituted from another representative station. The representativeness of
the substituted data is a key element and the user should keep in mind that the most
representative station may not be the nearest station. If significant data are missing in a given
sounding, e.g., all data above 1 km level are missing, it is generally advisable to replace the entire
sounding rather than mixing data from two different soundings. Similarly, if the entire sounding
is missing, it can be replaced from another representative data set.
To replace entire soundings, the user can obtain data from the Model Output Location Time
Series (MOLTS) database (available at
http://dss.ucar.edu/pub/gcip/). However, given that the MOLTS database is
only available for recent years, this may not always be an option. Another source for
substitution is the nearest grid point of any available MM4 or MM5 data, which is
often preferred over the MOLTS database. In many cases if the top level is missing from a
sounding, the user can often persist the next lower level, e.g., the 3.5 km level could
be persisted to the 4.5 km level. In some cases, however, it may not be necessary to
fill for occurrences of missing data at highest levels in the upper air soundings, if these
levels are above the top of the CALMET domain defined for the application.
When substituting data, the user should always make sure that the time period of the replacement
data is the same as the missing data. For example, it is not appropriate to use a 0Z sounding to
replace a missing 12Z sounding. Similarly, it is not appropriate to interpolate between two 0Z
soundings to obtain a 12Z sounding. The user should also make sure to adjust elevation levels
between two stations when substituting data because all elevations are referenced to mean sea
level (MSL).
When using data from international stations, the user is cautioned that quite often the data are
only reported for mandatory levels, e.g., surface, 850, 750 and 500 millibar levels, and may not
be appropriate to use in a given application.
BACK TO FAQs
2.3.5 What do I do if my meteorological data stations and/or the meteorological domain
cross different time zones?
This is generally not a problem because the upper air stations are referenced to the Greenwich
Mean Time (GMT). The model automatically calculates the appropriate time shift based on the
required user inputs which include the reference time zone and the time zone of each station.
However, if a given station is not referenced to GMT, then it must be adjusted to GMT prior to
using as input.
Note that the same is true for surface and precipitation data wherein the model automatically
calculates the appropriate time shift based on the user inputs.
BACK TO FAQs
2.4.1 What surface data formats are supported?
The following surface data formats are supported by the SMERGE preprocessor:
- CD-144
- SAMSON
- HUSWO
- DATSAV3 (TD-9956)
The CD-144, SAMSON and HUSWO formats can be directly input into SMERGE. However,
the DATSAV3 data must first be converted into the CD-144 format using the DATSAV
program. Regarding the DATSAV data, note that only the abbreviated, space-delimited
DATSAV3 format is supported, and not the full DATSAV3 format. It is currently not
included on a standard CD-ROM product available from National Climatic Data Center
(NCDC), and must be specifically obtained from the
NCDC in that
format.
The only format supported by the METSCAN program is the CD-144 format.
Note that the surface data available from the EPA's SCRAM website can be used by first
converting it into CD-144 format using the MET144 program, which is also available from the
SCRAM website.
BACK TO FAQs
2.4.2 What are the considerations in selecting surface sites, a) for long-range transport
applications, and b) for complex flow applications?
Generally, the same considerations apply when selecting surface stations as when selecting upper
air stations. The user should select all stations within the meteorological domain. The user
should also select a number of stations outside the domain in each direction to help interpolate data up to
the edge of the domain. Unless limited computer resources are available, or file size limitations
are a concern, the user can select more stations than needed because the model will automatically
ignore data that are not relevant.
The CALMET meteorological preprocessor allows stations with missing data to be included as
input stations. For example, stations that record only daytime data or 3-hourly data as opposed to
hourly data, or stations with no cloud cover data, are acceptable as input. The only requirement
is that a valid value must be available for each parameter for each hour from at least one of the
stations, with the exception that precipitation code could be missing from all stations. Without
the code, CALMET can determine if the precipitation is frozen by using the temperature data.
Note that the surface data available from the EPA's SCRAM website can be used by first
converting it into CD-144 format using the MET144 program, which is also available from the
SCRAM website.
BACK TO FAQs
2.4.3 Can ASOS data be used with CALMET, and are there any drawbacks to using such
data?
Most National Weather Service (NWS) observing stations at major airports in the U.S. have now
been upgraded to use the Automated Surface Observing System (ASOS) for collecting and
reporting routine weather observations, in place of data collected by a human observer.
Depending on the format of surface data being used, ASOS data may be coded differently than the
human observerations. One important distinction for air quality modeling is that the ASOS
derived cloud cover and ceiling height data are limited to detection of cloud bases below 12,000
feet. The SMERGE preprocessor for surface meteorological data can be run with ASOS data,
provided the data are available in one of the supported formats (see Section 2.4, 1 of the FAQ).
Regarding any potential drawbacks to using ASOS data with CALMET, as with the use of any
data, the answer depends on a determination of the representativeness of the data for a particular
application. An EPA study (EPA, 1997) examined the sensitivity of results from the ISCST3
model to use of ASOS data vs. use of human observer data. This study concluded that for some
applications the model results were significantly affected by the use of ASOS data, and especially
due to the limit of 12,000 feet for the ceiling height measurement. Another study (Atkinson, et
al., 2000) documented a bias toward an increase in the frequency of calm winds for ASOS data
as compared to pre-ASOS observations for a particular station. Since the CALMET preprocessor is
typically run with data from multiple upper air and surface NWS stations, in addition to any
available representative on-site data, the sensitivity of CALMET results to use of ASOS data
may be expected to be more limited. As with any application of the CALMET/CALPUFF
modeling system, concurrence on the selection of meteorological data, whether ASOS or not,
should be obtained from the appropriate regulatory agencies.
EPA, 1997: Analysis of the Affect of Asos-derived Meteorological Data on Refined Modeling,
EPA-454/R-97-014. U.S. Environmental Protection Agency, Research Triangle Park, NC.
(available at http://www.epa.gov/scram001/index.htm under the Meteorological Data, Guidance
menu)
Atkinson, D.G., R.W. Brode, and J.O. Paumier, 2000: Analysis of the Effects of ASOS Data on
Air Dispersion Modeling. Preprints of the 11th Joint Conference on Applications of Air
Pollution Meteorology, January 9-14, 2000, American Meteorological Society, Boston, MA.
2000.
BACK TO FAQs
2.4.4 How does
CALMET handle missing surface data?
First, it is important to note that missing surface data may not be a critical flaw because
CALMET allows stations with missing data to be processed. Although it is preferred to have
complete data for all stations, the minimum requirement is that there must be at least one valid value
for each parameter for each hour from any of the input stations. Therefore,
when selecting the surface stations the user should be aware that stations with missing data, e.g.,
stations with only daytime data or 3-hourly data, should not automatically be rejected. However,
the user should also be aware that the selected stations should (in total) make a complete data set
and cannot, for example, be all daytime-only stations because this will result in a data gap that will
halt the model.
BACK TO FAQs
2.4.5 How can I deal with missing surface data?
During execution, CALMET generates a list of missing data which the user can examine to
determine the type and extent of missing data. If a few hours of data are found to be missing,
these can be filled in either by interpolation or substitution from another representative station.
However, if large data gaps are found, e.g., if only daytime data are available from all of the
input stations, the data may be deemed to be not acceptable. In such a case, CALMET will
indicate that insufficient data are available. To address this problem, the user may have to select
alternate years and/or additional stations. This is one of the reasons why the user may consider
selecting all available stations that are suitable for the application.
BACK TO FAQs
2.4.6 Does CALMET define a day as hours 00 to 23 or as hours 01 to 24, and how does
CALMET and it's preprocessors handle this issue for different types of input
meteorological data?
The CALPUFF modeling system runs on a Hour 0-23 clock wherein Hour 0 is the midnight hour.
Therefore, "Day 2/Hour 0" is the same as "Day 1/Hour 24." The data for this hour corresponds
to that collected between 11 pm and 12 midnight on Day 1. This system is consistent with the
"hour ending" system used in recording data in CD-144 and DATSAV3 formats. In other
formats, such as SAMSON and HUSWO, the data are recorded on a Hour 01-24 basis.
However, CALMET will appropriately process the data recorded in either format, and the user
does not have to change the input data.
The user should note that in a full year of National Weather Service (NWS) data obtained from
National Climatic Data Center (NCDC), the records run from "Day 1/Hour 0" through
"Day 365/Hour 23." For a full-year model run, such as those required for regulatory applications,
it is recommended that the data for last hour also be obtained and appended at the end of the data
file. This last hour would be recorded as "Day 1/Hour 0" of the next year.
BACK TO FAQs
2.5.1 What precipitation data formats are supported in PXTRACT?
The only format supported by PXTRACT precipitation preprocessor is the National Climatic
Data Center (NCDC) TD-3240 data. These data are available from NCDC in fixed record length
as well as variable record length formats. Both of these formats are supported.
The user also has the option of creating a free-formatted precipitation data file that can be input
directly into CALMET. This option eliminates the need to run PXTRACT and PMERGE
preprocessors, and is generally useful for short CALMET runs (e.g., screening runs) for which
the data can easily be input manually. An example of the free-formatted file is provided below
along with a description of the necessary inputs.
Example free-formatted (ASCII) PRECIP.DAT file
89 1 1 89 2 9 6 4
412360 417943 417945 412797
89 1 1 0.000 0.000 0.000 9999.000
89 1 2 0.000 0.254 0.000 0.000
89 1 3 0.000 0.000 0.762 0.000
.
.
.
89 2 8 0.508 0.000 0.000 0.000
89 2 9 0.000 0.000 0.000 0.254
Description of inputs required in a free-formatted (ASCII) PRECIP.DAT file
Record 1:
Starting Year/Julian Day/Hour
Ending Year/Julian Day/Hour
Time zone (5=EST, 6=CST, etc.)
Number of input precipitation stations
Record 2:
Station code for each precipitation station
Record 3:
Year/Julian Day/Hour
Precipitation rate in mm/hour for each station in order (Missing = 9999)
(Note: Each input row is limited to 132 columns and additional rows are allowed
to enter the precipitation rates for all of the stations. Record 3 is repeated for each
hour)
BACK TO FAQs
2.5.2 What are the considerations in selecting precipitation sites, a) for long-range
transport applications, and b) for complex flow applications?
An important criterion is that the user should select as many precipitation stations as are
available, keeping in mind that generally there are many more precipitation stations available as
compared to surface data stations. Therefore, it is advisable to use all suitable stations within the
modeling domain and in the area immediately outside the domain.
When assessing the suitability of a station, the
user should determine whether the station reports hourly precipitation or accumulated
precipitation. Although hourly precipitation rates are preferred, stations with accumulated
precipitation can be used if accumulation periods are relatively short, say no more than
6 hours. The accumulated precipitation is distributed equally among all hours in the
accumulation period. Since this assumption of equal distribution over the accumulation period
may only be appropriate for short periods, the user should exercise caution when data are
reported over large accumulation periods. For extremely large accumulation periods, say
weekly accumulation, the data should generally be avoided. The user is advised to review
the PXTRACT list file which lists all accumulation periods to identify any such large periods.
Note that precipitation records, such as those contained in the NCDC TD-3240 data, do not
include precipitation codes, i.e., liquid vs. frozen precipitation. CALMET obtains the
precipitation codes from the surface data file (SURF.DAT) and passes them to CALPUFF via the
CALMET.DAT file.
For near-field applications, the user may wish to evaluate whether wet removal is an important
consideration given that the transport duration may be very small. For such applications, the user
can sometimes ignore precipitation data because the amount of plume material removed by wet
scavenging may be negligible.
BACK TO FAQs
2.5.3 Can I use the hourly precipitation data from my SAMSON meteorological data file,
and if so, how do I extract and merge the data with precipitation data from other
stations?
Although the surface data in SAMSON format contains hourly precipitation data, currently these
data cannot be read by the PXTRACT precipitation preprocessor. However, this is generally not
a concern because the NCDC TD-3240 data are available for most precipitation stations,
including the National Weather Service (NWS) stations for which SAMSON data are available.
Note that for a CALPUFF screening application, wherein the CPRAMMET or EPA's
PCRAMMET preprocessors are used to create ISC-type ASCII meteorological data, the hourly
precipitation data contained in the SAMSON format are indeed used.
BACK TO FAQs
2.6.1 What mesoscale data
formats are supported in CALMM5?
The CALMM5 preprocessor accepts data from the
NCAR/Penn State mesoscale meteorological models:
- MM4, "Generation 4"
- MM5 (version 2), "Generation 5"
CALMM5 converts these data into either the MM4.DAT
or MM5.DAT formats read by CALMET.
The MM4 data are in the Interagency Workgroup on Air Quality Modeling (IWAQM) 1990
CD-ROM format. These are available from the National Climatic Data Center (NCDC) on
a 12 CD set for the whole Unites States (including southern Canada and northern Mexico)
at:
http://nndc.noaa.gov/?http://ols.nndc.noaa.gov/plolstore/plsql/olstore.prodspecific?prodnum=C00451-CDR-A0001. The
MM4 data contain fewer parameters than the MM5 data and are appropriate to use if the additional
parameters are not needed. The additional parameters contained in MM5 include cloud and
precipitation data. Also note that CALMM5 only supports data created by version 2 of the MM5
model. Any data from the version 3 of the model must be converted to the version 2
format. A conversion utility is available from UCAR.
BACK TO FAQs
2.7.1 Which CALMET settings typically require expert judgement for tailoring the
analysis for a specific application?
There are seven (7) CALMET settings one should carefully examine: BIAS, IEXTRP, TERRAD,
R1, R2, RMAX1, and RMAX2. Let's take a look at each of these.
BIAS - affects how the initial Step 1 winds will be interpolated to each grid cell in each vertical
layer based on upper air and surface observations. The BIAS value ranges from -1 to +1, and a
value is input for each vertical layer. Normally, BIAS is set to zero (0) for each vertical layer,
and the upper air and surface wind and temperature observations are given equal weight in the
1/r2 interpolations used to initialize the computational domain. By setting BIAS to -1, we
eliminate upper-air observations in the interpolations for this layer. Conversely by setting BIAS
to +1, we eliminate the surface observations in the interpolations for this layer. An example
where non-default settings for BIAS may be used is for a narrow, twisting valley, where the only
upper-air observations were 100 km to the west, and the only local surface wind observations
were in one location in the valley. For this example, we might set BIAS to -1 within the valley
forcing surface data only to be used for the lowest layers, and BIAS to +1 above the valley
forcing upper air data only to be used aloft, and BIAS might go from -1 to +1 in the transitional
layers at the top of the valley.
IEXTRP - affects vertical extrapolation of surface winds,and whether layer 1 data from upper air
stations are ignored, and is normally is set to -4. Setting IEXTRP < 0, means that the lowest
layer of the upper-air observation will not be considered in any interpolations. Since upper-air
observations are only taken every 12-hours, the time-interpolated surface wind values from the
upper-air observations are usually of no use. When IEXTRP is set to -4, similarity theory is used
to extrapolate the surface winds into the layers aloft, which provides more information on
observed local effects to the upper layers. Setting IEXTRP to 0 means that no vertical
extrapolation from the surface wind data is used.
TERRAD - has meaning only if IWFCOD is 1 (i.e., diagnostic winds are to be computed), and is
used in computing the kinematic effects (IKINE), the slope flow effects (ISLOPE), and the
blocking effects (IFRADJ) on the wind field. You can view this as the distance CALMET
'looks' at in computing each of these effects. For instance, the terrain slope is needed to compute
the slope flow. If TERRAD is too small, then the nearby valley wall will not be seen. If
TERRAD is too large, then the hill three valleys away is seen, instead of the one nearby. Odds
are TERRAD is going to be of order 5 to 10 grid lengths expressed in km (see discussion
on terrain resolution).
R1 and R2 - are used in the construction of the Step 2 wind field, where the observed winds are
'blended' in with the Step 1 winds. R1 represents the distance from a surface observation station
at which the surface observation and the Step 1 wind field are weighted equally. R2 represents
the comparable distance for winds aloft. Remember, the Step 1 winds contain all the results of
the diagnostic wind model (kinematic, slope and blocking effects). If you give too much weight
to the observations, then you will essentially erase all the information generated in creating the
Step 1 winds. The formula used in this 'blending' operation is:
where (u,v)'2 are the Step 2 wind components, (u,v)1 are the Step 1 wind components, (uobs,vobs)
are the observed winds, R is R1 for the surface layer and R2 for all layers aloft, and Rk is the
distance from the grid cell to the k-th observation location.
By setting R1 and R2 to small values (say of order 1 km or so) then only when Rk is of order 1
km will the observation have much influence in developing the Step 2 winds. Typically, R1 and
R2 are set to fairly small values, on the order of the grid scale size or less.
RMAX1 and RMAX2 - are also used in the construction of the Step 2 wind field, where the
observed winds are 'blended' in with the Step 1 winds. Any observation for which Rk is greater
than RMAX1 in the surface layer, or RMAX2 aloft is excluded from the above 'blending'
formula. We can use RMAX1 and RMAX2 to exclude observations from being inappropriately
included (as they are in the next valley, on the other side of a mountain, etc.). Note, if you are
using RMAX1 and RMAX2 to exclude observations, then you do not want to set LVARY to T,
as then CALMET will increase the values or RMAX1 and RMAX2 to at least capture the nearest
observation, regardless of whether this makes sense.
BACK TO FAQs
2.7.2 What options are available for initializing the wind field in CALMET, and how do I
determine the best option for a particular application?
The following options are available for initializing the wind field in CALMET:
- Gridded field from a prognostic model, e.g., MM-data
- Objective analysis of all available observations
- Spatially-uniform guess field
- DIAG.DAT file
The first option, i.e., the use of MM data, is preferred because it provides a spatially-varying
wind field and takes into account geographic features to develop mesoscale flow patterns. The
MM data provide a good starting point in the form of an initial guess wind field which can be
further refined within CALMET based on local topography and weather observations. The
second option involves an objective analysis of all available surface and upper-air observations.
This option will also generate a spatially-varying wind field. When using this option,
the user is advised to allow the surface data to be extrapolated vertically, unless the surface data are strongly influenced by local terrain effects such as for stations located in a valley. See Section 2.2.1 of the
CALMET user's guide for details.
The last two options are remnants of older versions of the model and are generally not
recommended. The spatially-uniform guess field can be used for some near-field applications
where on-site data are available. The DIAG.DAT file allows the user to initialize the wind field by layer. However, instead of inputting data via the DIAG.DAT
file, it is recommended that the interpolation and spatial averaging routines within CALMET be
used (via the second option above) to initialize the wind field.
BACK TO FAQs
2.7.3 How do I select the appropriate grid spacing for my application of CALMET?
The most appropriate grid spacing for a particular
application of CALMET will of course depend primarily on the size of the domain of interest. For
a long range transport application involving transport distances of 100 to 200 kilometers or more,
the grid spacing will be larger than for an application involving near field impacts and complex
flows. It is important to look at the terrain features within the domain, and ensure that the
important features will be adequately resolved by the selected grid spacing (see discussion in
Section 2.1, 4 of the FAQ). If the grid
spacing is too large, then a valley may become discontinuous or an isolated hill may be smoothed
out. One method for evaluating whether the grid spacing is adequate for a particular application
is to select a light wind case where terrain induced flows will dominate and compare the resulting
wind field using the selected grid spacing with a simulation using twice the resolution (half the
grid spacing). If the wind field patterns are similar, then it is likely that the selected grid
spacing is adequate. A typical application of CALMET on a PC will include about 100 to 200
grid cells in both the x- and y- directions. Therefore, for a domain that is about 200 kilometers
on each side, a grid spacing of about 1 to 2 kilometers should be adequate. Smaller domains for
near-field applications may require a grid spacing of about 250 meters. Use of 20 to 30 grid cells
in each direction is generally not adequate, regardless of the size of the domain.
BACK TO FAQs
2.8.1 Can I use PRTMET to create a file that allows me to plot how meteorological
conditions vary over time at a single receptor?
Yes, this option is available in PRTMET. The user can specify the grid points to process in the
input control file and PRTMET will generate a time series at each of the grid points.
BACK TO FAQs
2.8.2 Can I use PRTMET to create files that will allow me to plot how meteorological
conditions vary over the entire domain (or some subdomain)?
Yes, there is an option available within PRTMET that allows the user to create either a grid file
(*.GRD) or an ASCII data file (*.DAT) in (X,Y,Z) format for the entire domain for any of the
meteorological conditions. The *.GRD file can be input directly into Golden Software's
SURFER utility to draw isopleths showing spatial variations of the specific meteorological
condition or to create vector plots of winds. The *.DAT file can be input either into SURFER or any other plotting utility to generate various types of plots.
BACK TO FAQs
3.1.1 How can I treat monthly or seasonal variations in emission rates?
CALPUFF allows the input of variable emission rates. The following options are available,
several of which are similar to those available in the EPA's ISCST3 model:
- Diurnal cycle (24 values)
- Monthly cycle (12 values)
- Hour and season (96 values)
- Wind speed and stability (36 values)
- Temperature (12 values, one for each of 12 pre-defined temperature categories)
- Arbitrary (via an external emissions file containing hourly emissions for the entire
modeling period)
Each option is available for all source types, i.e., point, area, volume and line sources,
with the exception of buoyant area sources for which only the last option (an external
BAEMARB.DAT file) is available. Also, to provide flexibility, the model allows the emissions
for each source and each pollutant to vary on a different cycle.
The user is allowed to either enter actual emission rates or scaling factors for any of the above
options. In other words, the user can either enter a unit emission rate in the source constant data
(Input Groups 13b, 14b, etc.) and actual emissions in the source variable emissions data (Input
Groups 13d, 14d, etc.), or an actual emission rate in the source constant data and multiplicative
scaling factors in the variable emissions data.
BACK TO FAQs
3.1.2 How can I track the impact of one or more sources or source types?
The most straightforward way to keep track of impacts from different sources or groups of
sources is to run each of them separately. The impacts from each individual model run can then
be evaluated separately or combined using the CALSUM postprocessor.
Note that when sources are modeled in separate CALPUFF runs and chemical transformation
calculations are performed, there may be a need to account for non-linear transformations
resulting from varying background ozone and ammonia concentrations and relative humidity.
The POSTUTIL postprocessor can be used for this purpose.
BACK TO FAQs
3.2.1 Where do I get background ozone data?
The ozone data are available from the following two sources:
AIRS (Aerometric Information Retrieval System) is a computer-based repository of information
about airborne pollution in the United States and various World Health Organization (WHO) member countries. The system is administered by
the U.S. Environmental Protection Agency (EPA), Office of Air Quality Planning and Standards (OAQPS), Information Transfer and Program
Integration Division (ITPID), located in Research Triangle Park, North Carolina. AIRS is installed on the IBM computer system at the EPA's
National Computer Center (NCC) in Research Triangle Park, North Carolina. Any organization or individual with access to the EPA computer
system may use AIRS to retrieve air pollution data. To retrieve information directly from AIRS, you need to obtain an account on the EPA
mainframe computer system and pay the applicable computer usage charges. Information about obtaining a computer account is available from
the Technical Support Center (help desk) at the EPA National Computer Center, telephone 800-334-2405 (toll free) or 919-541-7862.
Note that the AIRS ozone network provides hourly ozone concentrations only during the ozone
season (April-October) while CASTNET provides hourly data for the whole year.
Monitored ambient ozone concentrations can also be obtained from State and Local Ambient
Monitoring Stations (SLAMS) and National Ambient Monitoring Stations (NAMS) network.
While CASTNET stations are located in rural areas, the SLAMS/NAMS are mostly located in
urban areas. Further information regarding SLAMS/NAMS as well as AIRS summary data are
available at the EPA's AIRData
website
BACK TO FAQs
3.2.2 How can I vary the ozone background concentration for each grid square and hour?
The hourly ozone data file (OZONE.DAT) contains all available information to the CALPUFF
model, which includes station coordinates and the hourly ozone concentrations. The ozone data
are normally not available for each grid cell. Therefore, within the CALPUFF model, the ozone
concentration from the station that is nearest to the puff location during any given hour is used.
Note that although it is preferred to have a complete set of hourly ozone concentrations at each
station, missing values are allowed in the OZONE.DAT file. For each puff, the value from the
closest available station will be used by the model during each hour. If for any hour the values
are missing from all stations, the model will use the appropriate backup monthly value provided
by the user in the CALPUFF input control file.
BACK TO FAQs
3.2.3 Where do I get background ammonia data?
Ambient ammonia concentrations are normally not monitored. One source of ammonia
concentrations is the Federal Land Managers' Air Quality Related Values Workgroup (FLAG,
December 2000) document which provides three specific values depending upon land use, i.e.,
10 ppb for grasslands, 1 ppb for arid lands, and 0.5 ppb for forests.
It is also possible to account for ambient ammonia concentrations by specifically modeling
sources of ammonia, which will keep track of ground-level ammonia concentrations with time
and location. The modeled impacts can then be used by POSTUTIL to perform chemical
transformation calculations.
BACK TO FAQs
3.2.4 How can I vary the background ammonia value?
Generally, background ammonia values are not varied due to lack of sufficient monitored data.
However, when data are available, the most typical way to vary the background value is to
provide 12 monthly values within the CALPUFF input control file.
Another option is to create an hourly-varying ammonia concentration file by modeling sources of
ammonia within CALPUFF. CALPUFF will create this hour-by-hour, receptor-by-receptor concentration file
(CONC.DAT), which can then be read into POSTUTIL to perform the
chemical transformation calculations.
Although users have the option of creating their own hourly ammonia file using CASTNET
data, there is currently no software available for this option.
BACK TO FAQs
3.3.1 Which CALPUFF settings typically require expert judgement for tailoring the
analysis for a specific application?
CALPUFF provides default selections for most of the options. For most applications, the default
options should be used. However, depending on the application, there may be a need to deviate
from the default selections under certain scenarios. Some such options are listed below with
links provided to other FAQs for further discussion.
BACK TO FAQs
3.3.2 When should I use the slug option in the CALPUFF model?
A slug is simply an elongated puff. For most CALPUFF applications, the modeling of emissions
as puffs is adequate. The selection of puffs produces very similar results as compared to the slug
option, while resulting in significantly faster computer runtimes. However, there are some cases
where the slug option may be preferred. One such case is the episodic time-varying emissions,
e.g., an accidental release scenario. Another case would be where transport from the source to
receptors of interest is very short (possibly involving sub-hourly transport times). These cases
generally involve demonstration of causality effects due to specific events in the near- to
intermediate-field.
BACK TO FAQs
3.3.3 What criteria should I use to determine whether or not to allow puff splitting in
CALPUFF?
The decision to allow puff splitting is generally a subjective call, and there are no clear tests
regarding when it should be done. There are two types of puff splitting - vertical and horizontal.
Vertical splitting slices the puff horizontally into NSPLIT puffs (the recommended default is 3).
This provides a means for accounting for variation of the horizontal wind as a function of height,
which is most prevalent at night (since convective mixing during the day decreases wind shear in
the vertical). Usually, one can adequately address this effect by splitting puffs at night and then
only once, near sunset (local hour 17). The longer the transport distances of concern, and the
greater the possibility of tracking puffs for longer than 12 hours, the more likely the need to
account for this effect.
For horizontal splitting, the issue is that of puff coherence. If the puff size becomes sufficiently
large that it covers several grid cells, it may be advisable to split the puff because one large puff
will not respond correctly to the cell-to-cell variability in meteorological conditions. Horizontal
puff splitting becomes increasingly important with large transport distances (say 200-300 km). It
may also become important at shorter distances if the grid cell size is very small.
Use of vertical or horizontal puff splitting may increase the dispersion of the puffs,
which will increase the horizontal extent of the area impacted and decrease the local
maximum impact in comparison to not activating these options. Use of either vertical
or horizontal puff splitting should be used cautiously because it splits each puff
into say three puffs, which in turn could split into nine puffs, and so on, resulting
in many puffs. CALPUFF has a limit to the number of puffs it can track (MXPUFF, see
Section 3.3, 7 of the FAQ).
BACK TO FAQs
3.3.4 What are the various options available for selecting dispersion coefficients, and can
I select options that are similar to other dispersion models such ISCST3, AERMOD
and CTDM?
There are several dispersion options available within the CALPUFF model, which are selected
via the MDISP parameter in the input control file, or on the "Input, Model Options, Dispersion"
screen of the CALPUFF graphical user interface (GUI).
The various options are described below.
MDISP = 1
Dispersion coefficients are computed from measured values of turbulence,
sigma-v and sigma-w. The user must provide an external PROFILE.DAT file
containing these parameters, and select a backup method out of options 2, 3 and 4
below in case of missing data.
MDISP = 2
Dispersion coefficients are computed from internally-calculated sigma-v, sigma-w
using micrometeorological variables (u*, w*, L, etc.). This option can simulate
AERMOD-type dispersion when the user also selects the use of PDF method for
dispersion in the convective boundary layer (MPDF = 1). Note that when
simulating AERMOD-type dispersion, the input meteorological data must be from
CALMET and cannot be ISC-type ASCII format data. The user should also be
aware that under this option the CALPUFF model will be more sensitive to the
appropriateness of the land use characterization.
MDISP = 3
Pasquill-Guifford (PG) dispersion coefficients for rural areas (computed using the
ISCST3 multi-segment approximation) and McElroy-Pooler (MP) coefficients in
urban areas.
MDISP = 4
Same as MDISP = 3, except PG coefficients are computed using the MESOPUFF II
equations.
MDISP = 5
CTDM sigmas are used for stable and neutral conditions. For unstable conditions,
sigmas are computed as in MDISP=3 described above. When selecting this
option, the user must provide an external PROFILE.DAT file, and select a backup
method out of options 2, 3 and 4 above in case of missing data.
The current default selection is MDISP = 3, which is ISC-type dispersion. Given
the demonstrated improved characterization of dispersion provided by AERMOD, and
EPA's intention to replace ISC with AERMOD, use of AERMOD-like dispersion (MDISP = 2,
and MPDF = 1) is also acceptable, but likely will be of most benefit for
short-range complex flow applications.
BACK TO FAQs
3.3.5 What criteria should I use to determine whether or not to use a) the CTSG option
for subgrid-scale complex terrain, and b) the SGTIBL option for subgrid-scale
coastal effects?
For long range transport applications involving analysis of Class I area impacts, the CTSG option
is not usually considered since impacts on near-field terrain features are likely to be addressed by
a model other than CALPUFF. For near-field applications involving complex flows, the grid
spacing is generally small enough to resolve the terrain adequately. Therefore, the CTSG option
is not commonly employed. However, the CTSG option in CALPUFF does allow the model to
simulate impacts on significant terrain features that are not well resolved by the gridded terrain
data. If such features exist, the user should first consider whether the grid resolution is adequate
for the domain selected. If the grid resolution is determined to be adequate overall, but a terrain
feature exists where impacts are of concern and the terrain is not sufficiently resolved by the
gridded terrain data, then the CTSG option may be appropriate.
The SGTIBL option for simulating subgrid-scale coastal effects should only be considered where
the issue of coastal fumigation is thought to be important. Coastal fumigation is only of concern
in cases involving tall stacks located close to the shoreline. The more general effects of land/sea
breeze circulations on transport of the plume should be addressed through use of mesoscale
prognostic meteorological data, such as MM5, in the CALMET processing.
BACK TO FAQs
3.3.6 CALPUFF chemistry. What are the tradeoffs and known limitations between use of
RIVAD and MESOPUFF II, a) from the respect of setting model options and
defining model input, and b) from the respect of effects on modeling results.
The difference between the two options is that RIVAD is a 6-species scheme wherein NO and
NO2 are treated separately, while MESOPUFF II is a 5-species scheme in which all emissions of
nitrogen oxides are simply input as NOx. Unlike the MESOPUFF II scheme, the RIVAD scheme
does not assume an immediate conversion of all NO to NO2. Therefore, in order to use the
RIVAD scheme, the user must divide the NOx emissions into NO and NO2 for each source.
Another difference is that in the MESOPUFF II scheme, the conversion of SO2 to sulfates is
dependent on relative humidity (RH), with an enhanced conversion rate at high RH. In the
RIVAD scheme the conversion of SO2 to sulfates is not RH-dependent. The conversion of NOx
to nitrates is RH-dependent in both the schemes.
In several tests conducted to date, the results have shown no significant differences between the
modeling results for the two options. However, for any regulatory applications, the user should consult with the relevant reviewing authorities
regarding the selection of the chemical transformation scheme for the particular application.
BACK TO FAQs
3.3.7 How do I solve the problem of too many puffs in my CALPUFF run?
The CALPUFF modeling system provides three executables with increasing array sizes for
each of the main modules, i.e., CALMET, CALPUFF and CALPOST. The maximum number of puffs
allowed is controlled by the MXPUFF parameter in the model code. If for a given application
the number of puffs being generated exceeds the MXPUFF parameter, the user can select an
executable with higher array limits. The user may also increase the MXPUFF parameter and
recompile the code to produce a new executable.
If the user has selected puff splitting, this option could also result in an exceedance of the
MXPUFF parameter. To resolve this problem, the user can consider reducing the number of
puffs into which each original puff is split. In the case of horizontal splitting, the user can also
change the CNSPLITH parameter which stops further splitting of a puff once it has reached a
certain dilution in the atmosphere. CNSPLITH is a concentration level below which puffs are
not split, and can be specified either as a single value for all species being modeled or a separate
values for each individual species. For further discussion on puff splitting, see
Section 3.3, 3 of the FAQ).
The number of sources in a single CALPUFF run can also be reduced, thereby reducing the number
of puffs generated. More CALPUFF runs would be needed, and the resulting output files can be
combined prior to using CALPOST.
BACK TO FAQs
4.1.1 How can I splice together separate CALPUFF runs that are tracking separate
sources or source types?
When modeling sources in separate CALPUFF runs,
the output data files created by CALPUFF can be combined using CALSUM to create a single data
file containing the cumulative impacts. The data files that are combined can either be the
concentration files or the deposition flux files. The user must ensure that the files being
combined cover identical time periods, have the same number of receptors and all receptors
were modeled in the same order in each CALPUFF run.
Note that the results in each data file can be scaled prior to being summed. See further
discussion in Section 4.1, 2 of the FAQ.
Here's a sample of the CALSUM input file. Note that the input file names and the scaling
factors are repeated as many times as the number of files being combined. The last three lines of
input are the run title.
2 - Number of files to be combined
cpuf1.con - INPUT file name (file #1)
cpuf2.con - INPUT file name (file #2)
cpufsum.con - OUTPUT file name
| 
