Four issues with CMAQv5.3

CMAQ
1

(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).

  1. 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.

  1. 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 3.9.1.1 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.

  2. 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.

  3. 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
END IF

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.

Thanks.

Dazhong

2 Likes
2

Hello Dazhong,

thank you for reporting these issues you are encountering.

  1. For this issue, could you please try adding the environment variable “CTM_EMLAYS” to your run script, set it to a value of 12 (i.e. “setenv CTM_EMLAYS 12”) and report back how this affects your run? Are you trying to use multiple 2D, 3D, and inline emission files, or just this single 3D file?

  2. Could you please let us know which LSM you are using in your WRFv3.9.1.1 simulations (PX, NOAH, etc.)?

  3. Please see the solution for this issue posted on our CMAQ v5.3 Known Issues page

  4. We will look into this issue, all our model simulations typically start at 00:00 GMT so it may take us a while to replicate this error and investigate its cause.

Christian

3

Hi Christian,

  1. For the emission file issue, setting CTM_EMLAYS seems not helping. Originally I had 1 3D emission file, 4 inline point source files, and 2 inline fire emission files. But I tried also to turn off all inline files and have only the 3D file. After CTM_EMLAYS was set to 12, cctm threw the same error message as before.

  2. The LSM in the WRFv3.9.1.1 simulations is PX.

Thanks for quick response.

Dazhong

4

I had encountered the same issue by using CMAQv5.3. My 3D emission file had 5 vertical layers and cctm run with 14-layers MET file. When I run cctm, it crashed with the same error message as dazhong reported.
However, the cctm can run successfully by using CMAQv5.2.1 when I used the same emission and MET files.
Are there any methods to solve it?

5

Please contact David at wong.david-c@epa.gov for his fix to CMAQv5.3 for your 3D emissions file issue.

6

thx for your information, dazhong.

7

The advice is really helpful, thanks!