Users Guide For The Industrial Source Complex ICS2 Dispersion Models Volume 1 User Instructions


EPA450/4-92-008a
           United States
           Environmental Protection
           Agency
Office of Air Quality
Planning and Standards
Research Triangle Park, NC 27711
EPA-450/4-92-008a
March 1992
           Air
           USER'S GUIDE FOR THE
           INDUSTRIAL SOURCE COMPLEX
           (ISC2) DISPERSION MODELS
           VOLUME I - USER INSTRUCTIONS

-------
                                   EPA-450/4-92-008a
         USER'S GUIDE FOR THE
     INDUSTRIAL SOURCE COMPLEX
       (ISC2) DISPERSION MODELS

    VOLUME I - USER INSTRUCTIONS
b
f
          U.S. ENVIRONMENTAL PROTECTION AGENCY
           Office of Air Quality Planning and Standards
               Technical Support Division
           Research Triangle Park, North Carolina 27711

                  March 1992

-------

-------
                            NOTICE

     The information in this document has been reviewed in its
entirety by the U.S. Environmental Protection Agency (EPA), and
approved for publication as an EPA document.  Mention of trade
names, products, or services does not convey, and should not be
interpreted as conveying official EPA approval, endorsement, or
recommendation.
     The following trademarks appear in this guide:
IBM, IBM/MVS, IBM VS FORTRAN, and IBM 3090 are registered
trademarks of International Business Machines Corp.
Microsoft and MS-DOS are registered trademarks of Microsoft
Corp.
VAX/VMS is a registered trademark of Digital Equipment Corp.
Lahey F77L-EM/32 is a registered trademark of Lahey Computer
Systems, Inc.
OS/386 is a registered trademark of Ergo Computing, Inc.
INTEL, 8086, 80286, 80386, 80486, 80287, and 80387 are
registered trademarks of Intel, Inc.
SunOS is a registered trademark of Sun Microelectronics, Inc.
UNIX is a registered trademark of AT&T Bell Laboratories
Cray and UNICOS are registered trademarks and CFT77, CRAY Y-MP,
and SEGLDR are trademarks of Cray Research, Inc.

-------

-------
                            PREFACE

     This volume of the User's Guide for the Industrial Source
Complex (ISC2) Dispersion Models (Version 2) provides user
instructions for setting up and running the ISC2 models.  The
volume is organized to provide different levels of detail to
meet the different needs of various types of users, from novice
users to experienced modelers.  The ISC2 User's Guide has been
developed as part of a larger effort to restructure and
reprogram the original ISC models,  and to improve the
"end-user" documentation for the models.  Volume II of the ISC2
User's Guide provides a technical description of the dispersion
algorithms utilized in the ISC2 models.  Volume III provides a
guide to programmers, including a description of the structure
of the computer code and information about installing and
maintaining the code on various computer systems.
                              111

-------

-------
                        ACKNOWLEDGEMENTS

     The User's Guide for the original version of the ISC
Models was written by J.F. Bowers, J.R. Bjorklund, and C.S.
Cheney (1979) of the H.E. Cramer Company, Inc., Salt Lake City,
Utah.  That work was funded by the Environmental Protection
Agency under Contract No. 68-02-3323, with George Schewe as the
Project Officer.  The second edition of the User's Guide for
the original models was prepared by David J. Wackter and John
A. Foster, TRC Environmental Consultants, Inc., East Hartford,
Connecticut  (EPA, 1987a).  That effort was funded by the
Environmental Protection Agency under Contract No. 68-02-3886
with Russell F. Lee as Project Officer.  The User's Guide for
the ISC2 Models has been prepared by Roger W. Erode and JieFu
Wang of Pacific Environmental Services, Inc., Durham, North
Carolina.  This effort has also been funded by the
Environmental Protection Agency under Contract No. 68D00124,
with Russell F. Lee as Work Assignment Manager.
                               xv

-------

-------
                           CONTENTS

PREFACE	iii

ACKNOWLEDGEMENTS  	  iv

FIGURES	ix

TABLES  	   x

1.0 INTRODUCTION	1-1
     1.1 HOW TO USE THE ISC2 MANUALS	1-1
          1.1.1 Novice Users	1-2
          1.1.2 Experienced Modelers  	 1-2
          1.1.3 Management/Decision Makers  	 1-3
          1.1.4 Programmers/Systems Analysts  	 1-4
     1.2 OVERVIEW OF THE ISC2 MODELS	1-4
          1.2.1 Regulatory Applicability  	 1-5
          1.2.2 Basic Input Data Requirements 	 1-5
          1.2.3 Computer Hardware Requirements  ....:. 1-6
          1.2.4 Overview of Available Modeling Options  .  . 1-8
     1.3 RELATION TO PREVIOUS VERSIONS OF ISC	1-15
          1.3.1 Brief Background of Restructuring Effort   1-15
          1.3.2 Differences Between the Original ISC and
               the ISC2 Models	1-16
          1.3.3 Suggestions for Converting Previous Input
               Files	1-17

2.0 GETTING STARTED - A BRIEF TUTORIAL  	 2-1
     2.1 DESCRIPTION OF KEYWORD/PARAMETER APPROACH  . .  .  .2-1
          2.1.1 Basic Rules for Structuring Input
               Runstream Files	2-3
          2.1.2 Advantages of the Keyword Approach  .... 2-5
     2.2 REGULATORY DEFAULT OPTION  	 2-6
     2.3 MODEL STORAGE LIMITS 	 2-8
     2.4 SETTING UP A SIMPLE RUNSTREAM FILE	2-10
          2.4.1 A Simple Industrial Source Application  .  2-12
          2.4.2 Selecting Modeling Options - CO Pathway .  2-12
          2.4.3 Specifying Source Inputs - SO Pathway .  .  2-16
          2.4.4 Specifying a Receptor Network - RE
               Pathway	2-20
          2.4.5 Specifying the Meteorological Input - ME
               Pathway	2-21
          2.4.6 Selecting Output Options - OU Pathway .  .  2-24
          2.4.7 Using the Error Message File to Debug the
               Input Runstream File	2-27
          2.4.8 Running the Model and Reviewing the
               Results	2-33
     2.5 MODIFYING AN EXISTING RUNSTREAM FILE	2-42
          2.5.1 Modifying Modeling Options  	  2-42
          2.5.2 Adding or Modifying a Source or Source
               Group	2-44
          2.5.3 Adding or Modifying a Receptor Network  .  2-44

-------
          2.5.4 Modifying Output Options  	  2-45

3.0 DETAILED KEYWORD REFERENCE  	 3-1
     3.1 AN OVERVIEW OF SHORT TERM VS.  LONG TERM MODEL
          INPUTS	3-2
     3.2 CONTROL PATHWAY INPUTS AND OPTIONS 	 3-2
          3.2.1 Title Information 	 3-3
          3.2.2 Dispersion Options	 3-3
          3.2.3 Averaging Time Options	3-6
          3.2.4 Specifying the Pollutant Type	3-10
          3.2.5 Modeling With Exponential Decay 	  3-10
          3.2.6 Options for Elevated Terrain Heights  .   .  3-11
          3.2.7 Flagpole Receptor Height Option 	  3-12
          3.2.8 To Run or Not to Run -  That is the
               Question	3-13
          3.2.9 Generating an Input File for the Short
               Term EVENT Model	3-13
          3.2.10 The Model Re-start Capability  	  3-14
          3.2.11 Performing Multiple Year Analyses for
               PM-10	'.....  3-16
          3.2.12 Detailed Error Listing File  	  3-18
     3.3 SOURCE PATHWAY INPUTS AND OPTIONS  	  3-19
          3.3.1 Identifying Source Types and Locations   .  3-20
          3.3.2 Specifying Source Release Parameters  .   .  3-21
          3.3.3 Specifying Building Downwash Information   3-25
          3.3.4 Using Variable Emission Rates ......  3-30
          3.3.5 Adjusting the Emission Rate Units for
               Output ........... 	  3-33
          3.3.6 Specifying Variables for Settling, Removal
               and Deposition Calculations  	  3-35
          3.3.7 Using Source Groups 	  3-36
     3.4 RECEPTOR PATHWAY INPUTS AND OPTIONS  	  3-38
          3.4.1 Defining Networks of Gridded Receptors   .  3-39
          3.4.2 Using Multiple Receptor Networks  ....  3-45
          3.4.3 Specifying Discrete Receptor Locations   .  3-46
          3.4.4 Specifying Plant Boundary Distances . .   .  3-49
     3.5 METEOROLOGY PATHWAY INPUTS AND OPTIONS 	  3-50
          3.5.1 Specifying the Input Data File and Format  3-51
          3.5.2 Specification of Anemometer Height  , ,   .  3-57
          3.5.3 Specifying Station Information  	  3-58
          3.5.4 Specifying the Meteorological STAR Data
                (Applies Only to ISCLT2)	3-59
          3.5.5 Specifying a Data Period to Process
                (Applies Only to ISCST2)	3-61
          3.5.6 Correcting Wind Direction Alignment
               Problems	3-63
          3.5.7 Specifying Wind Speed Categories  ....  3-64
          3.5.8 Specifying Wind Profile Exponents ....  3-64
          3.5.9 Specifying Vertical Temperature Gradients  3-66
          3.5.10 Specifying Average Wind Speeds for the
               Long Term Model	3-67
          3.5.11 Specifying Average Temperatures for the
               Long Term Model	3-68


                               vi

-------
          3.5.12 Specifying Average Mixing Heights for the
               Long Term Model	3-68
     3.6 EVENT PATHWAY INPUTS AND OPTIONS (APPLIES ONLY TO
          ISCEV2)	3-69
          3.6.1 Using Events Generated by the ISCST2
               Model	3-71
          3.6.2 Specifying Discrete Events  	  3-73
     3.7 OUTPUT PATHWAY INPUTS AND OPTIONS  	  3-73
          3.7.1 Short Term Model Options	3-73
          3.7.2 Short Term EVENT Model (ISCEV2) Options  .  3-84
          3.7.3 Long Term Model Options	3-85
     3.8 CONTROLLING INPUT AND OUTPUT FILES 	  3-89
          3.8.1 Description of ISC2 Input Files	3-89
          3.8.2 Description of ISC2 Output Files  ....  3-91
          3.8.3 Control of File Inputs and Outputs (I/O)   3-98

4.0 COMPUTER NOTES	4-1
     4.1 MINIMUM HARDWARE REQUIREMENTS  	 4-1
          4.1.1 Requirements for Execution on a PC  .... 4-1
          4.1.2 Requirements for Execution on a DEC VAX
               Minicomputer 	 4-3
          4.1.3 Requirements for Execution on an IBM
               Mainframe	4-3
     4.2 COMPILING AND RUNNING THE MODELS ON A PC 	 4-3
          4.2.1 Microsoft Compiler Options  	 4-3
          4.2.2 Modifying PARAMETER Statements for Unusual
               Modeling Needs 	 4-6
     4.3 PORTING THE MODELS TO OTHER HARDWARE
          ENVIRONMENTS  	 4-9
          4.3.1 Non-DOS PCs	4-9
          4.3.2 DEC VAX	4-10
          4.3.3 IBM 3090	4-12
          4.3.4 Various UNIX machines (CRAY, SUN,  DEC VAX,
               AT&T)  	4-13
          4.3.5 Advanced Topics	4-15

5.0 REFERENCES	5-1

APPENDIX A. ALPHABETICAL KEYWORD REFERENCE  	 A-l

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

APPENDIX C. UTILITY PROGRAMS  	 C-l
     C.I CONVERTING INPUT RUNSTREAM FILES - STOLDNEW  .  .  . C-l
     C.2 CONVERTING UNFORMATTED RAMMET FILES TO ASCII
          FORMATTED FILES - BINTOASC  	 C-3
     C.3 LISTING HOURLY METEOROLOGICAL DATA - METLIST .  .  . C-4

APPENDIX D. BATCH FILE DESCRIPTIONS FOR COMPILING AND
     RUNNING THE MODELS ON A PC	D-l
     D.I MICROSOFT/DOS VERSIONS 	 D-l
     D.2 LAHEY/EXTENDED MEMORY VERSIONS 	 D-4
                              vil

