A Comprehensive Development Plan for a Multimodal Noise and Emissions Model (2010)

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

I-1 APPENDIX I. CURRENT AIR QUALITY, DISPERSION, AND NOISE MODELS This appendix describes noise and air quality current in use around the world. The models are grouped as follows: ● Air Quality Emissions and Dispersion Models (Sec. I.1); ● Noise Models (Sec. I.2); and ● Models that do Both Noise and Air Quality (Sec. I.3). Forty-seven (47) models are described (29 classified as air quality, 15 classified as noise, and 3 classified as both). Tables are used to organize the descriptions according to a model evaluation protocol with the following topics: 1. Overall model scope 2. Algorithms (scientific merit) 3. System architecture 4. Database 5. Usability 6. Documentation 7. Validation and confidence in use 8. Outputs 9. Policy or requirements

I-2 I.1. Air Quality Emissions and Dispersion Models Model: ACAM (Air Conformity Applicability Model) 1. Overall Model Scope a. In public domain? If not, who is caretaker? In public domain and maintained by the Air Force. b. Air quality or noise? a. Air quality: emissions or dispersion? Emissions b. Noise: SI, SPL, or other? c. Mode (highway, rail, water, air) Aviation – air and ground (vehicles) d. Screening or detailed (intended categorization)? Intended for detailed analysis, but some screening can be accomplished by the details inherent in the input data. e. Scales of analysis a. Air quality (e.g., microscale, regional, national, etc.) Microscale b. Noise (free field, long range propagation) f. Regulatory use (e.g., NEPA assessments, etc.)? All emissions evaluations at Air Force basis including those related to NEPA can be conducted using ACAM. 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.) ICAO reference method using “certified” emission factors for military aircraft. Simple correlations and emissions modeling based on emission factors and activity data. Simple comparisons to General Conformity de minimis threshold levels. b. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) Combination of simple and First order. b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with average information) c. Theoretically-based (e.g., vehicle-specific with individual characteristics and theoretical propagation implemented) 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.) Microsoft Access and flat ASCII files b. Operating system (e.g., MS-DOS, Windows, Linux, etc.) Windows c. Software language (e.g., Fortran, C#.NET, etc.) Visual Basic d. Software structure (e.g., single exe, modularized components, preprocessors, etc.) Single integrated exe e. Distributed computing? (yes or no) No f. Connectivity with other tools (e.g., AEDT-APMT linkage, etc.) No g. Hardware/additional software requirements None

I-3 Model: ACAM (Air Conformity Applicability Model) 4. Database a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) Military aircraft, GAVs, stationary sources b. What data is included? (e.g., NPD, EI, performance profiles, etc.) Military aircraft emission factors, MOBILE6 emission factors, stationary source emission factors c. Robustness of data (i.e., fidelity and resolution of data Fidelity and resolution of the internal data is generally fixed, but flexibility of input data allows different levels of fidelity d. Traceability (e.g., documented sources, acceptability, etc.) All data are well-documented. e. Publicly available All data are publicly available 5. Usability a. General data requirements (e.g., readily available, easily found, considerable effort required, etc.) Some work required, but data is generally available. b. Input flexibility (e.g., different resolution of data, user- defined sources, etc.) Some flexibility for aircraft operational and vehicle types (as well as for other sources) c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.) Relatively easy to understand. d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) Software is currently well developed and mature. 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) Complete b. Format (e.g., series of notes, hardcopies only, on-line, etc.) Electronic and on-line 7. Validation and confidence use Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results: a. Valid only in special cases b. Moderate Moderate to high for emissions. c. High 8. Outputs a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.) Emissions in mass per time (e.g., metric tons per year) b. If air quality, what pollutants are covered? CO, NOx, SO2, VOC, PM10, and PM2.5 c. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) 9. Policy or requirements a. Is this a preferred or required model? Generally considered required for Air Force bases, but can be substituted with EDMS as necessary. b. Input restrictions (i.e., parameter limits) Based each modules limit.

I-4 Model: ACAM (Air Conformity Applicability Model) c. Limitations on application (i.e., scenario limits) Only air force bases and below mixing height Model: ALAQS-AV (Airport Local Air Quality Studies, ArcView Based) 1. Overall Model Scope a. In public domain? If not, who is caretaker? No. Eurocontrol (ian.fuller@eurocontrol.int). b. Air quality or noise? a. Air quality: emissions or dispersion? Both emissions and dispersion in a tool set. b. Noise: SI, SPL, or other? c. Mode (highway, rail, water, air) Aircraft, airport sources, highway. d. Screening or detailed (intended categorization)? Detailed. e. Scales of analysis a. Air quality (e.g., microscale, regional, national, etc.) Microscale. b. Noise (free field, long range propagation) f. Regulatory use (e.g., NEPA assessments, etc.)? Primarily used in Europe and satisfies requirements of air quality regulations. Not known to be required for use by a governmental agency 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.) Use of program permits a 4-D emission inventory based on emission factors and time/location of use for equipment. Input by the use of temporal profiles allows emissions to be allocated by time. Use of aircraft vertical profiles, assignment of ground tracks, and GIS (ARCVIEW9.0) enhance the spatial delineation of the emissions. Model can use COPERT III for highway emission work (European specific). Dispersion can then be accomplished by using the Lagrangian model LASAT, the Gaussian model AERMOD, or a CFD model approach. b. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with average information) c. Theoretically-based (e.g., vehicle-specific with individual characteristics and theoretical propagation implemented) This model is most closely related to theoretical although dispersion is done by other models and simplifications do occur. 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.) Input is by entry to various screens. b. Operating system (e.g., MS-DOS, Windows, Linux, etc.) Runs in Windows. c. Software language (e.g., Fortran, C#.NET, etc.) Proprietary software. d. Software structure (e.g., single exe, modularized components, preprocessors, etc.) Use of modularized components permit emission inventories to be completed. The software then acts as a preprocessor for other dispersion models.

I-5 Model: ALAQS-AV (Airport Local Air Quality Studies, ArcView Based) e. Distributed computing? (yes or no) No. f. Connectivity with other tools (e.g., AEDT-APMT linkage, etc.) Can use input from INM for flight tracks. g. Hardware/additional software requirements Runs on PC. 4. Database a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) Small number of stationary sources, aircraft, APUs, GSEs, and motor vehicles. b. What data is included? (e.g., NPD, EI, performance profiles, etc.) EIs (made for European use) are available for all included sources. Flight profiles (SAE1845) included. c. Robustness of data (i.e., fidelity and resolution of data Robust. Data is very similar to that used in EDMS with the exception of the motor vehicles based on European vehicles. d. Traceability (e.g., documented sources, acceptability, etc.) Source EIs are fully documented as are flight profiles. e. Publicly available Must obtain from Eurocontrol. 5. Usability a. General data requirements (e.g., readily available, easily found, considerable effort required, etc.) For complete use, data requires considerable effort. b. Input flexibility (e.g., different resolution of data, user- defined sources, etc.) Rigid input but use of defaults is possible. c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.) Easy to understand. d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) Has been validated and changed so assumed to be implementation ready. 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) Unknown, not readily available. b. Format (e.g., series of notes, hardcopies only, on-line, etc.) Unknown, not readily available. 7. Validation and confidence use Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results: a. Valid only in special cases b. Moderate c. High High. Model has been validated and used successfully. 8. Outputs a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.) User defined metrics for both spatial and temporal input. Uses gridded emission inventory concept. b. If air quality, what pollutants are covered? CO, NOx, HC. c. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted)

I-6 Model: ALAQS-AV (Airport Local Air Quality Studies, ArcView Based) 9. Policy or requirements a. Is this a preferred or required model? Not required by regulation. b. Input restrictions (i.e., parameter limits) No. c. Limitations on application (i.e., scenario limits) Designed specifically for airports Model: ADMS – Airport (Atmospheric Dispersion Modeling System) 1. Overall Model Scope a. In public domain? If not, who is caretaker? In public domain for purchase. b. Air quality or noise? a. Air quality: emissions or dispersion? Dispersion. b. Noise: SI, SPL, or other? c. Mode (highway, rail, water, air) Aircraft, airport sources with rail capability. d. Screening or detailed (intended categorization)? Detailed. e. Scales of analysis a. Air quality (e.g., microscale, regional, national, etc.) Microscale. b. Noise (free field, long range propagation) f. Regulatory use (e.g., NEPA assessments, etc.)? Not required by regulations but provides output that satisfies European requirements. 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.) Gaussian dispersion nested in a trajectory model. b. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with average information) c. Theoretically-based (e.g., vehicle-specific with individual characteristics and theoretical propagation implemented) Theoretically based although some simplifications are made. 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.) Formation of input file required. b. Operating system (e.g., MS-DOS, Windows, Linux, etc.) Windows c. Software language (e.g., Fortran, C#.NET, etc.) Proprietary d. Software structure (e.g., single exe, modularized components, preprocessors, etc.) Single executable e. Distributed computing? (yes or no) No f. Connectivity with other tools (e.g., AEDT-APMT ArcGIS and EMIT emission model.

I-7 Model: ADMS – Airport (Atmospheric Dispersion Modeling System) linkage, etc.) g. Hardware/additional software requirements PC 4. Database a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) Handles multiple types of sources but does not include emission work. b. What data is included? (e.g., NPD, EI, performance profiles, etc.) User input. c. Robustness of data (i.e., fidelity and resolution of data N/A d. Traceability (e.g., documented sources, acceptability, etc.) N/A e. Publicly available Yes, purchase through CERC. 5. Usability a. General data requirements (e.g., readily available, easily found, considerable effort required, etc.) Considerable effort. b. Input flexibility (e.g., different resolution of data, user- defined sources, etc.) Fixed. c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.) Extensive but easy to understand. d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) High reliability. 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) Complete user guide with examples and help support. b. Format (e.g., series of notes, hardcopies only, on-line, etc.) Hardcopy. 7. Validation and confidence use Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results: a. Valid only in special cases b. Moderate c. High High, designed for use in the vicinity of airports. 8. Outputs a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.) User defined for both temporal and spatial. b. If air quality, what pollutants are covered? Designed for conservative pollutants although a chemistry algorithm for the NOx cycle is included. c. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) 9. Policy or requirements a. Is this a preferred or required model? Not required by regulations.

I-8 Model: ADMS – Airport (Atmospheric Dispersion Modeling System) b. Input restrictions (i.e., parameter limits) Physical limits on input. c. Limitations on application (i.e., scenario limits) Designed for use in the vicinity of airports. Model: LASAT (Lagrangian Simulation of Aerosol-Transport, Version 1.6) 1. Overall Model Scope a. In public domain? If not, who is caretaker? No. Unclear but Janicke Consulting has reported. b. Air quality or noise? a. Air quality: emissions or dispersion? Dispersion. Lagrangian particle model. b. Noise: SI, SPL, or other? c. Mode (highway, rail, water, air) Not source specific but used in the vicinity of airports for all airport sources. d. Screening or detailed (intended categorization)? Detailed. e. Scales of analysis a. Air quality (e.g., microscale, regional, national, etc.) Microscale. b. Noise (free field, long range propagation) f. Regulatory use (e.g., NEPA assessments, etc.)? Not required by regulations but complies with German Guideline VDI 3945 Part 3. 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.) Emission dispersion based on Lagrangian particle model. b. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with average information) c. Theoretically-based (e.g., vehicle-specific with individual characteristics and theoretical propagation implemented) Primarily theoretical based but uses random walk theory as approximation to turbulence. 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.) User created ASCII files. b. Operating system (e.g., MS-DOS, Windows, Linux, etc.) Windows. c. Software language (e.g., Fortran, C#.NET, etc.) Thought to be JAVA. d. Software structure (e.g., single exe, modularized components, preprocessors, etc.) Modularized components. e. Distributed computing? (yes or no) No. f. Connectivity with other tools (e.g., AEDT-APMT linkage, etc.) Used in ALAQS. g. Hardware/additional software requirements PC 4. Database

I-9 Model: LASAT (Lagrangian Simulation of Aerosol-Transport, Version 1.6) a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) None. b. What data is included? (e.g., NPD, EI, performance profiles, etc.) None. c. Robustness of data (i.e., fidelity and resolution of data N/A d. Traceability (e.g., documented sources, acceptability, etc.) N/A e. Publicly available No. 5. Usability a. General data requirements (e.g., readily available, easily found, considerable effort required, etc.) From Easily Found to Considerable Effort depending upon desired results. b. Input flexibility (e.g., different resolution of data, user- defined sources, etc.) User defined sources. c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.) Unknown, assumed easy to understand. d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) High. Based on proven methods and has been validated. 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) Unknown. b. Format (e.g., series of notes, hardcopies only, on-line, etc.) Unknown. 7. Validation and confidence use Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results: a. Valid only in special cases b. Moderate c. High High. Has been proven in direct use. 8. Outputs a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.) User defined. b. If air quality, what pollutants are covered? Conservative pollutants. c. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) 9. Policy or requirements a. Is this a preferred or required model? Not required but conforms to German Guideline VDI 3945 Part 3. b. Input restrictions (i.e., parameter limits) Physical limits. c. Limitations on application (i.e., scenario limits) Not limited for airport sources. Model: LASPORT (LASAT for Airport)

I-10 Model: LASPORT (LASAT for Airport) 1. Overall Model Scope a. In public domain? If not, who is caretaker? No. Janicke Consulting. b. Air quality or noise? a. Air quality: emissions or dispersion? Emission and dispersion model. Uses LASAT (Lagrangian Simulation of Aerosol Transport) for dispersion. b. Noise: SI, SPL, or other? c. Mode (highway, rail, water, air) Airport, airport sources, highway. d. Screening or detailed (intended categorization)? Detailed. e. Scales of analysis a. Air quality (e.g., microscale, regional, national, etc.) Microscale. b. Noise (free field, long range propagation) f. Regulatory use (e.g., NEPA assessments, etc.)? Not required by regulations. 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.) Emission modeling (with temporal/spatial allocation) and dispersion. b. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with average information) c. Theoretically-based (e.g., vehicle-specific with individual characteristics and theoretical propagation implemented) Theoretical based although some approximations occur. 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.) Creation of data ASCII input file. b. Operating system (e.g., MS-DOS, Windows, Linux, etc.) Windows. c. Software language (e.g., Fortran, C#.NET, etc.) JAVA and ANSI-C. d. Software structure (e.g., single exe, modularized components, preprocessors, etc.) Modularized components. e. Distributed computing? (yes or no) No. f. Connectivity with other tools (e.g., AEDT-APMT linkage, etc.) GIS files. g. Hardware/additional software requirements PC 4. Database a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) Aircraft, some stationary sources, GSE, APU, highways. b. What data is included? (e.g., NPD, EI, performance EIs are included and default performance profiles.

I-11 Model: LASPORT (LASAT for Airport) profiles, etc.) c. Robustness of data (i.e., fidelity and resolution of data High. Very similar to EDMS with European information. d. Traceability (e.g., documented sources, acceptability, etc.) Fully documented. e. Publicly available No. 5. Usability a. General data requirements (e.g., readily available, easily found, considerable effort required, etc.) Considerable effort although default values may be used. b. Input flexibility (e.g., different resolution of data, user- defined sources, etc.) Defined input format. c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.) Unknown, assumed easy to understand. d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) High, has undergone extensive evaluations. 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) Unknown. b. Format (e.g., series of notes, hardcopies only, on-line, etc.) Unknown. 7. Validation and confidence use Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results: a. Valid only in special cases b. Moderate c. High High, validation efforts have occurred. 8. Outputs a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.) User defined both spatially and temporally. b. If air quality, what pollutants are covered? CO, HC, NOx, PM. c. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) 9. Policy or requirements a. Is this a preferred or required model? Not required by regulations. b. Input restrictions (i.e., parameter limits) Physical limits applied c. Limitations on application (i.e., scenario limits) Designed for use in the vicinity of airports. Model: AUSTAL2000 (Version 2.4.4) 1. Overall Model Scope a. In public domain? If not, who is caretaker? Yes. Purchase through SELMAGIS for 3950 Euros. b. Air quality or noise?

I-12 Model: AUSTAL2000 (Version 2.4.4) a. Air quality: emissions or dispersion? Dispersion based on Lagrangian particle model. b. Noise: SI, SPL, or other? c. Mode (highway, rail, water, air) User defined sources. d. Screening or detailed (intended categorization)? Detailed e. Scales of analysis a. Air quality (e.g., microscale, regional, national, etc.) Micro to Mesoscale. b. Noise (free field, long range propagation) f. Regulatory use (e.g., NEPA assessments, etc.)? Official German Federal Environmental Agency Model. 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.) Emissions dispersion. b. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with average information) c. Theoretically-based (e.g., vehicle-specific with individual characteristics and theoretical propagation implemented) Theoretical based with some simplifications. 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.) User derived ASCII file. b. Operating system (e.g., MS-DOS, Windows, Linux, etc.) Windows. c. Software language (e.g., Fortran, C#.NET, etc.) Unknown but thought to be JAVA. d. Software structure (e.g., single exe, modularized components, preprocessors, etc.) Modularized components. e. Distributed computing? (yes or no) No for purchased version although unknown in German government offices. f. Connectivity with other tools (e.g., AEDT-APMT linkage, etc.) SELMA GIS, ARCGIS, ARCMAP and CADNA-A. g. Hardware/additional software requirements PC 4. Database a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) None. b. What data is included? (e.g., NPD, EI, performance profiles, etc.) None. c. Robustness of data (i.e., fidelity and resolution of data N/A d. Traceability (e.g., documented sources, acceptability, etc.) N/A

I-13 Model: AUSTAL2000 (Version 2.4.4) e. Publicly available Yes, for purchase. 5. Usability a. General data requirements (e.g., readily available, easily found, considerable effort required, etc.) Considerable effort but use of defaults could change to easily found. b. Input flexibility (e.g., different resolution of data, user- defined sources, etc.) Flexible. c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.) Unknown, but thought to be easy to understand. d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) High. Has been thoroughly tested. 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) Paper user guide and help services. b. Format (e.g., series of notes, hardcopies only, on-line, etc.) Hard copy with call in help 7. Validation and confidence use Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results: a. Valid only in special cases b. Moderate c. High High. Has been thoroughly tested. 8. Outputs a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.) User defined. b. If air quality, what pollutants are covered? Conservative pollutants. c. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) 9. Policy or requirements a. Is this a preferred or required model? Official German Federal Environmental Agency Model. b. Input restrictions (i.e., parameter limits) Physical limitations. c. Limitations on application (i.e., scenario limits) User defined for sources so limitations are only in input parameters. Model: CMAQ (Community Multi-scale Air Quality, Version 4.7) 1. Overall Model Scope a. In public domain? If not, who is caretaker? Yes. Download at CMAS. b. Air quality or noise? a. Air quality: emissions or dispersion? Eulerian dispersion, various scales with chemical kinetic modeling possible. b. Noise: SI, SPL, or other? c. Mode (highway, rail, water, air) Not for any one mode as it uses more of regional approach.

I-14 Model: CMAQ (Community Multi-scale Air Quality, Version 4.7) d. Screening or detailed (intended categorization)? Detailed. e. Scales of analysis a. Air quality (e.g., microscale, regional, national, etc.) Regional. b. Noise (free field, long range propagation) f. Regulatory use (e.g., NEPA assessments, etc.)? No required use. 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.) Emissions dispersion with heavy chemistry interactions possible. b. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with average information) c. Theoretically-based (e.g., vehicle-specific with individual characteristics and theoretical propagation implemented) Theoretically based with multiple approximations. 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.) ASCII files. b. Operating system (e.g., MS-DOS, Windows, Linux, etc.) Windows or LINUX. c. Software language (e.g., Fortran, C#.NET, etc.) Fortran. d. Software structure (e.g., single exe, modularized components, preprocessors, etc.) Modularized components with multiple preprocessors. e. Distributed computing? (yes or no) No. f. Connectivity with other tools (e.g., AEDT-APMT linkage, etc.) MM5 for meteorology. g. Hardware/additional software requirements PC and SUN systems. 4. Database a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) Not source specific, regional scale dispersion modeling with chemistry. b. What data is included? (e.g., NPD, EI, performance profiles, etc.) Chemical kinetic data. c. Robustness of data (i.e., fidelity and resolution of data N/A d. Traceability (e.g., documented sources, acceptability, etc.) N/A e. Publicly available Yes, free download. 5. Usability a. General data requirements (e.g., readily available, Considerable effort.

I-15 Model: CMAQ (Community Multi-scale Air Quality, Version 4.7) easily found, considerable effort required, etc.) b. Input flexibility (e.g., different resolution of data, user- defined sources, etc.) No. Rigid input. c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.) Steep learning curve. d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) High. Implementation ready with many validations. 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) User guide in downloadable zip file. Multiple other help files available on various topics. b. Format (e.g., series of notes, hardcopies only, on-line, etc.) Computer zipfile of hardcopy. 7. Validation and confidence use Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results: a. Valid only in special cases b. Moderate c. High High, many users and many validations. 8. Outputs a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.) User defined very flexible time scales. Spatially can be reduced to User defined km sized grids. b. If air quality, what pollutants are covered? Can handle most pollutants that remain airborne. c. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) 9. Policy or requirements a. Is this a preferred or required model? Not required by regulation but has been heavily used in regional modeling analyses. b. Input restrictions (i.e., parameter limits) Kilometer sized grids. Most pollutants. c. Limitations on application (i.e., scenario limits) Very flexible upward spatial changes and very flexible time scales. Large grids do not support receptor location input. Model: UAM V (Urban Airshed Model V) 1. Overall Model Scope a. In public domain? If not, who is caretaker? Yes. Downloadable from SAI. b. Air quality or noise? a. Air quality: emissions or dispersion? Regional Eulerian photochemical dispersion with chemistry modules. Work horse for ozone evaluations for a long time. b. Noise: SI, SPL, or other? c. Mode (highway, rail, water, air) Not mode specific since regional model.

I-16 Model: UAM V (Urban Airshed Model V) d. Screening or detailed (intended categorization)? Detailed. e. Scales of analysis a. Air quality (e.g., microscale, regional, national, etc.) Regional with km sized grids. b. Noise (free field, long range propagation) f. Regulatory use (e.g., NEPA assessments, etc.)? Was model of choice in the past by EPA for regional ozone analysis. 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.) Emission dispersion in regional grid boxes. b. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with average information) c. Theoretically-based (e.g., vehicle-specific with individual characteristics and theoretical propagation implemented) Theoretically based. 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.) ASCII input files. b. Operating system (e.g., MS-DOS, Windows, Linux, etc.) MS-DOS. c. Software language (e.g., Fortran, C#.NET, etc.) Fortran. d. Software structure (e.g., single exe, modularized components, preprocessors, etc.) Modularized components with multiple preprocessors. e. Distributed computing? (yes or no) Has been used in this way but not required. f. Connectivity with other tools (e.g., AEDT-APMT linkage, etc.) g. Hardware/additional software requirements PC (SUN and mainframe versions also). 4. Database a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) Not source dependent since regional model. b. What data is included? (e.g., NPD, EI, performance profiles, etc.) Kinetic chemistry relations. c. Robustness of data (i.e., fidelity and resolution of data N/A d. Traceability (e.g., documented sources, acceptability, etc.) N/A e. Publicly available Yes, downloadable from SAI. 5. Usability a. General data requirements (e.g., readily available, Considerable effort.

I-17 Model: UAM V (Urban Airshed Model V) easily found, considerable effort required, etc.) b. Input flexibility (e.g., different resolution of data, user- defined sources, etc.) Rigid input for reactive pollutants. c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.) Steep learning curve. d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) High. Multiple evaluations. 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) Downloadable pdf file user guide. Other help documents available on various topics. b. Format (e.g., series of notes, hardcopies only, on-line, etc.) Zip files of hard copy. 7. Validation and confidence use Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results: a. Valid only in special cases b. Moderate c. High High. Multiple validations have occurred. 8. Outputs a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.) User defined but has lower limitations on time and space. b. If air quality, what pollutants are covered? Inert and reactive pollutants primarily HC, NOx and Ozone. c. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) 9. Policy or requirements a. Is this a preferred or required model? Was preferred by EPA in the past. b. Input restrictions (i.e., parameter limits) Kilometer sized grids and longer reaction times. c. Limitations on application (i.e., scenario limits) Primarily used for regional ozone analysis. Large grids do not permit receptor location approximations. Model: CAMx (Comprehensive Air quality Model with eXtensions, Version 4.5) 1. Overall Model Scope a. In public domain? If not, who is caretaker? Yes. Download from Environ. b. Air quality or noise? a. Air quality: emissions or dispersion? Photochemical Eulerian dispersion model. b. Noise: SI, SPL, or other? c. Mode (highway, rail, water, air) Photochemical Eulerian dispersion model. d. Screening or detailed (intended categorization)? Detailed, although CAMx Screen is also available. e. Scales of analysis

