WARNING in subroutine GET_EMIS

hi,eyeryone,I am currently trying to run the CMAQ5.2 version
No error is reported during CCTM operation, and it runs normally. But after running it, I looked at the LOG file, and it showed:
WARNING in subroutine GET_EMIS:INTERPX
Bad window dimension(s)
M3WARN: DTBUF 8:52:30 Jan. 13, 2020 (2020013:085230)

 >>--->> WARNING in subroutine GET_EMIS on PE 002
 Could not read TERP from EMIS_1
 M3WARN:  DTBUF 8:52:30   Jan. 13, 2020 (2020013:085230)
 Bad argument LAY1=        29

TERP is in my EMIS compound. What is the cause of this problem?

Please post the full log file and a text file showing the output of ncdump -h of your emissions file.

thanks for your reply!But due to upload file size limitations, I couldn’t uploading my whole LOG file, so I deleted a lot of WARNING in the LOG file.

Looking forward to your reply!

CTM_LOG_001.txt (8.0 MB)

ncdump -h.txt (14.6 KB)

Thank you.

Could you please also post your run script and the output of ‘ncdump -h’ for your METCRO3D_china1.nc file?

I could be reading it wrong, but based on your log file, you seem to have only a single gridded emissions file with only a single layer and no inline point source / stack group files.

If so, try setting the following in your run script

setenv CTM_EMLAYS 1

and see if this gets rid of the numerous warnings about the INTERPX function in subroutine GET_EMIS not being able to read the emissions due to a wrong window definition.

(post deleted by author)

Thanks for your reply!
I added "setenv CTM_EMIS 1 " to the script like you said, and rerun the run_cctm.csh, but the process went worng.
Could you take a look at it for me, please.
*** ERROR ABORT in subroutine AQCHEM on PE 003
Maximum AQCHEM total iterations exceeded
PM3EXIT: DTBUF 1:00:00 Jan. 2, 2020
Date and time 1:00:00 Jan. 2, 2020 (2020002:010000)
CTM_LOG_003.v52_intel_china1_20200102.txt (167.4 KB)

here are my run scripts and METCRO3D_china1.nc file:
ncdump -h.txt (10.1 KB)
run_cctm.csh (24.7 KB)

If you examine your new CTM_LOG file, you’ll see that adding setenv CTM_EMLAYS 1 solved all these types of warnings

 Bad argument LAY1=        29
 
 >>--->> WARNING in subroutine GET_EMIS:INTERPX
 Bad window dimension(s)
 M3WARN:  DTBUF 0:02:30   Jan. 14, 2020 (2020014:000230)
 
 >>--->> WARNING in subroutine GET_EMIS on PE 001
 Could not read NO2 from EMIS_1
 M3WARN:  DTBUF 0:02:30   Jan. 14, 2020 (2020014:000230)

that were present in your original log file. The reason you saw these warnings (and the reason no emissions could be read from your EMIS_1 file) was that you set CTM_PT3DEMIS to N in your run script, but did not provide a 3D emissions file, only a single layer emission file. This is not an expected setup in CMAQv52 where the assumption is that you provide an offline 3D emissions file if CTM_PT3DEMIS is set to N and a combination of a 2D gridded emission file and stack emission / stack group files for inline point source plume rise calculations if CTM_PT3DEMIS is set to Y. Put differently, based on your run script settings, the code was expecting a 3D gridded emissions file and failed to read emissions when you provided a 2D gridded emissions file. Adding setenv CTM_EMLAYS 1 solved this by telling the code that your gridded emissions file only has one layer despite setting CTM_PT3DEMIS to N. You could also have solved this issue by setting CTM_PT3DEMIS to Y, specifying EMISfile in the second portion of the if/then block below, and setting NPTGRPS to 0.

 if ( $CTM_PT3DEMIS == 'N' ) then
    #> Offline 3d emissions file name
    set EMISfile  = emis_mole_all_\${YYYYMMDD}_cb6_bench.nc
 else
     set EMISfile  = emis_mole_all_${YYYYMMDD}_cb6_bench.nc #> Surface emissions
     setenv NPTGRPS 0          #> Number of elevated source groups

 endif

As a side comment, it likely is not appropriate for most cases to add all of your emissions to the first model layer, without considering plume rise for point sources either offline or within CMAQ. You may want to reconsider your emissions processing approach.

The crash in aqchem you are now seeing is triggered by NaN values likely originating after reading in your emissions. If you examine your new CTM_LOG file, you see the following:

 Maximum eddy diffusivity of:   345.54     (m**2/sec)
 at col, row, layer:   2,  64,   4
 corresponding to a free tropospheric wind shear of:  4.65772E-03 (/sec),
                        a bulk Richardson Number of:  -34.532    ,
 and pot. temps. in layer and layer+1:   266.07       263.37    
 
 after     VDIFF G  NaN           A  NaN           N  NaN          
 after COUPLE_WR G  NaN           A  NaN           N  NaN          

These reported NaN values likely originate from missing and/or bad values in your emissions input file, and then cause the CCTM calculations to fail. To solve this issue, you will need to examine your emission input files for bad (very large negative or positive) values.