It is not an error or warning, but I don’t know whether it is a must to repeatedly retireve BCFILE.
During my CCTM running on an domain (not nested), I find that the program has to call retrieve_boundary_data() to read BCFILE at every ASTEP (the time step in CCTM-HADV). That is because the tstep of BCFILE generated in the mode of PROFILE is zero, which will not change the variable cio_bndy_data_tstamp() used in function r_interpolate_var_2db, and then when RDBCON is called in hadvppm.F (CCTM-HADV), the same BCFILE (doesn’t change with time) is always necessary to retrieve.
But when I run CCTM in a nested domain, the tstep of BCFILE (generated in the mode of “regrid”) is 1 hour, and the program needs to only retrieve the BCFILE once an hour, which is reasonable.
I just want to know if there are some reasons to retrieve boundary conditions from BCFILE so many times. If not, maybe the code can be modified to save around 40% of the whole CCTM processing time when running on a 512x512x16 domain.
Thanks for your question. Could you please share which version of CMAQ you are using?
Versions prior to CMAQv5.3.2 had an issue with excessive read times when using time-independent boundary condition files. This issue was fixed in CMAQv5.3.2 and later.
CMAQv5.3.2 release notes
I wonder in your testing, did you see any run time difference in a substantial way?
From the coding point of view, the number of times subroutine interpolate_var (this is translated into r_interpolate_var_2db within centralized_io_module.F) is being called from rdbcon.F is unchanged no matter what type of boundary file (time dependent or independent) is used running CMAQ. Inside r_interpolate_var_2db, there is a distinctive treatment between time dependent and independent bc files. For the former case, when the requested data lies outside the time range in the circular buffer, a new hourly data will be read in from the bc file. However for the time-independent case, no bc data will be read in except at the very beginning of the simulation to fill up the circular buffer. I believe you anticipate the number of calls to r_interpolate_var_2db will be less for time independent bc file than time dependent bc file and that made you raise this concern. In summary, in CMAQ level, there is no mechanism (at this point of time) to determine what type of bc file is using. In subroutine interpolate_var, it does know how to treat them differently. We are grateful for you to bring this to our attention.
Thanks for your reply.
The version I am using is 5.3.1, which seems to be the point.
Thanks for your reply!
These are two of the cases I have tested:
Case.1, named d01. BCFILE generated in profile mode and domain is 512x512x16.
Case.2, named d01a. Same to Case.1 but I modified the code in CCTM to make the program skip the call of read3(BCFILE) except the firstime call, which means that the BCFILE will be read only once in one day.
In this way, for a single step of processing, HADV time cost is reduced from 12.7s to 2.7s and a whole processing step is reduced by around 40%.
CMAQ version issue. My apology. I have completely forgotten there was an issue in the earlier version.
Don’t worry about it. I really appreciate your attention to my issue.
Have a nice weekend!