I-18 Model: CAMx (Comprehensive Air quality Model with eXtensions, Version 4.5) a. Air quality (e.g., microscale, regional, national, etc.) Regional. b. Noise (free field, long range propagation) f. Regulatory use (e.g., NEPA assessments, etc.)? Not required by regulations. 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.) Emission dispersion in grid cells. Chemical reactions considered. b. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with average information) c. Theoretically-based (e.g., vehicle-specific with individual characteristics and theoretical propagation implemented) Theoretically based with multiple approximations. 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.) User defined ASCII files and input binary files. b. Operating system (e.g., MS-DOS, Windows, Linux, etc.) Windows. c. Software language (e.g., Fortran, C#.NET, etc.) Fortran. d. Software structure (e.g., single exe, modularized components, preprocessors, etc.) Modularized components with pre and post processors available. e. Distributed computing? (yes or no) Yes, can be used in this fashion. f. Connectivity with other tools (e.g., AEDT-APMT linkage, etc.) PAVE, Surfer, Vis5D, and Grads. g. Hardware/additional software requirements PC 4. Database a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) Not source specific due to regional nature. b. What data is included? (e.g., NPD, EI, performance profiles, etc.) Chemical kinetics. c. Robustness of data (i.e., fidelity and resolution of data N/A d. Traceability (e.g., documented sources, acceptability, etc.) N/A e. Publicly available Yes, from Environ. 5. Usability a. General data requirements (e.g., readily available, easily found, considerable effort required, etc.) Considerable effort required. b. Input flexibility (e.g., different resolution of data, user- Rigid input but for both reactive air pollutants (including toxics) and particulate

I-19 Model: CAMx (Comprehensive Air quality Model with eXtensions, Version 4.5) defined sources, etc.) matter. c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.) Steep learning curve. d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) Very good. More validation may be needed. 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) User guide in PDF format. b. Format (e.g., series of notes, hardcopies only, on-line, etc.) PDF format of hard copy. 7. Validation and confidence use Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results: a. Valid only in special cases b. Moderate Moderate, may need more validation. c. High 8. Outputs a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.) User defined but 1 hour minimum and large km sized girds. b. If air quality, what pollutants are covered? Inert and reactive air pollutants and particulate matter. c. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) 9. Policy or requirements a. Is this a preferred or required model? No. b. Input restrictions (i.e., parameter limits) Large grids and at least one hour. Regional. c. Limitations on application (i.e., scenario limits) Large grids do not permit receptor location input. Model: REMSAD (REgional Modeling System for Aerosols and Deposition, Version 8) 1. Overall Model Scope a. In public domain? If not, who is caretaker? Yes. Download from SAI. b. Air quality or noise? a. Air quality: emissions or dispersion? Eulerian Dispersion. b. Noise: SI, SPL, or other? c. Mode (highway, rail, water, air) Not mode specific as it is a macroscale model. d. Screening or detailed (intended categorization)? Originally intended as screening model but has evolved into a “one atmosphere” model. e. Scales of analysis a. Air quality (e.g., microscale, regional, national, Regional to macroscale (national).

I-20 Model: REMSAD (REgional Modeling System for Aerosols and Deposition, Version 8) etc.) b. Noise (free field, long range propagation) f. Regulatory use (e.g., NEPA assessments, etc.)? Not required by regulation. 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.) Emission dispersion in km size gridded cells. b. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) Has evolved to theoretically based, but has major simplifications, especially simplified ozone chemistry. b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with average information) c. Theoretically-based (e.g., vehicle-specific with individual characteristics and theoretical propagation implemented) 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.) User defined ASCII files. b. Operating system (e.g., MS-DOS, Windows, Linux, etc.) Windows c. Software language (e.g., Fortran, C#.NET, etc.) Fortran d. Software structure (e.g., single exe, modularized components, preprocessors, etc.) Modularized components. e. Distributed computing? (yes or no) No f. Connectivity with other tools (e.g., AEDT-APMT linkage, etc.) No g. Hardware/additional software requirements PC 4. Database a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) None b. What data is included? (e.g., NPD, EI, performance profiles, etc.) Chemical kinetic information. c. Robustness of data (i.e., fidelity and resolution of data N/A d. Traceability (e.g., documented sources, acceptability, etc.) N/A e. Publicly available Yes, download from SAI. 5. Usability a. General data requirements (e.g., readily available, easily found, considerable effort required, etc.) Considerable effort. b. Input flexibility (e.g., different resolution of data, user- Fixed input but can be used for different reactive species.

I-21 Model: REMSAD (REgional Modeling System for Aerosols and Deposition, Version 8) defined sources, etc.) c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.) Steep learning curve. d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) Good. More validation may be needed. 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) Downloadable user manual. b. Format (e.g., series of notes, hardcopies only, on-line, etc.) Computer file of hard copy. 7. Validation and confidence use Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results: a. Valid only in special cases b. Moderate Moderate. More validation may be needed. c. High 8. Outputs a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.) Large time scales and spatial grids. b. If air quality, what pollutants are covered? Spatial and temporal distribution of toxic and particulate emissions including sulfur dioxide (SO2), oxides of nitrogen (NOx), volatile organic compounds (VOC), and ammonia (NH3) (both anthropogenic and non-anthropogenic). c. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) 9. Policy or requirements a. Is this a preferred or required model? No b. Input restrictions (i.e., parameter limits) Not for all gases but does do both wet and dry particulate matter deposition. c. Limitations on application (i.e., scenario limits) Very large areas so receptor location estimation not possible. A typical advective time step for coarse (50–80 km) grid spacing is 10–15 minutes, whereas time steps for fine grid spacing (10–30 km) are on the order of a few minutes. Model: URBEMIS (URBan EMISsions, Version 9.2.4) 1. Overall Model Scope a. In public domain? If not, who is caretaker? Yes. Downloadable from urbemis. b. Air quality or noise? a. Air quality: emissions or dispersion? Emission model for land use development projects. b. Noise: SI, SPL, or other? c. Mode (highway, rail, water, air) Highway, off-road, and land uses including construction.

I-22 Model: URBEMIS (URBan EMISsions, Version 9.2.4) d. Screening or detailed (intended categorization)? More screening than detailed. e. Scales of analysis a. Air quality (e.g., microscale, regional, national, etc.) Regional emissions. b. Noise (free field, long range propagation) f. Regulatory use (e.g., NEPA assessments, etc.)? No, although could be preferred in California. 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.) Emission estimation with built in trip generation rates and emission factors for various land use activities. b. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with average information) First order approximation techniques used in model. c. Theoretically-based (e.g., vehicle-specific with individual characteristics and theoretical propagation implemented) 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.) Input to spreadsheet type environment. b. Operating system (e.g., MS-DOS, Windows, Linux, etc.) Windows with Microsoft.Net. c. Software language (e.g., Fortran, C#.NET, etc.) Visual Basic running in Microsoft.Net. d. Software structure (e.g., single exe, modularized components, preprocessors, etc.) Single but now has add-ins as dlls. e. Distributed computing? (yes or no) Yes f. Connectivity with other tools (e.g., AEDT-APMT linkage, etc.) EMFAC2007 and OFFROAD2007. g. Hardware/additional software requirements PC 4. Database a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) Highway, off-road, and land uses including construction. b. What data is included? (e.g., NPD, EI, performance profiles, etc.) EFs for land use and trip generation rates. c. Robustness of data (i.e., fidelity and resolution of data Good d. Traceability (e.g., documented sources, acceptability, etc.) Good e. Publicly available Yes, download from urbemiss. 5. Usability a. General data requirements (e.g., readily available, Easily found.

I-23 Model: URBEMIS (URBan EMISsions, Version 9.2.4) easily found, considerable effort required, etc.) b. Input flexibility (e.g., different resolution of data, user- defined sources, etc.) User must define scenario so flexibility is limited. c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.) Easy to understand. d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) Bugs have been reported so some issues probably still remain. 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) User guide (downloadable) and training videos available. b. Format (e.g., series of notes, hardcopies only, on-line, etc.) Downloadable hard copies and training videos. 7. Validation and confidence use Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results: a. Valid only in special cases b. Moderate Moderate, only because of scenario limitations and reported bugs c. High 8. Outputs a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.) Emissions in California air basins and daily estimates. b. If air quality, what pollutants are covered? Reactive organic gases, NOx, CO, SO2, and PM10. c. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) 9. Policy or requirements a. Is this a preferred or required model? No. But could be a requirement for California analysis. b. Input restrictions (i.e., parameter limits) Only for air basins in California and daily changes. c. Limitations on application (i.e., scenario limits) Made for use only in California and limited land use selections do not include airports. Model: TEXIN2-5 (TEXas Intersection, Version 2 with Mobile 5) 1. Overall Model Scope a. In public domain? If not, who is caretaker? Yes. But out of date so no one source. b. Air quality or noise? a. Air quality: emissions or dispersion? Dispersion model meant for CO. b. Noise: SI, SPL, or other? c. Mode (highway, rail, water, air) Highway intersections. d. Screening or detailed (intended categorization)? Detailed. e. Scales of analysis

I-24 Model: TEXIN2-5 (TEXas Intersection, Version 2 with Mobile 5) a. Air quality (e.g., microscale, regional, national, etc.) Microscale. b. Noise (free field, long range propagation) f. Regulatory use (e.g., NEPA assessments, etc.)? No 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.) Dispersion based on Gaussian model. Also includes algorithms for traffic performance. b. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with average information) c. Theoretically-based (e.g., vehicle-specific with individual characteristics and theoretical propagation implemented) Theoretically based (both dispersion and traffic). 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.) Development of ASCII files by user. b. Operating system (e.g., MS-DOS, Windows, Linux, etc.) MS-DOS. c. Software language (e.g., Fortran, C#.NET, etc.) Fortran. d. Software structure (e.g., single exe, modularized components, preprocessors, etc.) Single executable. e. Distributed computing? (yes or no) No f. Connectivity with other tools (e.g., AEDT-APMT linkage, etc.) No, but MOBILE5 built in. g. Hardware/additional software requirements PC 4. Database a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) Motor vehicles. b. What data is included? (e.g., NPD, EI, performance profiles, etc.) EIs and traffic parameters. c. Robustness of data (i.e., fidelity and resolution of data Very good, but older. d. Traceability (e.g., documented sources, acceptability, etc.) Good e. Publicly available Yes, but old and no longer from any one source. 5. Usability a. General data requirements (e.g., readily available, easily found, considerable effort required, etc.) Easily found. b. Input flexibility (e.g., different resolution of data, user- Limited to intersections.

I-25 Model: TEXIN2-5 (TEXas Intersection, Version 2 with Mobile 5) defined sources, etc.) c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.) Easy to understand. d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) Fair 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) User guide and technical manual in hard copy. b. Format (e.g., series of notes, hardcopies only, on-line, etc.) Hard copy. 7. Validation and confidence use Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results: a. Valid only in special cases b. Moderate Moderate since more validation needed. Also has become dated. c. High 8. Outputs a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.) Only for intersections and one hour averages. b. If air quality, what pollutants are covered? Conservative pollutants, designed for CO. c. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) 9. Policy or requirements a. Is this a preferred or required model? No b. Input restrictions (i.e., parameter limits) Only for intersections and one hour averages. c. Limitations on application (i.e., scenario limits) Intersection use only.

I-26 Model: ROADWAY 1. Overall Model Scope a. In public domain? If not, who is caretaker? Yes, but very old and no known source. Originally developed by GM. b. Air quality or noise? a. Air quality: emissions or dispersion? Gaussian dispersion (line source). b. Noise: SI, SPL, or other? c. Mode (highway, rail, water, air) Highway free flow. d. Screening or detailed (intended categorization)? Screening for most cases. e. Scales of analysis a. Air quality (e.g., microscale, regional, national, etc.) Microscale. b. Noise (free field, long range propagation) f. Regulatory use (e.g., NEPA assessments, etc.)? No. Very old (early 1970s). 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.) Gaussian dispersion, adapted as a line source. b. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) Simple b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with average information) c. Theoretically-based (e.g., vehicle-specific with individual characteristics and theoretical propagation implemented) 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.) ASCII b. Operating system (e.g., MS-DOS, Windows, Linux, etc.) MS-DOS c. Software language (e.g., Fortran, C#.NET, etc.) Fortran d. Software structure (e.g., single exe, modularized components, preprocessors, etc.) Single executable e. Distributed computing? (yes or no) No f. Connectivity with other tools (e.g., AEDT-APMT linkage, etc.) No g. Hardware/additional software requirements PC 4. Database a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) None. Dispersion model only. However, interesting that plume rise from motor vehicles is included since it has been neglected in other models. b. What data is included? (e.g., NPD, EI, performance None

I-27 Model: ROADWAY profiles, etc.) c. Robustness of data (i.e., fidelity and resolution of data N/A d. Traceability (e.g., documented sources, acceptability, etc.) N/A e. Publicly available Yes, but very old and no single source. 5. Usability a. General data requirements (e.g., readily available, easily found, considerable effort required, etc.) Readily available. b. Input flexibility (e.g., different resolution of data, user- defined sources, etc.) Little flexibility. c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.) Easy to understand. d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) Implementation ready, no bugs. 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) User pamphlet. b. Format (e.g., series of notes, hardcopies only, on-line, etc.) Hard copy 7. Validation and confidence use Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results: a. Valid only in special cases Only for free flow line source such as highway traffic. b. Moderate c. High 8. Outputs a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.) Receptor located by user with restrictions. Generally one hour averages. b. If air quality, what pollutants are covered? Conservative pollutants, used primarily for CO. c. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) 9. Policy or requirements a. Is this a preferred or required model? No b. Input restrictions (i.e., parameter limits) Receptor locations limited and need to generally be at 45 degree angle or greater to wind direction/highway direction. c. Limitations on application (i.e., scenario limits) Line source such as highway only.

I-28 Model: HIWAY 1. Overall Model Scope a. In public domain? If not, who is caretaker? Yes, but very old was part of EPA UNAMAP series of models. b. Air quality or noise? a. Air quality: emissions or dispersion? Gaussian dispersion (line source). b. Noise: SI, SPL, or other? c. Mode (highway, rail, water, air) Highway free flow. d. Screening or detailed (intended categorization)? Screening for most cases. e. Scales of analysis a. Air quality (e.g., microscale, regional, national, etc.) Microscale. b. Noise (free field, long range propagation) f. Regulatory use (e.g., NEPA assessments, etc.)? No. Very old (early 1970s). 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.) Gaussian dispersion, adapted as a line source. b. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) Simple b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with average information) c. Theoretically-based (e.g., vehicle-specific with individual characteristics and theoretical propagation implemented) 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.) ASCII b. Operating system (e.g., MS-DOS, Windows, Linux, etc.) MS-DOS c. Software language (e.g., Fortran, C#.NET, etc.) Fortran d. Software structure (e.g., single exe, modularized components, preprocessors, etc.) Single executable e. Distributed computing? (yes or no) No f. Connectivity with other tools (e.g., AEDT-APMT linkage, etc.) No g. Hardware/additional software requirements Originally for mainframe but can port to PC. 4. Database a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) None. Dispersion model only. b. What data is included? (e.g., NPD, EI, performance None

I-29 Model: HIWAY profiles, etc.) c. Robustness of data (i.e., fidelity and resolution of data N/A d. Traceability (e.g., documented sources, acceptability, etc.) N/A e. Publicly available Yes, but very old and no single source. Can get old mainframe computer tapes of UNAMAP series. 5. Usability a. General data requirements (e.g., readily available, easily found, considerable effort required, etc.) Readily available. b. Input flexibility (e.g., different resolution of data, user- defined sources, etc.) Little flexibility. c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.) Easy to understand. d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) Implementation ready, no bugs. 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) User pamphlet. b. Format (e.g., series of notes, hardcopies only, on-line, etc.) Hard copy. 7. Validation and confidence use Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results: a. Valid only in special cases Only for free flow line source such as highway traffic. b. Moderate c. High 8. Outputs a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.) Receptor located by user with restrictions. Generally one hour averages. b. If air quality, what pollutants are covered? Conservative pollutants, used primarily for CO. c. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) 9. Policy or requirements a. Is this a preferred or required model? No b. Input restrictions (i.e., parameter limits) Receptor locations limited and need to generally be at 45 degree angle or greater to wind direction/highway direction. c. Limitations on application (i.e., scenario limits) Line sources such as highway only.

I-30 Model: CTDMPLUS (Complex Terrain Dispersion Model PLUS Algorithms for Unstable Situations) 1. Overall Model Scope a. In public domain? If not, who is caretaker? Yes, EPA download. b. Air quality or noise? a. Air quality: emissions or dispersion? Gaussian dispersion in complex terrain. Intended for point sources. b. Noise: SI, SPL, or other? c. Mode (highway, rail, water, air) Non-modal, dispersion only. d. Screening or detailed (intended categorization)? Detailed. e. Scales of analysis a. Air quality (e.g., microscale, regional, national, etc.) Microscale b. Noise (free field, long range propagation) f. Regulatory use (e.g., NEPA assessments, etc.)? An EPA preferred model in assessments such as NEPA. 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.) Gaussian point source dispersion with algorithms for complex terrain and unstable conditions. A skewed bi-Gaussian distribution used in unstable cases. b. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with average information) c. Theoretically-based (e.g., vehicle-specific with individual characteristics and theoretical propagation implemented) Theoretically-based with simplifications. 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.) ASCII files defined by user. b. Operating system (e.g., MS-DOS, Windows, Linux, etc.) MS-DOS although was run on mainframe as well. c. Software language (e.g., Fortran, C#.NET, etc.) Fortran d. Software structure (e.g., single exe, modularized components, preprocessors, etc.) Modularized components with preprocessors. Terrain data preparation processor used to format raw terrain data. e. Distributed computing? (yes or no) No f. Connectivity with other tools (e.g., AEDT-APMT linkage, etc.) Preprocessors g. Hardware/additional software requirements PC (mainframe in past). 4. Database a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) None. Dispersion only. b. What data is included? (e.g., NPD, EI, performance None other than dispersion algorithms.

I-31 Model: CTDMPLUS (Complex Terrain Dispersion Model PLUS Algorithms for Unstable Situations) profiles, etc.) c. Robustness of data (i.e., fidelity and resolution of data N/A d. Traceability (e.g., documented sources, acceptability, etc.) N/A e. Publicly available Yes, EPA download. 5. Usability a. General data requirements (e.g., readily available, easily found, considerable effort required, etc.) If defined source, readily available. b. Input flexibility (e.g., different resolution of data, user- defined sources, etc.) Rigid format but flexible for terrain, weather and source emission rate. c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.) Steep learning curve. d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) Very good. Often used so validated. 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) Downloadable PDF user manual for main kernel program, meteorological preprocessor and terrain preprocessor. b. Format (e.g., series of notes, hardcopies only, on-line, etc.) PDF of hard copy. 7. Validation and confidence use Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results: a. Valid only in special cases b. Moderate c. High High. Often used. 8. Outputs a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.) User defined receptor locations and time periods. One hour or more most often used. b. If air quality, what pollutants are covered? Conservative pollutants. c. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) 9. Policy or requirements a. Is this a preferred or required model? This is a preferred model for complex terrain by EPA. Preferred EPA model. b. Input restrictions (i.e., parameter limits) Physical limits on input. c. Limitations on application (i.e., scenario limits) Designed for point source with limits flexibility for other uses. Model: NONROAD2005 1. Overall Model Scope a. In public domain? If not, who is caretaker? Yes. EPA download.

I-32 Model: NONROAD2005 b. Air quality or noise? a. Air quality: emissions or dispersion? Emission inventory model for a large array of off road sources including diesel engines and airport/aircraft sources. b. Noise: SI, SPL, or other? c. Mode (highway, rail, water, air) Off-road sources, large database. d. Screening or detailed (intended categorization)? Detailed. e. Scales of analysis a. Air quality (e.g., microscale, regional, national, etc.) Best used on regional basis, but use on microscale basis possible. b. Noise (free field, long range propagation) f. Regulatory use (e.g., NEPA assessments, etc.)? Recommended model due to regulations involving portions of data base. 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.) Base emission factor with corrections for multiple parameters for a large number of off road equipment. b. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with average information) Actually more than first order approximation but has many simplifications. c. Theoretically-based (e.g., vehicle-specific with individual characteristics and theoretical propagation implemented) 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.) ASCII files built but GUI has been designed for system. b. Operating system (e.g., MS-DOS, Windows, Linux, etc.) MS-DOS. c. Software language (e.g., Fortran, C#.NET, etc.) Fortran. d. Software structure (e.g., single exe, modularized components, preprocessors, etc.) Single executable. e. Distributed computing? (yes or no) No f. Connectivity with other tools (e.g., AEDT-APMT linkage, etc.) No g. Hardware/additional software requirements PC 4. Database a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) A very large number of off road sources including diesel and aircraft. Sources are broken down into multiple components for breakout. b. What data is included? (e.g., NPD, EI, performance profiles, etc.) Emission factors and estimation processes. c. Robustness of data (i.e., fidelity and resolution of data Very good, multiple validations.

I-33 Model: NONROAD2005 d. Traceability (e.g., documented sources, acceptability, etc.) Very good documentation. e. Publicly available Yes, downloadable from EPA. 5. Usability a. General data requirements (e.g., readily available, easily found, considerable effort required, etc.) Considerable effort, sources must be quantified and characterized. b. Input flexibility (e.g., different resolution of data, user- defined sources, etc.) Flexibility in selection of off road service but limited flexibility for other parameters. c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.) Steep learning curve but not extremely difficult. d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) Multiple iterations and changes have resulted in excellent reliability. 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) Complete. Strong user guide and multiple technical references. b. Format (e.g., series of notes, hardcopies only, on-line, etc.) Downloadable PDF files. 7. Validation and confidence use Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results: a. Valid only in special cases b. Moderate c. High Strong validation. 8. Outputs a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.) Best for long time periods such as year. Not spatially oriented. b. If air quality, what pollutants are covered? HC (including evaporative) , CO, NOx , PM, SO2, CO2 c. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) 9. Policy or requirements a. Is this a preferred or required model? This model is recommended and has been used for conformity and SIP preparation. b. Input restrictions (i.e., parameter limits) Limits on input relating to sources and time periods. c. Limitations on application (i.e., scenario limits) Designed for longer term applications such as yearly. Model: OFFROAD2007 1. Overall Model Scope a. In public domain? If not, who is caretaker? Yes, through CARB b. Air quality or noise? a. Air quality: emissions or dispersion? Emission model for off road sources of 94 equipment types including GSEs.

I-34 Model: OFFROAD2007 b. Noise: SI, SPL, or other? c. Mode (highway, rail, water, air) Multiple off road sources. d. Screening or detailed (intended categorization)? Detailed. e. Scales of analysis a. Air quality (e.g., microscale, regional, national, etc.) Emission model best for regional. b. Noise (free field, long range propagation) f. Regulatory use (e.g., NEPA assessments, etc.)? Preferred in California. 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.) Emission estimation process with emission factors. b. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with average information) Actually more that first order approximation but called first order since many simplifications required. c. Theoretically-based (e.g., vehicle-specific with individual characteristics and theoretical propagation implemented) 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.) Building of input files but has GUI. b. Operating system (e.g., MS-DOS, Windows, Linux, etc.) Windows with Microsoft .NET Framework 2.0. c. Software language (e.g., Fortran, C#.NET, etc.) d. Software structure (e.g., single exe, modularized components, preprocessors, etc.) Three main modules: population, activity, and emissions factor. e. Distributed computing? (yes or no) Yes f. Connectivity with other tools (e.g., AEDT-APMT linkage, etc.) No g. Hardware/additional software requirements PC 4. Database a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) 94 off road sources including GSE for airport operations. b. What data is included? (e.g., NPD, EI, performance profiles, etc.) Emission factors, numbers of equipment, adjustments to base emission factor. c. Robustness of data (i.e., fidelity and resolution of data Very good. Well tested. d. Traceability (e.g., documented sources, acceptability, etc.) Very good e. Publicly available Yes, Through CARB

I-35 Model: OFFROAD2007 5. Usability a. General data requirements (e.g., readily available, easily found, considerable effort required, etc.) Considerable effort in quantification and typing of sources needed. b. Input flexibility (e.g., different resolution of data, user- defined sources, etc.) Flexible but has very defined source mechanisms. c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.) Steep learning curve but not difficult. d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) Very good. Well tested. 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) User brochure with additional helps. b. Format (e.g., series of notes, hardcopies only, on-line, etc.) Downloadable files in Word format. 7. Validation and confidence use Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results: a. Valid only in special cases b. Moderate c. High Considerable use. 8. Outputs a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.) Not spatially oriented best for longer time periods typical of emission inventories. b. If air quality, what pollutants are covered? TOG,CO, NOx PM, CO2, SO2, N2O, CH4 c. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) 9. Policy or requirements a. Is this a preferred or required model? Recommended in California. b. Input restrictions (i.e., parameter limits) Temporarily for longer periods. c. Limitations on application (i.e., scenario limits) Defined source categories sometimes hard to apply. Model: CALINE3 1. Overall Model Scope a. In public domain? If not, who is caretaker? In public domain. Developed by CALTRANS and maintained/promulgated by EPA. b. Air quality or noise? a. Air quality: emissions or dispersion? Dispersion b. Noise: SI, SPL, or other? c. Mode (highway, rail, water, air) Highway d. Screening or detailed (intended categorization)? Detailed

