Dear CMAQ users and developers,
Could you please clarify whether the vertical layer specification VGLVLS in EMIS file must match the VGLVLS used by MCIP? In my current setup, the EMIS file lists
In light of this vertical-layer mismatch, can CMAQ still yield accurate pollutant concentrations, or should I explicitly add setenv CTM_EMLAYS 6 to the run script? like:
#> Vertical extent
set NZ = 29
setenv CTM_EMLAYS 6
I use CMAQ v5.2. Previously, I ran the CCTM script with mismatched vertical layers and the script executed
The CMAQ model is driven by meteorological fields from the WRF model. The gridding properties of the meteorological model define the maximum extent of the air quality simulation domain, and the CTM inherits this information from the meteorological model via MCIP.
Layer collapsing is no longer supported within MCIP. Please see the following forum post for additional information.
Thank you for your reply. I have read the article you recommended.
I would like to confirm with you once again. I have two possible solutions: one is to upgrade to CMAQ version 5.3 or later, in which case I would not need to modify my emission files; the other is that if I continue using CMAQ v5.2, I would need to adjust the VGLVLS in the EMIS files to exactly match those in the MCIP output. Is my understanding correct?
Dear teacher, I attempted to run CMAQ 5.3.2. However, the Cctm script encountered an error when it reached the end of the first day of the run. Could you please tell me what the reason is? CTM_LOG_000.v532_intel_china6_20200602.txt (148.3 KB) run_cctm_2016_12US1.csh (35.0 KB)
Processing Day/Time [YYYYDDD:HHMMSS]: 2020154:235500
Which is Equivalent to (UTC): 23:55:00 Tuesday, June 2, 2020
Time-Step Length (HHMMSS): 000500
VDIFF completed... 13.5 seconds
COUPLE completed... 0.0 seconds
HADV completed... 1.5 seconds
ZADV completed... 0.2 seconds
HDIFF completed... 0.6 seconds
DECOUPLE completed... 0.0 seconds
PHOT completed... 0.1 seconds
CLDPROC completed... 9.2 seconds
CHEM completed... 0.9 seconds
AERO completed... 1.8 seconds
Master Time Step
Processing completed... 27.8 seconds
=--> Data Output completed... 31.8 seconds
Processing Day/Time [YYYYDDD:HHMMSS]: 2020155:000000
Which is Equivalent to (UTC): 0:00:00 Wednesday, June 3, 2020
Time-Step Length (HHMMSS): 000500
NCVGT: : NetCDF: Index exceeds dimension bound
NCVGT: : NetCDF: Index exceeds dimension bound
application called MPI_Abort(MPI_COMM_WORLD, 1634494817) - process 31
real 170.62
user 0.00
sys 0.00
** Runscript Detected an Error: CGRID file was not written. **
** This indicates that CMAQ was interrupted or an issue **
** exists with writing output. The runscript will now **
** abort rather than proceeding to subsequent days. **
Start Day: 2020-06-02
End Day: 2020-06-03
Number of Simulation Days: 1
Domain Name: china6
Number of Grid Cells: (ROW x COL x LAY)
Number of Layers: 29
Number of Processes: 64
All times are in seconds.
Num Day Wall Time
01 2020-06-02 170.62
Total Time = 170.62
Avg. Time = 170.62
The problem is that you’re starting your CCTM simulation at 23:00 on June 2 and are trying to run for 24 hours but your emission files start at 00:00 on June 2 and contain 25 time steps. Therefore, after the CCTM run finishes the first hour (writing output at 00:00 on June 3) and tries to read inputs for the next hour, it cannot find them in the emissions input files and crashes.
Also, in response to your original question, if you decide to continue working with CMAQv5.2, then yes, you should use this setting in your run script if your MCIP files define a 29 layer vertical structure but your emissions were processed such that all mass was allocated to the first six layers only and the resulting gridded 3D emissions file only has 6 layers, corresponding to the lowest six MCIP layers.
This earlier thread contains some additional context on the use of the CTM_EMLAYS variable in earlier versions of CMAQ. It also notes that CMAQ’s emissions interface was changed substantially in versions starting with CMAQv5.3.