# CMAQ fails with 2nd day EMIS file

**URL:** <https://forum.cmascenter.org/t/cmaq-fails-with-2nd-day-emis-file/1570>\
**Category:** CMAQ\
**Created:** [June 11, 2020, 2:21pm UTC](https://forum.cmascenter.org/t/cmaq-fails-with-2nd-day-emis-file/1570 "2020-06-11T14:21:29Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![hannah.n](https://avatars.discourse-cdn.com/v4/letter/h/48db29/32.png) [@hannah.n](https://forum.cmascenter.org/u/hannah.n)\
**Post date:** [June 11, 2020, 2:21pm UTC](https://forum.cmascenter.org/t/cmaq-fails-with-2nd-day-emis-file/1570/1 "2020-06-11T14:21:29Z")

</div>

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 ![ANTH_INDO_2019_D01_20190901.txt|attachment](https://canada1.discourse-cdn.com/flex027/uploads/cmas/original/1X/6988db17cdeb52b73f6bacdbadb750d8ff4b3c74.txt) (8.3 KB)

Thanks!

---

<div class="post-metadata">

**Author:** ![lizadams](https://avatars.discourse-cdn.com/v4/letter/l/49beb7/32.png) [@lizadams](https://forum.cmascenter.org/u/lizadams)\
**Post date:** [June 11, 2020, 3:21pm UTC](https://forum.cmascenter.org/t/cmaq-fails-with-2nd-day-emis-file/1570/2 "2020-06-11T15:21:58Z")

</div>

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](https://forum.cmascenter.org/t/incorrect-timestepping-for-elevated-point-source-emissions/1214)

---

<div class="post-metadata">

**Author:** ![cgnolte](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.cmascenter.org/cgnolte/32/53_2.png) [@cgnolte](https://forum.cmascenter.org/u/cgnolte)\
**Post date:** [June 11, 2020, 3:27pm UTC](https://forum.cmascenter.org/t/cmaq-fails-with-2nd-day-emis-file/1570/3 "2020-06-11T15:27:11Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![cjcoats](https://avatars.discourse-cdn.com/v4/letter/c/ac8455/32.png) [@cjcoats](https://forum.cmascenter.org/u/cjcoats)\
**Post date:** [June 11, 2020, 3:37pm UTC](https://forum.cmascenter.org/t/cmaq-fails-with-2nd-day-emis-file/1570/4 "2020-06-11T15:37:12Z")

</div>

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…

---

<div class="post-metadata">

**Author:** ![hannah.n](https://avatars.discourse-cdn.com/v4/letter/h/48db29/32.png) [@hannah.n](https://forum.cmascenter.org/u/hannah.n)\
**Post date:** [June 11, 2020, 4:05pm UTC](https://forum.cmascenter.org/t/cmaq-fails-with-2nd-day-emis-file/1570/5 "2020-06-11T16:05:10Z")

</div>

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](https://forum.cmascenter.org/uploads/short-url/6X6okrBHMYp403fWt68fEetRVsc.txt) (173.6 KB) [run\_cctm.csh](https://forum.cmascenter.org/uploads/short-url/5v1v2rj9eO9ZbRdOXNneEPfJPYw.csh) (32.3 KB)

Many thanks!

---

<div class="post-metadata">

**Author:** ![cgnolte](https://yyz1.discourse-cdn.com/flex027/user_avatar/forum.cmascenter.org/cgnolte/32/53_2.png) [@cgnolte](https://forum.cmascenter.org/u/cgnolte)\
**Post date:** [June 11, 2020, 4:35pm UTC](https://forum.cmascenter.org/t/cmaq-fails-with-2nd-day-emis-file/1570/6 "2020-06-11T16:35:26Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![hannah.n](https://avatars.discourse-cdn.com/v4/letter/h/48db29/32.png) [@hannah.n](https://forum.cmascenter.org/u/hannah.n)\
**Post date:** [June 12, 2020, 8:32am UTC](https://forum.cmascenter.org/t/cmaq-fails-with-2nd-day-emis-file/1570/7 "2020-06-12T08:32:03Z")

</div>

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!

---

<div class="post-metadata">

**Author:** ![lizadams](https://avatars.discourse-cdn.com/v4/letter/l/49beb7/32.png) [@lizadams](https://forum.cmascenter.org/u/lizadams)\
**Post date:** [June 12, 2020, 1:45pm UTC](https://forum.cmascenter.org/t/cmaq-fails-with-2nd-day-emis-file/1570/8 "2020-06-12T13:45:11Z")

</div>

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](https://www.cmascenter.org/ioapi/documentation/all_versions/html/BUFFERED.html)