-------
APPENDIX E. EXPLANATION OF ERROR MESSAGE CODES  ...... E-l
     E.I INTRODUCTION	  . E-l
     E.2 THE OUTPUT MESSAGE SUMMARY	 E-2
     E.3 DESCRIPTION OF THE DETAILED MESSAGE LAYOUT .... E-3
     E.4 DETAILED DESCRIPTION OF THE ERROR/MESSAGE CODES   . E-6

APPENDIX F. DESCRIPTION OF FILE FORMATS	F-l
     F.I ASCII METEOROLOGICAL DATA	F-l
     F.2 RAMMET METEOROLOGICAL DATA	F-2
     F.3 STAR SUMMARY JOINT FREQUENCY DISTRIBUTIONS .... F-4
     F.4 THRESHOLD VIOLATION FILES (MAXIFILE OPTION)   .  .  . F-5
     F.5 POSTPROCESSOR FILES (POSTFILE OPTION)  	 F-6
     F.6 HIGH VALUE RESULTS FOR PLOTTING (PLOTFILE
          OPTION)	F-8

APPENDIX G. QUICK REFERENCE CARD PULL-OUT FOR ISCST2 AND
     ISCLT2 MODELS  	 G-l

APPENDIX H. QUICK REFERENCE CARD PULL-OUT FOR ISCEV2
     (EVENT) MODEL  	 H-l

GLOSSARY	  GLOSSARY-1

INDEX	INDEX-1
                              viii

-------
                            FIGURES

Figure                                                     Page

2-1. EXAMPLE INPUT FILES FOR ISCST (top) AND ISCST2
     (bottom) MODELS FOR SAMPLE PROBLEM 	  2-11

2-2. EXAMPLE INPUT RUNSTREAM FILE FOR SAMPLE PROBLEM  . .  2-26

2-3. EXAMPLE MESSAGE SUMMARY TABLE FOR RUNSTREAM SETUP  .  2-32

2-4. EXAMPLE OF KEYWORD ERROR AND ASSOCIATED MESSAGE
     SUMMARY TABLE  	  2-33

2-5. ORGANIZATION OF ISCST2 MODEL OUTPUT FILE	2-35

2-6. EXAMPLE MODEL OPTION SUMMARY TABLE FROM AN ISC2 MODEL
     OUTPUT FILE	2-39

2-7. EXAMPLE OUTPUT TABLE OF HIGH VALUES BY RECEPTOR  . .  2-40

2-8. EXAMPLE OF RESULT SUMMARY TABLES FOR THE ISC2 SHORT
     TERM MODEL	2-41

E-l. EXAMPLE OF AN ISC2 MESSAGE SUMMARY	 E-3
                               IX

-------

-------
                             TABLES

Table                                                      Page

3-1  SUMMARY OF SUGGESTED PROCEDURES FOR ESTIMATING INITIAL
     LATERAL DIMENSIONS a  AND INITIAL VERTICAL DIMENSIONS azo
     FOR VOLUME AND LINE SOURCES	3-24

B-l  DESCRIPTION OF CONTROL PATHWAY KEYWORDS  	 B-3

B-2  DESCRIPTION OF CONTROL PATHWAY KEYWORDS AND
     PARAMETERS	B-4

B-3  DESCRIPTION OF SOURCE PATHWAY KEYWORDS 	 B-7

B-4  DESCRIPTION OF SOURCE PATHWAY KEYWORDS AND
     PARAMETERS	B-8

B-5  DESCRIPTION OF RECEPTOR PATHWAY KEYWORDS 	  B-ll

B-6  DESCRIPTION OF RECEPTOR PATHWAY KEYWORDS AND
     PARAMETERS	B-12

B-7  DESCRIPTION OF METEOROLOGY PATHWAY KEYWORDS  ....  B-l5

B-8  DESCRIPTION OF METEOROLOGY PATHWAY KEYWORDS AND
     PARAMETERS	B-16

B-9  DESCRIPTION OF EVENT PATHWAY KEYWORDS  	  B-19

B-10 DESCRIPTION OF EVENT PATHWAY KEYWORDS AND PARAMETERS  B-20

B-ll DESCRIPTION OF OUTPUT PATHWAY KEYWORDS 	  B-21

B-12 DESCRIPTION OF OUTPUT PATHWAY KEYWORDS AND
     PARAMETERS	B-22

-------

-------
                        1.0  INTRODUCTION

     The Industrial Source Complex (ISC2) dispersion models
described in this document refer to restructured and
reprogrammed versions of the original ISC models described in
the ISC Dispersion Model User's Guide - Second Edition
(Revised) (EPA, 1987a).  The models were reprogrammed in order
to improve the overall quality of the computer code, to improve
the user interface, and to improve the end user documentation
of the models.

     This section provides an overall introduction to the ISC2
models and to the ISC2 User's Guide.   It also serves
specifically as an introduction to the user instructions
contained in this volume for setting up and running the ISC2
models.  Some suggestions are offered on how various users
would best benefit from using the manuals.  Also provided is an
overview of the model's applicability, range of options, basic
input data and hardware requirements, and a discussion of the
relation of the ISC2 models to previous versions of ISC.  The
input file needed to run the ISC2 models is based on an
approach that uses descriptive keywords and allows for a
flexible structure and format.  This is quite different from
the earlier versions of the models which used a
rigidly-formatted file with numeric option switches.  Hence,
this volume of the ISC2 Model User's Guide bears little
resemblance to the previous ISC User's Guide.

1.1 HOW TO USE THE ISC2 MANUALS

     The ISC2 Model User's Guide has been designed in an
attempt to meet the needs of various types of users, depending
on their level of experience with the models.  This section
describes briefly how different types of users would benefit
most from their use of the manual.
                              1-1

-------
1.1.1 Novice Users

     Novice users are those whose exposure to or experience
with the ISC2 models has been limited.  They may be new to
dispersion modeling applications in general, or new to the ISC2
models and therefore unfamiliar with the keyword/parameter
approach utilized for the input file.  These users should
review the remainder of this Introduction to gain an overall
perspective of the use of ISC2 models, particularly for
regulatory modeling applications.  They should then concentrate
their review on Section 2, which provides a brief tutorial on
setting up an input file that illustrates the most commonly
used options of the ISC2 Short Term model.  Section 2 provides
a basic description of the input file structure and explains
some of the advantages of the keyword/parameter approach to
specifying modeling options and inputs.  As the user becomes
more familiar with the operation of the models and encounters
the need to use more advanced features of the models, he/she
will want to review the contents of Section 3, which provides a
more detailed and complete reference of the various options for
running the models.

1.1.2 Experienced Modelers

     Experienced modelers will have had considerable experience
in applying the ISC2 models in a variety of situations.  They
should have basic familiarity with the overall goals and
purposes of regulatory modeling in general, and with the scope
of options available in the ISC2 models in particular.
Experienced modelers who are new to the ISC2 models will
benefit from first reviewing the contents of Section 2 of this
volume, which will give them a basic orientation to the
structure, organization and philosophy of the keyword/parameter
approach used for the input runstream file.  Once they have a
basic grasp of the input file structure and syntax rules, they
will benefit most from using Section 3 of this volume as a
                              1-2

-------
reference to learn the overall capabilities of the models, or
to understand the mechanics for implementing particular
options.  The information in Section 3 has a functional
organization with detailed descriptions of each of the
individual keyword options by functional pathway.  Once they
are familiar with most or all of the keywords, they may find
the functional keyword reference provided in Appendix B useful
to quickly review the proper syntax and available
options/parameters for a particular keyword.  They may also
find the Quick Reference Card pull-out available at the end of
the user's guide sufficient as a simple reminder of the
available keywords for each pathway and to ensure the proper
order of parameters for each input image.

     Modelers who have considerable experience with the
previous versions of the ISC models should review the
discussion at the end of this Introduction to understand the
relation of the current version to previous versions of the
models.

     Experienced modelers may also have occasion to peruse the
contents of Volume II, which describes the technical details of
the dispersion modeling algorithms utilized in the ISC2 models.
They may also have an interest in or need to review the
contents of Volume III to learn about the structure and
organization of the computer code, particularly if they are
involved with installing the code on another computer system,
or with compiling the code to meet the memory storage
requirements for a particular application.

1.1.3 Management/Decision Makers

     Those involved in a management or decision-making role for
dispersion modeling applications will be especially interested
in the remainder of this section, which provides an overview of
the models, including their role in various regulatory
                              1-3

-------
programs, a brief description of the range of available
options, and basic input data and computer hardware
requirements needed to run the models.  From this information
they should understand the basic capabilities of the ISC2
models well enough to judge the suitability of the models for
particular applications.  They may also want to review the
brief tutorial provided in Section 2 to learn about the nature
and structure of the input runstream file, in order to better
be able to review the modeling results.

1.1.4 Programmers/Systems Analysts

     Programmers and systems analysts, specifically those
involved with installing the ISC2 code on other computer
systems or charged with maintaining the code, should review the
contents of Volume III.  This will acquaint them with the
structure and organization of the computer code, give specific
details on compiling and linking the code for various
situations, and explain in detail the memory storage
requirements and control of input and output (I/O).  They may
also wish to review the remainder of this Introduction and the
brief tutorial in Section 2 of this volume in order to have a
basic understanding of the nature and overall capabilities of
the models, and to understand the basic input runstream file
structure and organization.

1.2 OVERVIEW OF THE ISC2 MODELS

     This section provides an overview of the ISC2 models,
including a discussion of the regulatory applicability of the
models, a description of the basic options available for
running the models, and an explanation of the basic input data
and hardware requirements needed for executing the models.
                              1-4

-------
1.2.1 Regulatory Applicability

     The U.S. Environmental Protection Agency (EPA) maintains a
Guideline on Air Quality Models which provides the agency's
guidance on regulatory applicability of air quality dispersion
models in general.  Any regulatory application of the ISC2
models should conform to the guidance set forth in the
Guideline on Air Quality Models (Revised) (EPA,  1987b),
including the most recent Supplements to the guideline.  Any
non-guideline application of the models should meet the
requirements of the applicable reviewing agency, such as an EPA
Regional Office, a State or a local air pollution control
agency.  In general, regulatory modeling applications should be
carried out in accordance with a modeling protocol that is
reviewed and approved by the appropriate agency prior to
conducting the modeling.  The modeling protocol should identify
the specific model, modeling options and input data to be used
for a particular application.

1.2.2 Basic Input Data Requirements

     There are two basic types of inputs that are needed to run
the ISC2 models.  One of the inputs is the runstream setup file
which contains the selected modeling options, as well as source
location and parameter data, receptor locations, meteorological
data file specifications, and output options.  The second basic
type of input data needed to run the model is the
meteorological data.  There are various options for
meteorological data file formats available with the ISC2
models.  These are described briefly later in this section, and
in more detail in Sections 2 and 3.
                              1-5

-------
1.2.3 Computer Hardware Requirements

     1.2.3.1 PC Hardware Requirements.

     Given the rapid increase in speed and capacity of personal
computers (PCs) available for modeling in recent years, and
their relative ease of use and access,  the PC has become the
most popular environment for performing dispersion modeling
applications within the modeling community (Bauman and Dehart,
1988; Rorex, 1990).  This trend can be expected to continue in
the future.  The current versions of the ISC2 models were
developed on an IBM-compatible PC using the Microsoft FORTRAN
Optimizing Compiler (Version 5.1), and have been designed to
run on such machines with a minimum of 64OK bytes of RAM and
MS-DOS Version 3.2 or higher.  In order to handle the input
data files  (runstream setup and meteorology)  and the output
files, it is highly recommended that the system have a hard
disk drive.  The amount of storage space required on the hard
disk for a particular application will depend greatly on the
output options selected.  Some of the optional output files of
concentration data can be rather large.  More information on
output file products is provided in Sections 2 and 3.

     While a math coprocessor chip is optional for execution of
the ISC2 models on a PC, it is highly recommended, especially
for the Short Term model, due to the large increase in
execution speed that will be experienced.  The model may be
expected to run about five to ten times faster with a math
coprocessor than without one.

     For particularly large applications, involving a large
