Hi
I’m having an issue with CMAQ reading in the second day’s Emissions file. The first day (2019243) runs fine, but for the second day I get this error:
Processing Day/Time [YYYYDDD:HHMMSS]: 2019244:000000
Which is Equivalent to (UTC): 0:00:00 Sunday, Sept. 1, 2019
Time-Step Length (HHMMSS): 000500
netCDF error number -40
>>--->> WARNING in subroutine RDTFLAG
Error reading netCDF time step flag for GR_EMIS_001
M3WARN: DTBUF 1:00:00 Sept. 1, 2019 (2019244:010000)
>>--->> WARNING in subroutine XTRACT3
Time step not available for file: GR_EMIS_001
M3WARN: DTBUF 1:00:00 Sept. 1, 2019 (2019244:010000)
*** ERROR ABORT in subroutine retrieve_time_de on PE 031
Could not extract GR_EMIS_001 file
PM3EXIT: DTBUF 1:00:00 Sept. 1, 2019
Date and time 1:00:00 Sept. 1, 2019 (2019244:010000)
From what I understand this is a timestamp issue, but I have triple checked my emissions inputs netcdfs for 2019244 (attached) and they have the correct start time of 2019244:000000 and I have tested running straight from the second day and the GR_EMIS_001 is read in fine and runs for 2019244.
What is DTBUF and why has it added an hour to the start time? Any advice on this would be really appreciated
(8.3 KB)
Thanks!
If you are using CMAQv5.3, then this issue contains a discussion about the error, and the best fix is to upgrade to CMAQv5.3.1. Incorrect timestepping for elevated point source emissions
The attachment did not come through, at least for me using Chrome.
The error message indicates it is GR_EMIS_001, which is a gridded emissions file, rather than a point source file.
Please specify what version of CMAQ you are using.
What do you mean when you say “tested running straight from the second day”? Please describe more clearly what the run settings are that lead to an error, and what run settings work ok.
It looks as though the GR_EMIS_001 file for this run does not contain all the data it needs.
This message indicates that the program is trying to process date&time 2019244:010000 and failing because the requested time-step is not available in the file.
As a secondary check, what happens when you use M3Tools program m3stat to look at the file, in particular,
m3stat GR_EMIS_001 DEFAULT
My suspicion is that something will fail for date&time 2019244:010000…
Thanks for the quick response,
I am already running CMAQ5.3.1, so I think this is not the issue, and yes these are gridded emissions files.
When I say I ran it from the second day what i mean is - If I run CMAQ from 2019243 it runs for 2019243 then fails when trying to open the GR_EMIS_001 for 2019244, but if I change the the simulation start day to 2019244, and run with ICs for 2019244 it reads in the 2019244 GR_EMIS_001 file without error, runs the whole of 2019244, and then fails again when trying to open GR_GRID_001 for 2019245 with the same error. I kept the same run setting in all except for changing the start day and different IC ect.
I ran several consecutive days of GR_EMIS_001 through m2stat as you suggested, the output is attached and seems to show that all time steps are present and completes succesfully.
It seems to be an issue with transitioning from one day to the next, I have also attached my run script
m3stat_test.txt (173.6 KB) run_cctm.csh (32.3 KB)
Many thanks!
The CMAQ run script that EPA distributes is set up for multiple executions of the model, with each run being 24 hours. You have set NSTEPS to 1440000, or 144 hours, equal to 6 days. It is possible to do a single execution for 6 days (or far longer), but you need to have all your meteorology, emissions, IC/BCs, etc., available in the files specified by the run script. Here your gridded emissions file for September 1 contains only 24 time steps, and CMAQ does not know to look for the next file.
I think you just need to change NSTEPS to 240000 and the run should be ok.
1 Like
This makes sense now, I was trying to run multiple days with a single execution, but had only seen the single day benchmark example files. I hadn’t realised all days had to be contained in the same IC, BC MET and EMIS files to do this.
Thank you very much!
You may be able to use the I/O API File-Set File Lists to combine multiple 24 hr emis/bc/ic files into a single logical filename.
'Multiple files which have the same structure (type, dimensions, list of variables, time step), and which cover an extended time period may be opened under a single logical name by: ’
https://www.cmascenter.org/ioapi/documentation/all_versions/html/BUFFERED.html
1 Like