CCTM with a long-timestep BCON data

Hi.
Let me ask about CCTM calculation (CMAQv5.3.1) using a custom-made BCON data with a timestep of 720h (~1 month). I could use such long-timestep BCON data for the CCTM of CMAQv5.0.2, but I encountered the following error when I executed CCTM of CMAQv5.3.1 with the long-timestep BCON data.

 >>--->> WARNING in subroutine RDTFLAG
 Error reading netCDF time step flag for BNDY_CONC_1
 M3WARN:  DTBUF 12:00:00  Dec. 31, 2018 (2018365:120000)

 >>--->> WARNING in subroutine bct:INTERP3
 Time step not available for "AECI" from BNDY_CONC_1
 M3WARN:  DTBUF 12:00:00  Dec. 31, 2018 (2018365:120000)


 *** ERROR ABORT in subroutine retrieve_boundar on PE 002
 Could not read BNDY_CONC_1                              file
 PM3EXIT:  DTBUF 0:00:00   Dec. 2, 2018
 Date and time 0:00:00   Dec. 2, 2018   (2018336:000000)

========================

With the following revision of CCTM/src/cio/centralized_io_module.F, it appears that the long-timestep BCON data was successfully read during the CCTM execution.

[Temporary fix of the subroutine retrieve_boundary_data]

  1. Replace “read3(BCFILE,…)” with “interp3(BCFILE,…)”.
  2. Replace “loc_jdate_met” with “loc_jdate” for the date of MET_BDY_3D data.
  3. Declare “USE M3UTILIO, ONLY : INTERP3”

========================
$ diff centralized_io_module.F.fixed centralized_io_module.F.orig

2745d2744
< USE M3UTILIO, ONLY : INTERP3
2756c2755
< & iter, loc_jdate, loc_jdate_met, loc_jtime_met, loc_jtime, v, beg_v, end_v
.> & iter, loc_jdate, loc_jtime_met, loc_jtime, v, beg_v, end_v
2783d2781
< loc_jdate_met = jdate ! temporary fix (YM)
2790c2788
< ! cio_bndy_data_tstamp(1, buf_loc, v) = loc_jdate ! temporary fix (YM)
.> cio_bndy_data_tstamp(1, buf_loc, v) = loc_jdate
2792d2789
< cio_bndy_data_tstamp(1, buf_loc, v) = loc_jdate_met ! temporary fix (YM)
2795d2791
< cio_bndy_data_tstamp(1, buf_loc, v) = loc_jdate ! temporary fix (YM)
2807c2803
< & loc_jdate_met, loc_jtime_met, cio_bndy_data(begin:end) ) ) THEN ! emporary fix (YM)
.> & loc_jdate, loc_jtime_met, cio_bndy_data(begin:end) ) ) THEN
2809c2805
< CALL M3EXIT ( PNAME, loc_jdate_met, loc_jtime_met, XMSG, XSTAT1 ) ! temporary fix (YM)
.> CALL M3EXIT ( PNAME, loc_jdate, loc_jtime_met, XMSG, XSTAT1 )
2815,2818c2811,2812
< ! if (.not. read3 (BCFILE, cio_bndy_var_name(v,1), -1,
< ! & loc_jdate, loc_jtime, cio_bndy_data(begin:end) ) ) THEN
< if (.not. interp3 (BCFILE, cio_bndy_var_name(v,1), cio_bndy_var_name(v,2),
< & loc_jdate, loc_jtime, (end-begin+1), cio_bndy_data(begin:end) ) ) THEN ! temporary fix (YM)
.> if (.not. read3 (BCFILE, cio_bndy_var_name(v,1), -1,
.> & loc_jdate, loc_jtime, cio_bndy_data(begin:end) ) ) THEN
2829c2823
< CALL NEXTIME ( loc_jdate_met, loc_jtime_met, file_tstep(f_met)) ! temporary fix (YM)
.> CALL NEXTIME ( loc_jdate, loc_jtime_met, file_tstep(f_met))
========================

I understand that my BCON data might not meet the requirement for the CCTM input data, but I’d like to know whether the above-mentioned program fix is correct or not for the CCTM calculation with a long-timestep BCON data.

Thanks in advance,
Yu

Yes. I’m surprised the code uses READ3; the original (back many years ago) did use INTERP3.

Hello Yu,
There was a similar bug in CMAQv5.3, which we addressed in CMAQv5.3.1. See bug fix #4 here. It is a bit surprising–and concerning–that you encountered a similar problem–are you sure you used v5.3.1 rather than v5.3?

Version 5.3.2 will be released soon. If the issue still occurs, please post again so that we can get this fixed.