Insert or find the grid parameters in the GRIDDESC file

The GRIDDESC file contains many grid descriptions and grid projections. Each grid description is defined by a 16-character (or less) name. Chapter 8, SMOKE Input Files contains the file format. If the grid you want is already in the file, note its name.

If the grid you want is not in the file, use the format in Chapter 8, SMOKE Input Files to insert or modify a grid description for the new grid. The grid cells must align with the cells of the cross-grid meteorology data files that will be used for modeling biogenic emissions and possibly for point and on-road mobile sources.

Change the GRID variable in the Assigns file to a new grid name

As described in Section Section 4.4.1, “Change Assigns file to set scenario names, grid names, and other case-specific configuration information”, change the GRID environment variable to a name that will be used to name output and intermediate files. This name should be coordinated with the selection made in step 3. Since the GRID variable is used in naming files, it is helpful to use a name that is easily distinguished from other grid names that you might use, but not so long as to add a lot of characters to the name of each file that includes the GRID variable in its name. Usually a name of 4 or 5 characters is sufficient.

Changing the GRID setting is a good reason to create a new Assigns file. To do this, you can copy an existing Assigns file as described in Section 4.4, “How to use SMOKE”.

Change the IOAPI_GRIDNAME_1 variable in the Assigns file to the name of the grid entered or found in step 1.

As noted in step 2, the name selected should have some relationship to the GRID environment variable. For example, if the IOAPI_GRIDNAME_1 setting is “US36_120X90”, the GRID setting might be “us36”.

Update the run scripts to use the Assigns file for the new grid.

Follow the remaining steps in the next subsection.

Update or install the grid description in the GRIDDESC file, if not done previously (see step 1 in the previous subsection).

Create and install the spatial surrogates file and surrogate description file SRGDESC

The Area and Mobile spatial surrogates files located in SRGPRO_PATH and the BGPRO are one of the most difficult inputs to create for SMOKE. The gridded data in the files must match the definition in the GRIDDESC and SRGDESC files for the grid selected using the IOAPI_GRIDNAME_1 variable.

