Hi,
I am trying to use 2017 EPA model platform inventory and scripts to generate emissions for 2020 over my domain. I think I need the ‘Gentpro_TPRO_HOUR_HOURLY_BASH_NH3…ncf’ file to run AG sector. But the latest year I can find for this file is 2018. I searched some results here and it seems Gentpro program can generate it. So I am wondering if there is a script that can help me run the Gentpro program.
Thanks
Wei
We have not yet prepared an hourly temporal profile for 2020 but the “utilities” package posted with the 2016 beta platform has sample Gentpro scripts:
https://gaftp.epa.gov/Air/emismod/2016/beta/scripts/smoke_2016beta_platform_utilities.zip
One note: Gentpro from SMOKE v4.* doesn’t work for ag because of the way SMOKE v4.* formats FIPS codes with extra leading zeroes. So, for now we use Gentpro from SMOKE v3.7 when creating new met-based profiles for ag. We will add this to our list of things to fix. For RWC profiles, either version of SMOKE can be used.
A good QA check to do when eventually running SMOKE (Temporal) with the new profiles is to compare emissions on, for example, two different Wednesdays in the same month, and confirm the emissions on those two days are different in every county.
Thanks very much for the quick reply. I think I will have to dig into the scripts and run Gentpro.
I have one follow-up question. I have seen the 2D met data for the whole year of 2020 in: https://gaftp.epa.gov/Air/emismod/2020/met_for_emissions/12US1/. Would the 2D data be enough for running the Gentpro program? If this is true, I can save time for generating my own met data. And if I used these files, the grid resolution of the temporal files would be 12km. I guess I can use the temporal files to my own domain regardless of the resolution?
Thanks
Wei
Yes, you can use those met files as those are the only ones needed by Gentpro.
And Yes, Gentpro temporal files generated using 12US1 met can then be used in SMOKE for any CONUS domain.
Thanks for your answers! That is really helpful!!
Sorry to get back to you because I cannot find the 12US1 surrogate (459x299) anywhere in the CMAS’s warehouse or at EPA’s platform. Do you know where I can get that?
Thanks!
Surrogates are released with the EPA platforms. They don’t have to be on 12US1 – but can be on larger domains and SMOKE will work fine.
2016v2 surrogates are here: https://gaftp.epa.gov/Air/emismod/2016/v2/spatial_surrogates/
2017 surrogates are here – they are very similar to 2016v2: https://gaftp.epa.gov/Air/emismod/2017/spatial_surrogates/
So I go ahead and use the ‘us12k_516x444’ surrogate. It seems bigger than the 12US1 domain. But the Gentpro RWC stops saying ’ Subscript out of range for array matched (gentpro.f: 876) subscript=-1, lower bound=1, upper bound=3170, dimension=2’. And the end of the log file is like:
Since the 2D met data is 12US1, I am not sure if this is the issue.
Thanks
Wei
Right, it shouldn’t be a problem with the surrogate as SMOKE will subset it as long as it is aligned with the grid you are running.
Can you attach your full Gentpro log so we can help determine which input might be causing a problem?
Also, what are the key inputs you are running Gentpro with?
run_gentpro_rwc_smoke36.csh (4.4 KB)
Gentpro_TREF_DAILY_RWC.RWC_2011eh_11g_12US2_smk36_hou1v2.log.txt (9.0 KB)
I uploaded the run script and log file for your reference. Since the year I am running is 2020, I am not sure if the 2011 ‘Gentpro_TREF_DAILY_RWC.RWC_2011vf_11f.txt’ file would be an issue. And the ‘Gentpro_TREF_agNH3_RWC_2007ed.txt’ file for BASH_NH3 seems not in the folder of the 2016beta platform. Can I use the RWC file for BASH_BH3?
I really appreciate your help!
Wei
The error has to do with the temperature override file that specifies which states to apply a 60F temperature cutoff instead of the usual 50F. For some reason Gentpro is balking at the value of 60.0 and unable to convert that to REAL format. We haven’t seen that at EPA. Some things to check or try:
We assume you haven’t made any changes to the RWC_county_threshold.csv file that was posted? Or did you make your own?
Change the “60.0” values to “60” (no decimal place) and see what happens
Try the precompiled SMOKE 3.7 Gentpro executable from https://gaftp.epa.gov/Air/emismod/2011/v3platform/smoke_2011v6_3_platform.zip ?
Thanks for the response.
I did not change the RWC_county_threshold.csv file. And changing 60.0 to 60 does not work for me. I then tried to use smoke 3.7. And the log file shows that the TREF_IN file seems too old from 2016beta platform. Is there a new format from smoke3.7?
Gentpro_TREF_DAILY_RWC.RWC_2011eh_11g_12US2_smk36_hou1v2.log.txt (8.3 KB)
Thanks
Wei
Yes, the temporal profile formats changed in SMOKE 3.7 – thanks for the reminder…
That may be part of the issue.
There are other later TREF files with platforms after 2016 beta.
That platform definitely used a version of SMOKE after the formats changed.
Thanks for the confirmation! Could you kindly point out where I can find the new files? I looked through the years after 2016 but with no luck.
Thanks!
Wei
Even the 2016 beta platform used SMOKE 4.6 which is much later than SMOKE 3.7.
I’m not sure which file(s) you are looking for but couldn’t find?
The temporal profiles are available with each platform under ancillary_data e.g.
https://gaftp.epa.gov/air/emismod/2016/v2/ancillary_data/2016v2_temporal_ge_dat_15sep2021.zip
https://gaftp.epa.gov/air/emismod/2017/ancillary_data/ge_dat_for_2017gb_temporal_29jun2020.zip
https://gaftp.epa.gov/air/emismod/2018/ancillary_data/ge_dat_for_2018gc_temporal_11oct2021.zip
Thanks for your help!! Now I can successfully create the 2020 monthly and daily profile for RWC sector. But when I used these files in the annual script of the 2017platform, they cannot be read in properly. Then I compared them with the 2017 default profile. The format seems different (attached below). Do I need to add quote marks to the profile ID column to make it work?
I really appreciate your help!
Wei
Which version of GentPRO did you use? Was it from SMOKE 3.7 package?
I tried to use both SMOKE 3.7 and 4.7 precompiled Gentpro. And they gave the same format.
Wei
We note that you have the correct format for the ATPRO_DAILY file.
It looks like the leap year was handled properly – the header of that file says 2020001-2020366.
To confirm for sure, you could check the February profiles (second column 02) for a county that is definitely colder than 50 degrees on 2/29 (e.g. somewhere in Minnesota or North Dakota) and confirm that the DAY29 column is nonzero. (For February, the DAY30 and DAY31 columns will be zero.)
If Temporal is crashing due to a formatting problem, can you provide the Temporal log file?
Thanks for the quick reply.
Below is the screenshot of the daily file in a Minnesota county of February. I am not sure the unit of the numbers, but the Day30 and Day31 are zeros.
I also attached my temporal log file.
temporal_rwc_hou1v2_20200801.log.txt (400.6 KB)
Thanks for debugging with me.
Wei