number of sources, source groups, receptors and averaging
periods, the user may find that the 640K RAM limit available
with DOS is not enough.  In addition to the DOS executable
versions of the models, extended memory versions are available
for use on  80386 and 80486 PCs with at least 4 MB of RAM.
                              1-6

-------
Section 4.2.2 of this volume and Volume III of the ISC2 User's
Guide contain information on increasing the capacity of the
model and setting it up to run on systems (with 80386
processors and higher) that make use of extended memory beyond
the 640K limit of DOS.  There are special requirements for the
operating system and Fortran language compiler needed to
utilize the extended memory on these machines.

     1.2.3.2 DEC VAX Requirements.

     The models have also been uploaded and tested on a DEC VAX
minicomputer.  As with the IBM 3090, the VAX has some
advantages of speed and greater memory capacity over the PC
environment.  There are no particular hardware requirements for
running the models on the VAX.  The user must be familiar with
the operating system and Fortran language compiler being
utilized on the VAX in order to properly setup and run the
model and control the input and output files.  Instructions for
setting up and running the models on the DEC VAX are included
in this volume and in more detail in Volume III of the User's
Guide.

     1.2.3.3 IBM 3090 Requirements.

     While the models were developed on the PC, they have been
uploaded and tested on EPA's IBM 3090 mainframe computer.  The
mainframe has advantages of speed and greater memory capacity
over the PC environment.  There are no particular hardware
requirements for running the models on the IBM 3090.  However,
the user must be familiar with the IBM Job Control Language
(JCL) and the VS FORTRAN Version 2.0 compiler in order to
properly setup and run the models and control the input and
output files in the mainframe environment.  Instructions for
setting up and running the models on the IBM 3090 are included
in this volume and in Volume III of the User's Guide,
                              1-7

-------
1.2.4 Overview of Available Modeling Options

     The ISC2 models include a wide range of options for
modeling air quality impacts of pollution sources, making them
popular choices among the modeling community for a variety of
applications.  The following sections provide a brief overview
of the options available in the ISC2 models.

     1.2.4.1 Dispersion Options.

     Since the ISC2 models are especially designed to support
the EPA's regulatory modeling programs, the regulatory modeling
options, as specified in the Guideline on Air Quality Models
(Revised), are the default mode of operation for the models.
These options include the use of stack-tip downwash,
buoyancy-induced dispersion, final plume rise (except for
sources with building downwash), a routine for processing
averages when calm winds occur, default values for wind profile
exponents and for the vertical potential temperature gradients,
and the use of upper bound estimates for super-squat buildings
having an influence on the lateral dispersion of the plume. The
user can easily ensure the use of the regulatory default
options by selecting a single keyword on the modeling option
input card.  To maintain the flexibility of the model, the
non-regulatory default options have been retained, and by using
descriptive keywords to specify these options it is evident at
a glance from the input or output file which options have been
employed for a particular application.

     As with the earlier version of the ISC models, the user
may select either rural or urban dispersion parameters
(although the non-regulatory options of Urban Mode 1 and Urban
Mode 2 have been eliminated), depending on the characteristics
of the source location.  The user also has the option of
calculating either concentration values or deposition values
for a particular run.  The user can specify several short term
                              1-8

-------
averages to be calculated in a single run of the ISC2 Short
Term model, as well as requesting the overall period (e.g.
annua1)  averages.

     1.2.4.2 Source Options.

     The model is capable of handling multiple sources,
including point, volume and area source types.  Line sources
may also be modeled as a string of volume sources.  Several
source groups may be specified in a single run, with the source
contributions combined for each group.  This is particularly
useful for PSD applications where combined impacts may be
needed for a subset of the modeled background sources that
consume increment, while the combined impacts from all
background sources (and the permitted source) are needed to
demonstrate compliance with the National Ambient Air Quality
Standards  (NAAQS).  As with earlier versions of ISC, the models
contain algorithms for modeling the effects of aerodynamic
downwash due to nearby buildings on point source emissions, and
algorithms for modeling the effects of settling and removal
(through dry deposition) of large particulates.  As noted
above, for applications involving large particulates, the user
can select either concentration or deposition values to be
calculated.  Once a run has been setup for either concentration
or deposition, then a trivial change of one keyword is all that
is needed to switch the model to calculate the other.

     Source emission rates can be treated as constant
throughout the modeling period, or may be varied by month,
season,  hour-of-day, or other optional periods of variation.
These variable emission rate factors may be specified for a
single source or for a group of sources.
                              1-9

-------
     1.2.4.3 Receptor Options.

     The ISC2 models have added flexibility in the
specification of receptor locations compared to the previous
versions of the model.  The user now has the capability of
specifying multiple receptor networks in a single run, and may
also mix Cartesian grid receptor networks and polar grid
receptor networks in the same run.  This is useful for
applications where the user may need a coarse grid over the
whole modeling domain, but a denser grid in the area of maximum
expected impacts.  There is also greater flexibility in
specifying the location of the origin for polar receptors than
in the earlier models, which assumed that all polar receptors
were referenced to an origin at (0,0) in x,y, coordinates.

     As with the earlier version of the ISC models, the user
can input elevated receptor heights in order to model the
effects of terrain above (or below) stack base, and may also
specify receptor elevations above ground level to model
flagpole receptors.  Any terrain heights input above the
release height for a particular source are "chopped-off" at the
release height for that source's calculations.  The ISC2 models
do not include algorithms to model the impacts of sources on
complex terrain, i.e., terrain above the release height.

     1.2.4.4 Meteorology Options.

     The ISC2 Short Term (ISCST2) model can utilize the
unformatted, sequential files of meteorological data generated
by the RAMMET and the MPRM preprocessors, provided the data
file was generated by the same Fortran compiler as was used for
the model.  The user also has considerable flexibility to
utilize formatted ASCII files that contain sequential hourly
records of meteorological variables.  For these hourly ASCII
files, the user may use a default ASCII format, may specify the
ASCII read format, or may select free-formatted reads for
                              1-10

-------
inputting the meteorological data.  A utility program called
BINTOASC is provided with the ISC2 models to convert
unformatted meteorological data files of several types to the
default ASCII format used by ISCST2 and ISCEV2.  This greatly
improves the portability of applications to different computer
systems.  The BINTOASC program is described in Appendix C.

     The previous version of the ISCST model allowed the user
to specify hourly meteorological data in a "card image" format
within the input option file.  Applications of the earlier
ISCST model using card image meteorological data can easily be
duplicated using the ASCII file options available in the ISCST2
model.  The model will process all available meteorological
data in the specified input file by default, but the user can
easily specify selected days or ranges of days to process.

     The ISC2 Long Term (ISCLT2) model uses joint frequency
distributions of wind speed class, by wind direction sector, by
stability category, known as STAR summaries (for STability
ARray).  These STAR summaries are available from the National
Climatic Data Center in Asheville, North Carolina.  They may
also be generated from sequential data files using the STAR
utility program available on EPA's SCRAM Bulletin Board System
or by the MPRM meteorological processor for on-site data.  The
meteorological data for ISCLT2 are read in from a separate data
file rather than being included in the input option file, as
was done in the earlier versions of ISCLT.

     1.2.4.5 Output Options.

     The ISC2 models retain options for all of the basic types
of outputs available with the previous versions, and also
include some new output options.  The basic types of printed
output available with ISCST2 are:
                              1-11

-------
        Summaries of high values (highest/ second highest,
        etc.)  by receptor for each averaging period and source
        group combination;
        Summaries of overall maximum values (e.g., the maximum
        50) for each averaging period and source group
        combination; and
        Tables of concurrent values summarized by receptor for
        each averaging period and source group combination for
        each day of data processed.  These "raw" concentration
        values may also be output to unformatted  (binary)
        files, as described below.
     For the Long Term model, the user can also select output
tables of values for each receptor, and/or tables of overall
maximum values.  The tables by receptor and maximum value
tables can be output for the source group values or for the
individual source values, or both.  In addition, when maximum
values for individual sources are output, the user has the
option of specifying whether the maximum source values are to
be the maximum values for each source independently, or the
contribution of each source to the maximum group values, or
both.

     In addition to the tabular printed output products
described above, the new models provide options for several
types of file output products.  One of these options for ISCST2
corresponds to the option for an unformatted ("binary") file of
all concentration values available with the previous versions
of ISCST.  These files are often used for special
postprocessing of the data.  In addition to the unformatted
concentration files, ISCST2 provides options for two additional
types of file outputs.  One option is to generate a file of
(X,Y) coordinates and design values (e.g., the second highest
values at each receptor for a particular averaging period and
source group combination) that can be easily imported into many
graphics plotting packages to generate contour plots of the
concentration values.  Separate files can be specified for all
                              1-12

-------
of the averaging period and source group combinations of
interest to the user.

     Another output file option of the ISCST2 model is to
generate a file of all occurrences when a concentration value
equals or exceeds a user-specified threshold.  Again, separate
files are generated for only those combinations of averaging
period and source group that are of interest to the user. These
files include the date on which the threshold violation
occurred, the receptor location, and the concentration value.

     In addition to the availability of these new options for
output products from ISCST2, the user has more flexibility to
select only the output desired for a particular application. As
an example, the option in the old ISCST model to generate an
unformatted ("binary") file of concentration values for
postprocessing combined the results for each receptor, source
group and averaging period combination into a single file. This
file of raw concentration values could be very large for even
routine size runs, and the structure of the file made it
cumbersome to work with.  Often the user may be interested in
postprocessing a single averaging period and source group of
interest that is a small subset of the file for a full
application.  For the original ISCST model, a separate run may
have been set up to generate the concentration file for only
that combination.  In ISCST2, the unformatted concentration
files are separated for each averaging period and source group
combination, and the user can specify that files be generated
for only those combinations that are of interest for
postprocessing.  Similar flexibility is available with all of
the output options for the new model.
                              1-13

-------
     1.2.4.6 Source Contribut ion Analyses.

     In air quality dispersion modeling applications, the user
may have a need to know the contribution that a particular
source makes to an overall concentration value for a group of
sources.  This section provides a brief introduction to how
these types of source contribution (sometimes referred to as
source culpability) analyses are performed using the ISC2
models.  More detailed information about exercising these
options is provided in Section 3.

     In the previous version of the ISCLT model, the user had
an option (controlled by option switch ISW(ll)) to have the
highest 10 values for each source and source group reported
independently, or to have the 10 highest values from the
combined source group and the contributions from the individual
sources to those highest group values.  This option is retained
in the ISCLT2 model, as mentioned briefly in the previous
section.

     The previous version of the ISCST model provided the
option of specifying source groups for which the model
calculates high values independently.  However, there was no
easy mechanism for obtaining the same kind of source
contribution information that was provided by the ISCLT model.
Users would often have to run the model a second time selecting
only specific days where the high values occurred, and setting
up each source in its own source group in order to obtain
source contribution results.

     Recognizing that source contribution information is also
important to many short term modeling analyses, the ISCST2
model has been designed to make it much easier for users to
perform this type of analysis.  This is accomplished with the
introduction of an additional model, referred to as the ISC2
Short Term - EVENT model  (ISCEV2).  The ISCST2 model treats
                              1-14

-------
source groups independently, in the same manner as the old
ISCST model.  The ISCEV2 (EVENT) model is set up specifically
to provide the contributions from individual sources to the
concentration values for particular events.  These events may
be the design concentrations (e.g., the high-second-high
24-hour average concentration for a particular group of
sources) that were generated from an execution of the ISCST2
model.  Other events of interest might be occurrences of
violations of a particular standard, for which it is necessary
to determine whether the source being permitted contributes
above a significance level.  The models are set up in such a
way that both of these types of events can be passed directly
from an execution of the ISCST2 model to an input file for the
EVENT model.  The user is thus able to run the models in a
batch mode to obtain the overall design value results from
ISCST2 and the source contribution information from ISCEV2 in a
single step.  The EVENT model can also be run separately and
accepts user-specified events for source contribution
processing.

1.3 RELATION TO PREVIOUS VERSIONS OF ISC

