Hi all again,
I doing some tests for 2 different domains with CMAQ by changing the IBCON data. These are the configurations adopted:
profile mode with default of CMAQ: using the file avprofile_cb6r3m_ae7_kmtbr_hemi2016_v53beta2_m3dry_col051_row068.csv
IBCON provided by GEOS-Chem with resolution of 4x5 degrees
IBCON provided by GEOS-Chem with resolution of 2x2.5 degrees
The simulations with configurations 2 e 3 are fine. They concluded with successful with 3-4 days using 2 nodes (total of 80 tasks).
However the first configuration (with default file of CMAQ) is taking too much time. Is someone knows why that is happening?
The only difference that I am finding in the logs are the HADV time, that i think it is causing the issue.
The parameters related to time-step length are equal for all configurations.
setenv CTM_MAXSYNC 720 #> max sync time step (sec) [ default: 720 ]
setenv CTM_MINSYNC 60 #> min sync time step (sec) [ default: 60 ]
setenv SIGMA_SYNC_TOP 0.7 #> top sigma level thru which sync step determined [ default: 0.7 ]
setenv CTM_ADV_CFL 0.75 #> max CFL [ default: 0.75]
The screen shot you posted indicates a one-minute time step. That is the minimum you are specifying via CTM_MINSYNC. Are the other runs using a different domain and meteorological data sets? If so, the amounts of time required may be very different.
When I mentioned that the simulations were with different domains, I meant that, when comparing one with their respectives, all the simulations that adopted the IBCON profile are facing the same issue.
Meteorological data are from the same dataset.
If I understand it correctly, only the PROFILE version is not working. My guess is that the file is corrupted or incomplete. Have you QA’d the file? Given that one works and one doesn’t, it would probably highlight a problem if you compared the magnitudes you might find something. If you used aqmbc, then I am guessing you have access to PseudoNetCDF on your system. The command below can be run from the command line and will print the min, mean, and max for each variable for two datasets for easy comparison.
python -ic "
import PseudoNetCDF as pnc
bconpathg = 'BCON_GEOS.nc'
bconpathp = 'BCON_v531_RGMV_profile_20191031'
bconfg = pnc.pncopen(bconpathg, format='ioapi')
bconfp = pnc.pncopen(bconpathp, format='ioapi')
varkeys = getattr(bconfp, 'VAR-LIST').split()
for varkey in varkeys:
varp = bconfp.variables[varkey]
valsp = varp[:]
print(f'PROFILE,{varkey:>16s},{valsp.min():.2e},{valsp.mean():.2e},{valsp.max():.2e},{varp.units}')
if varkey in bconfg.variables:
varg = bconfg.variables[varkey]
valsg = varg[:]
print(f'GC_BCON,{varkey:>16s},{valsg.min():.2e},{valsg.mean():.2e},{valsg.max():.2e},{varg.units}')
else:
print('GCBCON,,,,,')
"
If you don’t have PseudoNetCF, you could run ioapi’s m3stat and comb through the reports.
Thank you Barron. Yes, you’re right. The issue appears when I setup the IBCON for profile mode.
I did what you suggested, and the mean values didnt look like weird despite some had different orders of magnitude (the greatest was TOLU, profile = 2.27E-20 and GC = 5.44E-05, but most values had an order of magnitude difference around -1 to -3). Anyway, I commented out some variables of the default file in order to check if the issue is associated with the number of variables since they are different.
By default, I had 248 variables in profile file. By adopting 144 variables, the time-step length of HADV dropped to 16.9 secs. With 109 variables, the time-step length of HADV dropped to 9.7 secs. Thank you all for helping again.
In the AQMBC program that you developed, I used the definition files (gc_airmolden.expr, gc12_to_ae7.expr and gc12_to_cb6r3.expr). In the profile file, I left the species that appeared in the IBCON generated from GC, which means that if the variable appeared in both file, it would used in the default mode. Thus, those variables that only appeared in the profile file I removed out.
Please contact me at wong.david-c@epa.gov and I will email you a new piece of code which will be in the next release (don't know the exact release date).