I-36 Model: CALINE3 e. Scales of analysis a. Air quality (e.g., microscale, regional, national, etc.) Microscale b. Noise (free field, long range propagation) f. Regulatory use (e.g., NEPA assessments, etc.)? Yes, used for regulatory studies 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.) Gaussian dispersion from finite length links b. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with average information) Between first order and theoretical c. Theoretically-based (e.g., vehicle-specific with individual characteristics and theoretical propagation implemented) 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.) Flat ASCII files b. Operating system (e.g., MS-DOS, Windows, Linux, etc.) MS-DOS c. Software language (e.g., Fortran, C#.NET, etc.) Fortran d. Software structure (e.g., single exe, modularized components, preprocessors, etc.) Single executable e. Distributed computing? (yes or no) No f. Connectivity with other tools (e.g., AEDT-APMT linkage, etc.) No, but intended to use the direct outputs from models like MOBILE6.2 g. Hardware/additional software requirements None 4. Database a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) Vehicular sources only b. What data is included? (e.g., NPD, EI, performance profiles, etc.) No data c. Robustness of data (i.e., fidelity and resolution of data Emission factors, speed, etc, can be general or specific d. Traceability (e.g., documented sources, acceptability, etc.) N/A since all data are inputs e. Publicly available N/A since all data are inputs 5. Usability a. General data requirements (e.g., readily available, easily found, considerable effort required, etc.) Readily available

I-37 Model: CALINE3 b. Input flexibility (e.g., different resolution of data, user- defined sources, etc.) Rigid data format, but resolution of data is flexible c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.) Relatively cryptic keys and switches in text file d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) Well tested and free of bugs 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) Complete b. Format (e.g., series of notes, hardcopies only, on-line, etc.) Electronic and on-line 7. Validation and confidence use Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results: a. Valid only in special cases b. Moderate c. High High confidence based on volume of validation work 8. Outputs a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.) ppm b. If air quality, what pollutants are covered? Generally only stable compounds like CO, but depends on what the user is willing to accept. c. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) 9. Policy or requirements a. Is this a preferred or required model? This is a required model b. Input restrictions (i.e., parameter limits) None except based on scope of model c. Limitations on application (i.e., scenario limits) Only for microscale applications Model: CALINE4 1. Overall Model Scope a. In public domain? If not, who is caretaker? In public domain. Developed by CALTRANS and maintained/promulgated by EPA. b. Air quality or noise? a. Air quality: emissions or dispersion? Dispersion b. Noise: SI, SPL, or other? c. Mode (highway, rail, water, air) Highway d. Screening or detailed (intended categorization)? Detailed e. Scales of analysis a. Air quality (e.g., microscale, regional, national, Microscale

I-38 Model: CALINE4 etc.) b. Noise (free field, long range propagation) f. Regulatory use (e.g., NEPA assessments, etc.)? Yes, used for regulatory studies generally in California only 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.) Gaussian dispersion from finite length links and modal emissions b. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with average information) Between first order and theoretical c. Theoretically-based (e.g., vehicle-specific with individual characteristics and theoretical propagation implemented) 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.) Flat ASCII files b. Operating system (e.g., MS-DOS, Windows, Linux, etc.) Windows c. Software language (e.g., Fortran, C#.NET, etc.) Visual Basic d. Software structure (e.g., single exe, modularized components, preprocessors, etc.) Single executable e. Distributed computing? (yes or no) No f. Connectivity with other tools (e.g., AEDT-APMT linkage, etc.) No, but intended to use the direct outputs from models like EMFAC2007 and MOBILE6.2 g. Hardware/additional software requirements None 4. Database a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) Vehicular sources only b. What data is included? (e.g., NPD, EI, performance profiles, etc.) No data c. Robustness of data (i.e., fidelity and resolution of data Emission factors, speed, etc, can be general or specific d. Traceability (e.g., documented sources, acceptability, etc.) N/A since all data are inputs e. Publicly available N/A since all data are inputs 5. Usability a. General data requirements (e.g., readily available, easily found, considerable effort required, etc.) Readily available b. Input flexibility (e.g., different resolution of data, user- defined sources, etc.) Rigid data format, but resolution of data is flexible

I-39 Model: CALINE4 c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.) Relatively cryptic keys and switches in text file d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) Well tested and free of bugs 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) Complete b. Format (e.g., series of notes, hardcopies only, on-line, etc.) Electronic and on-line 7. Validation and confidence use Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results: a. Valid only in special cases b. Moderate c. High High confidence based on volume of validation work 8. Outputs a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.) ppm b. If air quality, what pollutants are covered? Generally only stable compounds like CO, but depends on what the user is willing to accept. c. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) 9. Policy or requirements a. Is this a preferred or required model? This is a required model for California b. Input restrictions (i.e., parameter limits) None except based on scope of model c. Limitations on application (i.e., scenario limits) Only for microscale applications Model: CAL3QHC (CALINE3 with Queuing and Hot spot Calculations) 1. Overall Model Scope a. In public domain? If not, who is caretaker? In public domain. Maintained by EPA b. Air quality or noise? a. Air quality: emissions or dispersion? Dispersion b. Noise: SI, SPL, or other? c. Mode (highway, rail, water, air) Highway d. Screening or detailed (intended categorization)? Detailed e. Scales of analysis a. Air quality (e.g., microscale, regional, national, etc.) Microscale b. Noise (free field, long range propagation) f. Regulatory use (e.g., NEPA assessments, etc.)? Yes, used for regulatory studies

I-40 Model: CAL3QHC (CALINE3 with Queuing and Hot spot Calculations) 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.) Gaussian dispersion from finite length links and queuing theory b. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with average information) Between first order and theoretical c. Theoretically-based (e.g., vehicle-specific with individual characteristics and theoretical propagation implemented) 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.) Flat ASCII files b. Operating system (e.g., MS-DOS, Windows, Linux, etc.) MS-DOS c. Software language (e.g., Fortran, C#.NET, etc.) Fortran d. Software structure (e.g., single exe, modularized components, preprocessors, etc.) Single executable e. Distributed computing? (yes or no) No f. Connectivity with other tools (e.g., AEDT-APMT linkage, etc.) No, but intended to use the direct outputs from models like MOBILE6.2 g. Hardware/additional software requirements None 4. Database a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) Vehicular sources only b. What data is included? (e.g., NPD, EI, performance profiles, etc.) No data c. Robustness of data (i.e., fidelity and resolution of data Emission factors, speed, etc, can be general or specific d. Traceability (e.g., documented sources, acceptability, etc.) N/A since all data are inputs e. Publicly available N/A since all data are inputs 5. Usability a. General data requirements (e.g., readily available, easily found, considerable effort required, etc.) Readily available b. Input flexibility (e.g., different resolution of data, user- defined sources, etc.) Rigid data format, but resolution of data is flexible c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.) Relatively cryptic keys and switches in text file d. Reliability (e.g., software bugs, technical errors, Well tested and free of bugs

I-41 Model: CAL3QHC (CALINE3 with Queuing and Hot spot Calculations) implementation issues, etc.) 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) Complete b. Format (e.g., series of notes, hardcopies only, on-line, etc.) Electronic and on-line 7. Validation and confidence use Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results: a. Valid only in special cases b. Moderate c. High High confidence based on volume of validation work 8. Outputs a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.) ppm b. If air quality, what pollutants are covered? Generally only stable compounds like CO, but depends on what the user is willing to accept. c. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) 9. Policy or requirements a. Is this a preferred or required model? This is a required model b. Input restrictions (i.e., parameter limits) None except based on scope of model c. Limitations on application (i.e., scenario limits) Only for microscale applications Model: CALPUFF 1. Overall Model Scope a. In public domain? If not, who is caretaker? In public domain. Maintained Earth Tech b. Air quality or noise? a. Air quality: emissions or dispersion? Dispersion b. Noise: SI, SPL, or other? c. Mode (highway, rail, water, air) Potentially all since it is a generic dispersion model d. Screening or detailed (intended categorization)? Detailed e. Scales of analysis a. Air quality (e.g., microscale, regional, national, etc.) Microscale and regional b. Noise (free field, long range propagation) f. Regulatory use (e.g., NEPA assessments, etc.)? Yes, used for regulatory studies on a case by case basis 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.) Gaussian dispersion based on point, line, area, and volume sources. Also, contains detailed modeling of atmospheric effects. Can be used to model visibility. All of

I-42 Model: CALPUFF these modeling can be accomplished under a time-varying environment. b. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with average information) Between first order and theoretical c. Theoretically-based (e.g., vehicle-specific with individual characteristics and theoretical propagation implemented) 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.) Flat ASCII files and GUI b. Operating system (e.g., MS-DOS, Windows, Linux, etc.) Windows c. Software language (e.g., Fortran, C#.NET, etc.) Fortran and Visual Basic d. Software structure (e.g., single exe, modularized components, preprocessors, etc.) Single executable e. Distributed computing? (yes or no) No f. Connectivity with other tools (e.g., AEDT-APMT linkage, etc.) No, but intended to use the direct outputs from models like EMFAC2007 and MOBILE6.2 g. Hardware/additional software requirements None 4. Database a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) None. This is a generic dispersion model b. What data is included? (e.g., NPD, EI, performance profiles, etc.) No data c. Robustness of data (i.e., fidelity and resolution of data Emission factors, speed, etc, can be general or specific d. Traceability (e.g., documented sources, acceptability, etc.) N/A since all data are inputs e. Publicly available N/A since all data are inputs 5. Usability a. General data requirements (e.g., readily available, easily found, considerable effort required, etc.) Readily available, but some time-varying data may be difficult to obtain. Will depend on the needs of the user. b. Input flexibility (e.g., different resolution of data, user- defined sources, etc.) Rigid data format for input. CALPUFF is flexible to model various sources including both stationary and moving. c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.) Relatively easy to understand GUI. d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) Well tested and free of bugs 6. Documentation

I-43 Model: CALPUFF a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) Complete b. Format (e.g., series of notes, hardcopies only, on-line, etc.) Electronic and on-line 7. Validation and confidence use Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results: a. Valid only in special cases b. Moderate c. High High confidence based on volume of validation work 8. Outputs a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.) ppm b. If air quality, what pollutants are covered? Generally only stable compounds like CO, but pseudo-first-order chemical mechanisms for SO2, SO4, NOx, HNO3, and NO3. Depends on the assumptions the user is willing to make. c. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) 9. Policy or requirements a. Is this a preferred or required model? This is an alternate model that can be used on a case by case basis. b. Input restrictions (i.e., parameter limits) None c. Limitations on application (i.e., scenario limits) Generally none, but need to consider reactivity of pollutants modeled and range of dispersion. Model: CMEM (Comprehensive Modal Emissions Model) 1. Overall Model Scope a. In public domain? If not, who is caretaker? In public domain. Maintained by UC Riverside and requires a fee to purchase. b. Air quality or noise? a. Air quality: emissions or dispersion? Emissions model b. Noise: SI, SPL, or other? c. Mode (highway, rail, water, air) Highway d. Screening or detailed (intended categorization)? Detailed e. Scales of analysis a. Air quality (e.g., microscale, regional, national, etc.) Microscale b. Noise (free field, long range propagation) f. Regulatory use (e.g., NEPA assessments, etc.)? Currently no 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.) Regressed equations to take into account various vehicle characteristics, operational, and environmental variables.

I-44 Model: CMEM (Comprehensive Modal Emissions Model) b. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with average information) Between first order and theoretical c. Theoretically-based (e.g., vehicle-specific with individual characteristics and theoretical propagation implemented) 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.) MS Access database files b. Operating system (e.g., MS-DOS, Windows, Linux, etc.) Windows c. Software language (e.g., Fortran, C#.NET, etc.) VB Script d. Software structure (e.g., single exe, modularized components, preprocessors, etc.) Various modules with a single database query GUI e. Distributed computing? (yes or no) No f. Connectivity with other tools (e.g., AEDT-APMT linkage, etc.) No g. Hardware/additional software requirements None 4. Database a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) Vehicular sources only (currently only light duty vehicles) b. What data is included? (e.g., NPD, EI, performance profiles, etc.) Fleet characteristics, operational, and environmental effects data c. Robustness of data (i.e., fidelity and resolution of data Internal data is generally high resolution. Input data such as speed, age, type, etc, can be general or specific d. Traceability (e.g., documented sources, acceptability, etc.) Well documented e. Publicly available Internal databases available with purchased software 5. Usability a. General data requirements (e.g., readily available, easily found, considerable effort required, etc.) Most are readily available, but others may require considerable effort depending on fidelity requirements of the user b. Input flexibility (e.g., different resolution of data, user- defined sources, etc.) Rigid data format, but resolution of data is flexible c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.) Relatively easy to understand GUI. d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) Some software bugs 6. Documentation

I-45 Model: CMEM (Comprehensive Modal Emissions Model) a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) Complete b. Format (e.g., series of notes, hardcopies only, on-line, etc.) Electronic, not on-line 7. Validation and confidence use Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results: a. Valid only in special cases b. Moderate c. High High confidence based on initial validation work 8. Outputs a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.) Grams per second, Grams per vehicle-hour, grams per vehicle-mile b. If air quality, what pollutants are covered? CO, THC, NOx, CO2 c. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) 9. Policy or requirements a. Is this a preferred or required model? Currently no b. Input restrictions (i.e., parameter limits) None c. Limitations on application (i.e., scenario limits) Only for light-duty, on-road vehicles Model: EMFAC2007 1. Overall Model Scope a. In public domain? If not, who is caretaker? In public domain. Maintained by CARB. b. Air quality or noise? a. Air quality: emissions or dispersion? Emissions model b. Noise: SI, SPL, or other? c. Mode (highway, rail, water, air) Highway d. Screening or detailed (intended categorization)? Detailed e. Scales of analysis a. Air quality (e.g., microscale, regional, national, etc.) Initially intended for regional and national, but can be used for microscale as well b. Noise (free field, long range propagation) f. Regulatory use (e.g., NEPA assessments, etc.)? Yes, but mainly in California 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.) Regressed equations to take into account various California-specific vehicle characteristics, operational, and environmental variables. b. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.)

I-46 Model: EMFAC2007 b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with average information) Between first order and theoretical c. Theoretically-based (e.g., vehicle-specific with individual characteristics and theoretical propagation implemented) 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.) Flat ASCII files and GUI b. Operating system (e.g., MS-DOS, Windows, Linux, etc.) Windows c. Software language (e.g., Fortran, C#.NET, etc.) Visual Basic d. Software structure (e.g., single exe, modularized components, preprocessors, etc.) Single exe with various libraries underneath e. Distributed computing? (yes or no) No f. Connectivity with other tools (e.g., AEDT-APMT linkage, etc.) No, but the outputs can be directly used by some other tools g. Hardware/additional software requirements None 4. Database a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) Vehicular sources only b. What data is included? (e.g., NPD, EI, performance profiles, etc.) Fleet characteristics (age, type, etc.), operational (hot, cold, speed, etc.), and atmospheric data correlated to basic emission rates c. Robustness of data (i.e., fidelity and resolution of data Internal data is generally high resolution. Input data such speed, age, type, etc, can be general or specific d. Traceability (e.g., documented sources, acceptability, etc.) Well documented e. Publicly available Most datasets are publicly available 5. Usability a. General data requirements (e.g., readily available, easily found, considerable effort required, etc.) Most are readily available, but others may require considerable effort depending on fidelity requirements of the user b. Input flexibility (e.g., different resolution of data, user- defined sources, etc.) Rigid data format, but resolution of data is flexible c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.) Relatively easy to understand GUI d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) Well developed and issues resolved 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) Complete b. Format (e.g., series of notes, hardcopies only, on-line, Electronic and on-line

I-47 Model: EMFAC2007 etc.) 7. Validation and confidence use Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results: a. Valid only in special cases b. Moderate c. High High based on validation work 8. Outputs a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.) Grams per vehicle-hour, grams per vehicle-mile b. If air quality, what pollutants are covered? CO, CO2, NOx, SOx, THC (and various components), PM10, PM2.5, Pb c. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) 9. Policy or requirements a. Is this a preferred or required model? Required in California b. Input restrictions (i.e., parameter limits) None c. Limitations on application (i.e., scenario limits) Only for on-road vehicles covered by the model Model: EMIT (Easy Mobile Inventory Tool) 1. Overall Model Scope a. In public domain? If not, who is caretaker? Not in public domain. Maintained by FHWA b. Air quality or noise? a. Air quality: emissions or dispersion? Emissions model b. Noise: SI, SPL, or other? c. Mode (highway, rail, water, air) Highway d. Screening or detailed (intended categorization)? Detailed e. Scales of analysis a. Air quality (e.g., microscale, regional, national, etc.) Initially intended for regional and national, but can be used for microscale as well b. Noise (free field, long range propagation) f. Regulatory use (e.g., NEPA assessments, etc.)? Yes 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.) MOBILE6.2 emissions b. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with average information) Between first order and theoretical

I-48 Model: EMIT (Easy Mobile Inventory Tool) c. Theoretically-based (e.g., vehicle-specific with individual characteristics and theoretical propagation implemented) 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.) Through GUI b. Operating system (e.g., MS-DOS, Windows, Linux, etc.) Windows c. Software language (e.g., Fortran, C#.NET, etc.) Visual Basic d. Software structure (e.g., single exe, modularized components, preprocessors, etc.) Single exe with MOBILE6.2 underneath e. Distributed computing? (yes or no) No f. Connectivity with other tools (e.g., AEDT-APMT linkage, etc.) No, but the outputs can be directly used by some other tools g. Hardware/additional software requirements None 4. Database a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) Vehicular sources only b. What data is included? (e.g., NPD, EI, performance profiles, etc.) All those associated with MOBILE6.2 such as fleet characteristics (age, type, etc.), operational (hot, cold, speed, etc.), and atmospheric data correlated to basic emission rates c. Robustness of data (i.e., fidelity and resolution of data Internal data is generally high resolution. Input data such speed, age, type, etc, can be general or specific d. Traceability (e.g., documented sources, acceptability, etc.) Data are for MOBILE6.2 and well documented e. Publicly available Most datasets are publicly available 5. Usability a. General data requirements (e.g., readily available, easily found, considerable effort required, etc.) Most are readily available, but others may require considerable effort depending on fidelity requirements of the user b. Input flexibility (e.g., different resolution of data, user- defined sources, etc.) Rigid data format, but resolution of data is flexible c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.) Easy to understand GUI d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) Likely some bugs in GUI 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) Complete b. Format (e.g., series of notes, hardcopies only, on-line, etc.) Electronic 7. Validation and confidence use

I-49 Model: EMIT (Easy Mobile Inventory Tool) Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results: a. Valid only in special cases b. Moderate c. High High based on the user of MOBILE6.2 8. Outputs a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.) Same as MOBILE6.2: Grams per vehicle-hour, grams per vehicle-mile b. If air quality, what pollutants are covered? Same as MOBILE6.2: CO, CO2, NOx, SOx, THC (and various components), PM10, PM2.5 c. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) 9. Policy or requirements a. Is this a preferred or required model? Required based on use of MOBILE6.2 b. Input restrictions (i.e., parameter limits) None c. Limitations on application (i.e., scenario limits) Only for on-road vehicles covered by MOBILE6.2 Model: FLINT (FLorida INTersection Model) 1. Overall Model Scope a. In public domain? If not, who is caretaker? Not in public domain. Maintained by FDOT and University of Central Florida. b. Air quality or noise? a. Air quality: emissions or dispersion? Dispersion model b. Noise: SI, SPL, or other? c. Mode (highway, rail, water, air) Highway d. Screening or detailed (intended categorization)? Detailed e. Scales of analysis a. Air quality (e.g., microscale, regional, national, etc.) Microscale b. Noise (free field, long range propagation) f. Regulatory use (e.g., NEPA assessments, etc.)? Not currently used for regulatory studies 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.) Gaussian dispersion from PAL2 and vehicle queuing algorithm b. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with average information) Between first order and theoretical c. Theoretically-based (e.g., vehicle-specific with

I-50 Model: FLINT (FLorida INTersection Model) individual characteristics and theoretical propagation implemented) 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.) GUI and Flat ASCII files b. Operating system (e.g., MS-DOS, Windows, Linux, etc.) Windows c. Software language (e.g., Fortran, C#.NET, etc.) Visual Basic d. Software structure (e.g., single exe, modularized components, preprocessors, etc.) Single exe with model underneath (e.g., PAL2) e. Distributed computing? (yes or no) No f. Connectivity with other tools (e.g., AEDT-APMT linkage, etc.) No, but intended to use the direct outputs from models like MOBILE6.2 g. Hardware/additional software requirements None 4. Database a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) Vehicular sources only b. What data is included? (e.g., NPD, EI, performance profiles, etc.) No data c. Robustness of data (i.e., fidelity and resolution of data Emission factors, speed, etc, can be general or specific d. Traceability (e.g., documented sources, acceptability, etc.) N/A since all data are inputs e. Publicly available N/A since all data are inputs 5. Usability a. General data requirements (e.g., readily available, easily found, considerable effort required, etc.) Readily available b. Input flexibility (e.g., different resolution of data, user- defined sources, etc.) Rigid data format, but resolution of data is flexible c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.) Relatively easy to understand GUI d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) GUI has some bugs 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) Some technical papers but no user’s guide b. Format (e.g., series of notes, hardcopies only, on-line, etc.) Electronic, not on-line 7. Validation and confidence use Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results: a. Valid only in special cases

I-51 Model: FLINT (FLorida INTersection Model) b. Moderate Moderate to high based on initial validation work c. High 8. Outputs a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.) ppm b. If air quality, what pollutants are covered? Generally only stable compounds like CO, but depends on what the user is willing to accept. c. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) 9. Policy or requirements a. Is this a preferred or required model? No b. Input restrictions (i.e., parameter limits) None except based on scope of model c. Limitations on application (i.e., scenario limits) Only for microscale applications Model: HYROAD 1. Overall Model Scope a. In public domain? If not, who is caretaker? In public domain. Maintained by SAIC b. Air quality or noise? a. Air quality: emissions or dispersion? Dispersion and emissions model b. Noise: SI, SPL, or other? c. Mode (highway, rail, water, air) Highway d. Screening or detailed (intended categorization)? Detailed e. Scales of analysis a. Air quality (e.g., microscale, regional, national, etc.) Microscale b. Noise (free field, long range propagation) f. Regulatory use (e.g., NEPA assessments, etc.)? In certain cases as an option 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.) AERMOD dispersion, NETSIM traffic simulation, MOBILE6.2 emissions b. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with average information) Between first order and theoretical c. Theoretically-based (e.g., vehicle-specific with individual characteristics and theoretical propagation implemented) 3. System architecture