1.3.1 Brief Background of Restructuring Effort

     The ISC2 models came about as a result of a major effort
to restructure and reprogram the models that began in April
1989, and was completed in January 1992.  The effort was
largely motivated by the need to improve the quality,
reliability, and maintainability of the code when numerous
"bugs" were discovered after the implementation of the revised
downwash algorithms for shorter stacks.  It became widely
recognized that the code, originally developed in the 1970's
and modified numerous times since, had become impossible to
reliably modify, debug or maintain.  However, the goals of the
reprogramming effort also included improving the user interface
by modifying the input file structure and the output products,
                              1-15

-------
and to provide better "end user" documentation for the revised
models.  The ISC2 models were developed as replacements for and
not updates to the previous versions of the models.  The
purpose of the reprogrammina effort was NOT to modify any of
the ISC model algorithms.

1.3.2 Differences Between the Original ISC and the ISC2 Models

     During the course of reprogramming and testing the models,
several discrepancies with the older versions of the models
were discovered.  These discrepancies were resolved, and
corrections were incorporated into the ISC2 models prior to
their release.  Because of the nature of some of these bugs in
the earlier versions, it was not practical to "fix" the
previous versions prior to releasing the new models.  However,
for most applications, the design values estimated by the ISC2
models will not differ significantly from the design values
estimated by the original models.  The most significant
discrepancies are likely to occur for sources whose plume rise
is dominated by momentum rather than buoyancy, and for certain
source situations involving the building downwash algorithms.
Impacts for area sources for the ISCST2 model will be about
11.4 percent lower than previous versions of ISCST due to the
correction of an error in the derivation of the area source
equation for a finite line segment.  There was also an error in
the original ISCLT model in the treatment of lateral virtual
distances that effects area sources, volume sources and point
sources with building downwash.  The largest differences due to
this error are likely to be for receptors located relatively
close to the source.

     The only technical change between ISC2 and old versions of
ISC, not involving correction of an error, is the extension of
the direction-specific treatment of building downwash
influences from the Schulman-Scire algorithm for shorter stacks
                              1-16

-------
to the Huber-Snyder algorithm for stacks up to the Good
Engineering Practice (GEP) stack height.

1.3.3 Suggestions for Converting Previous Input Files

     In order to make the transition from the old models to
ISC2 as easy as possible, a file conversion utility (STOLDNEW)
has been developed that converts input files for the old ISCST
model to the format required to run the ISCST2 model.   Since
there is considerable flexibility in structuring and formatting
the input file for the ISCST2 model, and there are options
available in ISCST2 that weren't available in the old model,
the file generated by the conversion program may not always be
in a form that will best meet the user's needs relative to
ISCST2.  However, user's will be able to make use of old input
files and easily setup previous applications to run with the
ISCST2 model.  The file conversion utility is described in more
detail in Appendix C.  Due to similarities between the ISCST2
and ISCLT2 inputs, it is now much easier to setup an ISCLT2 run
from an ISCST2 input file.
                              1-17

-------

-------
             2.0 GETTING  STARTED  - A BRIEF TUTORIAL

     This section provides a brief tutorial for setting up a
simple application problem with the ISC2 Short Term model,
which serves as an introduction for novice users to the ISC2
models.  The example illustrates the usage of the most commonly
used options in the ISC2 models for regulatory applications.  A
more complete description of the available options for setting
up the ISC2 models is provided in Section 3.

     The example problem presented in this section is a simple
application of the ISCST2 model to a single point source.  The
source is a hypothetical stack at a small isolated facility in
a rural setting.   Since the stack is below the Good Engineering
Practice (GEP) stack height, the emissions from the source are
subject to the influence of aerodynamic downwash due to the
presence of nearby buildings.  The tutorial leads the user
through selection and specification of modeling options,
specification of source parameters,  definition of receptor
locations,  specification of the input meteorological data, and
selection of output options.  Since this discussion is aimed at
novice users of the ISC2 models,  a general description of the
input file keyword/parameter approach is provided first.

2.1 DESCRIPTION OF KEYWORD/PARAMETER APPROACH

     The input file for the ISC2 models makes use of a
keyword/parameter approach to specifying the options and input
data for running the models.  The descriptive keywords and
parameters that make up this input runstream file may be
thought of as a command language through which the user
communicates with the model what he/she wishes to accomplish
for a particular model run.  The keywords specify the type of
option or input data being entered on each line of the input
file, and the parameters following the keyword define the
specific options selected or the actual input data.   Some of
                              2-1

-------
the parameters  are also input as descriptive secondary
keywords.

     The runstream file is divided  into five functional
"pathways."   These pathways are identified by a two-character
pathway ID placed at the beginning  of  each runstream image.  The
pathways and the order in which they are input to the model  are
as follows:

     CO - for specifying overall job control options;
     SO - for specifying source information;
     RE - for specifying REceptor information;
     ME - for specifying MEteorology information; and
     OU - for specifying output options.

     Each line  of the input runstream  file consists of a
pathway ID,  an  8-character keyword, and a parameter list.  An
example of a line of input from a runstream file, with its
various parts identified, is shown  below:
      Column: 12345678901234567890123456789012345678901234567890123456789
            CO HODELOPT 0FAULT RURAL COMC
                                   Parameters
                                   	 8-Character Keyword
                                   	 2-Character Pathway ID
     The  following sections describe the rules for structuring
the input runstream file, and explain some of the advantages of
the keyword/parameter approach.
                                2-2

-------
2.1.1 Basic Rules for Structuring Input Runstream Files

     While the input runstream file has been designed to
provide the user with considerable flexibility in structuring
the input file, there are some basic syntax rules that need to
be followed.  These rules serve to maintain some consistency
between input files generated by different users, to simplify
the job of error handling performed by the models on the input
data, and to provide information to the model in the
appropriate order wherever order is critical to the
interpretation of the inputs.  These basic rules and the
various elements of the input runstream file are described in
the paragraphs that follow.

     One of the most basic rules is that all inputs for a
particular pathway must be contiguous, i.e., all inputs for the
CO pathway must come first, followed by the inputs for the SO
pathway, and so on.  The beginning of each pathway is
identified with a "STARTING" keyword, and the ending of the
pathway with the "FINISHED" keyword.  Thus the first functional
record of each input file must be "CO STARTING" and the last
record of each input file must be "OU FINISHED."  The rest of
the input images will define the options and input data for a
particular run.

     Each record in the input runstream file is referred to as
a runstream "image."  These records are initially read into the
model as 80-character images.  The information on each input
image consists of a "pathway," a "keyword," and one or more
"parameters."  Each of these "fields" on the runstream image
must be separated from other fields by at least one blank
space.  To simplify the interpretation of the runstream image
by the model, the runstream file must be structured with the
two-character pathway in columns 1 and 2, the eight-character
keyword in columns 4 through 11, followed by the parameters in
columns 13 through 80, as necessary.  (For reasons that are
                              2-3

-------
explained in Section 2.4.8,  the models will accept  input  files
where all inputs are shifted by up to three columns to  the
right.)  For most  keywords,  the order of parameters following
the keyword is  important —  the exact spacing of the parameters
is not important,  as long as they are separated from each other
by at least one blank space  and do not extend beyond the  80
character limit.   The example of a runstream image  from the CO
pathway shown above is repeated here:
      CoIumn: 12345678901234567890123456789012345678901234567890123456789
           CO MODELOPT OFAULT RURAL CONC
                                   Parameters
                                  	 8-Character Keyword
                                  	 2-Character Pathway ID
     Alphabetical  characters can be input as either  lower case
or upper case  letters.   The models convert all character input
to upper case  letters internally, with the exception of the
title fields and file names to be discussed later.   Throughout
this document,  the convention of using upper case  letters is
followed.  For numeric input data, it should be noted that all
data are assumed to be in metric units, i.e., length units of
meters, speed  units of meters per second, temperature units of
degrees Kelvin,  and emission units of grams per second.   In a
few instances,  the user has the option of specifying units of
feet for length and the model will perform the conversion to
meters.  These exceptions are the input of receptor  heights for
elevated terrain and the specification of anemometer height,
since these values are often more readily available  in feet
than in meters.

     Certain keywords are mandatory and must be present in
every runstream file, such as the MODELOPT keyword shown in the
                               2-4

-------
example above which identifies the modeling options.  Other
keywords are optional and are only needed to exercise
particular options, such as the option to allow for the input
of flagpole receptor heights.  Some of the keywords are
repeatable, such as the keywords to specify source parameters,
while other keywords may only appear once.  The keyword
references in Section 3, Appendices A and B and the Quick
Reference Card at the end of this volume identify each keyword
as to its type, either mandatory or optional, and either
repeatable or non-repeatable.

     With a few exceptions that are described below, the order
of keywords within each pathway is not critical.  For the CO
pathway, an exception is that the MODELOPT and POLLUTID
keywords must be specified before the DCAYCOEF or HALFLIFE
keyword because of the link between the urban default option
and the decay coefficient for S02.   For the SO pathway,  the
LOCATION keyword must be specified before other keywords for a
particular source, and the SRCGROUP keyword must be the last
keyword before SO FINISHED.  For keywords on the SO pathway
that accept a range of source IDs, the source parameters
specified by those keywords will only be applied to the sources
already defined, and will exclude any sources that are
specified latter in the input file.

2.1.2 Advantages of the Keyword Approach

     The keyword approach provides some advantages over the
type of input file used by the earlier versions of ISC.  One
advantage is that the keywords are descriptive of the options
and inputs being used for a particular run, making it easier
for a reviewer to ascertain what was accomplished in a
particular run by reviewing the input file.  Another advantage
is that the user has considerable flexibility in structuring
the inputs to improve their readability and understandability,
as long as they adhere to the few basic rules described above.
                              2-5

-------
     Some special provisions have been made to increase the
flexibility to the user in structuring the input files.  One
provision is to allow for blank records in the input file. This
allows the user to separate the pathways from each other, or to
separate a group of images, such as source locations, from the
other images.  Another provision is for the use of "comment
cards," identified by a "**" in the pathway field. Any input
image that has "**" for the pathway ID will be ignored by the
model.  This is especially useful for labeling the columns in
the source parameter input images, as illustrated in the
example problem later in this section.  It may also be used to
"comment out" certain options for a particular run without
deleting the options and associated data (e.g., elevated
terrain heights) completely from the input file.  Because of
the descriptive nature of the keyword options and the
flexibility of the inputs it is generally much easier to make
modifications to an existing input runstream file to obtain the
desired result.

     Another reason for improved "user-friendliness" of the new
models over the previous versions of the models is that much
more detailed error-liandling has been built into the models.
The new model provides descriptions of the location and nature
of all of the errors encountered for a particular run.  Rather
than stopping execution at each occurrence of an input error,
the new model will read through and attempt to process all
input records and report all errors encountered.  If a fatal
error occurs, then the model will not attempt to execute the
model calculations.

2.2 REGULATORY DEFAULT OPTION

     The regulatory default option is controlled from the
MODELOPT keyword on the CO pathway.  As its name implies, this
keyword controls the selection of modeling options.  It is a
mandatory, non-repeatable keyword, and it is an especially
                              2-6

-------
important keyword for understanding and controlling the
operation of the ISC2 models.  As noted in Section 1, the
regulatory default options, as specified in the Guideline on
Air Quality Models, are truly the default options for the ISC2
models.  That is to say that, unless specified otherwise
through the available keyword options, the ISC2 models
implement the following regulatory options:

        Use stack-tip downwash (except for Schulman-Scire
        downwash);
        Use buoyancy-induced dispersion (except for
        Schulman-Scire downwash);
        Do not use gradual plume rise (except for building
        downwash);
        Use the calms processing routines;
        Use upper-bound concentration estimates for sources
        influenced by building downwash from super-squat
        buildings;
        Use default wind profile exponents; and
        Use default vertical potential temperature gradients.

