Hi all,
I am confused about an issue as described below.
I would like to initialize my CMAQv5.3.2 run started in UTC+8 with a day-by-day simulation. For example, the CMAQv5.3.2 starts on Jan 1st 08:00 UTC. When the simulation time moves forward to Jan 2nd 00:00UTC, the CMAQ will try to find the emission for UTC+9 for next day rather than UTC+0 which is not available in the emission file. Then, the model will crash. This is quite strange that why the model will try to read UTC+9 for Jan 2nd at the timestep of Jan 2nd UTC00:00.
The time configuration in CCTM.csh is listed below.
Any comments are highly appreciated! @hogrefe.christian@lizadams
#> Set Start and End Days for looping
setenv NEW_START TRUE #> Set to FALSE for model restart
set START_DATE = “2018-01-01” #> beginning date (July 1, 2018)
set END_DATE = “2018-12-31” #> ending date (July 14, 2018)
#> Set Timestepping Parameters
set STTIME = 080000 #> beginning GMT time (HHMMSS)
set NSTEPS = 240000 #> time duration (HHMMSS) for this run
set TSTEP = 010000 #> output time step interval (HHMMSS)
To help us diagnose the issue, could you please attach your entire run script as well as the output of ‘ncdump -h’ for file GR_EMIS_001?
Aside from the wrong hour, it also seems the routine is looking for the wrong year (2020 instead of 2018). Does GR_EMIS_001 cover 2018001:080000 to 2018002:080000?
Hi Christian,
The run.cctm.csh has been attached. Yes, I note that the TFLAG in the emission file starts at 2020001:0800. However, as far as I am concerned, the date in TFLAG does not matter if we set the following option in the run.cctm.csh. Am I correct? setenv GR_EM_SYM_DATE_001 T
At this time, I am trying to resolve this issue by using m3tools to extract the UTC00 to UTC24 for each day and then combine them into a new emission file which has 25 hours and starts at UTC00 and ends at UTC00 in next day. While it looks like the issue can be resovled by this solution, I would like to know the exact solution for initilize on UTC+8.
The setting of GR_EM_SYM_DATE_001 to T indeed is what appears to be causing the problem in this particular case where STTIME is not 0. One of my colleagues performed a quick test to confirm that this particular combination of options (GR_EM_SYM_DATE_001 T, STTIME 080000) cannot currently be handled by CMAQ.
We will have a look at updating the code to handle this situation in the future. In the meantime, either following your approach of creating new emission files that run from UTC00 to UTC00 and changing STTIME to 0, or an alternate approach of using m3thift to change the year of your existing UTC08 - UTC08 emission files from 2020 to 2018 and changing GR_EM_SYM_DATE_001 from T to F should work.
Hello Bonyoung, unfortunately we weren’t able to address this issue prior to the code freeze for our CMAQv5.3.3 release.
If using m3tshift or a similar tool to create separate emission files for each day (which would then allow you to change GR_EM_SYM_DATE from T to F to avoid this error) is not an option, please reach out to me directly and I will put you in touch with a colleague who has a potential code fix for this problem.
