Yes, I have those premerged data from the IWDW.
But right now, I just want to get emis_mole & inline files for each day for the nonipm sector as base SMOKE run has missing files for each day (comment #1 ) due to temporal allocation in L_TYPE & M_TYPE.
OK – I think we now understand what is going on. With the EPA platform, there are scripts for doing the CAMx conversion that do not require files to be there for each day.
The 2016v1 package includes CAMx conversion scripts. See section 8 of this file:
Hello @eyth.alison
Sorry for the late reply. I was trying to solve this. But faced the following error:
So, as your suggestions I modified L_TYPE and M_TYPE to ‘all’ and ‘mwdss_Y’ to ‘all’ in the SECTORLIST file. T1_Annual_ptnonipm_daily_36US3_2028fh_16j.csh.txt (7 KB)
But run stopped automatically after only two days output
Hello @eyth.alison
It’s working. Thank you so much. One more question:
How do I confirm that my output has no error. My SMOKE run has generated one file for each day and each files are same size. Is that enough to conclude that run is success?
Along with what Alison mentioned, their run scripts use m3stat tool to make sure that those output files are created correctly. If the format of output is not complete, there will be an error message.
You can edit the “run_setting.txt” run setting file located under run scripts folder to enable Smkreport runs. By default, there should be already some Smkreport reports generated by Smkreport like county, state, county-scc, and so on summary report. Check your log folder to find out which reports are generate by review the Smkreport log files. If you wish to generate any additional reports, then you can update the run setting input file.
Hello @eyth.alison and @bbaek ,
So, I was double checking the outputs by using m3diff. According to https://www.epa.gov/sites/production/files/2020-11/documents/2016v1_emismod_tsd_508.pdf , "The value “mwdss” means hourly emissions for one representative Monday, representative weekday (Tuesday through Friday), representative Saturday, and representative Sunday for each month. This means emissions have variation between Mondays, other weekdays, Saturdays and Sundays within the month, but not week-to-week variation within the month"
So, Tuesday represents Wednesday, Thursday, and Friday. So, for the 1/5/2016 (Tuesday) result should match with 1/7/2016 (Thursday). But when I use DEFAULT (A-B) m3diff analysis for emis_mole files for these specific dates, the top differences are:
[Michael@ADEQPlanning ptnonipm_ARDEQ_allday]$ m3diff infileA infileB DEFAULT | grep -w “A:B” newfile | awk -F’@’ ‘{print $1}’ | sort -rk3 | head -10
A:B 9.96206E-07
A:B 9.94815E-07
A:B 9.92429E-06
A:B 9.91113E-06
A:B 9.90092E-06
A:B 9.89054E-07
A:B 9.87940E-04
A:B 9.82778E-06
A:B 9.79428E-07
A:B 9.78180E-05
The gist of this question is, when you create ptnonipm emissions for every day, should Thursday emissions be the same as Tuesday emissions. This is a good question to ask…
It turns out there is one SCC in the ptnonipm sector which uses a temporal profile which is not the same for every day Tuesday through Friday. It is an airports SCC. So, emissions generated using Thursday temporal profiles will in fact be just a little bit different from Tuesday, but only for that one SCC, and only slightly because that SCC is in just two counties, and because the weekly profile doesn’t have that much Tuesday-Friday variation. So for this reason, the emissions won’t be exactly the same between the days. You are probably better to create some Smkreports to make sure the gist of the emissions totals are consistent.
@eyth.alison I am trying to get output files for every day in my episode for the airports sector. I tried the fix described here for ptnonipm. I changed my sectorlist to “all” and the M_TYPE,L_TYPE variables to “all”. I commented out MRG_BYDAY and I replaced the final line in the Annual_airports scripts with
Regarding replacing the final line of the scripts with $RUNSCRIPTS/emf/smk_pt_daily_emf.csh … this particular change should only be done to the ‘daily’ script, not the ‘onetime’ script.
The onetime script should still have “$RUNSCRIPTS/emf/smk_pt_annual_onetime_emf.csh $REGION_ABBREV $REGION_IOAPI_GRIDNAME onetime” as the last line.
We don’t think changing the onetime script would cause the SPINUP_LIST error message though, so it might be something else. Can you provide your airports run scripts and standard output?