Rather than specifying options with numeric switches as in the
earlier version of the ISC model, the parameters for the
MODELOPT keyword are character strings,  called "secondary
keywords," that are descriptive of the option being selected.
For example, to ensure that the regulatory default options be
used for a particular run, the user would include the secondary
keyword "DFAULT" on the MODELOPT input.   The presence of this
secondary keyword tells the model to override any attempt to
use a non-regulatory default option.  The model will warn the
user if a non-regulatory option is selected along with the
DFAULT option, but will not halt processing.  For regulatory
modeling applications, it is strongly suggested that the DFAULT
switch be set, even though the model defaults to the regulatory
options without it.
                              2-7

-------
     For any application in which a non-regulatory option is to
be selected, the DFAULT switch must not be set, since it would
otherwise override the non-regulatory option.  The
non-regulatory options are also specified by descriptive
secondary keywords, such as "NOBID" to specify the option not
to use buoyancy-induced dispersion.  (A programmer note:  these
modeling option keywords also correspond to the Fortran logical
variable names used to control the options in the ISC2 computer
code.  This is one reason why they are limited to six
characters, .e.g., DFAULT instead of DEFAULT, since the
standard Fortran language (ANSI, 1978) only allows variable
names up to six characters in length).

     The MODELOPT keyword, which is also used to specify the
selection of rural or urban dispersion parameters, and
concentration or deposition values, is described in more detail
in the Section 3.2.2.

2.3 MODEL STORAGE LIMITS

     The ISC2 models have been designed using a static storage
allocation approach, where the model results are stored in data
arrays, and the array limits are controlled by PARAMETER
statements in the Fortran computer code.  These array limits
also correspond to the limits on the number of sources,
receptors, source groups and averaging periods that the model
can accept for a given run.  Depending on the amount of memory
available on the particular computer system being used, and the
needs for a particular modeling application, the storage limits
can easily be changed by modifying the PARAMETER statements and
recompiling the model.  Section 4.2.2 of this volume and Volume
III of the User's Guide provide more information about
modifying the storage limits of the models.

     The limits on the number of receptors, sources, source
groups, averaging periods, and events  (for ISCEV2 model) are
                              2-8

-------
initially set as follows for the three models for the DOS and
extended memory (EM) versions on the PC:
PARAMETER
Name
NREC
NSRC
NGRP
NAVE
NEVE
Limit
Controlled
Number of
Receptors
Number of
Sources
Number of
Source
Groups
Number of
Short Term
Averages
Number of
Events
ISCST2
600 (DOS)
1200 (EM)
100 (DOS)
300 (EM)
2 (DOS)
5 (EM)
2 (DOS)
4 (EM)
-
ISCEV2
-
100 (DOS)
500 (EM)
25 (DOS)
50 (EM)
4 (DOS)
4 (EM)
2500 (DOS)
5000 (EM)
ISCLT2
500 (DOS)
1200 (EM)
100 (DOS)
300 (EM)
3 (DOS)
5 (EM)
-
-
     Fortran PARAMETER statements are also used to specify the
array limits for the number of high short term values by
receptor to store for the ISCST2 model (NVAL, initially set to
6),  and the number of overall maximum values to store (NMAX,
initially set to 50 for ISCST2 and to 10 for Long Term).  The
NMAX limits correspond to the limits available in the previous
versions of the model, but can also be modified by the user and
the model recompiled in order to meet particular needs.

     In addition to the parameters mentioned above, parameters
are used to specify the number of gridded receptor networks in
a particular run (NNET),  and the number of x-coordinate (or
distance) and y-coordinate (or direction) values (IXM and IYM)
for each receptor network.  Initially, the models allow up to 5
receptor networks (of any type), and up to 50 x-coordinates (or
distances) and up to 50 y-coordinates (or directions).  The
source arrays also include limits on the number of variable
emission rate factors per source (NQF, initially set to 96 for
SEASHR in Short Term and to 36 for the DOS version of Long Term
                              2-9

-------
and 144 for the EM version of Long Term),  the number of sectors
for direction-specific building dimensions (NSEC, initially set
to 36 for Short Term and 16 for Long Term),  and the number of
settling and removal categories (NVSMAX,  initially set to 20).

2.4 SETTING UP A SIMPLE RUNSTREAM FILE

     This section goes through a step-by-step description of
setting up a simple application problem,  illustrating the most
commonly used options of the ISCST2 model.  The example problem
is based on the test example file provided with the previous
version of the ISCST model.  The input files for the previous
version of the ISCST model and the new version are shown
together in Figure 2-1.  The remainder of this section explains
the various parts of the input file for the ISCST2 model, and
also illustrates some of the flexibility in structuring the
input file.
                              2-10

-------
  TEST RUNSTREAM - RURAL  DOUMUASH TEST  -  35M STACK, "TALL" BUILDING
   141001001000011011101101211112
                 36
                 200.
1
 100.
  10.
  6.1
      300.
          500.
 1000.
                  10.
  11111111111111111111111111111111111111111111111111111111111111111111111111111111
  11111111111111111111111111111111111111111111111111111111111111111111111111111111
  11111111111111111111111111111111111111111111111111111111111111111111111111111111
  11111111111111111111111111111111111111111111111111111111111111111111111111111111
  1111111111111111111111111111111111111111111111
   94823
      1
   34.0
   34.0
   34.0
     64 94823
          1.0
   34.0 34.0
   34.0 34.0
   34.0 34.0
  64

34.0
34.0
34.0
              35.  432. 11.70   2.4 -34. 33.33
34.0  34.0  34.0  34.0  34.0  34.0 34.0  34.0
34.0  34.0  34.0  34.0  34.0  34.0 34.0  34.0
34.0  34.0  34.0  34.0  34.0  34.0 34.0  34.0
                               15.
   35.43 36.45 36.37 35.18 32.92 29.66 25.50 20.56  15.00 20.56 25.50  29.66
   32.92 35.18 36.37 36.45 35.43 33.33 35.43 36.45  0.00 35.18 32.92  29.66
   25.50 20.56 15.00 20.56 25.50 29.66 32.92 35.18  36.37 36.45 35.43  33.33
  CO STARTING
  CO TITLEONE A Simple Example Problem for the ISCST2 Model
  CO HOOELOPT  DFAULT  RURAL  CONC
  CO AVERT I ME  3  24  PERIOD
  CO POLLUTID  S02
  CO  RUNORNOT
  CO  FINISHED

  SO  STARTING
  SO  LOCATION
  SO  SRCPARAM
  SO  BUILDHGT
  SO  BUILDHGT
  SO  BUILDHGT
  SO  BUILDUID
  SO  BUILDUID
  SO  BUILDUID
  SO  BUILDUID
  SO  BUILDUID
  SO  SRCGROUP
  SO  FINISHED

  RE  STARTING
  RE  GRIDPOLR
  RE  GRIDPOLR
  RE  GRIDPOLR
  RE  GRIDPOLR
  RE  GRIDPOLR
  RE  FINISHED

  ME  STARTING
  ME  INPUTFIL
  ME  ANEMHGHT
  ME  SURFDATA
  ME  UAIRDATA
  ME  FINISHED

  OU  STARTING
  OU  RECTABLE
  OU  MAXTABLE
  OU  FINISHED
        RUN
        STACK1
        STACK1
        STACK1
        STACK1
        STACK1
        STACK1
        STACK1
        STACK1
        STACK1
        STACK1
        ALL
POINT  0.0
1.00  35.0
34. 34. 34.
34. 34. 34.
34. 34, 34.
35.43 36.45
15.00 20.56
35.43 33.33
25.50 20.56
36.37 36.45
       0.0   0.0
      432.0  11.7
      34.  34. 34.
      34.  34. 34.
      34.  34. 34.
      36.37 35.18
      25.50 29.66
      35.43 36.45
      15.00 20.56
      35.43 33.33
 2.4
34. 34.  34.
34. 34.  34.
34. 34.  34.
32.92 29.66
32.92 35.18
 0.00 35.18
25.50 29.66
34. 34.  34.
34. 34.  34.
34. 34.  34.
25.50 20.56
36.37 36.45
32.92 29.66
32.92 35.18
POL1
POL1
POL1
POL1
POL1
STA
ORIG
DIST
GDIR
END

0.0
100.
36


0.0
200.
10.



300.
10.

                                    500.  1000.
        PREPIT.BIN  UNFORM
        20  FEET
        94823  1964  PITTSBURGH
        94823  1964  PITTSBURGH
        ALLAVE
        ALLAVE
 FIRST
 50
  SECOND
FIGURE  2-1.  EXAMPLE  INPUT FILES  FOR  ISCST  (top)  AND  ISCST2

                   (bottom)  MODELS FOR  SAMPLE  PROBLEM
                                               2-11

-------
2.4.1 A Simple Industrial Source Application


     For this simple tutorial,  an application is selected

involving a single point source of SO2 that  is  subject  to the

influences of building downwash.  The source consists of a

35-meter stack with a buoyant release that is adjacent to a

building.  We will assume that the stack is situated in a rural

setting with relatively flat terrain within 50 kilometers of

the plant.  A polar receptor network will be placed around the

stack location to identify areas of maximum impact.


2.4.2 Selecting Modeling Options - CO Pathway


     The modeling options are input to the model on the control

pathway.  The mandatory keywords for the CO pathway are listed

below.  A complete listing of all keywords is provided in

Appendix B.


     STARTING - Indicates the beginning of inputs for the
                pathway; this keyword is mandatory on each of
                the pathways.

     TITLEONE - A user-specified title line (up to 68
                characters) that will appear on each page of
                the printed output file (an optional second
                title line is also available with the keyword
                TITLETWO).

     MODELOPT - Controls the modeling options selected for a
                particular run through a series of secondary
                keywords.

     AVERTIME - Identifies the averaging periods to be
                calculated for a particular run.

     POLLUTID - Identifies the type of pollutant being modeled.
                At the present time, this option only
                influences the results if SO, is modeled with
                urban dispersion in the regulatory default
                mode, when a half-life of 4 hours is used to
                model exponential decay.

     •RUNORNOT - A special keyword that tells the model whether
                to run the full model executions or not.  If


                              2-12

-------
                the user selects not to  run,  then the runstream
                setup file will be processed  and any input
                errors reported, but no  dispersion calculations
                will be made.
     FINISHED - Indicates that the user  is  finished with the
                inputs for this pathway;  this keyword is also
                mandatory on each of the other pathways.

     The first two keywords are fairly self-explanatory.  As
discussed above in Section 2.2, the MODELOPT  keyword on the CO
pathway is pivotal to controlling the modeling options used for
a particular run.  For this example, we  intend to use the
regulatory default options, so we will include the "DFAULT"
keyword on our MODELOPT input image.  We also need to identify
whether the source being modeled is in a rural or an urban
environment (see Section 8.2.8 of the Guideline on Air Quality
Models for a discussion of rural/urban determinations).   For
this example we are assuming that the facility is in a rural
setting.  We also need to identify on this  input image whether
we want the model to calculate concentration  values or
deposition values.  For this example, we are  calculating
concentration values.  After the first three  input records our
input file will look something like this:
      CO STARTING
      CO TITLEONE A Simple Example Problem for the ISCST2 Model
      CO MODELOPT DFAULT RURAL CONC
Note that the title parameter  field  does  not need to be in
quotations, even though it represents  a single parameter.   The
model simply reads whatever appears  in columns 13 through 80 of
the TITLEONE card as the title field,  without changing the
lower case to upper case letters.  Leading blanks are therefore
significant if the user wishes to  center  the title within the
field.  Note also that the spacing and order of the secondary
                              2-13

-------
keywords on the MODELOPT card are not significant.  A MODELOPT
card that looked  like this:
      CO HOOELOPT  RURAL  CONG           DFAULT
would have an  identical result as the example above.   It is
suggested that the  user adopt a style that is consistent and
easy to read.  A  complete description of the available modeling
options that can  be specified on the MODELOPT keyword is
provided in Section 3.

     Since the pollutant in this example is SO2, we will
probably need  to  calculate average values for 3-hour  and
24-hour time periods,  and we also need to calculate averages
for the full annual time period.  Our runstream file  might
therefore look something like this after adding two more
keywords:
      CO STARTING
      CO TITLEONE A Simple Example Problem for the ISCST2 Model
      CO MOOELOPT DFAULT RURAL  CONC
      CO AVERT I ME 3 24  PERIOD
      CO POLLUTID S02