I-52 Model: HYROAD a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.) GUI and Flat ASCII files b. Operating system (e.g., MS-DOS, Windows, Linux, etc.) Windows c. Software language (e.g., Fortran, C#.NET, etc.) Visual Basic d. Software structure (e.g., single exe, modularized components, preprocessors, etc.) Single exe with modularized components in serial fashion e. Distributed computing? (yes or no) No f. Connectivity with other tools (e.g., AEDT-APMT linkage, etc.) No g. Hardware/additional software requirements None 4. Database a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) Vehicular sources only b. What data is included? (e.g., NPD, EI, performance profiles, etc.) No data c. Robustness of data (i.e., fidelity and resolution of data Emission factors, speed, etc, can be general or specific d. Traceability (e.g., documented sources, acceptability, etc.) N/A since all data are inputs e. Publicly available N/A since all data are inputs 5. Usability a. General data requirements (e.g., readily available, easily found, considerable effort required, etc.) Readily available b. Input flexibility (e.g., different resolution of data, user- defined sources, etc.) Rigid data format, but resolution of data is flexible c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.) Relatively easy to understand GUI d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) GUI has some bugs 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) Complete b. Format (e.g., series of notes, hardcopies only, on-line, etc.) Electronic and on-line 7. Validation and confidence use Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results: a. Valid only in special cases b. Moderate Moderate to high based on initial validation work c. High 8. Outputs

I-53 Model: HYROAD a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.) ppm b. If air quality, what pollutants are covered? Generally only stable compounds like CO, but depends on what the user is willing to accept. c. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) 9. Policy or requirements a. Is this a preferred or required model? Alternative model b. Input restrictions (i.e., parameter limits) None except based on scope of model c. Limitations on application (i.e., scenario limits) Only for microscale applications Model: MOBILE6.2 1. Overall Model Scope a. In public domain? If not, who is caretaker? In public domain. Maintained by EPA b. Air quality or noise? a. Air quality: emissions or dispersion? Emissions model b. Noise: SI, SPL, or other? c. Mode (highway, rail, water, air) Highway d. Screening or detailed (intended categorization)? Detailed e. Scales of analysis a. Air quality (e.g., microscale, regional, national, etc.) Initially intended for regional and national, but can be used for microscale as well b. Noise (free field, long range propagation) f. Regulatory use (e.g., NEPA assessments, etc.)? Yes 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.) Regressed equations to take into account various vehicle characteristics, operational, and environmental variables. b. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with average information) Between first order and theoretical c. Theoretically-based (e.g., vehicle-specific with individual characteristics and theoretical propagation implemented) 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.) Flat ASCII files b. Operating system (e.g., MS-DOS, Windows, Linux, MS-DOS

I-54 Model: MOBILE6.2 etc.) c. Software language (e.g., Fortran, C#.NET, etc.) Fortran d. Software structure (e.g., single exe, modularized components, preprocessors, etc.) Single exe with various libraries underneath e. Distributed computing? (yes or no) No f. Connectivity with other tools (e.g., AEDT-APMT linkage, etc.) No, but the outputs can be directly used by some other tools g. Hardware/additional software requirements None 4. Database a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) Vehicular sources only b. What data is included? (e.g., NPD, EI, performance profiles, etc.) Fleet characteristics (age, type, etc.), operational (hot, cold, speed, etc.), and atmospheric data correlated to basic emission rates c. Robustness of data (i.e., fidelity and resolution of data Internal data is generally high resolution. Input data such speed, age, type, etc, can be general or specific d. Traceability (e.g., documented sources, acceptability, etc.) Well documented e. Publicly available Most datasets are publicly available 5. Usability a. General data requirements (e.g., readily available, easily found, considerable effort required, etc.) Most are readily available, but others may require considerable effort depending on fidelity requirements of the user b. Input flexibility (e.g., different resolution of data, user- defined sources, etc.) Rigid data format, but resolution of data is flexible c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.) Hard to understand codes, cryptic switches, and steep learning curve d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) Well developed and issues resolved 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) Complete b. Format (e.g., series of notes, hardcopies only, on-line, etc.) Electronic and on-line 7. Validation and confidence use Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results: a. Valid only in special cases b. Moderate c. High High based on validation work 8. Outputs a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual Grams per vehicle-hour, grams per vehicle-mile

I-55 Model: MOBILE6.2 average, etc.) b. If air quality, what pollutants are covered? CO, CO2, NOx, SOx, THC (and various components), PM10, PM2.5 c. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) 9. Policy or requirements a. Is this a preferred or required model? Required b. Input restrictions (i.e., parameter limits) None c. Limitations on application (i.e., scenario limits) Only for on-road vehicles covered by the model Model: MOVES 1. Overall Model Scope a. In public domain? If not, who is caretaker? In public domain. Maintained by EPA b. Air quality or noise? a. Air quality: emissions or dispersion? Emissions model b. Noise: SI, SPL, or other? c. Mode (highway, rail, water, air) Highway d. Screening or detailed (intended categorization)? Detailed e. Scales of analysis a. Air quality (e.g., microscale, regional, national, etc.) All levels b. Noise (free field, long range propagation) f. Regulatory use (e.g., NEPA assessments, etc.)? Currently no, but planned 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.) Regressed equations to take into account various vehicle characteristics, operational, and environmental variables. b. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with average information) Between first order and theoretical c. Theoretically-based (e.g., vehicle-specific with individual characteristics and theoretical propagation implemented) 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.) MySQL database files b. Operating system (e.g., MS-DOS, Windows, Linux, etc.) Windows c. Software language (e.g., Fortran, C#.NET, etc.) Java d. Software structure (e.g., single exe, modularized Various modules with a single GUI

I-56 Model: MOVES components, preprocessors, etc.) e. Distributed computing? (yes or no) Yes f. Connectivity with other tools (e.g., AEDT-APMT linkage, etc.) No g. Hardware/additional software requirements Added processors may be necessary for efficient runs of detailed scenarios 4. Database a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) Vehicular sources only b. What data is included? (e.g., NPD, EI, performance profiles, etc.) Fleet characteristics, operational, and environmental effects data c. Robustness of data (i.e., fidelity and resolution of data Internal data is generally high resolution. Input data such speed, age, type, etc, can be general or specific d. Traceability (e.g., documented sources, acceptability, etc.) Well documented, and supporting documents continuing to be developed e. Publicly available Yes 5. Usability a. General data requirements (e.g., readily available, easily found, considerable effort required, etc.) Most are readily available, but others may require considerable effort depending on fidelity requirements of the user b. Input flexibility (e.g., different resolution of data, user- defined sources, etc.) Rigid data format, but resolution of data is flexible c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.) Easy to understand database GU d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) Some software bugs 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) Complete b. Format (e.g., series of notes, hardcopies only, on-line, etc.) Electronic and on-line 7. Validation and confidence use Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results: a. Valid only in special cases b. Moderate Moderate to high based on initial validation work c. High 8. Outputs a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.) Grams per vehicle-hour, grams per vehicle-mile b. If air quality, what pollutants are covered? Currently just greenhouse gases (e.g., CO2, CH4, etc.) but criteria pollutants (CO, NOx, etc.) planned

I-57 Model: MOVES c. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) 9. Policy or requirements a. Is this a preferred or required model? Currently no b. Input restrictions (i.e., parameter limits) None c. Limitations on application (i.e., scenario limits) None Model: TRAQSIM (Traffic Air Quality Simulation Model) 1. Overall Model Scope a. In public domain? If not, who is caretaker? Currently not in public domain. Maintained by Wyle. b. Air quality or noise? a. Air quality: emissions or dispersion? Dispersion and emissions model b. Noise: SI, SPL, or other? c. Mode (highway, rail, water, air) Highway d. Screening or detailed (intended categorization)? Detailed e. Scales of analysis a. Air quality (e.g., microscale, regional, national, etc.) Microscale b. Noise (free field, long range propagation) f. Regulatory use (e.g., NEPA assessments, etc.)? Currently, no 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.) Gaussian puff dispersion, CMEM modal emissions, and traffic simulation using NETSIM core algorithms b. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with average information) Between first order and theoretical c. Theoretically-based (e.g., vehicle-specific with individual characteristics and theoretical propagation implemented) 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.) GUI and Flat ASCII files b. Operating system (e.g., MS-DOS, Windows, Linux, etc.) Windows c. Software language (e.g., Fortran, C#.NET, etc.) Visual Basic d. Software structure (e.g., single exe, modularized components, preprocessors, etc.) Single exe with modularized components that are fully integrated e. Distributed computing? (yes or no) No

I-58 Model: TRAQSIM (Traffic Air Quality Simulation Model) f. Connectivity with other tools (e.g., AEDT-APMT linkage, etc.) No g. Hardware/additional software requirements None 4. Database a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) Vehicular sources only b. What data is included? (e.g., NPD, EI, performance profiles, etc.) Pre-run CMEM modal emissions data c. Robustness of data (i.e., fidelity and resolution of data Emission factors, speed, etc, can be general or specific d. Traceability (e.g., documented sources, acceptability, etc.) CMEM data is fully documented e. Publicly available CMEM and its data is publicly available 5. Usability a. General data requirements (e.g., readily available, easily found, considerable effort required, etc.) Readily available b. Input flexibility (e.g., different resolution of data, user- defined sources, etc.) Rigid data format, but resolution of data is flexible c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.) Relatively easy to understand GUI d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) GUI has some bugs 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) Complete b. Format (e.g., series of notes, hardcopies only, on-line, etc.) Electronic, not on-line 7. Validation and confidence use Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results: a. Valid only in special cases b. Moderate Moderate to high based on initial validation work c. High 8. Outputs a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.) ppm b. If air quality, what pollutants are covered? Generally an only stable compound like CO, but depends on what the user is willing to accept. c. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) 9. Policy or requirements

I-59 Model: TRAQSIM (Traffic Air Quality Simulation Model) a. Is this a preferred or required model? Currently no b. Input restrictions (i.e., parameter limits) None except based on scope of model c. Limitations on application (i.e., scenario limits) Only for microscale applications

I-60 I.2. Aviation Noise Models Model: AAM (Advanced Acoustic Model) (NMSim + RNM) 1. Overall Model Scope a. In public domain? If not, who is caretaker?  NMSim 3.0 is the public version (some functionality is not available in the public version). NMSim and RNM were developed by Wyle Laboratories.  AAM 1.0 has been submitted to SERDP and availability to the public at this point (Fall 2008) is unlikely  Updates and transition from NoiseMap are happening now. b. Air quality or noise?  Noise a. Noise: SI, SPL, or other?  SPL (spectrum and overall level time histories) c. Mode (highway, rail, water, air)  NMSim: Aircraft (fixed-wing and helicopters), highway and rail  Simulation models support any noise source provided the data exists in sphere format d. Screening or detailed (intended categorization)?  Detailed e. Scales of analysis a. Noise (free field, long range propagation) Far-field noise analysis including audibility, terrain, 1-D weather, ground effects (reflections and impedance) f. Regulatory use (e.g., NEPA assessments, etc.)?  NMSim: The NPS has adopted the model as its preferred standard noise model.  AAM: Will be used by The Department of Defense for noise analysis in conjunction with NoiseMap until proper data is available for all analyses in AAM 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.) 3D directivity and all vehicle dynamics are taken into account in a detailed trajectory input including yaw, pitch, roll, thrust vector angle, thrust, speed, time, x, y, z, etc.

I-61 Model: AAM (Advanced Acoustic Model) (NMSim + RNM) Non-linearity can be approximated based off a table of source-dependent nonlinear coefficients calculated apriori using Pressure vs. Time wave files and a generalized form of the Burgers equation b. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with average information) c. Theoretically-based (e.g., vehicle-specific with individual characteristics and theoretical propagation implemented) Source data spheres are based on measurements and principles of linear acoustics which allow for “reverse” propagation back to the source based on local weather conditions. 3. System architecture

I-62 Model: AAM (Advanced Acoustic Model) (NMSim + RNM) a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.)  NMSim: Outputs at specific points of interest and grids in ESRI's ASCII and NMGF file formats.  AAM: Output data provided in ASCII files, TecPlot *.plt files, and/or NMPlot *.grd files based on user’s desires. b. Operating system (e.g., MS-DOS, Windows, Linux, etc.)  NMSim: 32 bit Windows  AAM: Windows and Linux c. Software language (e.g., Fortran, C#.NET, etc.)  NMSim: Visual Fortran  AAM: Fortran d. Software structure (e.g., single exe, modularized components, preprocessors, etc.)  NMSim: A full NMSim case can have as many as seven input files. Of these possible input files, only an Elevation File, a Trajectory File, and a Noise Source file are required.  AAM: single EXE with components such as trajectory builder, elevation file builder, 3D visualizer provided as separate EXE’s. Sphere input is in the form of NETCDF binaries, ELV files are binary, and an ASCII file is required with a Keyword structure with options, commands, grid definitions, etc. e. Distributed computing? (yes or no) No f. Connectivity with other tools (e.g., AEDT-APMT linkage, etc.) No g. Hardware/additional software requirements  NMSim: Recommended hardware: o 500 MHz Pentium (or equivalent) based computer o 256 Megabytes of RAM o 1024x768, 24-bit color display.  NMSim: Minimum hardware: o 200 MHz o 128 MB RAM o 800x600 with 16-bit color o If color rendering and animations are not required, color depth can be 8 bits.  AAM: Same as NMSim 4. Database a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.)  NMSim: Air Tour Fixed Wing Sources, Air Tour Helicopter Sources, Ground Sources, INM Converted Sources, Military Sources  Source data is subject to permission for release by the DoD or, in RNM’s case, NASA  AAM data currently limited to AV8-b, F-15, F-16 (GE engine), F-16 (PW engine), F-18A/C, F-22, and F-35A (soon to be updated with Fall 2008 Edwards AFB measurement data)  Preliminary techniques exist to convert NoiseMap data into AAM data, but validity has yet to be proven

I-63 Model: AAM (Advanced Acoustic Model) (NMSim + RNM) b. What data is included? (e.g., NPD, EI, performance profiles, etc.)  NMSim:  Air Tour Fixed Wing Sources o Based on measurements made by FAA during Grand Canyon Model Validation project. Noise sources do not vary with given parameters such as speed or throttle setting.  Air Tour Helicopter Sources o Based on measurements made by FAA during Grand Canyon Model Validation project. Noise sources do not vary with given parameters such as speed or throttle setting. Not as complex as RNM sources  Ground Sources o Cars, buses, trucks, motorcycles and trains. Automobiles sources based on speed. Train source based on incline of track.  INM Converted Sources o Based on INM spectral classes and INM's ground attenuation algorithms (which determine directivity pattern). Vary with given throttle setting. (Data not very refined.)  Military Sources o Developed by Wyle Laboratories from USAF flight test recordings. (Most accurate of sources.) c. Robustness of data (i.e., fidelity and resolution of data Resolution is variable, but current sources exhibit 5 degree longitudinal spacing and 15 degree lateral spacing on a sphere containing third-octave band data at each point. Nose and tail data is “smeared” to eliminate singularities, and lower hemisphere is mirrored on the top of the sphere as an approximation to handle very large roll angles. Lateral directivity is limited by the microphone array when measured, but generally is of high-fidelity out to 45 degrees from below the aircraft and the data from 30-45 degrees is averaged and repeated up to 90 degrees (where the wings are) d. Traceability (e.g., documented sources, acceptability, etc.) No formal acceptance plan is in place. POI results generated from AAM compared to original microphone data are agreeable, however. e. Publicly available No 5. Usability a. General data requirements (e.g., readily available, easily found, considerable effort required, etc.) Data is generated by the Acoustic Repropagation Technique (ART) and considerable effort is required to take measurements and create spheres. However, suite of executables includes one called Bullwink.exe capable of taking an ASCII file and turning it into a NETCDF sphere, which could circumvent the ART process if the data was available b. Input flexibility (e.g., different resolution of data, user- defined sources, etc.)  NMSim: User can define total grid size and grid resolution  Noise spheres may contain broadband, narrowband, or pure tone data.  Angular resolution on noise sphere is variable

I-64 Model: AAM (Advanced Acoustic Model) (NMSim + RNM)  Elevation data grid is variable c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.) AAM in single-track mode is generally used for research purposes and a host of cryptic switches and keywords are available if the user wishes to climb a steep learning curve and bury himself with output data. All keywords are explained in the AAM manual if one so chooses to look However, AAM in multi-track mode will be integrated with BaseOps and the user will not have to do much out of the ordinary, making AAM more accessible to the average user d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) Software is reliable, provided inputs are created properlly and all the ends meet. This can be somewhat difficult for a very detailed analysis, though. 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) AAM User’s guide and Technical Manual are available upon request from Wyle b. Format (e.g., series of notes, hardcopies only, on-line, etc.) PDF, Word, and hardcopies available 7. Validation and confidence use Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results:  NMSim: Evaluation of model performed at Grand Canyon National Park by National Park Service and FAA in 1999.  Field validation by Department of Defense and Department of Interior.  AAM / RNM propagation algorithms have been accepted by the DoD and NASA a. Valid only in special cases b. Moderate c. High Accuracy of results depends on availability of properly measured and generated data spheres. As with any noise model, comparing results with measurements will be heavily caveated by meteorological conditions 8. Outputs a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.)  NMSim: Flat-weighted max, A-weighted max, Leq, Ldn, Time-above ambient, Time-audible  AAM results provide, if not explicitly, the implicit capability for literally any and all metrics to be calculated based off spectral time histories b. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted)  NMSim: Gives spectral noise level for 1/3 octave bands for frequencies from 50 Hz to 10 kHz  AAM generally used from 10 Hz to 10 kHz in third octave bands. The model is flexible, however, and can handle narrowband data and pure- tone data as well 9. Policy or requirements a. Is this a preferred or required model? Likely will be required for use with highly directional fighter jets for military noise evaluations b. Input restrictions (i.e., parameter limits) Currently input data is contingent on proper measurements, but steps are being taken to provide input for legacy aircraft where immediate measurement is not a

I-65 Model: AAM (Advanced Acoustic Model) (NMSim + RNM) reasonable option c. Limitations on application (i.e., scenario limits) Model: CNM (Community Noise Model) 1. Overall Model Scope a. In public domain? If not, who is caretaker? Yes, but new users no longer provided model b. Air quality or noise? Noise. a. Air quality: emission or dispersion? N/A b. Noise: SI, SPL, or other? SPL, A-weighted (LAeq1hr, Ldn c. Mode (highway, rail, water, air) ) Highway, rail, community sources, limited air. d. Screening or detailed (intended categorization)? Detailed true simulation model e. Scales of analysis a. Air quality (e.g., microscale, regional, national, etc.) N/A b. Noise (free field, long range propagation) Free field with increased error occurring over 2000 feet. f. Regulatory use (e.g., NEPA assessments, etc.)? Not required model in US. 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.) Applied ray acoustics. Reference Energy Mean Emission Levels are adjusted for each time step and vehicle operational mode and type. Then propagation considering geometric spreading, ground effects, diffraction, vegetation, and atmospheric absorption is considered. Many of the algorithms based on ISO9613. Reports in A-weighted values. b. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with average information) c. Theoretically-based (e.g., vehicle-specific with individual characteristics and theoretical propagation implemented) Closest to theoretical-based although first order approximation techniques are applied as well. 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.) Requires input through GUI and forms a working database. Output reported in GUI and hard copy tables. b. Operating system (e.g., MS-DOS, Windows, Linux, etc.) Windows 95/98/ME/NT4/2000/XP. c. Software language (e.g., Fortran, C#.NET, etc.) Visual Basic.. d. Software structure (e.g., single exe, modularized components, preprocessors, etc.) Modularized components with central core executable program and DLL files.

I-66 Model: CNM (Community Noise Model) e. Distributed computing? (yes or no) No. Not as designed. f. Connectivity with other tools (e.g., AEDT-APMT linkage, etc.) No direct linkage. g. Hardware/additional software requirements IBM compatible PC with Pentium processor and above recommended. 4. Database a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) 5 motor vehicle types (Autos, medium trucks, heavy trucks, buses, and motorcycles.), multiple rail engines and trailing cars, compressors, overflights, rail yard activities, user defined sources. b. What data is included? (e.g., NPD, EI, performance profiles, etc.) Reference Energy Mean Emission Levels for all 5 vehicle types by speed and mode (cruise, deceleration, acceleration, idle) which is updated for each time step. c. Robustness of data (i.e., fidelity and resolution of data Use of USDOT motor vehicle REMELS (as used in TNM), reported rail values and overflights. Measurements used for validation. d. Traceability (e.g., documented sources, acceptability, etc.) Data reported in document: user manual and Journal of the TRB. e. Publicly available Yes. Although no longer distributed. 5. Usability a. General data requirements (e.g., readily available, easily found, considerable effort required, etc.) Highway data including roadway/path/receiver geometry, traffic volumes/speeds/vehicle type, ground type. Rail movements, track locations, crossing locations. Community noise source types and locations. b. Input flexibility (e.g., different resolution of data, user- defined sources, etc.) Little flexibility in input data. Metric/English. Creation of user-defined sources accepted. c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.) Straight forward graphical or spreadsheet entry. d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) Verified by multiple users in multiple countries but more needed on rail and community sources. Use of TNM REMELs make predictions reliable and added deceleration REMELs added to flexibility of use. 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) Complete with user guide (MacDonald, J, R.Wayson, Community Noise Model User’s Guide, University of Central Florida.. b. Format (e.g., series of notes, hardcopies only, on-line, etc.) Electronic copy on disk with model. 7. Validation and confidence use Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results: More validation would be desirable, on acoustic and vehicle movement. a. Valid only in special cases b. Moderate c. High High. Validation indicates good results for areas in the immediate vicinity of highway. Especially good in the vicinity of intersections.

I-67 Model: CNM (Community Noise Model) 8. Outputs a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.) LAeq1hr, Ldn b. If air quality, what pollutants are covered? , statistical metrics. N/A c. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) A-weight reported. 9. Policy or requirements a. Is this a preferred or required model? No. b. Input restrictions (i.e., parameter limits) Limited to use for normal urban sources (continuous sources). c. Limitations on application (i.e., scenario limits) In close proximity to highway. Model: CREATE (Chicago Rail Efficiency and Transportation Efficiency) 1. Overall Model Scope a. In public domain? If not, who is caretaker? Yes (developed by HMMH). It can be downloaded at: <http://www.fra.dot.gov/us/content/253> b. Air quality or noise? Noise a. Noise: SI, SPL, or other? SPL c. Mode (highway, rail, water, air) Road, rail d. Screening or detailed (intended categorization)? Screening e. Scales of analysis a. Noise (free field, long range propagation) Free field. f. Regulatory use (e.g., NEPA assessments, etc.)? The CREATE model is based on the Federal Transit Administration General Transit Noise Assessment. 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.) Moving noise sources are modeled as line sources and propagation is assumed to take place over soft ground, resulting in an attenuation rate of 4.5 dB per doubling of distance. A speed coefficient is defined to represent the variability of SEL of a pass-by as a function of vehicle speed. Stationary noise sources are modeled as point sources and propagation is assumed to take place over soft ground, resulting in an attenuation rate of 7.5 dB per doubling of distance. Track noise sources add a predetermined constant number of decibels to the level Intervening rows of buildings add a 4.5 dB attenuation for the first row and 1.5 dB for each additional row (up to 5 rows and no more than 10 dB). b. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) Simple b. First order approximation (e.g., partial vehicle

I-68 Model: CREATE (Chicago Rail Efficiency and Transportation Efficiency) data and propagation simplifications supplemented with average information) c. Theoretically-based (e.g., vehicle-specific with individual characteristics and theoretical propagation implemented) 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.) Program is spreadsheet, inputs and outputs in XLS file b. Operating system (e.g., MS-DOS, Windows, Linux, etc.) Operating system that supports MS Excel c. Software language (e.g., Fortran, C#.NET, etc.) Spreadsheet d. Software structure (e.g., single exe, modularized components, preprocessors, etc.) Single spreadsheet e. Distributed computing? (yes or no) No f. Connectivity with other tools (e.g., AEDT-APMT linkage, etc.) No g. Hardware/additional software requirements MS Excel 4. Database a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) Moving and stationary rail and road sources: • Moving Noise Sources: o Electric and diesel commuter locomotives o Commuter passenger cars o Light-rail transit (LRT) powered cars o Automated-guideway transit (AGT) cars (steel-wheeled and rubber- tired) o Monorail o Magnetic-levitation (Maglev) trains o Freight locomotives o Freight cars (typical and empty hopper) o Automobiles o Buses (city and commuter) o Commuter buses o Moving Noise Sources: • Stationary Noise Sources: o Track crossovers (switches, turnouts, crossing diamonds) o Rail yards or shops o Layover tracks o Bus storage yards o Bus operating facilities o Bus transit centers

I-69 Model: CREATE (Chicago Rail Efficiency and Transportation Efficiency) o Parking garages o Park and ride lots Also includes option to include track noise sources such as: o Percentage of wheel flats for rail cars o Jointed track o Embedded track o Aerial structure b. What data is included? (e.g., NPD, EI, performance profiles, etc.) Reference SELs at 50 feet, speed coefficients, reference speeds, etc. c. Robustness of data (i.e., fidelity and resolution of data Average, conservative values are used with approximations as needed. d. Traceability (e.g., documented sources, acceptability, etc.) Values are listed but not fully traceable. e. Publicly available Yes, included with spreadsheet 5. Usability a. General data requirements (e.g., readily available, easily found, considerable effort required, etc.) Input data related to source:  Source type, number of trains per hour for rail-related sources, number of vehicles per hour for road-related sources, number of locomotives or cars per train, duration of trains for track crossovers, and speed of vehicles. Input data related to receptor:  Land-use type (FTA Category 1,2,3), distance to noise sources, presence of noise barrier, and intervening building rows. b. Input flexibility (e.g., different resolution of data, user- defined sources, etc.) Not very flexible--choose from predetermined options. c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.) Simple spreadsheet d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) Reliability assumed to be high because CREATE is not an intricate program. 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) User's guide at: <http://www.fra.dot.gov/us/content/253> b. Format (e.g., series of notes, hardcopies only, on-line, etc.) PDF online 7. Validation and confidence use Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results: While the model has been extensively used, actual validation does not seem to have occurred. a. Valid only in special cases b. Moderate c. High 8. Outputs

I-70 Model: CREATE (Chicago Rail Efficiency and Transportation Efficiency) a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.) Hourly-equivalent (Leq) or day-night (Ldn) noise levels. b. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) Overall spectrum. 9. Policy or requirements a. Is this a preferred or required model? Preferred. b. Input restrictions (i.e., parameter limits) Input up to 8 different types of noise sources. c. Limitations on application (i.e., scenario limits) Simple scenarios only with restrictions such as single height barriers, barrier parallel to tracks, and simple topography. Model: Florida Rail Model 1. Overall Model Scope a. In public domain? If not, who is caretaker? Yes, available from Florida DOT. b. Air quality or noise? Noise. a. Air quality: emission or dispersion? N/A b. Noise: SI, SPL, or other? SPL, A-weighted (LAeq1hr, Ldn c. Mode (highway, rail, water, air) ) Rail with limited community sources. d. Screening or detailed (intended categorization)? Detailed true simulation model e. Scales of analysis a. Air quality (e.g., microscale, regional, national, etc.) N/A b. Noise (free field, long range propagation) Free field with increased error occurring over 2000 feet. f. Regulatory use (e.g., NEPA assessments, etc.)? Not required model in US but results are consistent with FTA simplistic spreadsheet.. 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.) Applied ray acoustics. Reference Energy Mean Emission Levels are adjusted for each time step and vehicle operational mode and type. Then propagation considering geometric spreading, ground effects, diffraction, vegetation, and atmospheric absorption is considered. Many of the algorithms based on ISO9613. Reports in A-weighted values. b. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with average information) c. Theoretically-based (e.g., vehicle-specific with individual characteristics and theoretical propagation implemented) Closest to theoretical-based although first order approximation techniques are applied as well.

