ERROR: No gridding cross-reference available when run onroad/RPV

I am trying to do a normal AQM-style CAP-focused run for CB6.

Thank you.

We recommend that you use the inputs and parameters from the 2016fj scripts (https://gaftp.epa.gov/Air/emismod/2016/v2/) with the exception of the 2019 activity data, EFTABLES, MCXREF/MFMREF (rep counties), and MRCLIST files which would be substituted with the 2019 versions of those

I see, thank you for this detailed information.

Sorry, one more error when I ran airport sector in smkmerge_airports_nov_2019ge_cb6_19k_20191124_US12KM_cmaq_cb6ae7.log
There are files in intermed/airports (ptmp_airports_nov_2019ge_cb6_19k_2019328.ncf ~2019334.ncf).
It seems that it can not use right name to find files.

 "PTMP_FRI" opened as OLD:READ-ONLY
 File name "/../smoke2019//2019ge_cb6_19k/intermed/airports/ptmp_airports_nov_2019ge_cb6_19k_2019330.ncf"
 File type GRDDED3
 Execution ID "????????????????"
 Grid name ""
 Dimensions: 62984 rows, 1 cols, 1 lays, 10 vbles
 NetCDF ID:    393216  opened as READONLY
 Starting date and time  2019330:000000 (0:00:00   Nov  26, 2019)
 Timestep                          010000 (1:00:00 hh:mm:ss)
 Maximum current record number        25
 PTMP_SAT        :/../smoke2019//2019ge_cb6_19k/intermed/airports/ptmp_airports_nov_2019ge_cb6_19k_.ncf

 >>--->> WARNING in subroutine OPENSET
 File not available.

 Could not open file set "PTMP_SAT".

 *** ERROR ABORT in subroutine OPENMRGIN
 Could not open file set "PTMP_SAT".

Annual_airports_daily_12US1_2019.csh (7.6 KB)
smkmerge_airports_nov_2019ge_cb6_19k_20191124_US12KM_cmaq_cb6ae7.log.txt (12.9 KB)
Thank you in advance.

First we recommend setting EPI_STDATE_TIME back to the original value, which is:

setenv EPI_STDATE_TIME “${BASE_YEAR}-01-01 00:00:00.0”

Even your modeling period starts on 11/24, you should keep EPI_STDATE_TIME set to 1/1, because some of the date settings may not work otherwise. The RUN_MONTHS and SPINUP_DURATION parameters are what should be used to select the time period instead of changing the start date and time.

Also, this may or may not be necessary, but for sectors like airports with representative dates (i.e. where M_TYPE != ‘all’), instead of RUN_MONTHS = 12 and SPINUP_DURATION = 7, we recommend using RUN_MONTHS = “11 12” and SPINUP_DURATION = 0 and just have SMOKE output emissions for all of the representative dates in November.

Thank you for this detailed information. Let me test it. I am not sure if I only have MCIP files from Nov. 24 to Dec. 31 and generate 3D point source emissiosns, is it OK for the set RUN_MONTHS = “11 12”?

Well for airports it will be OK as it doesn’t use met data.

Or you could consider setting it to just 12 and setting spinup to the number of days you have in November

thank you for your quick reply. I got a new error.

testing SRGPRO_PATH set by SRGPRO input: /…/smoke2019//ge_dat/gridding/surrogates/CONUS12_2017NEI_04mar2021_oilgas_2019/
Linux2_x86_64ifort
testing SRGPRO_PATH set by SRGPRO input: /…/smoke2019//ge_dat/gridding/surrogates/CONUS12_2017NEI_04mar2021_oilgas_2019/
Linux2_x86_64ifort
testing SRGPRO_PATH set by SRGPRO input: /…/smoke2019//ge_dat/gridding/surrogates/CONUS12_2017NEI_04mar2021_oilgas_2019/
Linux2_x86_64ifort
Number of dates to run for nov : 30
testing SRGPRO_PATH set by SRGPRO input: /…/smoke2019//ge_dat/gridding/surrogates/CONUS12_2017NEI_04mar2021_oilgas_2019/
Linux2_x86_64ifort
mondate is 2019308 2019315 2019322 2019329
tuedate is 2019309 2019316 2019323 2019330
weddate is 2019309 2019316 2019323 2019330
thudate is 2019309 2019316 2019323 2019330
fridate is 2019309 2019316 2019323 2019330
satdate is 2019306 2019313 2019320 2019327
sundate is 2019307 2019314 2019321 2019328
setenv: Too many arguments.

found answer for this error in this link.

Sorry, one more error again for cmv_c1c2.

SCRIPT ERROR: Some file patterns not matched for style Hourly_CMV
According to MULTIFILE_NAMEBREAK, the file prefixes are:
/…/smoke2019//2019ge_cb6_19k/inputs/cmv_c1c2_12/cmv_C1C2_11_cmv_c1c2_2019_12US1
Check file names and rerun
ERROR: Could not run combine_data.csh for hourly list file in Annual_area

I compared the hourly input files for 2019 and 2017, file name pattern are different. Is it OK to just rename those files or is there other better way to fix this error?

Thank you.

2019: cmv_C1C2_01_cmv_c1c2_2019_12US1_2019_CA_hourly.csv
2017: cmv_c1c2_2017adjust_20200422_12US1_2017_10_CA_hourly.csv
I am not sure if that is the reason.

Why would you combine the 2019 and 2017 files? Do you mean in the same directory? If so, I suggest separating them into different directories.

Sorry to confuse you. I did not combine them. They are not in the same directory. I just don’t know the reason for the error. I used the scripts in 2016v2, my guess if it is due to the different file name format. I just tested to rename 2019 file to be cmv_C1C2_cmv_c1c2_2019_12US1_2019_01_CA_hourly.csv, still not work.

worked after comment out this #setenv HOUR_SPECIFIC_YN “Y” :smiley:

We have posted some scripts here as .txt files: https://gaftp.epa.gov/Air/emismod/2019/

The 2019 CMV files had different naming conventions than 2016 platform

Check out the combine_data and smk_pt_daily scripts.

We plan to post a full portable set of scripts by early 2023.

Hi Alison,

Thank you for this information!
I have generated onroad and point emissions in Dec., 2019. I am not sure if these two new scripts impact much or not. Do I have to regenerate those emissions using the combine_data and smk_pt_daily scripts?

Thank you.

I don’t think you need to regenerate things that you have working – there were changes in the scripts for the CMV which you said you had problems with and these should address those issues.

I see, thank you for your help! :smiley:

Hi Alison,

I did not use CMAQ and did not see fertilizer emission from NEI2019, could I use that from NEI2018 folder for 2019?

Thank you.

It is probably better for you to start a new ticket when the topic diverges from the original.

But, FYI we just uploaded a zip of 2019 fertilizer emissions to this folder – they do vary by year so it’s best not to mix and match years:

https://gaftp.epa.gov/Air/emismod/2019/2019emissions/

I see, thank you for the update and suggestion.