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:

    CTGPROC -- params.ctg
    TERREL -- params.trl

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:

    df calpuff.obj comline.obj

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.

PGI FORTRAN Compiler in Linux

Extensive testing on Linux multi-processors using the PGI 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 PGI 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 (PGI 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.1.14      Will CALPUFF work with Windows 7 and 64-bit machines?

All the CALPUFF system FORTRAN codes will work with the Windows 7 operating system and 64-bit machines. However, three of the older CALPro GUIs won’t work in a 64-bit environment (the CALMET, CALPUFF and CALPOST GUIs are 16-bit applications that won’t work directly on 64-bit systems.) The other CALPUFF/CALPro GUIs are 32-bit, which will work on 64-bit systems running Windows 7.

There is an easy fix to make the 16-bit GUI applications work with Windows 7. You can download an emulator to run applications in Windows XP mode on your 64 bit machine. With the emulator, all of the CALPro GUIs worked well, including the 16-bit CALMET, CALPUFF and CALPOST GUIs.

To obtain and install the free emulator software, go to the following web site and follow the instructions.

http://www.microsoft.com/windows/virtual-pc/download.aspx?runGenuineCheck=true&system=5&lang=1&buttonClicked=winXpMode

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:

equation
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
T                                - Compression flag for OUTPUT file (T=True, F=False)
5                                - Number of species
.5 .0 .5 .0 .5 .0 .5 .0 .5 .0    - Scaling factors (aX+b) for each species and file
.5 .0 .5 .0 .5 .0 .5 .0 .5 .0    - Scaling factors (file #2)
CALSUM output file - Example CALPUFF Application
Sum of concentrations from 2 identical CALPUFF Files
Scale values by 0.5 before summing

BACK TO FAQs


4.1.2       Can I "adjust" source emission rates in CALSUM after CALPUFF has completed its run?

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 results in each data file can be scaled prior to being summed. The scaling factors are specified by the user and can be different for each species and each input data file. Therefore, if each source is modeled separately, CALSUM can be used to adjust emissions rates via the use of these scaling factors.

The ability of CALSUM to scale impacts can be beneficial in many applications. For example, when modeling net PSD increment consumption, the increment consuming and the increment expanding sources can be modeled separately and combined in CALSUM by specifying scaling factors of +1.0 and -1.0, respectively, for the two runs. Then, CALPOST processing on the resulting file can summarize the net increment consumption.

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
T                                - Compression flag for OUTPUT file (T=True, F=False)
5                                - Number of species
.5 .0 .5 .0 .5 .0 .5 .0 .5 .0    - Scaling factors (aX+b) for each species and file
.5 .0 .5 .0 .5 .0 .5 .0 .5 .0    - Scaling factors (file #2)
CALSUM output file - Example CALPUFF Application
Sum of concentrations from 2 identical CALPUFF Files
Scale values by 0.5 before summing

BACK TO FAQs


4.2.1       I need to split my CALMET run into smaller time periods due to file size limitations. How can I do this, and are there any special considerations (e.g., overlapping periods at beginning and end of each segment)?

When applying CALPUFF separately with meteorological data that is split into multiple consecutive time periods, e.g., 12 monthly runs for one full year, it is necessary to account for puffs that are remaining at the end of one time period in the next time period. One way to accomplish this is to model overlapping time periods, e.g., each monthly run should start with a few days of meteorological data (say 3 days) from the previous month. The other option is to use the RESTART option in each monthly run wherein CALPUFF will first initialize the domain with the puffs remaining from the previous month.

If all of the CALMET files are available on disk, a single CALPUFF application can be made. Simply list the CALMET file names in the CALPUFF input control file, and the model will access these in sequence.

If multiple CALPUFF runs are made, the APPEND program can be used to append the sequential output data files into a single file for CALPOST processing. The data files that are appended can either be the concentration files, deposition flux files, or the visibility data files. Note that the number and the order of the receptors must be identical in each CALPUFF run. Overlapping time periods between multiple runs are not a problem because the user can specify the number of hours to skip at the beginning and the total number of hours to read from each file.

Here's a sample of the APPEND input control file. Note that the input filenames, the number of hours to skip, and the ending hour are repeated as many times as the number of files to be appended. The last three lines are the run title. In this example, the runs for January, February and March for a non-leap year are being appended, and the user had an overlap of three days between the months.

1                 - File type (1=conc/flux files, 2=RH/visibility files)
3                 - Number of input data files
cpuf1.con         - File name (file #1)
0, 744            - Number of hours to skip, total hours to read from file #1
cpuf2.con         - File name (file #2)
72, 744           - Number of hours to skip, total hours to read from file #2
cpuf3.con         - File name (file #3)
72, 816           - Number of hours to skip, total hours to read from file #3
cpufapp.con       - Output data file name
APPEND Demonstration
Reconstructing CALPUFF concentration file
Combine January, February and March runs, skip the 3-day overlap

BACK TO FAQs


4.3.1       How can I get total Sulfur and total Nitrogen deposition amounts?

The CALPUFF output files will contain the wet and dry deposition fluxes of both primary and secondary species. Wet fluxes are reported in one file, and dry fluxes are reported in another. The wet and dry fluxes must be added to obtain the total flux of each species, at each receptor, each hour. Futhermore, these fluxes are for the modeled species and so do not represent the mass flux of either sulfur or nitrogen. The deposition flux of sulfur includes contributions from SO2, SO4, and any other modeled sulfur compounds. The deposition flux of nitrogen includes contributions from NOx, NO3, HNO3, SO4, and any other modeled nitrogen compounds. Note that sulfate (SO4) and nitrate (NO3) are depositied as ammonium sulfate and ammonium nitrate, and therefore carry nitrogen in the ammonium portion of the compound.

The POSTUTIL processor can be configured to sum the wet and dry fluxes, and to 'compute' the total sulfur and nitrogen contributed by the modeled species. The resulting sulfur and nitrogen fluxes are written to the output file for subsequent CALPOST processing. Typically, species names S and N are given to these computed species.

The process for applying POSTUTIL for this purpose is detailed in the "Guide for Applying the EPA Class I Screening Methodology with the CALPUFF Modeling System (September 2001)."

BACK TO FAQs


5.1.1       What are the differences and tradeoffs between the different options provided for computing regional visibility impacts?

The calculation of regional visibility impacts in CALPUFF takes into account the scattering of light caused by several particulate matter (PM) constituents in the atmosphere. This scattering of light is referred to as extinction. The PM constituents that are accounted for in the visibility calculations include ammonium sulfate, ammonium nitrate, organic carbon, elemental carbon, soil, and coarse and fine PM. While most of these constituents are considered to be naturally occurring, an individual source may typically only emit fine PM and contribute to sulfate and nitrate formation via SO2 and NOx emissions. The CALPUFF model calculates the light extinction attributable to a source's emissions and compares it to the extinction caused by the background constituents to estimate a change in extinction.

The extinction caused by a source's emissions is affected by several factors. One such factor is the formation of light scattering constituents by chemical transformation during plume transport, e.g., conversion of SO2 to sulfates and NOx to nitrates. These chemical transformations are dependent on the level of available gaseous ammonia and ozone in the atmosphere, i.e., the higher the ammonia and ozone concentration in the air, the greater the transformation, and hence the greater the light extinction. Therefore, it is recommended that area-specific background concentration levels for these gases should be used.

Since sulfates and nitrates are hygroscopic in nature, the light extinction caused by these constituents is also affected by relative humidity (RH). The other PM constituents are considered to be non-hygroscopic. For details on how the light extinction is calculated consult the IWAQM Phase II report and the Federal Land Managers' Air Quality Related Values Workgroup (FLAG, December 2000) document.

CALPOST provides six options to compute the background light extinction via the specification of the MVISBK parameter in the CALPOST input control file. The six options are as follows, with the default option being MVISBK=2.

MVISBK=1
The user supplies a single light extinction and hygroscopic fraction for the background. The Interagency Workgroup on Air Quality Modeling (IWAQM 1993) RH adjustment is applied to hygroscopic background and the modeled sulfates and nitrates.

MVISBK=2
Computes extinction from user-specified speciated background PM measurements. Hourly RH adjustment is applied to both the background and the modeled sulfates and nitrates using hourly RH data from a file created by CALPUFF (VISB.DAT). The RH factor is capped at a user-specified RHMAX (default 98%). The Rayleigh extinction value (BEXTRAY) is added to the computed background extinction.

MVISBK=3
Computes extinction from user-specified speciated background PM measurements. Hourly RH adjustment is applied to both the background and the modeled sulfates and nitrates using hourly RH data from a file created by CALPUFF (VISB.DAT). Unlike option 2 above, the hours with RH>RHMAX are excluded, and any receptor-day with fewer than 6 valid receptor-hours is also excluded. The Rayleigh extinction value (BEXTRAY) is added to the computed background extinction.

MVISBK=4
Reads user-supplied hourly transmissometer background extinction measurements. Hourly RH adjustment is applied to the modeled sulfates and nitrates using hourly RH data from a file created by CALPUFF (VISB.DAT). Any hours with an invalid measurement are excluded. Also, the hours with RH>RHMAX, and any receptor-day with fewer than 6 valid receptor-hours, are excluded.

MVISBK=5
Reads user-supplied hourly nephelometer background extinction measurements. The Rayleigh extinction value (BEXTRAY) is added to the measurements. Hourly RH adjustment is applied to the modeled sulfates and nitrates using hourly RH data from a file created by CALPUFF (VISB.DAT). Any hours with an invalid measurement are excluded. Also, the hours with RH>RHMAX, and any receptor-days with fewer than 6 valid receptor-hours, are excluded.

MVISBK=6
Computes extinction from user-specified speciated PM measurements. However, unlike option 2 above, the RH adjustment that is applied to both the observed and the modeled sulfates and nitrates is based on user-specified monthly RH factors. In a CALPUFF screening application for Class I areas, the RH factors can be obtained from the FLAG 2000 document for the specific Class I area being modeled. The Rayleigh extinction value (BEXTRAY) is added to the computed background extinction.

BACK TO FAQs


5.2.1       Can I use CALPOST to create a file that allows me to plot how concentrations vary over time at a single receptor?

CALPOST provides the option to select specific receptors to process and generate time series for any type of output for specific days out of the modeling period.

In the CALPOST graphical user interface (GUI), the receptors are selected on the "Process Options" screen under the "Input" menu item. The user can select specific receptors out of both the gridded and the discrete receptors. The type of output and the specific days to process are selected on the "Output Options" screen under the "Input" menu item.

BACK TO FAQs


5.2.2       Can I use CALPOST to create files that will allow me to plot how concentrations vary over the entire domain (or some subdomain)?

Yes, there is an option available within CALPOST 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 output types (concentrations, deposition rates, etc.). The *.GRD file can be input directly into Golden Software's SURFER utility to draw isopleths showing spatial variations of the output type. The *.DAT file can be input either into SURFER or any other plotting utility to generate various types of plots.

The user can either select the entire modeling domain, or chose to select or exclude any part of the domain for the plot files. For example, the user could exclude the on-site receptors, or select one Class I area out of several areas modeled in a single CALPUFF run.

In the CALPOST graphical user interface (GUI), the receptors are selected on the "Process Options" screen, while the option to generate plot files and the plot file format are selected on the "Output Options" screen, under the "Input" menu item.

BACK TO FAQs


For questions or comments, please contact asg@trcsolutions.com.
~ Last updated: September 4, 2008 ~