Note again that  the order of the parameters on the  AVERTIME
keyword  is not critical,  although the order of the  short term
averages given on the AVERTIME keyword will also  be the order
in which the  results are presented in the output  file.   The
order of the  keywords within each pathway is also not critical
in most cases, although the intent of the input runstream file
may be easier to decipher if a consistent and logical order is
followed.  It is suggested that users follow the  order in which
the keywords  are presented in Section 3, in Appendix B, and in
the Quick Reference Card, unless there is a clear advantage to
doing otherwise.
                               2-14

-------
     The  only remaining mandatory keywords  for the CO pathway
are RUNORNOT and FINISHED.   We will set the RUNORNOT switch to
RUN for this example.  If a user is unsure  about the operation
of certain options, or is setting up a complex runstream file
to run for the first time,  it may be desirable to set the model
NOT to run,  but simply to read and analyze  the input file and
report any errors or warning messages that  are generated.   Once
the input file has been debugged using these descriptive
error/warning messages, then the RUNORNOT switch can be  set to
RUN, avoiding a possible  costly waste of resources generating
erroneous results.  Even  if the model is set NOT to run,  all of
the inputs are summarized in the output file for the user to
review.


     Our  complete runstream file for the CO pathway may  look
something like this:
       CO STARTING
       CO TITLEONE A Simple Example Problem for the ISCST2 Model
       CO MODELOPT  DFAULT RURAL CONC
       CO AVERT!ME  3  24 PERIOD
       CO POLLUTID  S02
       CO RUNORNOT  RUN
       CO FINISHED
The following set of runstream images has  a more structured
look, but  it is equivalent to the example  above:
      CO STARTING
        TITLEONE A Simple Example Problem for the ISCST2 Model
        MODELOPT  DFAULT  RURAL CONC
        AVERT IME  3  24 PERIOD
        POLLUTID  S02
        RUNORNOT  RUN
      CO FINISHED
Since the  pathway ID is  required to begin  in column 1  (see
Section  2.4.8 for a discussion of this restriction), the  model
will assume-that the previous pathway is in effect if  the
                               2-15

-------
pathway field is left blank.  The model will do the same for
blank keyword fields, which will be illustrated in the next
section.

     In addition to these mandatory keywords on the CO pathway,
the user may select optional keywords to specify that elevated
terrain heights will be used (the default is flat terrain), to
allow the use of receptor heights above ground-level for
flagpole receptors, to specify a decay coefficient or a
half-life for exponential decay, and to generate an input file
containing events for processing with the EVENT model.  The
user also has the option of having the model periodically save
the results to a file for later re-starting in the event of a
power failure or other interruption of the model's execution.
These options are described in more detail in Section 3 of this
volume.

2<>4.3 Specifying Source Inputs ^ SO Pathway

     Besides the STARTING and FINISHED keywords that are
mandatory for all pathways, the SOurce pathway has the
following mandatory keywords:

     LOCATION - Identifies a particular source ID and specifies
                the source type and location of that source.
     SRCPARAM - Specifies the source parameters for a
                particular source ID identified by a previous
                LOCATION card.
     SRCGROUP - Specifies how sources will be grouped for
                calculational purposes.  There is always at
                least one group, even though it may be the
                group of ALL sources and even if there is only
                one source.
Since the hypothetical source in our example problem is
influenced by a nearby building, we also need to include the
optional keywords BUILDHGT and BUILDWID in our input file.
                              2-16

-------
     The input file for the SO pathway for this example will
look something like this:
SO STARTING
SO LOCATION
SO SRCPARAH
SO BUILDHGT
SO BUILDHGT
SO BUILDHGT
SO BUILDWID
SO BUILDWID
SO BUILDUID
SO BUILDUID
SO BUILDWID
SO SRCGROUP
SO FINISHED

STACK1
STACK1
STACK1
STACK1
STACK1
STACK1
STACK1
STACK1
STACK1
STACK1
ALL


POINT 0.0 0.0 0.0
1.00 35.0 432.0 11.7 2.4
34. 34. 34. 34. 34. 34. 34. 34. 34. 34. 34. 34.
34. 34. 34. 34. 34. 34. 34. 34. 34. 34. 34. 34.
34. 34. 34. 34. 34. 34. 34. 34. 34. 34. 34. 34.
35.43 36.45 36.37 35.18 32.92 29.66 25.50 20.56
15.00 20.56 25.50 29.66 32.92 35.18 36.37 36.45
35.43 33.33 35.43 36.45 0.00 35.18 32.92 29.66
25.50 20.56 15.00 20.56 25.50 29.66 32.92 35.18
36.37 36.45 35.43 33.33


     There are a few things to note about these inputs.
Firstly, the source ID (STACK1 in this example) is an
alphanumeric parameter (up to eight characters) that identifies
the inputs for different keywords with a particular source.  It
is crucial that the source be identified with a LOCATION card
before any other keyword makes reference to that source, since
this identifies the source type (POINT in this case), and
therefore which parameters the model will allow.  Besides POINT
sources, the current versions of the ISC2 models also allow
VOLUME and AREA sources to be specified.

     Another thing to note is that since the new versions of
the models use direction-specific building dimensions for all
sources with downwash, there are 36 building heights and 36
building widths entered on the appropriate keywords, one value
for each 10 degree sector beginning with the 10 degree flow
vector  (direction toward which the wind is blowing), and
continuing clockwise.  Since the user could not fit all 36
values on a single record, the pathway, keyword and source ID
were repeated as many times as were necessary.  In this case
there were 12 values given on each of three lines for the
building heights, and eight values on each of four lines plus a
line of four values for building widths.  There could have been
fewer or more lines as long as exactly 36 values were entered
                              2-17

-------
before starting with a new keyword.  Since all of the building
heights were the same across the sectors (fairly realistic for
the height but not for widths, unless the structure was
circular), there is a short cut available for specifying
numeric input in the runstream files for the new models.  The
user can specify "repeat values" by entering a field such as
"36*34.0" as a parameter for the BUILDHGT keyword.  The model
will interpret this as "36 separate entries, each with a value
of 34.0," and store the values in the appropriate arrays within
the model.  Since the model must identify this as a single
parameter field, there must not be any spaces between the
repeat-value and the value to be repeated.

     The final keyword before finishing the SO pathway must be
the SRCGROUP keyword.  In this example, since there is only one
source, we have taken advantage of a short cut provided by the
model by specifying a source group ID  (which may be up to eight
characters) of ALL.  Whenever this card appears in an input
file, it will generate a source group with a source-group ID of
ALL, consisting of all sources defined for that run.  The
sources do not have to be explicitly identified.  In a run
involving multiple sources, the user may specify multiple
source groups by repeating the SRCGROUP keyword.  The use of
the SRCGROUP card is explained in more detail in Section 3.
                              2-18

-------
     Using some of the formatting  options discussed above,  the
SO pathway for our example may look like this, with the same
result  as above:
       SO STARTING
         LOCATION STACK1 POINT  0.0  0.0  0.0
                     QS
                         HS
                             TS
VS  DS
** Point Source
** Parameters:     --	-- 	 —
  SRCPARAM STACK1  1.00 35.0 432. 11.7 2.4
  BUILDHGT STACK1  36*34.
  BUILDUID STACK1  35.43 36.45 36.37 35.18 32.92 29.66 25.50 20.56
        STACK1  15.00 20.56 25.50 29.66,32.92 35.18 36.37 36.45
        STACK1  35.43 33.33 35.43 36.45  0.00 35.18 32.92 29.66
        STACK1  25.50 20.56 15.00 20.56 25.50 29.66 32.92 35.18
        STACK1  36.37 36.45 35.43 33.33
  SRCGROUP ALL
SO FINISHED
This version of the  SO pathway  inputs illustrates the use  of
the comment card to  label the stack parameters  on the SRCPARAM
card,  i.e., QS for emission rate  (g/s),  HS for  stack height
(m), TS  for stack exit temperature (K),  VS for  exit velocity
(m/s), and DS for stack diameter  (m).  A complete description
of the source parameter card, with a list of parameters for
each source type, is provided in  Section 3.3 and in Appendix B.

     Other optional  inputs that may be entered  on the SO
pathway  include specifying variable emission rate factors  for
sources  whose emissions vary as a function of month, season,
hour-of-day, STAR category, or  season and hour-of-day (see
Section  3.3.4 for more details).   The number of factors entered
depends  on the option selected, and factors may be input for
single sources or for a range of  sources.  Other keywords  allow
the user to specify  settling velocity categories, mass
fractions, and reflection coefficients for sources of large
particulates that experience settling and removal of the
pollutant as it is dispersed and  transported downwind.  This
option is also explained in more  detail in Section 3.
                                2-19

-------
2.4.4 Specifying a Receptor Network  - RE  Pathway

     As mentioned above, this example will  illustrate the use
of a single polar receptor network centered on the stack
location.  Other options available on the REceptor pathway
include specifying a Cartesian grid  receptor network,
specifying discrete receptor locations  in either a polar or a
Cartesian system, and specifying the location of receptors
along the boundary around a particular  source.  These other
options are described in more detail in Section 3.4.

     For this example we will specify a polar network with
receptors located at five downwind distances for every
10-degree flow vector around the plant.   There will be a total
of 180 receptors.  The RE pathway for this  example will look
something like this:
      RE STARTING
        GRIDPOLR POL1  STA
              POL1  ORIG  Q.Q  0.0
              POL1  OIST  100. 200.  300. 500. 1000.
              POL1  GDIR  36  10.  10.
              POL1  END
      RE FINISHED
     The first thing to note  about these inputs is that there
is a new set of keywords,  including something that looks like a
STArting and ENDing.   In  fact the GRIDPOLR keyword can be
thought of as a "sub-pathway," in that all of the information
for a particular polar network must be in contiguous records,
and that the starting  and ending of the sub-pathway are
identified.  The order of secondary keywords within the
sub-pathway is not  critical,  similar to the main pathways. Each
card must be identified with  a network ID (up to four
alphanumeric characters),  in  this case it is "POLL"  Multiple
networks may be specified in  a single model run.  The model
waits until the END secondary keyword is encountered to set the
                              2-20

-------
variables, which may include terrain heights for receptors on
elevated terrain or flagpole receptor heights if those options
are being exercised by the user.  The use of these optional
secondary keywords is described in detail in Section 3.4.

     For this example, the ORIG secondary keyword specifies the
location of the origin, in (X,Y) coordinates, for the polar
network being defined.  This network is centered at the same
(X,Y) location as the source specified above.  The ORIG keyword
is optional, and the model will default to an origin of (0.0,
0.0) if it is omitted.  The DIST keyword identifies the
distances along each direction radial at which the receptors
will be located.  In this case there are five distances.  More
could be added by adding values to that input card or by
including a continuation card, if needed.  The GDIR keyword
specifies that the model will Generate DIRection radials for
the network, in this case there will be 36 directions,
beginning with the 10 degree flow vector and incrementing every
10 degrees clockwise.  The user may elect to define Discrete
DIRection radials instead by using the DDIR keyword in place of
the GDIR keyword.

2.4.5 Specifying the Meteorological Input - ME Pathway

     The MEteorolgy pathway has the following three mandatory
keywords  (besides STARTING and FINISHED, of course):

     INPUTFIL - Specifies the filename and format for the input
                meteorological data file.
     ANEMHGHT - Specifies the anemometer height for the wind
                data to be used for the modeling run.
     SURFDATA - Specifies information about the surface
                meteorological data which will be used in the
                modeling.
     UAIRDATA - Specifies' information about the upper air
                meteorological data (i.e. mixing heights)  which
                will be used in the modeling.
                              2-21

-------
For the purposes of this  example we will assume that the
meteorological data file  is  an unformatted (sometimes called
"binary") file that was generated by the RAMMET meteorological
preprocessor program.  The filename is PREPIT.BIN (the sample
file that is provided  on  the SCRAM BBS with the RAMMET model),
and it consists of one year  of data for Pittsburgh, PA from
1964.  The runstream images  for the MEteorology pathway would
look something like this:
      ME STARTING
        INPUTFR PREPIT.BIN  UNFORM
        ANEMHGHT 20 FEET
        SURFDATA 94823 1964 PITTSBURGH
        UAIROATA 94823 1964 PITTSBURGH
      ME FINISHED
     The first parameter  on the INPUTFIL keyword is the
