netCDF error in reading file

CMAQ
1 
Dear all, I'm running CMAQ v5.3.3 with gcc 9.4.0. The emissions are 2016 v1 12US1 with the 12US1 meteorology. The model stopped at reading the ocean file and point-source emissions (see the attached log file). I checked the files, they look reasonable. For instance, the ocean input file 12US1_surf.ncf was download from EPA ftp site. Any possible reason that CMAQ can not read these netCDF files? Thanks!


[CTM_LOG_001.v533_gcc_2016_CONUS_20151222.txt|attachment](upload://lktQvAWU5jgXqhETquootk1W1Cw.txt) (24.1 KB)

CMAQ v5.3.3, gcc 9.4.0

module list

1) hpcc/zaratan(default)          4) netcdf/gcc/9.4.0/openmpi/4.1.1/zen2/4.8.1
 2) gcc/9.4.0(default)             5) netcdf-fortran/gcc/9.4.0/openmpi/4.1.1/zen2/4.5.3
 3) openmpi/gcc/9.4.0/zen2/4.1.1   6) hdf5/gcc/9.4.0/openmpi/4.1.1/zen2/1.10.7

Place output from the above commands here.

2

Hi Haohe,

Iā€™ve increased the trust level for you, so that you can retry attaching your log file.

Thanks, Liz

3

