A bug in SMOKE elevpoint program for fields with missing stack parameters

**Rabab** · April 9, 2019, 5:33pm

Hi SMOKE developers,

There is an issue in SMOKE point source processing while it creates an elevated-point source ASCII file for several point sectors such as pt_noIPM. We are using SMOKE3.7 for 2017 USA inventory projected from 2011.

Below is the configuration used in run script:

setenv RUN_ELEVPOINT Y
setenv SMK_ELEV_METHOD 1
setenv SMK_PING_METHOD 1
setenv SMK_ASCIIELEV_YN Y

In pelvconfig file:

/SPECIFY PING/
HT >= 40.

/SPECIFY ELEV/
HT >= 0.

Based on above setting, all the points with stack height higher than 40m will be tagged as PING points (i.e major points) and the rest as non_PING (i.e. minor points). However, there is a lot of points with miss-tagging in elevts ASCII file for ptnoipm. For example the following line:

154200STD -97.66503 38.85815 3121711 95658212 20169
9.1 -0.95 298.2 40932.

which defines a stack with a major point flag ( stk_diameter= - 0.95) and stack_height assigned to 9.1 m which is below the PING cut-off defined in pelvconfig file.
Here is the information extracted form pt_noipm inventory for point mentioned above:

country_cd,region_cd,tribal_code,facility_id,unit_id,rel_point_id,process_id,agy_facility_id,agy_unit_id,agy_rel_point_id,agy_process_id,scc,poll,ann_value,ann_pct_red,facility_name,erptype,stkhgt,stkdiam,stktemp,stkflow,stkvel,naics,longitude,latitude,ll_datum,horiz_coll_mthd,design_capacity,design_capacity_units,reg_codes,fac_source_type,unit_type_code,control_ids,control_measures,current_cost,cumulative_cost,projection_factor,submitter_id,calc_method,data_set_id,facil_category_code,oris_facility_code,oris_boiler_id,ipm_yn,calc_year,date_updated,fug_height,fug_width_ydim,fug_length_xdim,fug_angle,zipcode,annual_avg_hours_per_year,jan_value,feb_value,mar_value,apr_value,may_value,jun_value,jul_value,aug_value,sep_value,oct_value,nov_value,dec_value
"US","20169",,"3121711","38155413","95658212","138419214","0002","001","001_D","2","30200553","PM25-PRI",0.00114900000000000006,,"CARGILL, INC.","1",,,,,,"424510",-97.6650389999999931,38.8581459999999979,,,,,,,"999",,,,,,"USEPA",5,"2011EPA_PM-","UNK",,"2011",20130519,,,,,"67401",,,,,,,,,,,,
"US","20169",,"3121711","38155413","95658212","138419314","0002","001","001_D","3","30200551","PM25-PRI",0.0220219999999999999,,"CARGILL, INC.","1",,,,,,"424510",-97.6650389999999931,38.8581459999999979,,,,,,,"999",,,,,,"USEPA",5,"2011EPA_PM-","UNK",,,2011",20130519,,,,,"67401",,,,,,,,,,,,
"US","20169",,"3121711","38155413","95658212","39422714","0002","001","001_D","1","30200552","PM25-PRI",0.668911999999999951,,"CARGILL, INC.","1",,,,,,"424510",-97.6650389999999931,38.8581459999999979,,,,,,,"999",,,,,,"USEPA",5,"2011EPA_PM-","UNK",,,,"11",20130519,,,,,"67401",,,,,,,,,,,,

For this point, all three lines has the same set of region_cd, facility_id and rel_point_id . Since stack parameters are missing in this case, SMOKE will look at pstk file to pick the default stack information based on SCC. Here is the stack info extracted from pstk fiel for SCCs listed for this point:

0 “30200553” 54.86 0.95 295.9 16.96
0 “30200551” 9.14 1.86 298.2 11.37
0 “30200552” 3.81 1.14 298.2 12.51