I-71 Model: Florida Rail Model 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.) Requires input through GUI and forms a working database. Output reported in GUI and hard copy tables. b. Operating system (e.g., MS-DOS, Windows, Linux, etc.) Windows 95/98/ME/NT4/2000/XP. c. Software language (e.g., Fortran, C#.NET, etc.) Visual Basic.. d. Software structure (e.g., single exe, modularized components, preprocessors, etc.) Modularized components with central core executable program and DLL files. e. Distributed computing? (yes or no) No. Not as designed. f. Connectivity with other tools (e.g., AEDT-APMT linkage, etc.) No direct linkage. g. Hardware/additional software requirements IBM compatible PC with Pentium processor and above recommended. 4. Database a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) Multiple rail engines and trailing cars including high speed rail and some rail yard activities. User defined sources as line, area, or point also possible.. b. What data is included? (e.g., NPD, EI, performance profiles, etc.) Reference Energy Mean Emission Levels for all cars and engines and is updated for each time step. c. Robustness of data (i.e., fidelity and resolution of data Values derived from multiple sources as reported in the literature. Measurements used for validation. d. Traceability (e.g., documented sources, acceptability, etc.) Data reported in document: user manual and Journal of the TRB. e. Publicly available Yes. Request through Florida DOT. 5. Usability a. General data requirements (e.g., readily available, easily found, considerable effort required, etc.) Rail movements, track locations, crossing locations, number of horn blasts. b. Input flexibility (e.g., different resolution of data, user- defined sources, etc.) Little flexibility in input data. Metric/English. Creation of user-defined sources accepted. c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.) Straight forward graphical or spreadsheet entry. d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) Verified by multiple measurements at various locations. Comparison to FTA spreadsheet (simple cases only available in spreadsheet) shows consistency. 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) Complete with user guide (MacDonald, J, R.Wayson, Community Noise Model User’s Guide, Florida Dept. of Transportation.. b. Format (e.g., series of notes, hardcopies only, on-line, etc.) Electronic copy on disk with model. 7. Validation and confidence use Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results:

I-72 Model: Florida Rail Model More validation would be desirable. a. Valid only in special cases b. Moderate Moderate. Validation indicates good results for areas in the immediate vicinity of rail activities but more validation really needed. c. High 8. Outputs a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.) LAeq1hr, Ldn b. If air quality, what pollutants are covered? . N/A c. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) A-weight reported. 9. Policy or requirements a. Is this a preferred or required model? No. b. Input restrictions (i.e., parameter limits) Limited to use in rail activities and user defined sources. c. Limitations on application (i.e., scenario limits) In close proximity to rail activities. Model: HICNOM (Highway Construction Noise Computer Program) 1. Overall Model Scope a. In public domain? If not, who is caretaker? Sponsored by the U.S. Department of Transportation Federal Highway Administration. Developed by Vanderbilt Transportation Research, Vanderbilt University. b. Air quality or noise? Noise a. Noise: SI, SPL, or other? SI and SPL c. Mode (highway, rail, water, air) Highway Construction Noise d. Screening or detailed (intended categorization)? Detailed e. Scales of analysis a. Noise (free field, long range propagation) f. Regulatory use (e.g., NEPA assessments, etc.)? 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.)  Sources in HICNOM can have point, line or area geometries. Geometrical spreading, ground attenuation and barrier effects are incorporated. The 8-hour equivalent sound level is a function of the energy-averaged emission level over some time period measured at a reference distance, the number of hours the equipment is in operation, the excess attenuation rate, and the distance between the source and receiver. The energy averaged emission can be calculated as the Lmax (max level during the operating cycle of the equipment) and the difference between the max and the equivalent sound level values over the duty cycle. Calculations are made to represent equipment with a production rate associated with it where its production is being

I-73 Model: HICNOM (Highway Construction Noise Computer Program) coordinated with that of another piece of equipment with a production rate.  HICNOM uses an analogous method to that of FHWA Highway Traffic Noise Prediction Model (as of 1982) for both the haul and non-haul line source calculations.  Area sources are defined by segments defining a centerline of the area and a width of the area at the specified segment points. The segments are analyzed separately and combined for the total level calculation. The excess attenuation for an area source is calculated by dividing the source into strips and calculating separately for each strip.  Barrier effects for point sources are calculated according to Maekawa's formulation for screens. Barrier effects for line sources are calculated according to the Kurze and Anderson formulation in which the effect of shielding is integrated for point sources along the line. Barrier effects for area sources are calculated for each strip separately, applying the line source method. Only one barrier per source-receiver geometry is incorporated.  Source height and frequency data are not used apart for barrier effect calculations. b. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with average information) First order approximation c. Theoretically-based (e.g., vehicle-specific with individual characteristics and theoretical propagation implemented) 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.)  Data is inputted through HINPUT, which asks the user for the inputs it needs. HICNOM then performs the acoustical calculations and produces the results.  A results report is automatically printed after the program is run. An input data file report can be requested by the user with a TYPE or PRINT command made external to the program. b. Operating system (e.g., MS-DOS, Windows, Linux, etc.) c. Software language (e.g., Fortran, C#.NET, etc.) FORTRAN IV d. Software structure (e.g., single exe, modularized components, preprocessors, etc.) The HICNOM code structure makes use of several subroutines. e. Distributed computing? (yes or no) Assumed no. f. Connectivity with other tools (e.g., AEDT-APMT linkage, etc.)

I-74 Model: HICNOM (Highway Construction Noise Computer Program) g. Hardware/additional software requirements 4. Database a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) Database includes 53 different types of equipment. The source type and model number are used to select a particular piece of equipment. b. What data is included? (e.g., NPD, EI, performance profiles, etc.)  Data for point, line, and area sources.  Categories of data that may be contained in the database include: Lmax, (dBA), Delta (dBA), Cycle Time (hrs), Capacity (cu. yds.), Acoustic Height (ft.), Acoustic Frequency (Hz), Reference Speed (mph), Slope, Critical Speed (mph). c. Robustness of data (i.e., fidelity and resolution of data d. Traceability (e.g., documented sources, acceptability, etc.) Most of the data in the model was gathered for the program's development, but some was obtained from a review of the literature. e. Publicly available Available in Volume 5 of the FHWA Highway Construction Noise Handbook, probably for price. 5. Usability a. General data requirements (e.g., readily available, easily found, considerable effort required, etc.) User must provide the number and coordinates of receivers, the excess attenuation rate from the source to each receiver, names and model numbers of equipment used, coordinates of points defining positions and geometries, the number and coordinates of barriers, and, potentially, the speed and hourly volume for haul operations, the type of turn-arounds for loops on haul roads, source activity data, and the noise level and operational data for user-defined equipment. b. Input flexibility (e.g., different resolution of data, user- defined sources, etc.) Allows for user-defined sources. These can be permanently entered into the database. c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.) User responds to data entry prompts by the program. d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) User's Manual b. Format (e.g., series of notes, hardcopies only, on-line, etc.) A pdf was prepared for this research, at a price. Hardcopies exist. 7. Validation and confidence use  Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results: a. Valid only in special cases b. Moderate Moderate. Measurements were made at three construction sites for Interstate 440 in Nashville, Tennessee and compared to predictions for model validation. Results of differences between measured and predicted levels were 2.7, 2.7, and 2.5 dB, with the model always underpredicting levels. Conclusion was that model

I-75 Model: HICNOM (Highway Construction Noise Computer Program) is accurate to the degree that input data assumptions are accurate. c. High 8. Outputs a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.) Predicts 8-hour equivalent sound levels (Leq(8h)) and the sound level and intensity contributions of each source. b. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) Overall spectrum, A-weighted. Uses representative frequencies for each source when calculating barrier effects. 9. Policy or requirements a. Is this a preferred or required model? b. Input restrictions (i.e., parameter limits) HICNOM can use up to 10 point sources, up to 6 line sources (defined by up to 10 points each), up to 5 area sources (defined by up to 10 centerline points and widths each), and up to 3 barriers (defined by up to 5 top edge points each). c. Limitations on application (i.e., scenario limits) Up to 10 receiver locations. Model: Horn Model 1. Overall Model Scope a. In public domain? If not, who is caretaker? Yes. Available at Federal Railroad Administration's <http://www.fra.dot.gov/us/content/254> b. Air quality or noise? Noise a. Noise: SI, SPL, or other? SPL c. Mode (highway, rail, water, air) Train horn d. Screening or detailed (intended categorization)? Screening e. Scales of analysis a. Noise (free field, long range propagation) Free field f. Regulatory use (e.g., NEPA assessments, etc.)? Evaluation of horn noise by FRA 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.)  Moving noise sources are modeled as line sources and propagation is assumed to take place over soft ground, resulting in an attenuation rate of 4.5 dB per doubling of distance (3 dB from divergence and 1.5 dB from ground effect).  Atmospheric effects are not incorporated.  Shielding from rows of buildings add a 3 dB attenuation for the first row (assumed to be at 200 feet from the tracks) and 1.5 dB for each additional row (assumed to be at 400, 600, 800, and 1000 feet from the tracks). b. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) Simple b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with average information)

I-76 Model: Horn Model c. Theoretically-based (e.g., vehicle-specific with individual characteristics and theoretical propagation implemented) 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.) Program is spreadsheet, inputs and outputs in XLS file b. Operating system (e.g., MS-DOS, Windows, Linux, etc.) Operating system that supports MS Excel c. Software language (e.g., Fortran, C#.NET, etc.) Spreadsheet d. Software structure (e.g., single exe, modularized components, preprocessors, etc.) Single spreadsheet e. Distributed computing? (yes or no) No f. Connectivity with other tools (e.g., AEDT-APMT linkage, etc.) No g. Hardware/additional software requirements MS Excel 4. Database a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) Train horn b. What data is included? (e.g., NPD, EI, performance profiles, etc.) User inputs Horn Lmax (dBA) @ 100 feet c. Robustness of data (i.e., fidelity and resolution of data Based on field measurements but average values used. d. Traceability (e.g., documented sources, acceptability, etc.) Field measurements at grade crossings from many railroads were used as the basis for the source reference. The reference level for the source is modeled as constant from 1/4 of a mile to 1/8 of a mile from the crossing and increases linearly from 1/8 of a mile to crossing. (This is because data shows the horn is sounded more continuously and more loudly as the train approaches the crossing.) e. Publicly available Yes 5. Usability a. General data requirements (e.g., readily available, easily found, considerable effort required, etc.) User must input parameters:  Noise situation (horns existing and future, horns in future only, no horns existing and future)  Horn Lmax (dBA) @ 100 feet  Horn location on locomotive (National Average: 50% front, 50% middle, all front mounted, all middle mounted, or used defined)  Non Train Noise Environment (Urban, suburban, rural, or used defined Ldn)  Shielding (Dense Urban, Light Urban, Dense Suburban, Light Suburban, Rural, No Shielding)  Length of Impact Area (1/4 mile, 20 seconds, 15 seconds)  Existing and future train speed (mph)  Number of existing and future trains in one direction

I-77 Model: Horn Model  Existing and future number of day trains (7am-10pm)  Existing and future number of night trains (10pm-7am)  Existing and future average number of cars  Existing and future average number of locomotives b. Input flexibility (e.g., different resolution of data, user- defined sources, etc.) User defines Lmax of the source c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.) Simple spreadsheet d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) Reliability assumed to be high because the Horn Model is not an intricate program. 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) Webpage on Horn Noise Questions and Answers: <http://www.fra.dot.gov/us/content/1173> Instructions sheet in spreadsheet b. Format (e.g., series of notes, hardcopies only, on-line, etc.) Webpage online 7. Validation and confidence use Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results: Has been used in multiple document but actual validation not listed. The original data taken from average of field measured data. a. Valid only in special cases b. Moderate c. High 8. Outputs a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.)  Existing and future 65 Ldn contour at crossing (in feet)  Existing and future 65 Ldn contour at 1/2 zone length (in feet)  Zone and 1/2 zone length (in feet)  Impact and severe impact distance at crossing (in feet)  Impact and sever impact distance at 1/2 zone length (in feet) b. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) Overall spectrum, A-weighted 9. Policy or requirements a. Is this a preferred or required model? Preferred by FRA. b. Input restrictions (i.e., parameter limits) Specified source with average values. General ground effects, shielding and divergence taken into account from input parameters. Limited to ¼ mile of crossing. c. Limitations on application (i.e., scenario limits) For use only of specific source.

I-78 Model: HSRNOISE (High-Speed Rail Initial Noise Evaluation) 1. Overall Model Scope a. In public domain? If not, who is caretaker? Yes (developed by HMMH). Available on the Federal Railroad Administration website. It can be downloaded at: <http://www.fra.dot.gov/us/content/167> b. Air quality or noise? Noise a. Noise: SI, SPL, or other? SPL c. Mode (highway, rail, water, air) Rail d. Screening or detailed (intended categorization)? Screening e. Scales of analysis a. Noise (free field, long range propagation) f. Regulatory use (e.g., NEPA assessments, etc.)? HSRNOISE uses the methods of Chapter 4 of the "High-Speed Ground Transportation Noise and Vibration Impact Assessment (FRA,1998). 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.) Simple equations are applied and corrections are made to reference levels provided for the three types of high-speed rail sources. Corrections are applied for attenuation of noise with distance and geometry, and shielding by intervening rows of buildings. b. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) Simple b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with average information) c. Theoretically-based (e.g., vehicle-specific with individual characteristics and theoretical propagation implemented) 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.) Program is spreadsheet, inputs and outputs in XLS file b. Operating system (e.g., MS-DOS, Windows, Linux, etc.) Operating system that supports MS Excel c. Software language (e.g., Fortran, C#.NET, etc.) Spreadsheet d. Software structure (e.g., single exe, modularized components, preprocessors, etc.) Single spreadsheet e. Distributed computing? (yes or no) No f. Connectivity with other tools (e.g., AEDT-APMT linkage, etc.) No g. Hardware/additional software requirements MS Excel 4. Database a. What sources are included? (e.g., number and types of  Train types: electric, fossil fueled, maglev

I-79 Model: HSRNOISE (High-Speed Rail Initial Noise Evaluation) vehicles, stationary source, etc.)  Track Geometries: tracks at grade, tracks in shallow cut, tracks in deep trench/cut, tracks on aerial structure, tracks on embankment, noise barrier. b. What data is included? (e.g., NPD, EI, performance profiles, etc.)  For each combination of train type and speed regime, the Reference SEL, Speed Coefficient, Reference Speed, Reference Length, and Transition Speed are provided.  For each combination of track geometry and speed regimes, a shielding correction is provided. c. Robustness of data (i.e., fidelity and resolution of data d. Traceability (e.g., documented sources, acceptability, etc.) e. Publicly available Yes, included with spreadsheet. 5. Usability a. General data requirements (e.g., readily available, easily found, considerable effort required, etc.) User inputs Land Use Category (Outdoor Quiet, Residences, or Institutional) of receiver, Receiver Data including distance to the track center line, and number of intervening building rows, and Train Data including train type (pick from list), speed, length of each power car, length of each passenger car, number of power cars in consist, number of passenger cars in consist, track geometry (pick from list), number of daytime trains, and number of nighttime trains. b. Input flexibility (e.g., different resolution of data, user- defined sources, etc.) Not very flexible--choose from predetermined options. c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.) Simple spreadsheet d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) Reliability assumed to be high because HSRNOISE is not an intricate program. 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) Description of HSRNOISE spreadsheet is provided as the first sheet of the spreadsheet. It outlines the purpose, implementation, and interpretation of the model. b. Format (e.g., series of notes, hardcopies only, on-line, etc.) Sheet within spreadsheet. 7. Validation and confidence use Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results: a. Valid only in special cases b. Moderate c. High 8. Outputs a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.) Ldn, daytime Leq, nighttime Leq, or peak hour Leq.

I-80 Model: HSRNOISE (High-Speed Rail Initial Noise Evaluation) b. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) Overall spectrum, A-weighted. 9. Policy or requirements a. Is this a preferred or required model? b. Input restrictions (i.e., parameter limits) One type of high-speed rail source. c. Limitations on application (i.e., scenario limits) One receiver. Model: IMMI 6.3.1 1. Overall Model Scope a. In public domain? If not, who is caretaker? No. It is a product of the German company, Wölfel Meßsysteme. There are 3 versions of IMMI: Standard, Plus, and Premium. b. Air quality or noise? Air quality and noise a. Air quality: emission or dispersion? Dispersion (for gaseous and odorous pollutants and dust) and emission. b. Noise: SI, SPL, or other? SPL c. Mode (highway, rail, water, air) Road, rail, air, industrial and recreational noise d. Screening or detailed (intended categorization)? Detailed e. Scales of analysis a. Air quality (e.g., microscale, regional, national, etc.) Maps can be calculated for projects of any scale b. Noise (free field, long range propagation) Maps can be calculated for projects of any scale f. Regulatory use (e.g., NEPA assessments, etc.)? IMMI complies with national and international (ISO/EU) noise calculation standards and with Austrian and German air pollution calculation standards. 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.) IMMI includes over 20 different noise calculation methods and 3 air dispersion modeling methods. Noise modeling effects such as reflections, diffraction, ground effect, geometric divergence, atmospheric absorption, and meteorological corrections are calculated according to the chosen calculation method. Road: o EU Interim Method: XP S 31-133/NMPB and Guide du Bruit o National methods: CRTN (UK), XP S 31-133 (France), RMW-SRMII (Netherlands), TemaNord 1996:525 (Nordic), StL-86 (Switzerland), RVS 3.02 (Austria), RLS-90 (Germany). Rail: o EU Interim Method: RMR-SRM II-1996 o National methods: CRN (UK), XP S 31-133 (France), RMR-SRM II (Netherlands), TemaNord 1996:524 (Nordic), SEMIBEL (Switzerland), ÖNorm S 5011 (Austria), SCHALL 03 (Germany) Industrial:

I-81 Model: IMMI 6.3.1 o EU Interim Method: ISO 9613-2 o National methods: Nordic Standard (Nordic), VDI 2714/2720/2571 (Germany), ISO 9613-1 & 9613-2 (International), BS 5228 (UK), ÖAL 28 (Austria) Aircraft: o EU Interim Method: ECAC.CEAC Doc. 29 1997 and Segmentation o National methods: ÖAL 24 (Austria), AzB/AzB-L (Germany), DIN 45684 IMMI uses a Gaussian air dispersion model, based on the German TA-Luft, Annex C of 1986. Point, line, and area sources are used for air pollution. IMMI can be equipped with the Lagrangian air dispersion model (using the external calculation module AUSTAL2000). Statistical meteorological data such as wind speed, wind direction, and stability classes are used for calculations The meteorological correction for long-term noise levels is calculated according to ISO 1996-2, where required. Average indoor levels are calculated according to a Sabine formula spreadsheet. b. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with average information) First order approximation c. Theoretically-based (e.g., vehicle-specific with individual characteristics and theoretical propagation implemented) 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.)  Measured spectra can be imported from text files or clipboard.  Noise maps can be exported to bitmaps and EMF vector graphics, DXF graphics formats, numeric text files, numeric dBase files, text and binary float raster data interface to ArcGIS applications (e.g. ArcView Spatial Analyst).  Numerical results can be exported to text, EXCEL, WORD, and RTF. b. Operating system (e.g., MS-DOS, Windows, Linux, etc.) Windows 32-bit c. Software language (e.g., Fortran, C#.NET, etc.) d. Software structure (e.g., single exe, modularized components, preprocessors, etc.) e. Distributed computing? (yes or no) Yes, with the AUDINOM option, IMMI accommodates distributed computing among several computers or within multi-core computers. A full license is

I-82 Model: IMMI 6.3.1 required for the "master" computer and one or several client licenses are required for the "slave" computers. f. Connectivity with other tools (e.g., AEDT-APMT linkage, etc.) GoogleEarth interface. Data interface with ArcView/ArcGIS (SHP) and MapInfo (MID/MIF). g. Hardware/additional software requirements 4. Database a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) IMMI includes a database of predefined airplanes and helicopters and allows user- defined aircraft. It also includes emission, transmission, and reflection spectra. Choices of databases exist for industrial, rail, building machinery, and recreation noise. b. What data is included? (e.g., NPD, EI, performance profiles, etc.) An Austro-German aircraft noise emission database, which is associated with the data-acquisition system for airports, is included with IMMI. c. Robustness of data (i.e., fidelity and resolution of data IMMI can calculate complete error statistics including confidence intervals, standard deviation and average, maximum and minimum error. A forecast feature can estimate the accuracy of results, in compliance with the latest release of DIN 45687 (quality assurance of noise mapping software packages). Air quality errors for concentration and deposition can be displayed graphically. d. Traceability (e.g., documented sources, acceptability, etc.) Databases include:  VDI 2571 (Industrial) and ÖAL 28 (Industrial and Rail)  VDI 3770 (Recreational activities)  Noise emission from building machinery HLUG, Heft 2  Saxonian study of noise from recreational activities  ÖAL 33 for gastronomy (assumed to be restaurants)  Sound forum for noise from industrial machinery e. Publicly available 5. Usability a. General data requirements (e.g., readily available, easily found, considerable effort required, etc.) b. Input flexibility (e.g., different resolution of data, user- defined sources, etc.) User can define grid mesh size, noise emission spectra and transmission loss databases. Spectra can be imported from and exported to Excel. c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.)  IMMI includes a 3D viewer with which the user can display noise maps, overlay noise maps, record AVI videos, define fixed flight paths, etc.  3D schemes can be drawn on-screen with the mouse.  IMMI can display 2D horizontal and vertical grids with noise contours d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) English Reference Manual, 2 volumes, over 600 pages. In addition, IMMI provides an online help system, manuals for aircraft noise, ESRI shape file and MapInfo MID/MIF data exchange interfaces, and air pollution calculation, and a

I-83 Model: IMMI 6.3.1 free service period and maintenance contracts covering hotline support and updates. b. Format (e.g., series of notes, hardcopies only, on-line, etc.) 7. Validation and confidence use Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results: Rasmussen claims it was "tested against all available test cases for the existing calculation methods." IMMI is certified for German aircraft noise calculation. a. Valid only in special cases b. Moderate c. High High 8. Outputs a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.) Noise: Leq, Lday, Levening, Lnight, Lden, LAmax, L10 Air Quality: Average and 50-99 percentiles of concentration and deposition can be calculated for gases and dust. Percentage of hours of a year with odor perception can be calculated for odors. and other sound or statistical indicators can be calculated depending on the calculation method employed. b. If air quality, what pollutants are covered? Using the Lagrangian air dispersion model, up to 45 pollutants are covered. c. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) Calculation in 1/3-octave bands for industrial noise. Calculation in octave bands for other source types if required by the calculation method. 9. Policy or requirements a. Is this a preferred or required model? Not required. b. Input restrictions (i.e., parameter limits) No limitation on the number of elements. c. Limitations on application (i.e., scenario limits) IMMI can use up to 25 orders of reflection. IMMI Standard can use up to 400,000 terrain nodes, 8001 by 8001 grid points, and 200 obstacles (each of which can have up to 500 nodes, allowing up to 99,800 horizontal diffracting edges). IMMI Plus can use up to 400,000 terrain nodes, 8001 by 8001 grid points, and 1000 obstacles (each of which can have up to 500 nodes, allowing up to 499,000 horizontal diffracting edges). IMMI Premium can use up to 4,000,000 terrain nodes, 40,001 by 40,001 grid points. Only the available RAM limits the number of obstacles.

I-84 Model: INM (Integrated Noise Model) 1. Overall Model Scope a. In public domain? If not, who is caretaker? Available for purchase ($300) to public. Developed and maintained by:  FAA Office of Environment and Energy (AEE-100)--project management  ATAC Corporation--system integration, user interface, and flight model  Volpe National Transportation Systems Center (VNTSC)--noise model b. Air quality or noise? Noise a. Noise: SI, SPL, or other? SPL c. Mode (highway, rail, water, air) Air d. Screening or detailed (intended categorization)? Detailed e. Scales of analysis a. Noise (free field, long range propagation) The scope of analysis is the terminal area. INM standard profiles start at 6,000 feet above the airport for approaches and end at 10,000 feet above the airport for departures. INM standard aircraft do not exist above these altitudes; consequently, no noise is produced. Sound exposure levels are calculated from NPD tables which range from 200 feet to 25000 feet. Extrapolation is performed beyond 25000 feet. Below 200 feet, 10Log is used for exposure-base noise metrics and 20Log is used for maximum noise metrics. f. Regulatory use (e.g., NEPA assessments, etc.)? Used for FAR Part 150 noise compatibility planning, FAR Part 161 approval of airport noise restrictions and, as stipulated by FAA Order 1050.1E, environmental assessments and environmental impact statements. 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.) Segmentation model incorporates spherical spreading, atmospheric absorption, terrain shielding, lateral attenuation, and ground effects. It is based on standards documents:  SAE-AIR-1845: "Procedure for the Calculation of Airplane Noise in the Vicinity of Airports"  SAE-AIR-5662: "Method for Predicting Lateral Attenuation of Airplane Noise"  SAE-ARP-866A: "Standard Values of Atmospheric Absorption as a Function of Temperature and Humidity"  ECAC Doc 29: "Report on Standard Method of Computing Noise Contours around Civil Airports"  ICAO Circular 205: "Recommended Method for Computing Noise Contours Around Airports"  HNM 2.2 integrated into INM, including additional adjustments applicable only to helicopters such as source noise due to advancing tip Mach Number, Lateral Directivity, static directivity, and static operation duration. a. Which category does the model fall into:

I-85 Model: INM (Integrated Noise Model) a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with average information) First order approximation c. Theoretically-based (e.g., vehicle- specific with individual characteristics and theoretical propagation implemented) 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.) Input files: DXF, Polyline TXT, Census 2000, and Radar Track CSV files, Census Tiger/Line data, 3CD/TX terrain data, GridFloat and DEM terrain data The format of most INM input and output files is dBase IV (DBF file extension) b. Operating system (e.g., MS-DOS, Windows, Linux, etc.) Windows 2000 or XP c. Software language (e.g., Fortran, C#.NET, etc.) C++ d. Software structure (e.g., single exe, modularized components, preprocessors, etc.) Modularized components e. Distributed computing? (yes or no) Yes. Has multi-threaded run mode that can make use of a PC's multiple cores by dividing calculations between cores to run in parallel for a given scenario. f. Connectivity with other tools (e.g., AEDT-APMT linkage, etc.) 3-tier Study/Scenario/Case input data structure that will be easier to integrate into AEDT g. Hardware/additional software requirements PC with minimum Pentium III processor hardware configuration 1.0-Gb RAM 4. Database a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) 3 aircraft types: Civil Airplanes, Military Airplanes, and Helicopters (over 250 fixed-wing aircraft includes commercial aircraft, military aircraft, small turboprop, and piston aircraft, 19 different helicopters) b. What data is included? (e.g., NPD, EI, performance profiles, etc.) NPD and performance data. Helicopter NPDs classified by operational mode (organized in categories of dynamic or static modes) rather than thrust/power setting. They come in sets of three for dynamic operational modes to represent the asymmetric directivity of helicopter noise, corresponding to noise levels directly below the helicopter and at angles of approximately 45 degrees to the left and right of the centerline. c. Robustness of data (i.e., fidelity and resolution of data Data complies with specifications and formats of SAE AIR 1845 and endorsed by ECAC d. Traceability (e.g., documented sources, acceptability, Data from most of the larger modern aircraft models is supplied by the

I-86 Model: INM (Integrated Noise Model) etc.) manufacturers and was acquired during noise certification tests carried out under internationally standardized procedures regulated by national certification agencies. Data from other aircraft was acquired from other sources like controlled tests carried out by national noise modeling agencies in various countries. The database specifies the source of the data and, possibly, more detailed information about the processes applied to derive the data for each listed aircraft. e. Publicly available NPD and performance data are available for free from Eurocontrol's Aircraft Noise and Performance (ANP) database at <http://www.aircraftnoisemodel.org> 5. Usability a. General data requirements (e.g., readily available, easily found, considerable effort required, etc.) Standard info on airport/heliport (e.g. runway position, airport elevation, etc.), terrain data file if terrain is to be used in noise computation, aircraft information (e.g. flight operation type, flight path, etc.), observer information (e.g. regular grid, location points, or irregular grid), noise metric information (e.g. metric identifier (DNL, SEL, etc.), low and high cutoff contour level (dB or minutes), etc.). Helicopter flight paths are not defined with flight tracks like fixed-wing aircraft. Data for helicopter procedure steps include: horizontal coordinate relative to an origin, altitude of the helicopter above the helipad, helicopter true airspeed at the point, helicopter operational mode, and time spent at the location for static operational modes. b. Input flexibility (e.g., different resolution of data, user- defined sources, etc.)  User can define own flight profiles, aircraft source noise data, and basic aircraft data.  User can specify grid resolution. c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.)  Menu of functions allows user to manage study, input data, run model and display results.  Interactive data entry in input windows  Interactive ground track data entry in graphics window  Option to import data from specially formatted text files  Direct edit of DBF input files in spreadsheet or database management program permitted.  Output charts, graphics, and tables displayed d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) Reliable. Any problems are resolved by the caretakers cited above. 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) User's guide, technical manual b. Format (e.g., series of notes, hardcopies only, on-line, etc.) CD-ROM with electronic copies of the User's Guide and Technical Manual, one paper User's Guide included with purchase 7. Validation and confidence use Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results:

I-87 Model: INM (Integrated Noise Model) a. Valid only in special cases b. Moderate Moderate c. High 8. Outputs a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.) A-Weighted Noise Metrics  SEL (A-Weighted Sound Exposure Level),  DNL (Day Night Average Sound Level),  CNEL (Community Noise Equivalent Level),  LAEQ (Equivalent Sound Level),  DDOSE (Change in Exposure),  LAMAX (A-Weighted Maximum Sound Level),  TALA and %TALA (Time-Above and Percent Time-Above),  TAUD and %TAUD (Time Audible and Percent Time Audible), C-Weighted Noise Metrics  CEXP (C-Weighted Sound Exposure Level),  LCMAX (C-Weighted Maximum Sound Level),  TALC and %TALC (Time-Above and Percent Time-Above), Tone-Corrected Preceived Noise Metrics  EPNL (Effective Perceived Noise Level),  NEF (Noise Exposure Forecast),  WECPNL (Weighted Equivalent Continuous Perceived Noise Level),  PNLTM (Tone-Corrected Maximum Perceived Noise Level),  TAPNL and %TAPNL (Time-Above and Percentage Time-Above) b. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) Displays overall spectrum. However, 1/3 octave band spectrums with frequencies of 50 to 10,000 Hz are used to calculate levels. 9. Policy or requirements a. Is this a preferred or required model? Required model per 14 CFR Part 150, 14 CFR Part 161, and FAA Order 1050.1E. b. Input restrictions (i.e., parameter limits) No limit with respect to airport layout or size, number of operations, or fleet mix, although INM's database is not as extensive for smaller aircraft. c. Limitations on application (i.e., scenario limits) INM is for use around single airports. NIRS is used for large-scale areas with multiple airports. INM designed to use average input data to estimate long-term average noise levels. It is not meant for single-event noise prediction.

I-88 Model: Lima™ 1. Overall Model Scope a. In public domain? If not, who is caretaker? No. It is the product of the German company Stapelfeldt Ingenieurgesellschaft. b. Air quality or noise? Air pollution and noise a. Air quality: emission or dispersion? Emission and dispersion b. Noise: SI, SPL, or other? SPL c. Mode (highway, rail, water, air) Road, rail, aircraft, industrial, sports, leisure, water traffic d. Screening or detailed (intended categorization)? Detailed e. Scales of analysis a. Air quality (e.g., microscale, regional, national, etc.) Maps can be calculated for projects of any scale b. Noise (free field, long range propagation) Maps can be calculated for projects of any scale f. Regulatory use (e.g., NEPA assessments, etc.)? 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.) Lima can use the noise calculation methods presented in any of the following standards and guidelines (as specified by the Mapping Software Catalogue spreadsheet):  Road Noise: RLS 90, VBUS, DIN 18005, RVS_3.02/RVS, NMPB/XPS31-133, CRTN, ISO9613, UT2.1-302  Rail Noise: Schall 03, VBUSCH, DIN 18005, AKUSTIK 04, TRANSRAPID, ÖAL 30/ÖNORM_S_5011, CRN, RLM2/SRM2, ISO9613, MSZ2904 XPS/FER  Aircraft Noise: AzB, VBUF, AzB-L, DIN 45684, LBF, ECAC DOC 29  Industrial Noise: VDI2714, VDI2720, VDI2571, ISO9613-2, ÖAL 28, DAL 32, Harmonoise, MSZ15036, DIN18005, VBUI, BS5228 Lima can include reflections up to the 10th order and sideways diffraction. Air pollution from road traffic or industrial sources can be calculated using the German regulation MLuS92, using VDI 3782, solving the 3D equation of compressible gas flow for up to 400 by 400 by 20 nodes using the program developed by Prof. Dr.-Ing. Schenk, Halle), or using the Canyon Plume Box (CPB) model with the program developed by IVU, Berlin. b. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with average information) First order approximation c. Theoretically-based (e.g., vehicle-specific with individual

I-89 Model: Lima™ characteristics and theoretical propagation implemented) 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.) Geometry inputs are done by digitizer, mouse, keyboard or data import. LimA has import tools for ARC INFO, ARC VIEW, SICAD SD, ALK GIAP, ATKIS, MAP INFO, ATLAS GIS, GRANIS, CITRA, EZSI, MOSS, DXF. Mouse input supported by PCX- or TIFF-maps, optionally. Can also import DXF, XML, VISUM, INM result, TNM result, MOSS, and B&K Measurement data. (Mapping software Catalogue spreadsheet) HPGL/HPGL-2 or POSTSCRIPT can be used for graphic output. Module data exchange can use ASCII text files. b. Operating system (e.g., MS-DOS, Windows, Linux, etc.) MS-DOS, Windows, Windows 9x, Windows NT, UNIX c. Software language (e.g., Fortran, C#.NET, etc.) FORTRAN d. Software structure (e.g., single exe, modularized components, preprocessors, etc.) Modularized components e. Distributed computing? (yes or no) Comment made in Mapping Software Catalogue spreadsheet implies that there is. f. Connectivity with other tools (e.g., AEDT-APMT linkage, etc.) Can be combined with SAIL II in order to use scanned maps for digitizing and result presentation. Lima can be embedded in GIS using LimAarc (as stated in the Mapping Software Catalogue spreadsheet) g. Hardware/additional software requirements 4. Database a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) 11 different types of emitter such as road traffic, railway traffic, industrial noise, sports, etc. b. What data is included? (e.g., NPD, EI, performance profiles, etc.) c. Robustness of data (i.e., fidelity and resolution of data d. Traceability (e.g., documented sources, acceptability, etc.) e. Publicly available 5. Usability a. General data requirements (e.g., readily available, easily found, considerable effort required, etc.)  Geometric data can be imported and LimA will automatically close any gaps in data derived from aerial surveys.  Objects that can be included are: o Natural obstacles (contour lines, punctual altitude information, break edges (quarries, etc.), embankments, gridnet altitude information, woods) o Artificial obstacles (screens, areas of average attenuation, cantilever roofs, buildings, roofs, bridges)

I-90 Model: Lima™ o Emitting objects (punctual emission source, line emission source, area emission source, vertical area emission source, moveable point source) o Special objects (traffic lights, areas of restriction for maximum noise level, graphic symbols, survey points, economic areas, planning zones) b. Input flexibility (e.g., different resolution of data, user- defined sources, etc.) One approach available in LIMA for aircraft noise allows the definition of point sources with time dependent intensity, directivity pattern, positioning, and width and height of flight corridors. c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.) Entering geometry input is done by digitizer, mouse, keyboard, or data import. 3D visualization, 10 forms of tabular result documentation and a variety of forms of graphic outputs. d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) b. Format (e.g., series of notes, hardcopies only, on-line, etc.) 7. Validation and confidence use  Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results: a. Valid only in special cases b. Moderate c. High High. Benchmarked with all published official test cases (as stated in the Mapping Software Catalogue spreadsheet) 8. Outputs a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.) Lden, Lnight, Leq 24 based on Lday, evening and night, L10, LASmax, LAZ, LAX, SEL for aircraft noise and moving point sources, total annoyance. b. If air quality, what pollutants are covered? c. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) Calculated in average frequency or octave bands. 9. Policy or requirements a. Is this a preferred or required model? Not required. b. Input restrictions (i.e., parameter limits) No software-imposed limitation on number of elements c. Limitations on application (i.e., scenario limits) Number of emitting elements and obstacles is limited by computer memory. A standard configuration of approximately 250,000 line elements can be used 32 MB RAM. Noise levels can be calculated for grids of 32,000 by 32,000 points.

I-91 Model: NIRS (Noise Integrated Routing System) 1. Overall Model Scope a. In public domain? If not, who is caretaker? NIRS is the FAA's standard regional noise model and can be purchased from the distributor, Metron Aviation. NIRS Screening Tool (NST) may only be used by FAA employees b. Air quality or noise? Noise a. Noise: SI, SPL, or other? SPL c. Mode (highway, rail, water, air) Air d. Screening or detailed (intended categorization)? Detailed. Another tool, the NIRS Screening Tool (NST), is used for simple air traffic changes, such as aircraft route, aircraft altitude, aircraft mix, number of operations, time of day or operational procedures, at altitudes above 3,000 feet over noise sensitive areas. e. Scales of analysis a. Noise (free field, long range propagation) Long range propagation. NIRS was designed to be used over broad areas with multiple airports. f. Regulatory use (e.g., NEPA assessments, etc.)? As stipulated in FAA Order 1050.1E, NIRS is to be used when noise is assessed in areas larger than the immediate vicinity of an airport, when multiple airports are involved, or when actions being considered are at altitudes above 3,000 feet AGL. NIRS is then used to determine noise impacts at altitudes up to 10,000 feet AGL. NIRS is also one of the models used to assess the significance of proposed changes affecting the level of aviation noise. 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.) NIRS is based on the same noise computation algorithms as INM. b. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with average information) First order approximation c. Theoretically-based (e.g., vehicle-specific with individual characteristics and theoretical propagation implemented) 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.) NIRS organizes applications as projects, which contain all input files, output files, reports, and graphics. NIRS organizes projects in a directory/file structure with the project files being a mix of ASCII and XML text, binary, and JPEG/GIF. b. Operating system (e.g., MS-DOS, Windows, Linux, etc.)  Linux RedHat 9.0 or greater, an equivalent Linux distribution, or Microsoft Windows XP SP2 or greater c. Software language (e.g., Fortran, C#.NET, etc.)  Java & C++

I-92 Model: NIRS (Noise Integrated Routing System) d. Software structure (e.g., single exe, modularized components, preprocessors, etc.)  Multi executable, project level management  Single Java executable wrapping several C++ executables with access to a dozen or so data files. e. Distributed computing? (yes or no)  Yes f. Connectivity with other tools (e.g., AEDT-APMT linkage, etc.)  Intended to work with other Air Traffic modeling systems that provide information on source of routes, events, and Air Traffic procedures (e.g. altitude restrictions)  Can import SDAT traffic files and TIGER population files.  Capabilities to be integrated with AEDT g. Hardware/additional software requirements  PC compatible computer  512 MB RAM  4 MB to install software  100-2000 MB or more of disk space for projects, depending on project size. 4. Database a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) Same as INM: 3 aircraft types: Civil Airplanes, Military Airplanes, and Helicopters b. What data is included? (e.g., NPD, EI, performance profiles, etc.) Same as INM: NPD, performance profile data c. Robustness of data (i.e., fidelity and resolution of data Same as INM: Data complies with specifications and formats of SAE AIR 1845 and endorsed by EC d. Traceability (e.g., documented sources, acceptability, etc.) Same as INM: Data from most of the larger modern aircraft models is supplied by the manufacturers and was acquired during noise certification tests carried out under internationally standardized procedures regulated by national certification agencies. Data from other aircraft was acquired from other sources like controlled tests carried out by national noise modeling agencies in various countries. The database specifies the source of the data and, possibly, more detailed informatio about the processes applied to derive the data for each listed aircraft. e. Publicly available Same as INM: NPD and performance data are available for free from ICAO's Aircraft Noise and Performance (ANP) database at <http://www.aircraftnoisemodel.org/> 5. Usability a. General data requirements (e.g., readily available, easily found, considerable effort required, etc.) Inputs include: runway data, population census data, grid data, scenarios or design alternatives, airspace routes, traffic files. b. Input flexibility (e.g., different resolution of data, user- defined sources, etc.) User can define a flight track in three-dimensions or use "standard" profiles that are consistent with the airspace design. NIRS can mix traffic from different operational configurations to appropriately represent average annual airspace and runway use c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.) From the main window interface, the user can: build and organize a study, error check all inputs and outputs, perform noise computation, analyze impacts and

I-93 Model: NIRS (Noise Integrated Routing System) trace their causes, format the output for reports and graphics that can be used in Word, Excel or Powerpoint. d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) Same as INM 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) Thompson, T, et al., Noise Integrated Routing System User's Guide -Version 7.0, Metron Aviation, Inc., October 2008. Available with distribution of software. b. Format (e.g., series of notes, hardcopies only, on-line, etc.) PDF 7. Validation and confidence use Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results: a. Valid only in special cases b. Moderate c. High High. Similar to INM: A detailed validation and verification process comparing INM and NIRS results is performed for each release of NIRS. 8. Outputs a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.) NIRS produces population impact and change-of-exposure reports and graphics and can determine which traffic elements are causing significant noise impacts. Change-of-exposure tables and maps use the criteria of plus or minus 1.5 dB for DNL greater than 65, plus or minus 3 dB for DNL between 60 and 65 dB and plus or minus 5 dB for DNL between 45 and 60 dB. Additionally, NIRS can output noise maps for population and grids over all 16 INM metrics. b. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) Same as INM: Displays overall spectrum. However, 1/3 octave band spectrums with frequencies of 50 to 10,000 Hz are used to calculate levels. 9. Policy or requirements a. Is this a preferred or required model? Required. b. Input restrictions (i.e., parameter limits) Realistic input parameters should be acceptable and produce reasonable results c. Limitations on application (i.e., scenario limits) NIRS is meant to be a large-scale model involving multiple airports as opposed to INM, which is meant to be used for noise assessments around a single airport

I-94 Model: NOISEMAP 1. Overall Model Scope a. In public domain? If not, who is caretaker? The basic version of NOISEMAP can be freely downloaded at www.wasmerconsulting.com‚Äîbaseops.htm. <http://www.wasmerconsulting.com/baseops.htm.> and used and distributed as acknowledgement-ware meaning that Wasmer Consulting must be acknowledged as the author. The Air Force Research Laboratory (AFRL/RHCB) oversees its development and maintenance. b. Air quality or noise? Noise a. Noise: SI, SPL, or other? SPL c. Mode (highway, rail, water, air) Air d. Screening or detailed (intended categorization)? Detailed analysis for Environmental Impact Statements e. Scales of analysis a. Noise (free field, long range propagation) Far field noise propagated long distances with rudimentary terrain effects f. Regulatory use (e.g., microscale, regional, national, etc.) The noise contours produced are used by base planners for on-base sitting and to advise local communities through the Air Installation Compatible Use Zone (AICUZ) program, encouraging development that protects airbase operational mission requirements. 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation)  Whereas INM flight tracks are point-to-point tracks, NOISEMAP flight tracks are represented as vectors.  NMAP is the NOISEMAP component that propagates the sound and calculates the noise contours.  2 ground impedances: hard (effective flow resistivity = 1,000,000 kNs/m^4) or soft (effective flow resistivity = 200 kNs/m^4)  Can use hard ground, soft ground, or a combination of the two.  Terrain can be flat, a valley, or a hill (wedge or wall). Based off approximation Maekawa and Rasmussen algorithms for shielding and diffraction effects. Integrated models such as INM and Noise map cannot handle anisotropic effects such as weather and terrain properly.  Monthly average temperature, relative humidity and atmospheric pressure used to calculate atmospheric absorption. a. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with First order approximation

I-95 Model: NOISEMAP average information) c. Theoretically-based (e.g., vehicle- specific with individual characteristics and theoretical propagation implemented) 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.)  Cases stored in BASEOPS file. Can also edit flight operations in Excel spreadsheet (XML).  2 files to compute noise exposure from aircraft operating on multiple flight tracks: o RUN files: contain specifications for execution of noise model o OPX files: contain descriptions of flight and run-up events  OPX files (and most other files) in NMAP 7 are ASCII  Display background maps can be stored as: o ARC/INFO Shapefile (SHP) o Digital Line Graph (DLG) o AutoCAD Data Exchange Format (DXF) o Georeferenced Bitmap (BMP, TIF, JPG, PNG) o Compressed ARC Digitized Rater Graphics (CADRG) b. Operating system (e.g., MS-DOS, Windows, Linux, etc.) Windows XP or Vista c. Software language (e.g., Fortran, C#.NET, etc.) FORTRAN? (NMAP is in FORTRAN) d. Software structure (e.g., single exe, modularized components, preprocessors, etc.) 3 Fundamental components: BASEOPS (input), NMAP (modeling), and NMPLOT (output). e. Distributed computing? (yes or no) No f. Connectivity with other tools (e.g., AEDT-APMT linkage, etc.) Can use RNM instead of NMAP to calculate noise from helicopters if RNM is installed. INM cases can be imported, but should be carefully checked to make sure no changes in the case where caused by importing. BaseOps exports noise level contours to a ARC/INFO Shapefile Noise level contours can be imported into a third-party Geographic Information System (GIS) as most GIS's can import shapefiles. g. Hardware/additional software requirements Processor--1.0 GHz Pentium Memory--512 MB Monitor--64,000 colors (i.e. 16-bit color), resolution of 1024x768 Hard Drive Space--50 MB 4. Database a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) Large number of aircraft preprogrammed in with different engine options. Number of variations on 4 types of flight tracks: arrival, departure, closed pattern,

I-96 Model: NOISEMAP and interfacility All reference noise data normalized to airspeed of 160 knots and sea level conditions. b. What data is included? (e.g., NPD, EI, performance profiles, etc.) Major data files are:  Flight01.dat: database of flyover spectral sound power levels for many aircraft, power settings, and airspeeds.  INM10SEL.dat: dataset of SEL versus distance for several INM aircraft.  Static01.dat: database of static spectral sound power levels for many aircraft and power settings for runups. Data appears to be in the form of NPD curves Hemisphere files for new aircraft in RNM can be used c. Robustness of data (i.e., fidelity and resolution of data Flight Data is provided as integrated metrics and a spectrum for the angle of maximum noise relative to the aircraft. Static runup data is provided on a circle around the vehicle as a function of third octave band – generally 50 to 5,000 Hz d. Traceability (e.g., documented sources, acceptability, etc.) Has been accepted as the standard for environmental impact statements for military bases for the past few decades e. Publicly available Available with NOISEMAP, which is publicly available 5. Usability a. General data requirements (e.g., readily available, easily found, considerable effort required, etc.) Standard inputs including information like flight track, engine, engine power setting, etc. RNM aircraft may require additional information like yaw angle, angle of attack, roll angles, and nacelle angle. If actual flight profile is unknown, a standard flight profile for the aircraft may be selected from a library in BaseOps b. Input flexibility (e.g., different resolution of data, user- defined sources, etc.)  User can create higher resolution contours with finer grid spacing around an area of interest.  Runways, flight tracks, flight profiles, etc. all have editable options.  If desired aircraft not included in standard aircraft library, user can define an aircraft substitution, using an aircraft in the library as an equivalent proxy.  Different scenarios can be defined in a single case allowing, for example, a different number of flight profile operations or static profiles. When case is run, noise data calculated for each scenario.  User can save own flight profiles to the standard profile library. c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.)  BaseOps is used for inputs. It has 3 panes: list, text, and map.  List pane has object type selector (to choose object type like runways, flight tracks, etc.) and object list (which displays all objects of the selected type).  Text pane displays properties of object selected in list pane and allows editing of those properties.  Map pane displays graphical representation of the object selected in list pane with which user can interact. User can draw flight tracks over map. d. Reliability (e.g., software bugs, technical errors,  NMAP 7.0 implements runway displacement incorrectly, shifting the entire

I-97 Model: NOISEMAP implementation issues, etc.) flight track down the runway instead of shifting the flight profile points along the flight track.  Typical INM cases will include information that BaseOps can't import. Therefore, imported cases must be carefully checked.  Computation time can increase by an order of magnitude when using topography option. 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) User's guides for BaseOps, NMAP, and NMPlot are all available within the download for the NOISEMAP program. b. Format (e.g., series of notes, hardcopies only, on-line, etc.) The user's guides for BaseOps and NMPlot are available in the Help menus of the programs. The NMAP user's guide is available as a Word document in the NMAP folder. The BaseOps and NMPlot user's guides can also be downloaded as a PDF or Plain Text file from <http://www.wasmerconsulting.com/baseops.htm> and <http://wasmerconsulting.com/nmplot.htm>, respectively. The NMAP User's guide can be downloaded from the Defense Technical Information Center at <http://oai.dtic.mil/oai/oai?&verb=getRecord&metadataPrefix=html&identifier=A DA406645>. 7. Validation and confidence use Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results: a. Valid only in special cases b. Moderate Moderate. Topography and surface noise models, developed under a joint NATO research project, were validated with measurements made in Narvik Norway c. High 8. Outputs a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, one hour average, annual average, etc.) CNEL, DNL, LEQ, NEF, WECPNL Days can be split into day and night or day, evening and night. b. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) Displays overall spectrum. However, Noisefile Flight Data in FLIGHT01.dat contains data as mean SPL levels in dB for frequency bands 10 through 40. Noisefile Static Data in STATIC01.dat contains data SPL levels for 19 angles from 0 to 180 degrees for frequency bands 10 through 40. 9. Policy or requirements a. Is this a preferred or required model? It is required to use Noisemap as the program in use to model noise exposure near military air bases caused by flights and engine runups. b. Input restrictions (i.e., parameter limits) Realistic input parameters should be acceptable and produce reasonable results c. Limitations on application (i.e., scenario limits) Meant to calculate many different scenarios involving noise calculations surrounding military air bases

I-98 Model: RCNM (Roadway Construction Noise Model) 1. Overall Model Scope a. In public domain? If not, who is caretaker? Yes, it is the Federal Highway Administration's (FHWA) national model and can be downloaded at: http://www.fhwa.dot.gov/environment/noise/cnstr_ns.htm b. Air quality or noise? Noise a. Noise: SI, SPL, or other? SPL c. Mode (highway, rail, water, air) Construction d. Screening or detailed (intended categorization)? Screening e. Scales of analysis a. Noise (free field, long range propagation) Intended for use in the vicinity of construction site (say, within 500 ft). Lmax levels measured from specific types of equipment are used in conjunction with geometrical spreading and user-determined shielding effects and usage factors (% time equipment is used at full power during a construction operation) to determined a received sound level at a user-defined distance from the construction equipment. f. Regulatory use (e.g., NEPA assessments, etc.)? Construction noise must be considered under regulations, RCNM is not required to be used on a federal level, but some states or cities are adopting use of RCNM in their noise specifications for construction projects. 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.) The RCNM algorithms are based on the primary equation from the CA/T Construction Noise Control Specification 721.560.  Lmax is calculated as the appropriate Lmax value for a specific piece of equipment at a distance of 50 feet minus 20log of the actual distance from the receiver to the source divided by 50 feet, minus a shielding term, which is the insertion loss of any barriers or mitigation.  Leq is calculated as the calculated Lmax value plus 10log of the time- averaging equipment usage factor (the percentage of time during an operation that a piece of equipment is used at full power)  L10 is calculated as the Leq plus a 3 dBA adjustment factor which was empirically derived by comparing CA/T construction noise data.  The total sound levels are logarithmic sums of the individual equipment sound level values, except for the Total Lmax, which is the maximum among the individual equipment Lmax values.  Some simplified shielding factors for use in the RCNM are presented in Appendix A of the User's Guide. b. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) Simple b. First order approximation (e.g., partial vehicle

I-99 Model: RCNM (Roadway Construction Noise Model) data and propagation simplifications supplemented with average information) c. Theoretically-based (e.g., vehicle-specific with individual characteristics and theoretical propagation implemented) 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.) Results are presented in a read-only spreadsheet Input information and results can be exported to a comma separated value (CSV) or text (TXT) file. Results can be saved for one or all receptors in the case. b. Operating system (e.g., MS-DOS, Windows, Linux, etc.) Windows 98 or newer. c. Software language (e.g., Fortran, C#.NET, etc.) Visual Basic 6 d. Software structure (e.g., single exe, modularized components, preprocessors, etc.) Single exe e. Distributed computing? (yes or no) No f. Connectivity with other tools (e.g., AEDT-APMT linkage, etc.) No g. Hardware/additional software requirements 192 MB or more RAM 1024x768 pixels or greater display setting Adobe Acrobat 4.0 or newer 4. Database a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) 57 different equipment sources with noise emissions and acoustical usage factors. b. What data is included? (e.g., NPD, EI, performance profiles, etc.) Acoustical Use Factor [%], Spec (specifications) Lmax @50 ft [dBA], Actual Measurement Lmax @50 ft [dBA] c. Robustness of data (i.e., fidelity and resolution of data Database from hundreds of pieces of equipment measured on CA/T project. d. Traceability (e.g., documented sources, acceptability, etc.) RCNM uses the data spreadsheet developed as a part of the Central Artery/Tunnel (CA/T) project (in Boston) noise control program. The spreadsheet originated from noise level work by the Environmental Protection Agency (EPA) and an Empire State Electric Energy Research Corp. Guide. The number of samples averaged together to computer the "Actual" emission level is given in the spreadsheet. e. Publicly available Yes. The spreadsheet is provided in the User's guide and the data is available in the program. 5. Usability a. General data requirements (e.g., readily available, easily found, considerable effort required, etc.) User must inputs receptor data, type of equipment, distance to receptor, and any estimated shielding. If comparison with noise limit is desired, user can input the noise limit criteria or use default settings. b. Input flexibility (e.g., different resolution of data, user- User can specify whether equipment is an impact device, the usage factor, and the

I-100 Model: RCNM (Roadway Construction Noise Model) defined sources, etc.) Lmax level (spec or actual measurement) if desired inputs are different than default values. c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.) The RCNM consists of one main display with sections for inputs and results in which the user employs command buttons and pull-down menus to adjust input data and descriptions d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) Reliability assumed to be high because RCNM is not an intricate program. 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) User's guide at: <http://www.catseyeservices.com/Handbooks/cd/references/083- Construction%20Noise%20Model_UserGuide.pdf b. Format (e.g., series of notes, hardcopies only, on-line, etc.) PDF online. A copy also downloads with the program. 7. Validation and confidence use Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results: a. Valid only in special cases b. Moderate c. High RCNM has not gone through a formal validation process, however, the CA/T spreadsheet, upon which RCNM is based, was used throughout the CA/T project, and results were shown to be good within 500 ft of the construction. The limitations are based on: 1) RCNM does not account for ground conditions and weather effects, 2) L10 predictions are only as good as the assumed usage factors, and 3) the shielding effects are only as good as the user estimates them. 8. Outputs a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.) Lmax, Leq, and L10, Daytime Lmax, Leq, and L10 Exceedance, Evening Lmax, Leq, and L10 Exceedance, and Nighttime Lmax, Leq, and L10 Exceedance. (Exceedance metrics involve the difference between the sound level quantity and the sound level quantity limit.) b. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) Overall spectrum, A-weighted 9. Policy or requirements a. Is this a preferred or required model? RCNM is not required to be used on Federal-aid projects; however this model is a screening tool that can be used for the prediction of construction noise during the various stages of project development and construction. For a more complex analysis HICNOM may be more appropriate. b. Input restrictions (i.e., parameter limits) Up to 20 pieces of equipment (either unique or repeated) can be analyzed at a time. c. Limitations on application (i.e., scenario limits) Receptors may be placed at any distance form construction activities. Only one receptor can be processed at a time Up to 100 receptors can be included in one case