What do the commands ncdump -h and ncdump -k say about the files? and what netCDF error-number is reported? (You can find a list of these at https://www.cmascenter.org/ioapi/documentation/all_versions/html/ERRORS.html#ncf331)

4

Hi Liz, the nnetcdf error number is very helpful, thanks!

For the in-line emissions files, attached are the ncdump -h results. I didnā€™t find anything strange. The ncdump -k result is ā€˜classicā€™.
CTM_LOG_001.v533_gcc_2016_CONUS_20151222.txt (24.1 KB)
inln_ptnonipm.txt (20.4 KB)

For the 12US1_surf.ncf file, below is the ncdump -h result. The error number is 40, meaning ā€˜coordinates out of rangeā€™. I downloaded the file from the EPA website, no sure why it has this problem.

netcdf \12US1_surf {
dimensions:
TSTEP = 1 ;
DATE-TIME = 2 ;
LAY = 1 ;
VAR = 2 ;
ROW = 299 ;
COL = 459 ;
variables:
int TFLAG(TSTEP, VAR, DATE-TIME) ;
TFLAG:units = ā€œ<YYYYDDD,HHMMSS>ā€ ;
TFLAG:long_name = "TFLAG " ;
TFLAG:var_desc = "Timestep-valid flags: (1) YYYYDDD or (2) HHMMSS " ;
float OPEN(TSTEP, LAY, ROW, COL) ;
OPEN:long_name = "OPEN " ;
OPEN:units = "UNKNOWN " ;
OPEN:var_desc = "OPEN " ;
float SURF(TSTEP, LAY, ROW, COL) ;
SURF:long_name = "SURF " ;
SURF:units = "UNKNOWN " ;
SURF:var_desc = "SURF " ;

// global attributes:
:IOAPI_VERSION = "Id: @(#) ioapi library version 3.0 " ;
:EXEC_ID = "??? " ;
:FTYPE = 1 ;
:CDATE = 2010067 ;
:CTIME = 155535 ;
:WDATE = 2010067 ;
:WTIME = 155535 ;
:SDATE = 0 ;
:STIME = 0 ;
:TSTEP = 0 ;
:NTHIK = 1 ;
:NCOLS = 459 ;
:NROWS = 299 ;
:NLAYS = 1 ;
:NVARS = 2 ;
:GDTYP = 2 ;
:P_ALP = 33. ;
:P_BET = 45. ;
:P_GAM = -97. ;
:XCENT = -97. ;
:YCENT = 40. ;
:XORIG = -2556000. ;
:YORIG = -1728000. ;
:XCELL = 12000. ;
:YCELL = 12000. ;
:VGTYP = 1 ;
:VGTOP = 100.f ;
:VGLVLS = 1.f, 0.f ;
:GDNAM = "12US1_459X299 " ;
:UPNAM = "CONVERT " ;
:VAR-LIST = "OPEN SURF " ;
:VAR-LIST = "OPEN SURF " ;
:FILEDESC = " $
:HISTORY = ā€œā€ ;
}

5

Have another look at the log-messages from opening these files, and at the date&time requested:

"STK_EMIS_001" opened as OLD:READ-ONLY   
 ...
 Starting date and time  2015340:000000 (0:00:00   Dec. 6, 2015)
 Timestep                          010000 (1:00:00 hh:mm:ss)
 Maximum current record number        25

contains 25 hours of data starting Dec. 6, 2015

 "STK_EMIS_002" opened as OLD:READ-ONLY   
 ...
 Starting date and time  2015356:000000 (0:00:00   Dec. 22, 2015)
 Timestep                          010000 (1:00:00 hh:mm:ss)
 Maximum current record number        25

contains 25 hours of data starting Dec. 22, 2015. which is the date&time of the read-failure:

 >>--->> WARNING in subroutine RDTFLAG
 Error reading netCDF time step flag for STK_EMIS_001
 M3WARN:  DTBUF 0:00:00   Dec. 22, 2015 (2015356:000000)

Oops!

6

I understand it. SMOKE only generate few days of ptnonimp files to represent the whole month. Then the run script read ā€˜smk_merge_dates_201512.txtā€™ file (attached at the end) to match the files. Here is my run script code:

setenv STK_EMIS_001 IN_PTpath/ptnonipm/inln_mole_ptnonipm_{mwdss_Y}${STKCASEE}.ncf setenv STK_EMIS_002 IN_PTpath/ptegu/inln_mole_ptegu_{YYYYMMDD}${STKCASEE}.ncf
setenv STK_EMIS_003 IN_PTpath/othpt/inln_mole_othpt_{mwdss_N}_${STKCASEE}.ncf

I have used this type of similar script for lots of runs. I donā€™t know why this time it does not work.

login-2.zaratan.umd.edu{haohe}290: cat smk_merge_dates_201512.txt
Date, aveday_N, aveday_Y, mwdss_N, mwdss_Y, week_N, week_Y, all
20151201, 20151206, 20151206, 20151206, 20151206, 20151208, 20151208, 20151201
20151202, 20151206, 20151206, 20151206, 20151206, 20151209, 20151209, 20151202
20151203, 20151206, 20151206, 20151210, 20151210, 20151210, 20151210, 20151203
20151204, 20151206, 20151206, 20151211, 20151211, 20151211, 20151211, 20151204
20151205, 20151206, 20151206, 20151205, 20151205, 20151205, 20151205, 20151205
20151206, 20151206, 20151206, 20151206, 20151206, 20151206, 20151206, 20151206
20151207, 20151206, 20151206, 20151206, 20151206, 20151207, 20151207, 20151207
20151208, 20151206, 20151206, 20151206, 20151206, 20151208, 20151208, 20151208
20151209, 20151206, 20151206, 20151206, 20151206, 20151209, 20151209, 20151209
20151210, 20151206, 20151206, 20151210, 20151210, 20151210, 20151210, 20151210
20151211, 20151206, 20151206, 20151211, 20151211, 20151211, 20151211, 20151211
20151212, 20151206, 20151206, 20151205, 20151205, 20151205, 20151205, 20151212
20151213, 20151206, 20151206, 20151206, 20151206, 20151206, 20151206, 20151213
20151214, 20151206, 20151206, 20151206, 20151206, 20151207, 20151207, 20151214
20151215, 20151206, 20151206, 20151206, 20151206, 20151208, 20151208, 20151215
20151216, 20151206, 20151206, 20151206, 20151206, 20151209, 20151209, 20151216
20151217, 20151206, 20151206, 20151210, 20151210, 20151210, 20151210, 20151217
20151218, 20151206, 20151206, 20151211, 20151211, 20151211, 20151211, 20151218
20151219, 20151206, 20151206, 20151205, 20151205, 20151205, 20151205, 20151219
20151220, 20151206, 20151206, 20151206, 20151206, 20151206, 20151206, 20151220
20151221, 20151206, 20151206, 20151206, 20151206, 20151207, 20151207, 20151221
20151222, 20151206, 20151206, 20151206, 20151206, 20151208, 20151208, 20151222
20151223, 20151206, 20151206, 20151206, 20151206, 20151209, 20151209, 20151223
20151224, 20151206, 20151224, 20151210, 20151224, 20151210, 20151224, 20151224
20151225, 20151206, 20151225, 20151211, 20151225, 20151211, 20151225, 20151225
20151226, 20151206, 20151226, 20151205, 20151226, 20151205, 20151226, 20151226
20151227, 20151206, 20151206, 20151206, 20151206, 20151206, 20151206, 20151227
20151228, 20151206, 20151206, 20151206, 20151206, 20151207, 20151207, 20151228
20151229, 20151206, 20151206, 20151206, 20151206, 20151208, 20151208, 20151229
20151230, 20151206, 20151206, 20151206, 20151206, 20151209, 20151209, 20151230
20151231, 20151206, 20151206, 20151210, 20151210, 20151210, 20151210, 20151231

7

The ptnonipm point source sector uses representative days. There is an environment variable STK_EM_SYM_DATE_001 that should be set to T for the ptnonipm sector (assuming PT_NONEGU is point source sector #1).

See the discussion around STK_EM_SYM_DATE in section 6.9.1 of the User Guide.

1 Like
8

That fixed the problem! Thanks a lot.