To determine whether your run worked correctly, you must quality assure your emissions processing. To one degree or another, you must design your quality assurance techniques to be specific to each emissions modeling effort, since no two efforts are exactly the same. This section describes some general methods that can be followed to assist users with quality assuring their emissions processing.
As stated in the introduction to this chapter, quality assurance consists of at least the following four components. These are discussed in Section 7.5.1, “Setting up SMOKE”, Section 7.5.2, “Reviewing log files”, Section 7.5.3, “Reviewing reports created by SMOKE core programs”, and Section 7.5.4, “Reviewing and customizing reports created by Smkreport”.
Setting up SMOKE using available documentation (this manual) on file formats and script setup.
Reviewing log files for errors and warnings, then resolving any problems.
Reviewing reports generated by SMOKE core programs (e.g., reports from the Cntlmat program indicating which controls were applied and the changes made to the inventory emissions).
Reviewing and customizing reports generated by the Smkreport program, and comparing these to one another and to totals from the emission inventory.
With all reporting and analyses, it is important to keep the following principles in mind:
Focus only on those pollutants and inventories that are key components of air quality problems in your modeling case. For example, it is often not worthwhile analyzing CO emissions, since their contribution to ozone air quality problems is minor. It is often worthwhile to first analyze the raw inventories to see which source categories are contributing the majority of key pollutants, to help target your efforts.
When performing analysis on a key inventory and pollutant, focus on those SCCs that contribute the majority of the emissions. For example, if 10% of the SCCs contribute 90% of the emissions, focus on quality assuring those 10% of SCCs.
Keep lists of potential issues, their status, and their resolution. Such lists will be critical to documenting the emissions modeling efforts when you are finished.
As problems are found, new inventories may be created and analyses rerun. Make sure to use new scenario names in the SMOKE
Assigns files when running a new version of the inventory. The INVEN, INVOP, and INVID environment variables can be configured to use the same input directories and new output directories.
Consider using version-control software (such as the UNIX CVS or SCCS programs) to keep track of changes in your inventories and SMOKE support files.
If possible, archive the SMOKE configuration, including all inputs and output files, once a set of “final” model-ready emissions is created and used in an air quality model. Inevitably, more changes will be made to the SMOKE setup, but you will most likely want or need to go back to the raw inputs used for a specific case, once it has been run through an AQM.
The information in Chapter 8, SMOKE Input Files, which provides detailed documentation on SMOKE input file formats, can be used to help ensure the quality of your modeling efforts. Although SMOKE programs check the input file formats when they are read and used, you should not rely on this capability entirely. There is no substitute for carefully comparing your input files with the file formats in this manual. The files should be checked in the following ways:
Make sure all required fields specified in the manual are present.
Make sure all fields are in the correct position in the file.
Make sure the type of the field (integer, real, character) is consistent between the file and the manual. Usually, it is acceptable to provide an integer value for a real field, if the data warrant this.
Make sure the file has been converted from DOS/Windows to UNIX format. This is often an issue when users edit their files on a Windows computer and move the file to a UNIX (including Linux) workstation for further processing. Files that have not been transferred properly will have “^M” entries at the end of each line and possibly a “^Z” entry at the end of the file. All of these erroneous fields must be removed. Some options for making this conversion automatically include the dos2unix and to_unix UNIX command-line programs.
Make sure tabs are not used in the file. SMOKE does not support tabs as delimiters in the input files, and the readers will not be able to read the data correctly if tabs are present.
Chapter 4, How to Use SMOKE provides documentation on the SMOKE example scripts. We recommend that new users start with these example scripts to enhance the quality of their experience using SMOKE - and thus the ultimate quality of their emissions modeling results. The script documentation should be reviewed carefully before making changes to the settings in the scripts. In addition, Chapter 5, SMOKE Utility Tools, Chapter 6, SMOKE Core Programs, and Section 7.2, “Smkreport Program” provide documentation on the UNIX environment variables that the scripts use to control the SMOKE programs. These settings can make a large difference in the emissions modeling results. Users should review each setting in the scripts, understand its purpose, and make an informed decision about the value to use for each setting prior to using the SMOKE run scripts on new inventory data. The end of Chapter 4, How to Use SMOKE provides some additional information about how to reconfigure your run scripts; these instructions should be followed carefully to ensure high quality in your emissions modeling.
A useful way to ensure that the settings have all been checked and set correctly is to create a table that includes all SMOKE settings for each source category. This table can then be filled in prior to running SMOKE for a new case, while reviewing the SMOKE documentation in detail for the correct settings. As the scripts are created for a new case, this table can be the reference for setting up the script properly. Prior to running the new script, its settings should be compared to the reference table as a final check that all the correct settings have been used.