Hello,
With Smoke 5.0, i am processing CONUS emission using 2022 emission modeling platform. I got following error when I ran 2020ha2_cb6_20k/scripts/onroad/Monthly_onroad_RPP_daily_12US1_2020ha2_cb6_20k.csh
*** ERROR ABORT in subroutine MOVESMRG
Could not find minimum or maximum temperatures for county 000000004027 and episode month 4
Date and time 0:00:00 April 1, 2019 (2019091:000000)
Tried to identfy what could be causing this, and i found that METMOVES file ge_dat/onroad/SMOKE_DAILY_2020nei_12US1_2020001-2021001.ncf has some missing value for part of Arizona. Please see the image below, white part of map has nodata value.
I am wondering if I am doing something wrong, or if there is workaround for this problem. Otherwise i am going to brute-force the processing by filling those cell by copying values from nearby cells.
We are unclear on what platform you are using because you mention 2022 but your error messages reference 2019.
If you are running 2019, then you either need to use the SMOKE_DAILY file from 2019 platform (and the spatial surrogates from that platform as well, related to the above) or run Met4moves themselves.
Re: the missing data in Arizona, Met4moves only fills in cells that are referenced by the spatial surrogates. If you are using our spatial surrogates, the cells with no temperature values will have no emissions, and that’s fine. If you are using a different set of surrogates, you will need to run Met4moves to create a new SMOKE_DAILY (METMOVES) file.
Thank you for reply. Sorry for confusing descriptions, here is corrections.
I am using 2020 platform, but want to create 2019 EI based on it, with HAP-CAP processing enabled. I figured i need 2019 METMOVES file for that, and I used SMOKE_DAILY_2019fj_19j_12US1_2019001-2020001.ncf, and i got the message above.
If i make the file back to SMOKE_DAILY_2019fj_19j_12US1_2019001-2020001.ncf and specify 2020 for meteorological year (BASE_YEAR env variable set in Monthly_onroad_RPP_daily_12US1_2020ha2_cb6_20k.csh , i dont tet the error.
Is this wrong approach for getting mobile emission from different year?
I went back to the original 2020 platform script, and changed only two things that I siad above. I confirmed that 2020 platform works as is for onroad/RPP, but when i changed “BASE_YEAR” env variable from 2020 to 2019, i got error that METMOVES do not have 2019 value. I then changed “METMOVES” env variable from ${GE_DAT}/onroad/SMOKE_DAILY_2020nei_12US1_2020001-2021001.ncf to ${GE_DAT}/onroad_2019/SMOKE_DAILY_2019fj_19j_12US1_2019001-2020001.ncf, which i copied from 2019 platform. And i got the error in my first post, movesmrg failed to get a cell’s value for FIPS 4027, which is Yuma county in Arizona.
What I don’t understand is that both of METMOVES files for 2020 and 2019 has missing cells in Yuma county, and why it worked in 2020 run, but not in 2019. Pic below is the 2019 METMOVES file, and i think they have missiong values for the same grid cell every day. Maybe for 2020 run, i am providing this temperature info for this county in methods other than this METMOVES file and no need to go through this part of code…?
Can you clarify why you are using the 2020 platform and not the 2019 platform if you want to run 2019? There are important differences in the configurations such as the one described here.
In order for the SMOKE_DAILY file for 2019 to work, you also need to use the spatial surrogates from 2019 platform / 2017NEI. The reason is because there is a slight difference in which cells receive emissions in the 2019 surrogates versus the 2020 surrogates. In particular, there is one cell in Yuma County that receives emissions in 2020 (based on 2020 surrogates) but not in 2019 (based on 2019 surrogates). It is the purple cell here:
This cell has temperature data in the 2020 SMOKE_DAILY but not the 2019 SMOKE_DAILY. So when you use the 2019 SMOKE_DAILY in combination with the 2020 surrogates, that cell with a surrogate value but not a temperature value causes an error. There are other cells along coastlines which would trigger a similar issue, but Yuma is just the first such cell that Movesmrg encounters. So basically, 2019 SMOKE_DAILY plus 2019 spatial surrogates should work.
I think I now understand i cannot simply copy SMOKE_DAILY file for used for 2019 platform, since spatial surrogate is different. Maybe new road is built for a certain part of country between two base year, or for some other reason that 2020 platform onroad/RPP processing need met data for more grid cell. Besides, min/max temperature for a grid cell for different year is different, and seems to be causing some other problem if i dont process proper way.
I ran MET4MOVES with correct met files and . It isn’t bad to go through this, i actually spent more time by my hacking for filling gap, and it is not accurate. I am running onroad/RPP sector now, and see if i can get through.
But, that doesnt use 2020 NEI, correct? We want to use later inventory. We are processing for 2019 only because the CMAx setting we have is based on 2019 met modeling. So we want to use 2020 data (latest available right now). Does this make sense?
What we want to accomplish is to run CAMx to get HAP concentration in the air, in finer spatial detail (at least 4km, ideally finer resolution). So we figured it makes most senst to start with 2020 NEI, and reprocess it with HAP export enabled. Also we define finer resolution grid for our area of interest.
In addition to above, we want to have boundary condition for this small area of interest, and for that i need CONUS HAP inventory in 12km resolution. So I am rerunning 2020 platform with HAP output. I am choosing 2019 met year, since our modeling episode is for 2019, as i said. Since this is needed only to establish boundary condition of our interest. We dont need super accuracy for that. I thought about even do something very simple, like put county wide annual emission to be evenly distributed across county, with no temporal profile. But since there is already a platform to process 2020 EI, i thought it is actually faster for us to go through SMOKE processing of 2020 EI with twists of ours (HAP export, 2019 met).
We are not going to use this output to match with observation directly. Observation we have is for year 2022 and 2023. We could have started with met modeling for those two years, process 2020 NEI for thoese year to run air quality model. Because of resource limitation we stick with 2019 met data, and do statistical comparison (e.g., does the model capture the range of values observed), instead of time/space paird comparsion between model and obs.
Meanwhile, I also fudged with ATPRO_HOURLY_NCF input that used for livestop, taking equivalent file from 2019 platform. Do you see problem with that…?
Thank you for sharing the nature of your study – that explains some things. I don’t see a problem with pulling the 2019 temporal profiles for livestock.
I will note that if EGUs are included in your run, the CEMS data used are year-specific and follow patterns of demand based on the meteorology.
