BELD4_LU undefined if CTM_ABFLUX == N
lizadams opened this issue · 8 comments
In the run script, if a user selects CTM_WB_DUST Y, and CTM_ABFLUX N, then the BELD4_LU is undefined. Need to add the following within the if then block for CTM_WB_DUST = Y.
# Input variables for BELD4 Landuse option
setenv BELD4_LU $LUpath/beld4_12US1_459X299_output_tot_bench.nc
https://github.com/USEPA/CMAQ/blob/5.2/CCTM/scripts/run_cctm.csh
Actually, there seems to be two different BELD4 files in the distribution, do you use one for the CTM_WB_DUST option, and the other for the CTM_ABFLUX option?
@jessebash. Can you answer this definitely?
There are two different BELD4 land use files in the distribution. One used for windblown dust, CTM_WB_DUST, and one for bidirectional NH3, CTM_ABFLUX. The NH3 bidirectional beld file is created by the Fest-C program and needs to be paired with the EPIC output from the program. We are working on making the land use data used by CMAQ more consistent and consolidated into fewer files.
As of the v5.2.1 release, the summarization of land use variables has not occurred. However, it does look like the current run script: https://github.com/USEPA/CMAQ/blob/5.2.1/CCTM/scripts/run_cctm.csh
successfully allows users to choose wind-blown dust or bidi calculations independently and the correct BELD4 files will be used.
I run cctm with the wbdust from modis data? It can’t run?
Can you be more specific about your run? What is the version of CMAQ and domain you are using?
I use CMAQ v5.2 and this figure show the question
It looks like you are running a near-real-time case? Would you mind sharing a log file or the file containing the FPAR data so that we can get a better idea of the issue? Feel free to follow up with a private message.
Hi, the error you are seeing is related to an issue within the global attributes of modis file itself not the actual code. For example, if we look at a modis file shown below and examine its global attributes using the netcdf command: ncdump -h [file name here]. We see:
// global attributes:
:IOAPI_VERSION = "3.4.1" ;
:EXEC_ID = "?" ;
:FTYPE = 1 ;
:CDATE = 2016050 ;
:CTIME = 110813 ;
:WDATE = 2016050 ;
:WTIME = 110813 ;
:SDATE = 2005001 ;
:STIME = 0 ;
:TSTEP = 240000 ;
:NTHIK = 1 ;
:NCOLS = 187 ;
:NROWS = 187 ;
:NLAYS = 1 ;
:NVARS = 2 ;
:GDTYP = 6 ;
:P_ALP = 1. ;
:P_BET = 45. ;
:P_GAM = -98. ;
:XCENT = -98. ;
:YCENT = 90. ;
:XORIG = -10098000. ;
:YORIG = -10098000. ;
:XCELL = 108000. ;
:YCELL = 108000. ;
:VGTYP = 7 ;
:VGTOP = 5000.f ;
:VGLVLS = 0.f, 0.f ;
:GDNAM = "WRF" ;
:UPNAM = "dpp" ;
:VAR-LIST = "MODIS_FPAR_T MODIS_LAI_T " ;
:FILEDESC = "con" ;
:HISTORY = "" ;
}
Pay special attention to the VAR-LIST entry.
:VAR-LIST = "MODIS_FPAR_T MODIS_LAI_T " ;
Per I/O API file formatting, each variable in var-list must be exactly 16 characters long. For example if our MODIS VAR-LIST global attribute file was formatted like this:
:VAR-LIST = "MODIS_FPAR_T MODIS_LAI_T" ;
The model would crash, printing out:
"Error reading IDs for variable MODIS_LAI_T????????"
"netCDF error number -49 processing file MODIS_FPAR"
Notice the difference here:
:VAR-LIST = "MODIS_FPAR_T MODIS_LAI_T " ; (Correct)
:VAR-LIST = "MODIS_FPAR_T MODIS_LAI_T" ; (Incorrect)
In the correct version each variable (MODIS_FPAR_T & MODIS_LAI_T) is 16 characters wide including spaces. In the incorrect version the MOSIS_FPAR_T variable is 16 characters wide, but the MODIS_LAI_T variable is not 16 characters wide.
To fix this issue, you have a couple of options:
Either manually edit the modis_fpar file using netcdf commands in your language of choice (e.g. R, Python, etc. ) to add spaces to the MODIS_LAI_T variable in var-list to make it 16 characters wide.
OR
In the upcoming release, this file is no longer an input when running with the wind blown dust option. Therefore, this issue will be automatically solved.
Hope this helps!
Please post any additional question to the CMAS User Forum: https://forum.cmascenter.org/