I-101 Model: TNM (Traffic Noise Model) 1. Overall Model Scope a. In public domain? If not, who is caretaker? Yes, but purchase required through McTrans. (http://mctrans.ce.ufl.edu/store/description.asp?itemID=417) b. Air quality or noise? Noise. a. Air quality: emission or dispersion? N/A b. Noise: SI, SPL, or other? SPL, A-weighted (LAeq1hr, Ldn, Lden c. Mode (highway, rail, water, air) ) Highway. d. Screening or detailed (intended categorization)? Detailed. However, simplified lookup table available in computer or paper format. e. Scales of analysis a. Air quality (e.g., microscale, regional, national, etc.) N/A b. Noise (free field, long range propagation) Free field with increased error occurring over 2000 feet. f. Regulatory use (e.g., NEPA assessments, etc.)? Required (or model with similar acoustic algorithms) by 23CFR772. 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.) Applied ray acoustics. Reference Energy Mean Emission Levels are adjusted for propagation considering geometric spreading, ground effects, diffraction, vegetation, and atmospheric absorption. In a subroutine, absorption of hard surfaces can also be evaluated. Works in one-third octave bands but reports in A- weighted values. b. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with average information) c. Theoretically-based (e.g., vehicle-specific with individual characteristics and theoretical propagation implemented) Closest to theoretical-based although first order approximation techniques are applied as well. 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.) Requires input through GUI and forms a working database. Output can be generated in ASCII files but GUI required. b. Operating system (e.g., MS-DOS, Windows, Linux, etc.) Windows 95/98/ME/NT4/2000/XP. c. Software language (e.g., Fortran, C#.NET, etc.) Proprietary modular software with executable core program. d. Software structure (e.g., single exe, modularized components, preprocessors, etc.) Modularized components with central core executable program and DLL files. e. Distributed computing? (yes or no) No. Not as designed. f. Connectivity with other tools (e.g., AEDT-APMT No direct linkage.

I-102 Model: TNM (Traffic Noise Model) linkage, etc.) g. Hardware/additional software requirements IBM compatible PC with Pentium processor and above recommended. Can be used with digitizing table. 4. Database a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) 5 motor vehicle types (Autos, medium trucks, heavy trucks, buses, and motorcycles.) b. What data is included? (e.g., NPD, EI, performance profiles, etc.) Reference Energy Mean Emission Levels for all 5 vehicle types by speed and mode (cruise and acceleration). c. Robustness of data (i.e., fidelity and resolution of data Database from over 6000 measurements in 9 states. d. Traceability (e.g., documented sources, acceptability, etc.) Data reported in document: Fleming, G.G, A. Rapoza, C. Lee, Development of National Reference Energy Mean Emission Levels for the FHWA Traffic Noise Model, Report No. FHWA-PD-96-093, Volpe National Transportation Systems Center, Cambridge, MA, 1994. e. Publicly available Yes. Although program must be purchased. 5. Usability a. General data requirements (e.g., readily available, easily found, considerable effort required, etc.) Highway data including roadway/path/receiver geometry, traffic volumes/speeds/vehicle type, ground type. b. Input flexibility (e.g., different resolution of data, user- defined sources, etc.) Little flexibility in input data. Metric/English. Creation of user-defined vehicles possible but not trivial. c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.) Straight forward graphical or spreadsheet entry. d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) Minor problems in Version 2.5, including some diffraction problems for various objects, incorrect calculation of Lden , and some geometry problems. 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) Complete with user guide (Anderson, G.S., C.S.Y. Lee, G.G. Fleming, and C.W. Menge, FHWA Traffic Noise Model , Version 1.0, User’s Guide, FHWA-PD-96- 009, U.S. DOT, Washington, D.C., Jan. 1998) and technical guide (Menge, C.W., C.F. Rossano, G.S. Anderson, and C.J. Bajdek, FHWA Traffic Noise Model , Version 1.0, Technical Manual, FHWA-PD-96-010, U.S. DOT, Washington, D.C., Feb. 1998.) Updates for later versions posted to internet. b. Format (e.g., series of notes, hardcopies only, on-line, etc.) Hard copy. 7. Validation and confidence use Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results: a. Valid only in special cases b. Moderate c. High High. Validation indicates good results for areas in the immediate vicinity of highway.

I-103 Model: TNM (Traffic Noise Model) 8. Outputs a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.) LAeq1hr, Ldn, Lden b. If air quality, what pollutants are covered? . N/A c. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) A-weight reported (computed from octave bands). 9. Policy or requirements a. Is this a preferred or required model? Required by 23CFR772 or equivalent. b. Input restrictions (i.e., parameter limits) Limited to use in urban highway environments. c. Limitations on application (i.e., scenario limits) In close proximity to highway.

I-104 I.3. Models that do Both Noise and Air Quality Model: AEDT/EDMS (Aviation Environmental Design Tool – Emissions and Dispersion Model System Component) 1. Overall Model Scope a. In public domain? If not, who is caretaker? Not in public domain. FAA/AEE is caretaker. b. Air quality or noise? a. Air quality: emissions or dispersion? Both b. Noise: SI, SPL, or other? c. Mode (highway, rail, water, air) Aviation – air and ground (vehicles) d. Screening or detailed (intended categorization)? Intended for detailed analysis, but some screening can be accomplished by the details inherent in the input data. e. Scales of analysis a. Air quality (e.g., microscale, regional, national, etc.) Currently, microscale to regional. b. Noise (free field, long range propagation) f. Regulatory use (e.g., NEPA assessments, etc.)? All emissions and air quality evaluations at airports including those related to NEPA. 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.) BFFM2, BADA, AERMOD, MOBILE b. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) Combination of all three. Simple for some emission factors (e.g., stationary sources), first-order for GAV emissions, and theoretically-based for BFFM2 and BADA. b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with average information) c. Theoretically-based (e.g., vehicle-specific with individual characteristics and theoretical propagation implemented) 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.) Currently uses dbf files but will use SQL database under AEDT. b. Operating system (e.g., MS-DOS, Windows, Linux, etc.) Currently Windows, but potential for others under AEDT depending on how modules are used. c. Software language (e.g., Fortran, C#.NET, etc.) Currently based on Visual C++ but will be C# .NET under AEDT. EPA modules are Fortran. d. Software structure (e.g., single exe, modularized components, preprocessors, etc.) Various exes in various stages of aggregation under an integrated environment with the GUI. Under AEDT, it will be highly modularized. e. Distributed computing? (yes or no) Not currently, but expected under AEDT f. Connectivity with other tools (e.g., AEDT-APMT Built in connections to EPA models and will have APMT linkage under AEDT.

I-105 Model: AEDT/EDMS (Aviation Environmental Design Tool – Emissions and Dispersion Model System Component) linkage, etc.) g. Hardware/additional software requirements Will run on any windows machine but will need high-end machine for detailed modeling. 4. Database a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) Aircraft, GAVs, GSEs, APUs, Stationary sources (e.g., power plants, paining, degreasing, etc.). b. What data is included? (e.g., NPD, EI, performance profiles, etc.) Aircraft performance, aircraft emissions, aircraft-engine matches, MOBILE6.2 emission factor. c. Robustness of data (i.e., fidelity and resolution of data Segment-level resolution for aircraft emissions allows different aggregation levels. Also, flexibility in how aircraft movements’ information can be input. The MOBILE data is pre-developed and cannot be readily changed, but MOBILE can be run externally to generate new data. d. Traceability (e.g., documented sources, acceptability, etc.) All data are well-documented. e. Publicly available All data are publicly available except for the BADA data which requires permission from Eurocontrol. Future developments under AEDT may not require the use of BADA. 5. Usability a. General data requirements (e.g., readily available, easily found, considerable effort required, etc.) Some work required, but data is generally available. b. Input flexibility (e.g., different resolution of data, user- defined sources, etc.) Some flexibility for aircraft movements data input and ability to generate vehicle emission factors externally. c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.) Relatively easy to understand. d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) Software is currently well developed and mature. New software under AEDT may need to be refined. 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) Complete b. Format (e.g., series of notes, hardcopies only, on-line, etc.) Electronic and on-line 7. Validation and confidence use Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results: a. Valid only in special cases b. Moderate Moderate to high for emissions. Currently unclear for atmospheric concentrations since there have been very little validation work using measured data for airport sources. c. High 8. Outputs

I-106 Model: AEDT/EDMS (Aviation Environmental Design Tool – Emissions and Dispersion Model System Component) a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.) Emissions are in mass per time (e.g., metric tons per year) and concentrations are in μg/m3. b. If air quality, what pollutants are covered? CO2, CO, THC, NMHC, VOC, TOG, NOx, SOx, PM2.5, PM10, and 395 speciated hydrocarbons. c. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) 9. Policy or requirements a. Is this a preferred or required model? This is the FAA required model. b. Input restrictions (i.e., parameter limits) Based each modules limits. c. Limitations on application (i.e., scenario limits) Only airports and below mixing height.

I-107 Model: AEDT/SAGE (- System for Assessing Global Emissions Component) 1. Overall Model Scope a. In public domain? If not, who is caretaker? Not in public domain and FAA/AEE is caretaker. b. Air quality or noise? a. Air quality: emissions or dispersion? Only aircraft emissions b. Noise: SI, SPL, or other? c. Mode (highway, rail, water, air) Aviation – air only d. Screening or detailed (intended categorization)? Detailed e. Scales of analysis a. Air quality (e.g., microscale, regional, national, etc.) National and global b. Noise (free field, long range propagation) f. Regulatory use (e.g., NEPA assessments, etc.)? Not for regulation, but for national policy 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.) Emissions (BFFM2), Aircraft performance (BADA), and delay (WWWLMINET) b. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with average information) c. Theoretically-based (e.g., vehicle-specific with individual characteristics and theoretical propagation implemented) Mostly theoretical but some mix of others as well. 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.) SQL database b. Operating system (e.g., MS-DOS, Windows, Linux, etc.) Windows c. Software language (e.g., Fortran, C#.NET, etc.) C#.NET d. Software structure (e.g., single exe, modularized components, preprocessors, etc.) Modularized DLLs, preprocessors, etc. e. Distributed computing? (yes or no) Yes f. Connectivity with other tools (e.g., AEDT-APMT linkage, etc.) Some linkage with APMT planned under AEDT g. Hardware/additional software requirements Needs server with multiple processors for efficient computations. Large hard drive spaces needed. 4. Database

I-108 Model: AEDT/SAGE (- System for Assessing Global Emissions Component) a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) Aircraft b. What data is included? (e.g., NPD, EI, performance profiles, etc.) ICAO emissions, BADA performance, SAE 1845, airport locations and weather, airport capacity, fleet mappings c. Robustness of data (i.e., fidelity and resolution of data Some flexibility based on specificity of data (e.g., average or specific airport taxi times) d. Traceability (e.g., documented sources, acceptability, etc.) All data and sources are well documented e. Publicly available All data are based on publicly available sources with the exception of BADA, WWLMINET data, and BACK Aviation fleet data. 5. Usability a. General data requirements (e.g., readily available, easily found, considerable effort required, etc.) Most are readily available, but others like BADA require permission. b. Input flexibility (e.g., different resolution of data, user- defined sources, etc.) Different resolution of data for some modules are allow (e.g., taxi data) c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.) Limited or no UI at this point, but one is being planned as a web-interface under AEDT. d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) Mature software with little or no bugs. 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) Complete b. Format (e.g., series of notes, hardcopies only, on-line, etc.) Electronic and on-line 7. Validation and confidence use Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results: a. Valid only in special cases b. Moderate c. High High confidence based on uncertainty and validation assessments 8. Outputs a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.) Emissions in mass units (e.g.,. kg, Gg, Tg, etc.) b. If air quality, what pollutants are covered? NOx, CO, HC, CO2, H2O, and SOx c. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) 9. Policy or requirements a. Is this a preferred or required model? No, but the only model used by FAA within the model’s scope. b. Input restrictions (i.e., parameter limits) Inputs based on FAA approval

I-109 Model: AEDT/SAGE (- System for Assessing Global Emissions Component) c. Limitations on application (i.e., scenario limits) Inputs based on FAA approval

I-110 Model: AEDT/INM (- Integrated Noise Model Component) 1. Overall Model Scope a. In public domain? If not, who is caretaker? The AEDT Development Team: John A. Volpe National Transportation Systems Center, ATAC Corp., CSSI Inc., Wyle Laboratories. b. Air quality or noise? a. Noise: SI, SPL, or other? c. Mode (highway, rail, water, air) d. Screening or detailed (intended categorization)? e. Scales of analysis a. Noise (free field, long range propagation) Local and global f. Regulatory use (e.g., NEPA assessments, etc.)? Assume will take the regulatory role held by INM, and other included tools 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.) AEDT will be based on the Integrated Noise Model (INM: local noise), the Emissions and Dispersion Modeling System (EDMS: local emissions), the Model for Assessing Global Exposure from Noise of Transport Airplanes (MAGENTA: global noise), and the System for Assessing Aviation's Global Emissions (SAGE: global emissions). a. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with average information) c. Theoretically-based (e.g., vehicle- specific with individual characteristics and theoretical propagation implemented) 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.) b. Operating system (e.g., MS-DOS, Windows, Linux, etc.) c. Software language (e.g., Fortran, C#.NET, etc.) C#.NET d. Software structure (e.g., single exe, modularized components, preprocessors, etc.) Modular e. Distributed computing? (yes or no) f. Connectivity with other tools (e.g., AEDT-APMT linkage, etc.) Connectivity with the Environmental Design Space (EDS) and the Aviation Environmental Portfolio Management Tool (APMT).

I-111 Model: AEDT/INM (- Integrated Noise Model Component) The EDS will be used to estimate source noise, exhaust emissions, performance, and economic parameters for new aircraft in planning stages under different technological scenarios. The APMT will use integrated analyses to assess and communicate environmental effects, interrelationships, and economic consequences, linking the environmental predictions of AEDT with comprehensive economic analysis capabilities. g. Hardware/additional software requirements 4. Database a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) b. What data is included? (e.g., NPD, EI, performance profiles, etc.) c. Robustness of data (i.e., fidelity and resolution of data d. Traceability (e.g., documented sources, acceptability, etc.) e. Publicly available 5. Usability a. General data requirements (e.g., readily available, easily found, considerable effort required, etc.) b. Input flexibility (e.g., different resolution of data, user- defined sources, etc.) c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.) Separate GUIs for local and global portions of AEDT. Local portion will merge INM and EDMS and try to maintain consistency with the existing INM and EDMS features. Global portion will merge MAGENTA and SAGE into MASAGE. d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) To be determined after AEDT Version 1.0 is released. 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) Architecture and ADD (ADD plays part of Technical Manual, expressing mathematical and logical concepts within software module). Maybe others when AEDT released. b. Format (e.g., series of notes, hardcopies only, on-line, etc.) 7. Validation and confidence use Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results: a. Valid only in special cases b. Moderate c. High 8. Outputs

I-112 Model: AEDT/INM (- Integrated Noise Model Component) a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.) b. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) 9. Policy or requirements a. Is this a preferred or required model? Assume will take the regulatory role held by INM, and other tools. Therefore, it would be required. b. Input restrictions (i.e., parameter limits) c. Limitations on application (i.e., scenario limits)

I-113 Model: CadnaA 1. Overall Model Scope a. In public domain? If not, who is caretaker? No. It is the product of the German company, DataKustik. A free Demo Version can be downloaded at: <http://www.datakustik.com/en/service-support/demo- versions/> b. Air quality or noise? Noise and, with Option APL (an available extension), air pollution emission and immission. a. Air quality: emission or dispersion? Emission and dispersion. b. Noise: SI, SPL, or other? SPL c. Mode (highway, rail, water, air) Industrial, road and rail, air d. Screening or detailed (intended categorization)? Detailed e. Scales of analysis a. Air quality (e.g., microscale, regional, national, etc.) Maps can be calculated for projects of any scale b. Noise (free field, long range propagation) Maps can be calculated for projects of any scale f. Regulatory use (e.g., NEPA assessments, etc.)? CadnaA complies with regulations in Austria, Switzerland, United Kingdom, France, Scandinavia, and with the calculation methods of the EC-directive 2002/49/EC (Environmental Noise Directive). 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.) CadnaA can use the noise calculation methods presented in any of the following standards and guidelines: o Industrial Noise: - ISO 9613 incl. VBUI and meteorology according to CONCAWE (International, EC-Interim) - VDI 2714, VDI 2720 (Germany) - DIN 18005 (Germany) - ÖAL Richtlinie Nr. 28 (Austria) - BS 5228 (United Kingdom) - General Prediction Method (Scandinavia) - Ljud från vindkraftverk (Sweden) - Harmonoise, P2P calculation model, preliminary version (International) o Road Noise - NMPB-Routes-96 (France, EC-Interim) - RLS-90, VBUS (Germany) - DIN 18005 (Germany) - RVS 04.02.11 (Austria) - STL 86 (Switzerland) - SonRoad (Switzerland) - CRTN (United Kingdom) - TemaNord 1996:525 (Scandinavia)

I-114 Model: CadnaA - Czech Method (Czech Republic) o Railway Noise - RMR, SRM II (Netherlands, EC-Interim) - Schall03, Schall Transrapid, VBUSch (Germany) - Schall03 new, draft (Germany) - DIN 18005 (Germany) - ONR 305011 (Austria) - Semibel (Switzerland) - NMPB-Fer (France) - CRN (United Kingdom) - TemaNord 1996:524 (Scandinavia) - FTA/FRA (USA) o Aircraft Noise - ECAC Doc. 29, 2nd edition 1997 (International, EC-Interim) - DIN 45684 (Germany) - AzB (Germany) - AzB-MIL (Germany) - LAI-Landeplatzleitlinie (Germany) - AzB 2007, draft (Germany) It uses the air pollution dispersion model, AUSTAL2000, which is a Lagrange particle model that processes time-dependent emissions from road and industrial sources and takes terrain and buildings, wind fields and atmospheric stability into account. b. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with average information) First order approximation c. Theoretically-based (e.g., vehicle-specific with individual characteristics and theoretical propagation implemented) 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.) Inputs can be imported in the following forms:  Atlas GIS, former GIS-software by ESRI (until 2001)  ArcView, shape-file from ArcView/ArcInfo-GIS-software (by ESRI)  ASCII grid, ASCII-format for grid point data  ASCII poly, ASCII-format for open or closed polygon-lines  AutoCad-DXF, AutoCad export format for object geometry (by Autodesk Inc.)

