I just want to discuss if this is a potential bug for emission reading on a new day when doing a cross-day simulation. This points to the diagnostic part of the codes in the DESID_DRIVER subroutine, which further links to the GR3D subroutine. My understanding is that the ‘DESID_STREAM_DATE( FSTREAM )’ will not update to the new date and that would cause wrong interpolation ratios in the centralized IO module.
Another small thing is that if I activate the ‘hrdebug’ macro, there will be an error in hrsolver when compiling the model. It seems the dimension of RXRAT is wrong.
We tested this behavior before the release of CMAQv5.3 and the day for the emissions does advance. See 936 in the GR3D subroutine. If you come across a specific case where this issue occurs, we would be happy to look further into it.
Thanks for the reply. I am running NOAA’s AQM model and it only uses CMAQ’s emission processing the chemistry, so I guess you cannot use the input. I tested to use a different TSTEP(1), and the error disappeared. So, I think they cannot be set the same.
Could you be more specific what you meant "cannot be set the same"? All emission input time step must be the same or all input? After will your clarification, I will look into the cio implementation.
I got the error when I used the same TSTEP(1) and TSTEP(2), which is 3 mins. I solved it after I set a different TSTEP(1), (e.g., 1h) with TSTEP(2) keeping 3 mins. I am not sure if this is an issue in cio or desid.
I see now. Yes typically we set TSTEP(1) = 10000 and it is not related to cio. Once I have time, I will try to set it be the same as TSTEP(2) to see whether we can reproduce the problem.