CMAQ PM2.5 overestimation

Dear Min,

Thank you for your insights, I feel I have a much clearer understanding now. I’m happy to share my thoughts on the topic, though I’m still relatively new to this.

About the monthly factors; variant monthly factors are applied when processing yearly inventory files. If the inventory input consists of pregridded separate monthly NetCDF files, then the full emissions of each month should be processed (factor of each month=1), unless there would be another logic behind it.

I assume the issue with the month variable in arinv.edgar.lst for EDGARv8 is specific to this dataset. Additionally, setting the month variable to 0 (as in your current solution for EDGARv8 files) does not necessarily guide SMOKE to process data on a yearly basis, it always does. Before I had applied your solution, I ran smkinven and temporal with month ≠ 0 and without providing ATPRO_MONTHLY. Despite this, temporal was still prompting for ATPRO_MONTHLY (@eyth.alison had mentioned this). It seems that the variable setenv SMKINVEN_MONTH might be more critical in controlling monthly processing.

Considering EDGAR.v2 and its separate monthly files, besides smooth compatibility with SMOKE, it seems to me feeding separate monthly files is almost essential for targeted monthly processing, avoiding the need to process an entire year’s data (yearly inventories) through temporal. With EDGAR.v8’s new structure, it appears to be a matter of data presentation, requiring additional preprocessing steps for SMOKE users.

The only minor drawback of your solution would be the necessity of multiple arinv.edgar.lst for distinguishing among the files of different months (maybe). Owing to the fact that G_RUNLEN has a small cap and SMKINVEN_MONTH targets a single month, and running temporal program on a daily basis is a common practice, I think this challenge doesn’t make a big difference eventually.

Kind regards,

Mason