filename, which can  be  entered as a full DOS pathname,
including the drive  specification and subdirectories, up to a
total of 40 characters.   The second parameter is the format of
the meteorology data file.   In this case the secondary keyword
of UNFORM is used  to specify that the meteorological data  file
is of the UNFORMatted type  generated by RAMMET (or MPRM).
Another option to  the user  would be to leave the format
parameter field blank,  in which case the model will assume a
default read format  for an  ASCII file of hourly records.   The
order of variables assumed  for the ASCII file input is as
follows:  year, month,  day,  hour, flow vector, wind speed
(m/s), temperature (K), stability category, rural mixing height
(m), and urban mixing height (m).  Other user options for
specifying the format for ASCII meteorology files are described
more fully in Section 3.5.1.

     The ANEMHGHT  keyword is important because the input wind
speed data are adjusted from the anemometer height to the
release height for model  calculations, so that differences in
anemometer height  can significantly effect the modeled results.

                              2-22

-------
For National Weather Service (NWS) data, the user should check
records (e.g. the Local Climatological Data summary report) for
the particular station to determine the correct anemometer
height for the data period used in the modeling, since the
anemometer location and height may change over time.  The model
will assume that the anemometer height is in meters, unless the
secondary keyword "FEET" is included in the runstream image, as
illustrated in this example.  The model will convert inputs in
feet to meters.

     The final two mandatory inputs identify the location and
data period of the input meteorological data.  A separate
keyword is used for the surface meteorological data and for the
upper air (mixing height) data.  The parameters on these cards
are the station number (e.g. WBAN number for NWS stations), the
data period (year), and a station name.  It is important that
these inputs be provided correctly since the model compares the
station number and year from the runstream input file with
values provided in the first record of the meteorology file.
The user may also optionally input the (X,Y) coordinates for
the location of the station(s), although these values are not
currently used by the model.

     Other optional keywords available on the ME pathway
provide the user with options to specify selected days to
process from the meteorological data file, a wind direction
rotation correction term, and user-specified wind speed profile
exponents and/or vertical potential temperature gradients.  The
wind profile exponents and potential temperature gradients are
ignored (and a warning message generated) if the regulatory
default option is selected.  These optional inputs are
described in more detail in Section 3.5.
                              2-23

-------
2.4.6 Selecting Output Options - OU Pathway

     All of the keywords on the output pathway are optional,
although the model will warn the user if no printed outputs are
requested and will halt processing if no outputs (printed
results or file outputs) are selected.  The following three
keywords correspond to the printed result output options
available in the previous version of the ISCST model, although
the user has greater flexibility to select only the outputs
that are needed for a particular application.  The printed
table keywords are:

     REGTABLE - Specifies the selection of high value by
                receptor table output options.
     MAXTABLE - Specifies the selection of overall maximum
                value table output options.
     DAYTABLE - Specifies the selection of printed results  (by
                receptor) for each day of data processed (this
                option can produce very large files and such be
                used with care).

     The RECTABLE keyword corresponds to the option for
highest, second-highest and third-highest values by receptor
available in the old ISCST model.  The MAXTABLE keyword
corresponds to the maximum 50 table option available in the old
ISCST model.  For both of these keywords, the user has
additional flexibility to specify for which short term
averaging periods the outputs are selected.  For the MAXTABLE
keyword the user can also specify the number of overall maximum
values to summarize for each averaging period selected, up to a
maximum number controlled by a parameter in the computer code.
For this example problem we will select the highest and
second-highest values by receptor, and the maximum 50 values
                              2-24

-------
for all averaging periods.   These OU pathway inputs will  look
something like this:
      OU STARTING
        RECTABLE ALLAVE FIRST  SECOND
        MAXTABLE ALLAVE 50
      OU FINISHED
     To simplify the  input for users who request the same
printed table output  options for all averaging periods, these
keywords recognize  the secondary keyword "ALLAVE" as the first
parameter for that  purpose.   In order to obtain the overall
maximum 10 values for the 24-hour averages only, then the  OU
pathway images would  look like this:
      OU STARTING
        RECTABLE ALLAVE FIRST  SECOND
        MAXTABLE 24  10
      OU FINISHED
It should also be  noted that these output table options  apply
only to the short-term averaging periods, such as the  3-hour
and 24-hour averages  used in our example.  If the user has
selected that PERIOD  averages be calculated (on the CO AVERTIME
keyword), then the output file will automatically include a
table of period averages summarized by receptor (the RECTABLE
option does not apply since there is only one period value for
each receptor).  In addition,  the printed output file  will
include tables summarizing the highest values for each
averaging period and  source group.

     Other options on the OU pathway include several keywords
to produce output  files for specialized purposes, such as
generating contour plots of high values, identifying
occurrences of violations of a particular threshold value  (e.g.
a NAAQS), and for  postprocessing of the raw concentration data.
These options are  described in detail in Section 3.6.

                               2-25

-------
     The complete input runstream file for this simple example
is shown in Figure 2-2.  Note that a consistent style has been
used for formatting and structuring the file in order to
improve its readability.  This input file is comparable to the
version shown earlier in Figure 2-1, which used a somewhat
different style.
                              2-26

-------
 CO STARTING
    TITLEONE A Simple Example Problem for the ISCST2 Model
    MODELOPT DFAULT RURAL CONC
    AVERT1ME 3 24 PERIOD
    POLLUTID S02
    RUNORNOT RUN
 CO FINISHED

 SO STARTING
    LOCATION STACK1 POINT 0.0  0.0  0.0

 ** Point Source     QS   HS   TS  VS  DS
 ** Parameters:     	  	 	 —
    SRCPARAM STACK1 1.00  35.0 432.  11.7 2.4

    BUILDHGT STACK1 36*34.
    BUILDWID STACK1 35.43 36.45 36.37 35.18 32.92 29.66 25.50 20.56
           STACK1 15.00 20.56 25.50 29.66 32.92 35.18 36.37 36.45
           STACK1 35.43 33.33 35.43 36.45  0.00 35.18 32.92 29.66
           STACK1 25.50 20.56 15.00 20.56 25.50 29.66 32.92 35.18
           STACK1 36.37 36.45 35.43 33.33
    SRCGROUP ALL
 SO FINISHED

 RE STARTING
    GRIDPOLR POL1  STA
           POL1  ORIG 0.0  0.0
           POL1  DIST 100.  200.  300.  500. 1000.
           POL1  GDIR 36   10.  10.
           POL1  END
 RE FINISHED

 ME STARTING
    INPUTFIL PREPIT.BIN UNFORM
    ANEMHGHT 20 FEET
    SURFDATA 94823 1964  PITTSBURGH
    UAIRDATA 94823 1964  PITTSBURGH
 ME FINISHED

 OU STARTING
    RECTABLE ALLAVE FIRST SECOND
    MAXTABLE ALLAVE 50
 OU FINISHED
FIGURE  2-2.  EXAMPLE INPUT  RUNSTREAM FILE  FOR  SAMPLE PROBLEM
2.4.7  Using the Error  Message  File to  Debug the Input Runstream
      File


      The previous  sections in  this tutorial have  lead through
the step-by-step construction  of a sample  runstream  input file
for ISCST2.   This  simple example problem illustrated the  usage
of  the most commonly used  options  of the ISCST2 model. However,
many real-time applications of the model will  be  much more
complex than this  example,  perhaps involving multiple sources
                                     2-27

-------
and source groups, multiple receptor networks, the addition of
discrete receptor locations, and/or elevated terrain heights.
Since humans are prone to make errors from time to time, an
effort has been made to develop improved error handling
capabilities for the ISC2 models.

     The error handling capabilities of the ISC2 models are
designed to accomplish two things for the user.  First, the
model should read through the complete input file and report
all occurrences of errors or suspect entries before stopping,
rather than stopping on the first instance (and every instance
thereafter) of an error in the input file.  Second, the model
should provide error and warning messages that are detailed and
descriptive enough that they will help the user in his/her
effort to debug the input file.  The remainder of this section
provides of brief introduction to the use of the model's error
handling capabilities.  Appendix E of this volume provides more
details about the error handling provided by the ISC2 models,
including a listing and explanation of all error and other
types of messages generated by the models.

     The ISC2 models generate messages during the processing of
the input data and during the execution of model calculations.
These messages inform the user about a range of possible
conditions including:

        Errors that will halt any further processing, except to
        identify additional error conditions;
        Warnings that do not halt processing but indicate a
        possible errors or suspect conditions; and
        Informational messages that may be of interest to the
        user but have no direct bearing on the validity of the
        results.

     As the model encounters a condition for which a message is
generated, the model writes the message to a temporary storage
file.  At the completion of the setup processing for a run, and
                              2-28

-------
at the completion of the model  calculations, the model rereads
the message file and generates  a summary of the messages which
is included in the main printed output file.  If the processing
of the model setup information  indicates no errors  or warnings,
and the user has selected the option to RUN the model
calculations on the CO RUNORNOT card, then the model will
simply write a statement to the print file that the model setup
was completed successfully.  Otherwise, the model will report a
summary of  the messages encountered.  The summary of model
setup messages that would be generated for the example problem
if the option NOT to run was chosen is shown in Figure 2-3.
This summary table reports the  total number of occurrences for
each of the message types, and  lists the detailed message for
any fatal errors or warning messages that were generated.  In
this case,  since there were no  errors or suspicious conditions
in the setup file, there are no error or warning messages
listed.

     An example of the warning  message that would have been
generated had we left out the card on the RE pathway that
specifies the origin of the polar receptor network  is shown
below:
       RE U220 39 REPOLR: Missing Origin (Use Default = 0,0) In GRIDPOLR
POL1
                                                   Hints
                   Detailed error/warning message
             Subroutine from which message is generated
           Line number of file where message occurred
        Message code. - including message type (E, W, I) and message number
      Pathway ID where message originated
Since this  is a warning message,  it would have appeared at the
end of the  message summary table  in the output file,  but it
would not have halted processing  of the data.  The  last item on
                               2-29

-------
the message line, "Hints," may include such information as the
keyword or parameter name causing the error, the source ID,
group ID or (as in this case) the network ID involved, or
perhaps the date variable identifying when the message occurred
during the processing of the meteorological data, such as an
informational message identifying the occurrence of a calm
wind.

     For new users and for particularly complex applications,
it is strongly recommended that the model first be run with the
RUNORNOT keyword (on the CO pathway) set NOT to run.  In this
way, the user can determine if the model is being setup
properly by the runstream file before committing the resources
to perform a complete run.  The user should make a point of
examining any warning messages carefully to be sure that the
model is operating as expected for their application, since
these messages will not halt processing by the model.  In most
cases, the detailed messages will provide enough information
for the user to determine the location and nature of any errors
in the runstream setup file.  If the intent of the message is
not immediately clear, then the user should refer to the more
detailed descriptions provided in Appendix E for the particular
error code generated.

     In deciphering the error and warning messages, the line
number provided as part of the message may be particularly
helpful in locating the error within the input file.  However,
if it is an error of omission that is caught by the error
checking performed at the completion of inputs for a pathway,
then the line number will correspond to the last record for
that pathway.  The user may need to examine all of the messages
carefully before locating the error or errors, especially since
a•single occurrence of certain types of errors may lead to
other error conditions being identified later in the input file
which do not really constitute errors in themselves.  An
example of this is provided  in Figure 2-4, which shows some
                              2-30

-------
inputs for the SO pathway where the building dimension keywords
have been typed incorrectly, and the associated list of error
messages.  Since continuation cards were being used for the
building width inputs, and the keyword was entered incorrectly
on the first line, the subsequent records were also taken by
the model to be invalid keyword inputs.  While the error
messages are the same for these records, the message originates
from a different part of the model (SUBROUTINE SOCARD) for the
records with the blank keyword.

     Since the detailed error and warning messages are listed
