(This message is intended mainly for CMAQ developers.)
I would like to report 4 issues we had encountered with CMAQv5.3 (on our linux cluster and with the Intel compiler suite).
- According to Section 6.9.1 of the CMAQ document on github, gridded stream emission files “may be 2D to represent just the surface layer emissions or they may be 3D. If 3D, the file may have the same number or fewer number of layers as the CMAQ grid.”
Our CMAQ grid has 30 vertical layers. When cctm was run with a 12-layer gridded emission file, it crashed with the following error message:
Time-independent data. Lower bound: 1 Upper bound: 30 Actual number of layers: 12 >>--->> WARNING in subroutine XTRACT3 Error in layer-bounds specification for file GR_EMIS_001 variable AACD M3WARN: DTBUF 8:00:00 July 25, 2017 (2017206:080000) *** ERROR ABORT in subroutine retrieve_time_de on PE 000 Could not extract GR_EMIS_001 file PM3EXIT: DTBUF 8:00:00 July 25, 2017 Date and time 8:00:00 July 25, 2017 (2017206:080000)
When furnished with a 30-layer gridded emission file, cctm happily ran.
In module LSM_Mod, the number of soil types is assigned to 11 or 16 depending on whether met model is wrf version 4+ or not. Our wrf version is 220.127.116.11 and 11 is assigned. But there are 16 soil types in our wrf output data. Therefore, wsat, wfc etc for grid cells with soil type larger than 11 are left as 0 from the initialization. This results floating point exception (divided by zero) in subroutine m3dry.
In the cctm run script, if environmental variable CONC_SPCS is set to “ALL” or left unset, the environmental variable CTM_WVEL cannot be set to N [default: N]. Otherwise, cctm throws a segmentation fault error.
When cctm is run from 08:00 UTC to next day 08:00 UTC and the cctm simulation is one synchronization step after 24:00 UTC of the first day, the following code snippet in subroutine GRIDEMIS and a similar code snippet in subroutine GET_PT3D_EMIS give incorrect values to EM_FILE_DATE and lead to model crashes.
C Ensure that the model and emissions timestamp dates stay synchronized
IF ( STDATE .NE. JDATE ) THEN
NDATE = JDATE; NTIME = JTIME
CALL NEXTIME( NDATE, NTIME, -TSTEP( 1 ) ) ! go back one output tstep
CALL NEXTIME( EM_FILE_DATE( FSTREAM ), NTIME, TSTEP( 1 ) ) ! advance the start date one time step
I would appreciate it if you could help resolve the issues. Please let me know if I missed anything or misunderstood how the model should be setup.