The best approach to creating this file is to obtain it from someone else who has created surrogates for your domain. For example, EPA has developed various spatial surrogates and available at EPA’s Emission Modeling Clearinghouse (http://www.epa.gov/ttn/chief/emch/). Of course, using a national file has its limitations if your domain happens to be far away from the center of the U.S. since the map projection for the surrogates is more distorted further away from the center of the projection. However, for most users, this distortion will be a small price to pay for having readily available spatial surrogates.

The second best approach to creating this file is to use the MIMS Spatial Allocator (MSA). This tool can create SMOKE-ready surrogates using GIS shape files, which are provided with the tool for multiple surrogates. Please refer to the CMAS web site for more information.

A third approach to creating this file it to perform the same calculations done by the MSA using a GIS like ArcInfo. The calculations being done by the MSA are provided on the MSA website and could be implemented in a GIS, though this would probably be much too difficult an option for most users.

The surrogate file does not need to have the same outer boundaries as your modeling grid, but the grid cells do need to align with the grid cells of the surrogate file. This means that the projection of the surrogates must be the same as the projection as the modeling grid and the cell sizes must also match. SMOKE will produce an error if there is an inconsistency. If the grid represented by the surrogates file is larger than the modeling grid and the cells align, SMOKE will automatically extract the grid cells for the modeling domain from the larger grid provided by the surrogates.

In addition to the surrogate file, it is important to create a surrogate description file (SRGDESC). This is simply a file that lists the surrogate codes and their descriptions. Since the surrogate file itself does not currently have descriptive text that indicate what the surrogate codes mean, the surrogate description file is the only way users have of knowing to what data the codes in the surrogate file refer.

The same surrogate file can be used for Area and Mobile. This is accomplished by using the same physical file name in the SRGDESC. Please see Chapter 8, SMOKE Input Files for more information on these files. The BGPRO file must include the “county area” spatial surrogate, and is used for estimating county-total emissions from gridded emissions.

The Area and Mobile spatial surrogate file(s) should be installed as a sub-directory in the $GE_DAT directory. This sub-directory is assigned to SRGPRO_PATH. The surrogate description file should be stored in $GE_DAT as well. It is useful to include the name of the GRID in the name of the sub-directory SRGPRO_PATH for you may in the future be modeling different grids and therefore needing different surrogate files. The Biogenic surrogate file BGPRO should be located in $GE_DAT.

Create and install the spatial cross-reference file

An example spatial cross-reference file (AGREF and MGREF) is provided with SMOKE that can be used for most inventories as long as the spatial surrogate codes in the new surrogate file match the codes in the example surrogate file, which are provided in the SRGDESC file described in Chapter 3, SMOKE Directory Structure. If the codes match then the only concern will be whether the surrogate assignments are acceptable. By default, the same file is used for both the AGREF and MGREF files, which is accomplished by using the same physical file name in the Assigns file for both logical file names. The files can be the same file or two different files, at the discretion of the user - usually one file is more convenient unless different default settings (SCC=0) are needed, or unless the data all already available as two separate files.

When Smkinven imports an area, non-road mobile, or on-road mobile inventory, a list of SCCs is created (logical file name ASCC, NSCC, or MSCC). After importing the data but before running spatial allocation, it is wise to examine the list of SCCs included in this file and compare it with the list in the example spatial cross-reference files. This comparison can be accomplished manually or using the Smkreport program with a report that includes the surrogate codes assigned to each SCC (see Chapter 7, SMOKE Quality Assurance). The Smkreport results will list all of the surrogate assignments by SCC and the emissions associated with each, with which users may evaluate if any SCCs were included in the inventory but not in the example SMOKE file. The example spatial cross-reference files (AGREF and MGREF) can be updated with any new assignments or to include SCCs that are in the user’s inventory but not in the example files.

If a new surrogates file uses surrogate codes that are different from the example codes, then new spatial surrogate cross-reference files need to be created. These can be created by copying and editing the existing files to replace the example surrogate codes with the new codes. For example, the current code for population is 100. If the new code for population is 400, then all of the “100” surrogate codes in the file would need to be replaced with “400”s. These replacements must be made carefully because the example file also uses “400” for the rural land area surrogate, so if global search and replace is performed, one must be careful to change what one intends to change. It is much easier to simply use the codes that are already in use in any new surrogates file, or modify the surrogate file to use those codes.

The spatial cross-reference file(s) should be installed in the $GE_DAT directory, since the file is likely to be shared by many SMOKE runs and source categories. It is useful to name the file(s) to include the GRID environment variable for easier identification as association with the surrogate file(s) with which it works.

Create and install the biogenic gridded land use data

You must create a gridded biogenic land use data (BELD4 for BEIS3.60 or BELD3_A, BELD3_B, and BELD3_TOT for BEIS3.14) to use for your grid. The MSA described in step 2 is able to create these files using the BELD3 or BELD4 database. Please refer to step 2 for the web address of this tool. The outputs of the MSA can be used for BEIS3 modeling directory.

The gridded land use data in the file must match the definition in the GRIDDESC file for the grid selected using the IOAPI_GRIDNAME_1 variable. As with the spatial surrogates, the grid can be larger than the modeling grid, but it the cells must overlay exactly with the grid cells of the actual modeling grid, which includes the grid projection and cell sizes.

The gridded biogenic land use file(s) should be installed in the $BGDAT directory for BEIS3 modeling.

Create and install the meteorology files.

Meteorology files are a necessary input to the air quality model; therefore, the same meteorology files that will be used for the air quality modeling can be used for input to SMOKE. The MCIP program (a CMAQ preprocessor) can be used to convert the files from MM5 output format to the I/O API input format for SMOKE and CMAQ. Other user-created programs can be used as well as long as the variable names and file arrangements are consistent with what SMOKE expects. Chapter 8, SMOKE Input Files explains the details on the meteorology files that SMOKE expects and the variables that must be included in these files.

The meteorology files must be consistent with the grid selected. Like the surrogate file, the meteorology grid can be larger than the SMOKE modeling grid, but the grid cells must align. This includes the cell sizes being the same and the projection being the same. If this is the case, the SMOKE programs that use the meteorology files (Met4moves, Temporal, Laypoint, Tmpbio, and Tmpbeis3) will extract the meteorology data from the region of the files that intersects with the modeling grid.

Optionally create the BIOSEASON file

If you are modeling biogenic emissions with SMOKE for an episode and grid that covers both winter and summer seasons, then the best modeling approach is to create a BIOSEASON file from the meteorology data for input to Tmpbio or Tmpbeis3. This file indicates which grid cells and days are during “winter” and which are during “summer”, to allow Tmpbio or Tmpbeis3 to apply the winter or summer emission factor for the correct cells and days. Summer is defined for biogenic modeling in the Northern Hemisphere as the period after the last freeze and before the first freeze in each grid cell. This file may not apply to some episodes or regions which do not experience freezing temperatures, and in those cases, users may run Tmpbio or Tmpbeis3 without this file.

Set the fallback surrogate in the run scripts for area/non-point, nonroad mobile, and on-road mobile sources.

All scripts for source categories that use spatial surrogates have a Grdmat setting SMK_DEFAULT_SRGID that is used to set a fallback surrogate code. The fallback surrogate code is explained in Chapter 6, SMOKE Core Programs with the Grdmat program. It prevents emissions from being zeroed out when there is no surrogate of the assigned type for a source. The fallback surrogate should therefore be a surrogate that is never zero for a county, such as population. Only one fallback surrogate can be set for all sources in a given run. The SMK_DEFAULT_SRGID setting should be reset if the surrogate codes change (e.g., the default setting of 8 is not population) or if you want to change the fallback surrogate to a different one.

Update Assigns file to use all new files.

Update the Assigns file that you are using for this case to include all new files that you have created in this step:

Check that the inventory files cover the region of the grid.

When using a new grid, it is important to use an inventory that covers the states and counties included in your domain. There are two ways of checking that this is the case. First, obtain a map of your modeling domain prior to creating your inventory and note the states that are included wholly or in part in the domain. Before modeling, create, adapt, or amend your inventory to ensure that the inventories from each of those states are included.

The second way that you can check that you are using data for all regions of the domain is to run the data through SMOKE and look at the resulting gridded emissions in PAVE. Using PAVE, reset the scale of the plot to a very small maximum value (e.g., 0.001). All areas of the domain with emissions should show up red. If any areas show up gray, then there are missing values that could be because the inventory is not complete.