In this example, the combination of region_cd, facility_id, rel_point_id and lat and lon is the same for different default SCC-based stacks, SMOKE wont be able to tag it correctly and assign appropriate stack parameters to it.
To fix this issue in SMOKE, we need to have more unique set of combined information for each point, specially we need to consider SCC or any other SCC-related ID like process_ID. Procces_ID is not being used explicitly as part of stack definition info in elevpoint program of SMOKE.
For now, we used a workaround: assigning artificial rel_point_id to the records (directly in the inventory) so that the records for one combination of fac_id+rel_point_id all have the same stack parameters.

I am wondering if there is any possibility to fix this issue either in SMOKE elevpoint codes or in the point sources inventory files.

Thanks,

Rabab Mashayekhi
Environment&Climate Change Canada

**bbaek** · April 9, 2019, 7:58pm

@Rabab. Not quite sure that I understood your questions since some of information are not shown properly on the screen. However, based on my understanding, you want to know whether SMOKE can be updated to assign the replacement stack parameters by facility_id and release_point_id?

But then you said at the end, you artificially add fake rel_point_id to the source to assign the same stack parameters for the source with the same fact_id+rel_point_id combination. With current approach (FIPS/SCD only), the same stack parameters will be assigned to any sources with the same SCC regardless of unit_id, rel_point_id, and process_id as long as their stack parameters are missing or out of bounds.

**Rabab** · April 9, 2019, 9:12pm

@bbaek. Sorry for not being clear enough in my note. The problem is that the information that SMOKE reads from point src inventory to define each single stack does not seem always unique. What SMOKE picks from inventory (based on what is printed in elevts ascci file for each stack) is lat, lon, facility_id, rel_point_id and region_cd. I do not see any other information (such as unit_id or procee_id) printed explicitly in elevts file. What we found is many lines for which we have the same lat, lon, facility_id, rel_point_id and region_cd and the same pollutant name but different SCCs. For these cases SMOKE is not able to assign the correct stack information specially if it has to use pstk file. When we looked at inventory, at least for noIPM sector, process_id is more unique than rel_point_Id and it seems like SMOKE does not use it to define each single stack. So, to have more unique set of stack information in elevts file, we filled rel_point_id with process_id. By this replacement we ended up having more unique set of stacks. We are not using only FIPS,SCC, but we are using lat,lon,facility_id,process_id and region_cd.

**bbaek** · April 9, 2019, 9:52pm

@Rabab. Thanks for clarifying my confusion. ;). Now I understand your issues. First, to be clear, SMOKE does not define the source characteristics in ELEVTS file but older version of CMAQ before version 4.7 (prior to inline option). At that time, CMAQ did not ask for any detail source information other than facility_id (plant_id in ORL) and rel_point_id (stack_id in ORL). Since then, SMOKE have been updated with a feature SMK_ELEV_METHOD=2 to support full inline plume calculation option in CMAQ for source level (FIPS/SCC/fac_id/uni_id/rel_point_id/process).

Regarding to the limited option of replacement stack parameter, to meet your needs, Yes, SMOKE needs an update to assign missing stack parameters by source level .

**Rabab** · April 10, 2019, 7:33pm

@bbaek. Thanks for your feedback. Do you have any plan to update SMOKE with SMK_ELEV_METHOD=1 sometime in near future?

**bbaek** · April 10, 2019, 8:15pm

Unfortunately, there is no specific plan on updating SMOKE but also it requires updates to CMAQ to read and process those new additional source characteristics. So, I don’t think there will be an update especially a full inline option (SMK_ELEV_METHOD=2) has been actively used in most of CMAQ runs.

**Rabab** · April 11, 2019, 7:33pm

@bbaek. Thank you! We actually use SMOKE here to make emissions for Canadian Air Quality forecasting system (GEM-MACH). So we have to prepare point sources based on SMK_ELEV_METHOD=1. That would be nice if you add this limitation in SMOKE documents for “SMK_ELEV_METHOD=1”. That would be an important awareness for non-CMAQ users of SMOKE. Thank you!