Could not extract GR_EMIS_001 file in CMAQ run

My test CMAQv5.3.1 simulation of 36km CONUS domain stopped in 30 minutes with this error:

The simulation was supposed to start at 20140102:030000 and end at 20140104 but as you see in the error above, for some reason, the error says ‘Time step not available for file: GR_EMIS_001’ seemingly for the timestamp 2014003:010000 even though when I checked the acutal GR_EMIS_001 file, it had that timestamp.

Could you post your run script and the main log file?

Hi @cgnolte, thanks for showing concern, and sorry for the late reply. I was on a different machine and did not have the old machine’s error I mentioned in this topic, but even on the new machine, the same error persisted. It turns out the issue was due to a bug when using representative dates for emissions, and I just used bug-fix at github to recompile CMAQ. That problem is now gone, but a new problem probably unrelated to the one in this thread came up - I have started a new thread for that new issue at Longjmp causes uninitialized stack frame.

I managed to get other errors away with LTNG and WB_DUST set to off, but the error Could not extract GR_EMIS_001 persisted (Run starts at 20140102:030000 and goes smoothly till the end of 20140102 and then exits when simulation for 20140103 starts), so I am revisiting the thread! The standard output shows this error towards this end:

The CTM_LOG_015* file has this:

I have checked my emission file for that day, and it exists and has the required timestamp.
slurm-5749119_4294967294.out.txt (244.1 KB) run_cctm_2016_12US1_stamp2_12US2_testrun_myfix_22may2020.csh (46.2 KB) CTM_LOG_015.v531_intel_2016_CONUS_20140102.txt (746.6 KB)

You are starting the run at 2014002:030000, and attempting to run for 24 hours.
Your GR_EMIS_001 emissions file begins at 2014002:000000, and contains 25 1-h time steps:

     "GR_EMIS_001" opened as OLD:READ-ONLY   
 File name "/home1/05774/tg850734/scratch/cmaq_run_18may2020/cmaq_in/emis/2d_emis/ag/m3tshift_to_20140102_on_18may2020_m3wndw_to_12US2_on_18may2020_emis_mole_ag_20160102_12US1_cmaq_cb6_2016fh_16j.ncf"
 File type GRDDED3 
 Execution ID "????????????????"
 Grid name "12US2"
 Dimensions: 246 rows, 396 cols, 1 lays, 29 vbles
 NetCDF ID:    524288  opened as READONLY            
 Starting date and time  2014002:000000 (0:00:00   Jan. 2, 2014)
 Timestep                          010000 (1:00:00 hh:mm:ss)
 Maximum current record number        25

Thus, the last time step is at 2014003:000000, and when the model looks for 2014003:010000, that data cannot be found, and the model aborts with an appropriate error message “Time step not available.”

Where you say “I have checked the emission file for that day, and it exists and has the required timestamp”, the log file indicates that is not the case. How did you check the time stamps? One way to do so is ncdump -vTFLAG <filename>.

Thanks a lot - I had been thinking that STTIME was only for the first day of the simulation, so I started from 2014002:030000 hours and set TSTEPS to 240000 hoping that from the second day onwards, the simulation would start at 2014003:000000 and end at 2014003:230000. My chemical BC files start at 030000 hrs and not at 000000 hrs, so if I set STTIME to 030000, START_DATE to 2014002 and TSTEPS to 210000, would CMAQ still run in 21 hours chunks for all days of the simulation period with this setting?

It might be helpful if you stated as clearly as you can what it is you are trying to do, rather than simply what error you are encountering. If you already said this in a previous thread, then I may have missed it or forgotten.

What is the overall time period you want to model? One day, or multiple days? You can run in 21-h run segments, followed by a 3-h run segment, and then repeat as many times as you like. I’m not clear why you would want to do so.

Your gridded emissions files start at 0Z and contain 25 time steps each. Do you have separate emissions data files for each day?
Your met files start at 040000 on 1 Jan and contain data for 741 hourly time steps, so presumably you want to run for about a month.
Your BNDY_CONC file starts at 030000 on 2 Jan and contains data for 5 6-h time steps.
If you have multiple BNDY_CONC files, then why not put them together into a single file, analogous to what you have done for the met data? You can use m3xtract for this, appending to the existing file as you go, until you have a month-long file.
Then you can start at 0Z on Jan 3, and run for 24-h periods. If you really want to start at 030000 on Jan 2, then first do a 21-h run segment, and pick up the run from there.

Thanks for the good suggestions - I was going for long simulations like you said, but hadn’t thought of these tricks.

No one seems to be using the file-set lists capabilities (requires I/O API 3.2; there were bugs in 3.1’s implementation of file-set lists). For example:

setenv GR_EMIS_001 "E1,E2,E3,E4,E5
setenv E1 <path for first-day emissions file>
setenv E2 <path for second-day emissions file>
setenv E3 <path for third-day emissions file>
setenv E4 <path for fourth-day emissions file>
setenv E5 <path for fifth-day emissions file>
[and similarly for other time stepped input files]
time CCTM.exe    !!  five-day continuous run
set foo = ${status}
if ( ${foo} != 0 )  then
    echo "*** ERROR ${foo} in CCTM.exe "
    exit ( ${foo} )

[Note that the script checks the error-status for CCTM.exe and exits (with a message and passing that status along as the status of the script) in case of failure…]