I-115 Model: CadnaA  Building height points, ASCII-format for building height points  EDBS, format used by the German ordnance surveys  GML, format used by the UK Ordnance Survey  GYpSiNOISE, data interchange format CadnaA-GIS  LimA, format used by LimA software  MapInfo, format used by MapInfo (by MapInfo Corp.)  MITHRA, format used by MITHRA software  NTF, UK National Transfer Format  QSI, data interchange format according to DIN 45687 and ÖAL 36  Sicad, GIS-software by AED-SICAD AG  SLIP, format used by SLIP road noise software  SOSI, format used by SOSI software (® Ordnance Survey Norwegen)  SoundPLAN, format used by SoundPLAN software  Stratis, program system for road design & civil eng. (by RIB Software AG)  T-Mobil, format used by Deutsche Telekom MobilNet GmbH  Winput-DGM, ASCII-format by the Bavarian Ordnance Survey, Munich Outputs can be exported to the following forms:  ArcView Grid, used by ArcView/ArcInfo-GIS-software (by ESRI)  ArcView Shape, used by ArcView/ArcInfo-GIS-software (by ESRI)  AutoCad DXF, AutoCad format for object geometry (by Autodesk Inc.)  Building height points, ASCII-format for building height points  Google Earth, Keyhole Markup Language (KML)  GYpSiNOISE, data interchange format CadnaA-GIS  IMMIS Luft, format used by IMMIS software  LimA, format used by LimA software  QSI, data interchange format according to DIN 45687 and ÖAL 36  Rich text format, document file format  Text files  X-file b. Operating system (e.g., MS-DOS, Windows, Linux, etc.) Windows c. Software language (e.g., Fortran, C#.NET, etc.) C/C++ d. Software structure (e.g., single exe, modularized components, preprocessors, etc.) Different “Option” extensions are available for purchase e. Distributed computing? (yes or no) Yes. CadnaA can use up to 32 parallel processors for multithreading If multiple licenses are available, PCSP (Program Controlled Segmented Processing) can be used to support distributed computing on several processors and/or computers.

I-116 Model: CadnaA If only one license is available, Option CALC (an available extension) can allow all computers in a network to use the CadnaA-processing kernel without the user- interface. f. Connectivity with other tools (e.g., AEDT-APMT linkage, etc.) Can import flight traffic data via ODBC-connection (Open Database Connectivity) g. Hardware/additional software requirements A 64-bit version of CadnaA exists and requires a processor with a 64-bit extension and 64-bit Windows operating system. 4 GB or more memory is recommended. 4. Database a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) 11 groups of aircraft, road traffic sources, about 150 modules for technical sound sources for industrial noise (with Option SET, an available extension) b. What data is included? (e.g., NPD, EI, performance profiles, etc.) For aircraft noise, predefined aircraft sorted according to their type and weight class into groups considered to have similar noise emission For road air pollution in Option APL, emission factors are obtained from a joint publication by the German, Swiss, and Austrian Environmental Protection Agencies (HBEFA Handbuch Emissionsfaktoren des Strassenverkehrs 2.1 - Manual for Emissions Factors of Road Traffic, February 2004). For Industrial Noise, with Option SET, sound power spectra can be generated based on technical parameters of a source (e.g. electric power, volume flow, or rpm) for about 150 predefined modules for technical sound sources like electric and combustion engines, pumps, etc. c. Robustness of data (i.e., fidelity and resolution of data Air pollution dispersion calculations have high resolution and incorporate buildings and terrain. d. Traceability (e.g., documented sources, acceptability, etc.) e. Publicly available 5. Usability a. General data requirements (e.g., readily available, easily found, considerable effort required, etc.) Complexity of required data depends on complexity of model. If generating a digital town, need geometry and object data for the roads, buildings and terrain. This type of data can be imported from files of different formats to generate the final digital town model. b. Input flexibility (e.g., different resolution of data, user- defined sources, etc.) Noise levels can be calculated at specified receiver positions, on horizontal or vertical grids, or on grids enveloping building facades. c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.) The CadnaA main window has a Menu bar, a Toolbar that provides one-click access to menu commands or features, a Toolbox that allows the user to insert objects or trigger actions by clicking an object icon in the Toolbox and inserting it directly into the main screen, and the main screen where the graphical plot of the environment being considered is displayed. 3D visualization possible in separate window

I-117 Model: CadnaA d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) Information on the website: <http://www.datakustik.com/en/products/cadnaa/> is extensive. There is also a CadnaA help file that comes with the program. b. Format (e.g., series of notes, hardcopies only, on-line, etc.) Online. 7. Validation and confidence use Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results: Validation was performed at a test airport and accuracy of the calculation was proven by the German Environmental Protection Agency (Umweltbundesamt UBA). a. Valid only in special cases b. Moderate Moderate c. High 8. Outputs a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.) Lden and L b. If air quality, what pollutants are covered? night PM10 fine particles, NO2, NOX, SO2 c. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) , benzene Overall spectrum (Lin, A, B, C, or D weighting can be used) 9. Policy or requirements a. Is this a preferred or required model? Not required. b. Input restrictions (i.e., parameter limits) Very high software-based limit. Therefore, practically no limit to project size by software. Most often, limiting factor is memory size of hardware. In the standard model of CadnaA, a maximum of 1000 buildings and 1000 barriers can be used. With the Option XL, there is no limit. c. Limitations on application (i.e., scenario limits)

I-118 Model: SoundPLAN 1. Overall Model Scope a. In public domain? If not, who is caretaker? No. It is the product of the German company Braunstein + Berndt GmbH. b. Air quality or noise? Air quality and noise a. Air quality: emission or dispersion? Dispersion. Emission source rates are user-defined. b. Noise: SI, SPL, or other? SPL c. Mode (highway, rail, water, air) Road, rail, industrial (and sports and leisure facilities), air d. Screening or detailed (intended categorization)? Detailed e. Scales of analysis a. Air quality (e.g., microscale, regional, national, etc.) MISKAM, SoundPLAN's air pollution model has a small pollutant simulation scope, accommodating studies that range out to a couple hundred meters. b. Noise (free field, long range propagation) Maps can be calculated for projects ranging from small to “huge.” f. Regulatory use (e.g., NEPA assessments, etc.)? SoundPLAN implements calculations in accordance with regulations and national standards of many different countries. The user may pick which standard they wish SoundPLAN to use. 2. Algorithms (scientific merit) a. What algorithms are used? (e.g., sound propagation, emissions dispersion, vehicle performance, etc.) SoundPLAN can use the noise calculation methods presented in any of the following standards and guidelines:  Road Noise: RLS 90, DIN 18005, Calculation of Road Traffic Noise (CoRTN), Statens Planverk 48, Federal Highway Model (FHWA), NMPB o (The above were explicitly stated in the SoundPLAN Manual. In the Mapping software Catalogue_VersAPR08.xls spreadsheet, Rasmussen claims that the VBUS, NMR-96, Nord2000, and RVS 3.02 standards are also included in SoundPLAN.)  Rail Noise: SCHALL-03, Transrapid, DIN 18005 with emission calculation railway, Calculation of Rail Noise CRN 99, Ö-Norm S 5011, RMR 2002, SEMIBEL, Nordic Prediction Method for Train Noise NMT 98, Nordic Rail Prediction Method Kilde Report 130, Japan Narrow Gauge Railways, ÖAL 30 o (The above were explicitly stated in the SoundPLAN Manual. In the Mapping software Catalogue_VersAPR08.xls spreadsheet, Rasmussen claims that the VBUSch and Nord2000 standards are also included in SoundPLAN.) o Industry Noise: VDI 2714, VDI 2720, ISO 9613, General Prediction Method, CONCAWE o Aircraft Noise:, AzB, AzB (free), AzB-L (revision from 1997), DIN 45643 strict, DIN 45643 (free), ÖAL 24, ECAC Doc 29 o Parking Lot Noise: DIN 18005, RLS 90, Bavarian Parking Lot Study o Indoor Noise: VDI 3760E, The Indoor Factory Noise Module

I-119 Model: SoundPLAN Calculation Method For pollution dispersion calculations, SoundPLAN provides both a Gauss model according to TA-Luft for pollutant dispersion from smoke stacks and the MISKAM model, which is more accurate for smaller scale dispersion calculations.  MISKAM is a "three dimensional non-hydrostatic flow and dispersion model for local prognosis of wind distribution and pollutant concentration in areas ranging from roads to city districts." It can model flow around buildings (treated as rectangle cubes), is "built on the complete 3 dimensional motion equations for simulation of the wind field and the advection-diffuse-equations for the dispersion of density neutral substances," and fulfills the German VDI 3782 /8. Air absorption can be calculated with the following standards  ANSI 126  ISO 3891  ISO 9613 Part 1 b. Which category does the model fall into: a. Simple (e.g., averaging methods based on assumptions, simple multipliers, etc.) b. First order approximation (e.g., partial vehicle data and propagation simplifications supplemented with average information) Between first order and theoretically-based. c. Theoretically-based (e.g., vehicle-specific with individual characteristics and theoretical propagation implemented) 3. System architecture a. Input/output data structure (e.g., flat ASCII files, SQL database, etc.) For data entry: A scanned map input must be a bitmap (.bmp), DXF data must be based on AutoCAD DXF Version 12/13. SoundPLAN can also import data uses CARD/1, Stratis, ASCII, or ESRI Shape file as input. Results are stored as .res files. A results table can be exported as an ASCII file, an Excel file, or WMF files b. Operating system (e.g., MS-DOS, Windows, Linux, etc.) Windows 98, Windows NT 4.0, Windows 2000, or Windows XP (website indicates Windows 95 and ME as well, but not updated recently) c. Software language (e.g., Fortran, C#.NET, etc.) d. Software structure (e.g., single exe, modularized components, preprocessors, etc.)  SoundPLAN software is installed from the CD and a floppy disk containing license information, user name and address.  Program updates are EXE files.  SoundPLAN is a modular program consisting of multiple programs geared

I-120 Model: SoundPLAN for specific functions and allowing multitasking within and between projects.  Each project is stored in its own folder.  Geo-Files (.geo), the smallest storage unit, contain information on elevation, coordinates, and attributes of objects.  Situations (.sit) contain a list of the Geo-Files that are included in the Situation.  Digital Ground Models (DGM) can be generated and used as the basis of the elevation model for digitizing new objects.  Graphics templates can be stored for personalized layouts to be used in any new project. e. Distributed computing? (yes or no) Yes. f. Connectivity with other tools (e.g., AEDT-APMT linkage, etc.) Data can be imported with the ArcView interface g. Hardware/additional software requirements Recommended:  PC Pentium 1 GigaHertz or higher  Graphics Card with resolution of minimum 1024 x 768, 256 colors, 16 or 32 MB memory, for 3D-Graphics you need a graphics card with OpenGL drivers and at least 32 MB memory  RAM memory >=256 MB  Hard disk 20 GigaByte  17" monitor  WinTab compatible Digitizer (WinTab drivers are available for nearly all current digitizers)  All windows compatible printers and plotters can be used. 4. Database a. What sources are included? (e.g., number and types of vehicles, stationary source, etc.) As stated in the manual regarding SoundPLAN's "library," it allows: "Access to the emission-, absorption-, transmissions- and mitigation library, the definitions of 2D- and 3D-directivity as well as day histograms, wind statistics, pollution component library(MISKAM) and the assessment library. The library comes with limited data and is ready to host your project and global data." b. What data is included? (e.g., NPD, EI, performance profiles, etc.) Many of the standards SoundPLAN uses in noise calculations specify source characteristics:  Road Noise: RLS90 assumes road source at 0.5 m height above the middle of the two outer lanes, the emission level is the level measured 25 m from the center of the road, 4 m above ground and can be entered or calculated with SoundPLAN’s “pocket calculator,” for example.  Railway Noise: SoundPLAN stores train types and properties and calculates emission data according to, for example, the standard Schall03.  Aircraft Noise: Emission data is kept in “On,Rn” tables (in octave bands)

I-121 Model: SoundPLAN for different aircraft classes for a set reference distance and direction factor (to include directivity).  Industrial Noise: Sources are included as point, line or area sources. SoundPLAN includes a “system library” with emission data for different sources that can be copied to the “project libraries.”  Parking Lot Noise: SoundPLAN includes parking lots as area sources, modeled with different standards. c. Robustness of data (i.e., fidelity and resolution of data d. Traceability (e.g., documented sources, acceptability, etc.) Much of the source data and algorithms used in SoundPLAN come from standards and guidelines listed above. e. Publicly available Emission data use by SoundPLAN can be viewed in SoundPLAN. 5. Usability a. General data requirements (e.g., readily available, easily found, considerable effort required, etc.)  Road Noise: The emission level for a road segment and can be calculated (based on number of vehicles, speed, etc.) or directly entered. User also enters the posted speed for cars and trucks in [km/hr]. The percentage of heavy vehicles and traffic load at night can be calculated from a table that was based on long time traffic observations, or entered by the user. The road type can be entered to result in corrections to sound levels.  Rail Noise: User defines the description of the rail line, the track number, direction, and status. Number of trains day/night for each train type, train type addition and break type percentage (disk versus wheel), train speed, train length. For multiple reflection calculations (in railway canyon), user defines height of walls of canyon, width of canyon, and average reflection losses.  Industrial Noise: User chooses between calculations of noise in only the mean frequency (which must be entered) or full spectra. SoundPLAN needs to know the sound power output for 24 hours (because industrial sources often do not operate 24 hours a day).  Aircraft Noise: Airport geometry and runway setup must be included in the SoundPLAN model. User picks from routes, aircraft classes and operations data in definition sheets. User can input glide paths or use a preprogrammed path. User must differentiate between operations during the day and night so appropriate penalties can be assessed.  Indoor Noise: User defines average room height, scattering object density, and absorption of floor, ceiling, scattering objects and facades.  2D or 3D directivity of sources can be entered.  Objects can be entered by selecting the object type from a list, entering the coordinates and checking or entering elevation information and any object properties.  For air quality calculations, user must specify meteorological conditions (vertical temperature gradient, wind statistics, etc.) and the emission rate of

I-122 Model: SoundPLAN pollutants (per km of road per day in kg). b. Input flexibility (e.g., different resolution of data, user- defined sources, etc.)  SoundPLAN offers many opportunities for a user to define or redefine element and source properties. For example a user can define his/her own source emission levels, 2D or 3D source emission directivity adjustments, heights of floors in buildings, road surface (by providing a user-specified addition to the sound level), etc.  The user can also define calculation settings such as grid size or height above ground for a grid noise map calculation.  With the Cartography module, the user can define his/her own graphics object type, influencing the object's appearance in the graphics modules. c. UI complexity (e.g., easy to understand, cryptic switches, steep learning curve, etc.)  SoundPLAN can produce calculations for a single point receiver, grid noise map, cross-sectional noise map, facade noise map, and city noise map, to display different soundscape information.  The "SoundPLAN-Manager" allows access to all modules of the program: Library, Geo-Database, Calculation Core, Documentation (results data), Spreadsheet (presentation of results), Expert Industry (analysis of source and receiver interactions, source contributions, etc.), Long Straight Road (rough screening calculations), City Noise Screening (rough screening calculations), Aircraft Noise Definition, and Socket Server (for distributed computing)  The graphical user interface tells the user which Geo-File is being viewed, what object is selected, etc. as well as showing a large picture (viewport) of the area being considered.  SoundPLAN's 3D-Graphics can be used to display any map in 3D. The 3D- Graphics model data check displays all data as used for calculations, while the 3D-Graphics animation shows further objects and allows the user to "drive" through an area on an existing road or railroad. The animation can be saved as an AVI file. d. Reliability (e.g., software bugs, technical errors, implementation issues, etc.) 6. Documentation a. Completeness (e.g., user's guide, technical manual, architecture, ADD, etc.) User's Manual, SoundPLAN on-Line Help (information on current problems, updated every SoundPLAN version) b. Format (e.g., series of notes, hardcopies only, on-line, etc.) PDF and online. Manual available in printed form. 7. Validation and confidence use Based on the breadth of validation and uncertainty assessments conducted to date and the merits of the methods used, what level of trust is there in the model to produce accurate results: Rasmussen claims: "Benchmarks have been performed on the published sets of official test cases defined in or for regulations. Additional documentation according to the Nordtest method NT ACOU 107 will be available end of 2006." The pollution model, MISKAM has been tested in wind tunnel experiments, with simulations and with measurements. However, SoundPLAN warns that MISKAM "cannot be regarded as a black box but rather a tool that requires considerable

I-123 Model: SoundPLAN amount of thought and work. Uncritical acceptance of the results shall be avoided." a. Valid only in special cases b. Moderate Moderate to High c. High 8. Outputs a. What are the metrics both spatially and temporally (e.g., Leq(1 hr), DNL, ug/m^3, ppm, one hour average, annual average, etc.) Leq (for day or night), Lmax, Lden, L10 (for UK road noise), Exceeding levels (for day and night) b. If air quality, what pollutants are covered? CO, HC, C6H6, NOx, Pb, SO2, PM. Additional pollutants can be defined for industrial sources. c. If noise, frequency components (i.e., octave bands) or overall spectrum (i.e., A-weighted) Octave or third-octave bands. Often A-weighted, however linear, B, C or D filters can also be set. 9. Policy or requirements a. Is this a preferred or required model? Not required. b. Input restrictions (i.e., parameter limits) Some source emissions are restricted to a maximum level Restrictions apply when designing walls Restrictions apply for the shape and characteristics of the inside of buildings when using the Indoor Factory Noise Module. c. Limitations on application (i.e., scenario limits) None specified.

I-124 REFERENCES "LIMA (English)." Programmsystem Lima. <http://www.stapelfeldt.de/framestarte.htm>. "Aviation Environmental Design Tool (AEDT)." Environmental Tool Suite Frequently Asked Questions. 27 Feb. 2008. Federal Aviation Administration. <http://www.faa.gov/about/office_org/headquarters_offices/aep/models/toolsfaq/index.cfm?print=go#aedt>. Roof, et al., Aviation Environmental Design Tool (AEDT): System Architecture, Doc No. AEDT-AD-01, Federal Aviation Administration, January 2007. “The Aircraft Noise and Performance (ANP) database.” Eurocontrol. <www.aircraftnoisemodel.org>. Boeker, et al., Integrated Noise Model (INM) Version 7.0 Technical Manual, Report No. FAA-AEE-08-01. Dinges, et al., Integrated Noise Model (INM) Version 7.0 User's Guide, Report No. FAA- AEE-07-04, Washington, D.C.: Federal Aviation Administration, April 2007. European Civil Aviation Conference (ECAC) Report on Standard Method of Computing Noise Contours around Civil Airports, Doc 29 (3rd Edition), July 2005. Flemming, Gregg G., Kenneth J. Plotkin, Christopher J. Roof, Bruce J. Ikelheimer, and David A. Senzig. Assessment of Tools for Modeling Aircraft Noise in the National Parks. Federal Interagency Committee on Aviation Noise (FICAN). 2005. "Integrated Noise Model (INM)." Environmental Tool Suite Frequently Asked Questions. 27 Feb. 2008. Federal Aviation Administration. <http://www.faa.gov/about/office_org/headquarters_offices/aep/models/toolsfaq/index.cfm?print=go#inm>. IMMI – Air dispersion modeling: Gas, dust, odours. Wölfel. <http://www.woelfel.de/fileadmin/ftp/Downloads/IMMI_Downloads/IMMI_Hauptinfo_air_pollution.pdf>. IMMI – Aircraft Noise. Wölfel. < http://www.woelfel.de/fileadmin/ftp/Downloads/IMMI_Downloads/IMMI_Hauptinfo_aircraft_noise.pdf>. IMMI – Distributed calculation on networked or multi-core computers. Wölfel. < http://www.woelfel.de/fileadmin/ftp/Downloads/IMMI_Downloads/Datenbl%E4tter%20Englisch/IMMI_KI_Distributed_calculation_on_network ed_or_multi-core_computers.pdf>. “IMMI Interfaces.” PRODUCTS / Modelling Software. Wölfel. <http://www.woelfel.de/en/products/modelling-software/immi-interfaces.html>.

I-125 IMMI - Noise Mapping & Noise Prediction. Wölfel. <http://www.woelfel.de/fileadmin/ftp/Downloads/IMMI_Downloads/IMMI_Hauptinfo_noise_mapping.pdf>. “IMMI – Noise Mapping Software.” PRODUCTS / Modelling Software. Wölfel. <http://www.woelfel.de/en/products/modelling-software/immi- noise-mapping.html>. IMMI – Reference Databases. Wölfel. < http://www.woelfel.de/fileadmin/ftp/Downloads/IMMI_Downloads/Datenbl%E4tter%20Englisch/IMMI_KI_Reference_Databases.pdf>. IMMI 6.3– Features explained. Wölfel. < http://www.woelfel.de/fileadmin/ftp/Downloads/IMMI_Downloads/IMMI_%20DB_Features.pdf. "Noise and Air Pollution Mapping." PRODUCTS / Modelling Software. Wölfel. <http://www.woelfel.de/en/products/modelling-software.html>. FRA High-Speed Rail Initial Noise Evaluation. HMMH Inc. Computer Software. Guidance on Assessing Noise and Vibration Impacts. <http://www.fra.dot.gov/us/content/167>. "Horn Noise Assessment." Federal Railroad Administration. 30 Oct. 2008. Department of Transportation. <http://www.fra.dot.gov/us/content/254>. "Horn Noise Questions and Answers." Federal Railroad Administration. 31 Oct. 2008. Department of Transportation. <http://www.fra.dot.gov/us/content/1173>. FRA Horn Noise Model. Computer software. Horn Noise Assessment. <http://www.fra.dot.gov/downloads/rrdev/hornmodel.xls>. Bowlby, W., and L. F. Cohn. Highway Construction Noise - Environmental Assessment and Abatement Volume IV - User's Manual for the FHWA Highway Construction Noise Computer Program, HICNOM. Rep. no. VTR 81-2. Vanderbilt University Transportation Research Group. Office of Research, Federal Highway Administration. "CadnaA: State-of-the-art Noise Prediction Software." CadnaA. DataKustik. <http://www.datakustik.com/en/products/cadnaa/>. "Calculation and Assessment of Air Pollutant Distribution." CadnaA. DataKustik. <http://www.datakustik.com/en/products/cadnaa/fields-of- application/air-pollutants/>. "Option APL: Air Pollutants." CadnaA. DataKustik. <http://www.datakustik.com/en/products/cadnaa/extensions/apl-air-pollutants/>.

I-126 "EC Directive on Environmental Noise 2002/49/EC." CadnaA. DataKustik. <http://www.datakustik.com/en/products/cadnaa/fields-of- application/noise-mapping/ec-directive-200249ec/>. "Calculation and Prediction of Aircraft Noise." CadnaA. DataKustik. <http://www.datakustik.com/en/products/cadnaa/fields-of- application/aircraft-noise/>. "Calculation using AUSTAL2000 Model." CadnaA. DataKustik. <http://www.datakustik.com/en/products/cadnaa/extensions/apl-air- pollutants/calculation-using-austal2000/>. "Calculation Standards." CadnaA. DataKustik. <http://www.datakustik.com/en/products/cadnaa/modeling-and-calculation/calculation-standards/>. "Import Formats." CadnaA. DataKustik. <http://www.datakustik.com/en/products/cadnaa/modeling-and-calculation/import-formats/>. "Export Formats." CadnaA. DataKustik. <http://www.datakustik.com/en/products/cadnaa/modeling-and-calculation/export-formats/>. "Multi Processor Support." CadnaA. DataKustik. <http://www.datakustik.com/en/products/cadnaa/features/multi-processor-support/>. "Option CALC: Distributed Calculation in a Network." CadnaA. DataKustik. <http://www.datakustik.com/en/products/cadnaa/extensions/calc- networked-calculation/>. "Option FLG: Aircraft Noise." CadnaA. DataKustik. <http://www.datakustik.com/en/products/cadnaa/extensions/flg-aircraft-noise/>. "Option 64: CadnaA 64-bit Version." CadnaA. DataKustik. <http://www.datakustik.com/en/products/cadnaa/extensions/64-cadnaa-64-bit- version/>. "Calculation and Assessment of Industrial Noise." CadnaA. DataKustik. <http://www.datakustik.com/en/products/cadnaa/fields-of- application/industrial-noise/>. "Aircraft Groups." CadnaA. DataKustik. <http://www.datakustik.com/en/products/cadnaa/extensions/flg-aircraft-noise/aircraft-groups/>. "Data Import." CadnaA. DataKustik. <http://www.datakustik.com/en/products/cadnaa/fields-of-application/noise-mapping/data-import/>. "Calculation of Noise Levels." CadnaA. DataKustik. <http://www.datakustik.com/en/products/cadnaa/modeling-and-calculation/calculation-of- noise-levels/>.

I-127 "Dynamic 3D: Powerful Dynamic 3D Visualization." CadnaA. DataKustik. <http://www.datakustik.com/en/products/cadnaa/features/dynamic- 3d/>. "Project Size." CadnaA. DataKustik. <http://www.datakustik.com/en/products/cadnaa/modeling-and-calculation/project-size/>. DataKustik. CadnaA: State-of-the-art noise prediction software (Demo Version). Computer software. <http://www.datakustik.com/en/service- support/demo-versions/>. "Airspace Design and Environmental Analysis: Noise Integrated Routing System." 2008. Metron Aviation. <http://www.metronaviation.com/nirs.php>. Environmental Impacts: Policies and Procedures. FAA Order 1050.1E. Federal Aviation Administration. June 2004. "Noise Integrated Routing System (NIRS).” Environmental Tool Suite Frequently Asked Questions. 27 Feb. 2008. Federal Aviation Administration. <http://www.faa.gov/about/office_org/headquarters_offices/aep/models/toolsfaq/index.cfm?print=go#nirs>. "Noise Integrated Routing System (NIRS) & NIRS Screening Tool (NST)." Aviation Policy, Planning & Environmental Topics. 5 Jan. 2007. Federal Aviation Administration. <http://www.faa.gov/about/office_org/headquarters_offices/aep/models/nirs_nst/>.