in the output file as part of the message summary table, there
will generally not be a need for the user to examine the
contents of the detailed message file.  For this reason, the
default operation of the model is to write the messages that
are generated by a particular run to a temporary file that is
deleted when the run is completed.  If the user wishes to
examine the complete list of detailed messages (of all types),
there is an optional keyword available on the CO pathway for
that purpose.  The ERRORFIL keyword, which is described in
                              2-31

-------
detail in Section 3.2.7,  allows the user  to  save the  complete

list of detailed messages to a user-specified filename.
   *** Message Sumiary For ISC2 Model Setup ***
           Summary of Total Messages
 A Total of         0 Fatal Error Message(s)
 A Total of         0 Warning Message(s)
 A Total of         0 Information Message(s)
    ******** FATAL ERROR MESSAGES ********
             ***  NONE  ***
    ********  WARNING MESSAGES  ********
             ***  NONE  ***
    ***********************************
    *** SETUP Finishes Successfully ***
    ***********************************
 FIGURE  2-3.    EXAMPLE  MESSAGE SUMMARY TABLE FOR RUNSTREAM  SETUP
                                      2-32

-------
 SO STARTING
   LOCATION STACK1  POINT  0.0   0.0  0.0
 ** Point Source      OS    HS    TS    VS  DS
 ** Parameters:      	  	  	--  —
   SRCPARAM STACK1  1.00  35.0  432.0 11.7  2.4
   BUILOHTS STACK1  36*34.
   BUILDUTS STACK1  35.43 36.45 36.37 35.18 32.92 29.66 25.50 20.56
           STACK1  15.00 20.56 25.50 29.66 32.92 35.18 36.37 36.45
           STACK1  35.43 33.33 35.43 36.45  0.00 35.18 32.92 29.66
           STACK1  25.50 20.56 15.00 20.56 25.50 29.66 32.92 35.18
           STACK1  36.37 36.45 35.43 33.33
   SRCGROUP ALL
 SO FINISHED
  *** Message Summary For ISC2 Model Setup ***
  	 Summary of Total Messages 	
 A Total of         6 Fatal Error Message(s)
 A Total of         0 Warning Message(s)
 A Total of         0 Information Message(s)

   ******** FATAL ERROR MESSAGES ********
 SO E105   17 EXKEY : Invalid Keyword Specified. The Troubled Keyword is BUILDHTS
 SO E105   18 EXKEY : Invalid Keyword Specified. The Troubled Keyword is BUILDUTS
 SO E105   19 SOCARD: Invalid Keyword Specified. The Troubled Keyword is BUILDUTS
 SO E105   20 SOCARD: Invalid Keyword Specified. The Troubled Keyword is BUILDUTS
 SO E105   21 SOCARD: Invalid Keyword Specified. The Troubled Keyword is BUILDUTS
 SO E105   22 SOCARD: Invalid Keyword Specified. The Troubled Keyword is BUILDWTS

   ********  UARNING MESSAGES   ********
            ***  NONE ***

   **************************************
   *** SETUP Finishes UN-successfully ***
   **************************************
FIGURE  2-4.  EXAMPLE OF KEYWORD ERROR AND  ASSOCIATED MESSAGE
                SUMMARY TABLE
2.4.8  Running the Model  and  Reviewing the  Results

      Now that we have  a  complete  and error-free runstream  input
file,  we are  ready  to  run the  model  and then review  the
results.    Running the  model  on the PC is similar to  running the
previous version of the  model  on  the PC, although  we now have
to specify the meteorology filename  from the runstream  file-
                                        2-33

-------
instead of on the command line.  Also,  the PC-executable files
available on the SCRAM BBS open the runstream input and printed
output files explicitly within the model, so there is no need
to "redirect" the I/O on the command line using the DOS
redirection symbols '<• and •>'.  The command line to run the
sample problem might look something like this on the PC:

          C:\>ISCST2 TEST-ST.INP TEST-ST.OUT

The "c-prompt" of DOS has been represented by the characters
"C:\>", but may appear different on different machines.  The
important points are that the ISCST2.EXE file either be in the
directory from which you are attempting to run the model, or in
a directory that is included on the DOS PATH command when the
system is "booted-up."  The runstream input filename must
appear first  (without any DOS "redirection" symbol), followed
by the desired output filename  (also without the DOS
redirection symbol), and these files must also be located in
the directory from which the model is being executed, unless a
complete DOS pathname is provided on the command line.

     As mentioned above, the SCRAM PC-executable files for ISC2
open the input and output files explicitly.  One reason for
this is to allow for the models to write an update on the
status of processing to the PC terminal screen.  For the ISCST2
model, the model first indicates that setup information is
being processed and then gives the Julian day currently being
processed.  If no status message is seen then the model did not
load into memory properly.  If the model stops after completing
the setup processing, then either the RUNORNOT option was set
NOT to run, or a fatal error was encountered during the setup
processing.  Another reason for not sending the printed output
to the default output device (i.e., to the screen or redirected
to a file), is so that any DOS error messages will be visible
on the screen and not be written to the printed file.  One such
message might be that there is insufficient memory available to
                              2-34

-------
run the program.  Handling of DOS error messages may require
some knowledge of DOS, unless the meaning of the message is
obvious.


     The order of contents and organization of the main output
file for the ISC2 models is presented in Figure 2-5.
 Echo of Input Runstream Images

 Summary of Runstream Setup Messages

 Summary of Inputs
      Summary of Modeling Options
      Summary of Source Data
      Summary of Receptor Data
      Summary of Meteorology Data

 Model Results

      Daily Results for Each Averaging Period Selected for
         Each Day  Processed (If  Applicable)
         - DAYTABLE Keyword

      Period Results for Each Source Group (If Applicable)
         - PERIOD  Parameter on AVERTIME Keyword

      Short Term Average Results  (High,  Second High,  etc.)
         by Receptor for Each Source Group  (If Applicable)
         - RECTABLE Keyword

      Overall Maximum Short Term  Average Results  for Each
         Source Group (If  Applicable)
         - MAXTABLE Keyword

 Summary Tables of High Values for Each Averaging Period  and
      Source Group  (Always provided if PERIOD averages or the
      RECTABLE keyword are used)

 Summary of Complete Model Execution Messages
     FIGURE 2-5.  ORGANIZATION OF ISCST2 MODEL OUTPUT FILE


Each page of the output file, except for the echo of the input

file images, is labeled with the model name and version number,

user-specified title(s), page number, and, for the PC version

of the model, the date and time of the particular run.  Also


                              2-35

-------
included as part of the header information for each page is a
one-line summary of the modeling options used for that
particular run.  The modeling options are listed as the
secondary keywords used to control the options, such as URBAN
or RURAL, CONG or DEPOS, DFAULT, NOCALM, etc.  (Details about
the date/time routines used on the PC version and how these
non-standard routines are bypassed on other systems are
provided in Volume III.)

     Since the complete input file is normally echoed back as
part of the output file, and since processing of the inputs
stops when the OU FINISHED card is reached, the run can be
duplicated by simply specifying the output filename as the
input runstream file.  Alternatively, the input records could
be "cut and pasted" from the output file to a separate file
using a text editor.  Since the outputs are not being printed
to the default output device by the DOS PC version, the input
records in the printed output file will all be shifted by one
column to the right (the first column is normally used for
Fortran carriage control, and is left blank in case the model
is ported to a system where the default output device is used).
The model will still run properly with these inputs, since it
has been written to allow a shift of up to three columns to the
right, as long as each input record is shifted by the same
amount.  However, each successive run of the model will shift
the inputs one more column, and there will be the risk that
parts of the record beyond column 80 will be lost, possibly
resulting in an error message or invalid results.

     By default, the models will echo each line of the input
runstream file to the printed output file.  This provides a
convenient record of the inputs as originally read into the
model, without any rounding of numerical values that may appear
in the input summary tables.  As noted above, it also means
that the output file can be used as .an input file to the model
to reproduce a particular application.  However, for some
                              2-36

-------
applications, the length of the input runstream file may be too
cumbersome to include the entire set of inputs at the beginning
of each output file.  This may happen, for example, if a large
number of sources are being defined or if a large number of
discrete receptor locations are used.  For this reason, the
user is provided with the option to "turn off" the echoing of
the input file at any point within the runstream file.  This is
accomplished by entering the keywords "NO ECHO" in the first
two fields anywhere within the runstream file.  In other words,
place NO in the pathway field, followed by a space and then
ECHO.  None of the input runstream images after the NO ECHO
will be echoed to the output file.  Thus, a user may choose to
place NO ECHO after the control pathway in order to keep the
control options echoed, but suppress echoing the rest of the
input file.

     The details of the message summary tables were discussed
in the previous section.  An example of the summary of modeling
option inputs is shown in Figure 2-6 for the simple example
described in this section.  For the new model, the summary of
source parameter input data includes separate tables for each
source type, rather than combining all sources onto a single
table.  In this way the column headings are specific to the
source type, and avoid the confusion of the earlier model.

     Figure 2-7 presents an example of the results output for
the second highest values by receptor for our sample problem.
These values are the second highest 24-hour averages at each
receptor location.  Note that several of the numbers are
followed by a 'c.'  This flag indicates that the average
included at least one calm hour during the averaging period.
The number in parentheses following each concentration value is
the date corresponding to each value.  The date is given as an
eight digit integer variable that includes the year (2-digits),
month, day, and hour corresponding to the end of the averaging
period.  Since these are 24-hour averages and are based on
                              2-37

-------
block (end-to-end) rather than running averages, all of the
dates end on hour 24.

     For each of the different types of model result tables,
the controlling keyword is identified above at the end of the
description.  All of the outputs of the same type, e.g. high
values by receptor, are printed together, and the order of
tables loops through all source groups for a particular
averaging period, and then loops through all averaging periods.
The summary tables of high values at the end of the model
results follow the same order of loops.  An example of the
summary tables for our sample problem is shown in Figure 2-8.
The summaries for all averaging periods have been combined onto
a single figure, but would appear on separate pages of the
actual output file.
                              2-38

-------
_> u/
X. •* (3
822
« «
{ i
1
<\J
1—
Vt
u
(O
01
j:
4V
L.
O
M-
I
|
Q.
01
1
U,
01
1
M
<
II
*
*
*
nj
S
Si
8
Vt
Of
s

* ISCST2 -
*
*

D FAULT
u.
_J
<
Q£
=)
oe
u

S
C/J
3
en
g
h-
g.

* MODEL INC
*
*

MODEL SETUP OPTIONS SUMMARY «**
Centration Values.
* o
* i U
*
i 01
O)
i 10
1_
• 01
1 H-
o
1
• °

1 *-»
10
1 — *
3
i U
i tO
u
L.
i O
u.
1
, §•
4V
i 01
Vt
at
i —t
*
• «

persion
at
0
_l
<
s
Ctf
1
1
z
*
«

'i
o
4-*
&
iV •
— 1 0)
i-2
S«
O Of
>» s
f- — *
O 0.
4-»
a — *
3§
ro-
ll u.
ac
U> T-
1
1
z
*
*
outine.
ature Gradients.
at Buildings.
de
at i- 3 o
o> o-z
?• a. IA
to E i- — •
. ._ 4V S 01 10
• 01 09 C ft— O. t~
§C W 01 33
IP- 01 c — ' co at
•*" 4V O O ID
IA 3 O O.— I- t-
l- O t- X V O O
Vat a. uj c M- M-
0) Ol 10 0> 4V ») X
• •— C 4V — • O 0) 10
-c o — 10 M- a. 3 o
CO M O «4- — • 0)
to ^ &o o — * ID a
X 01 01 O) (. ID >
c o u c a. o _ —
O"Q c_ o)'D4rf^'^
aca.iACc-C4->
.». — •— 01 3 C
Q->- 09Z3> O Ol
•*- X {= GO C
f U — • 0) +•• 4J Q
i c «o to — • — • «- a.
^OJO3330»X
U X ID ID O.UJ
ID o o) 4J •*-•*- a.
4^3cflOOIO)OO
oca^zaa: z

rJM>4-m-Oh-eoo

c
a
t_
i_
0)
i—
i—
u.
§
(A
L.
o
s.
0)
u
01
ae
IA

at
(A
<
i