File header inconsistent with GRIDDESC

Dear all
I want to run CMAQ for a 5Km resolution. I make the mcip files with my own preferences and now I am trying to use NEI emission inventory to run the CCTM scripts. So now I have the error which is
File name “/home/ubuntu/CMAQ/data/2017/emis/emis_mole_all_20171002_12US1_nobeis_norwc_2017gb_17j.ncf”
File type GRDDED3
Execution ID “???”
Grid name “12US1”
Dimensions: 299 rows, 459 cols, 1 lays, 66 vbles
NetCDF ID: 393216 opened as READONLY
Starting date and time 2017275:000000 (0:00:00 Oct. 2, 2017)
Timestep 010000 (1:00:00 hh:mm:ss)
Maximum current record number 25

 XCENT_B:    -71.000000000000  XCENT3D (file):    -97.000000000000
 YCENT_B:     42.360000000000  YCENT3D (file):     40.000000000000
 XCELL_B:   5000.000000000000  XCELL3D (file):  12000.000000000000
 YCELL_B:   5000.000000000000  YCELL3D (file):  12000.000000000000


 *** ERROR ABORT in subroutine SubhFile_Cell on PE 002
 File header inconsistent with GRIDDESC

PM3EXIT: date&time specified as 0
Date&time specified as 0

So how should I use NEI database for my case?

This says that your emission file’s grid and map projection are quite different from that of the CMAQ model-run you are doing.

At the very least, your emissions are on a 12KM grid, whereas the model-run is at 5KM. And the Cartesian origin of the map projection is at a different location. Quite possibly, many of the other grid and map projection parameters are different as well, although this log-chunk does not indicate for you. Sadly, the author of the subroutine that did this check did not choose to use the (much older) standard I/O API routine for such consistency checking (which would have reported all the inconsistencies), but instead chose to re-invent the wheel badly, and give you incomplete information.

You might want to do an ncdump -h on the emissions file and see what all the grid and map-projection differences are.

You can use M3Tools programs mtxcalc to compute a grid-to-grid interpolation matrix to interpolate from the emissions-grid to the model-grid, and then mtxcple to do the interpolation using that matrix. Please be careful with mtxcalc that you use environment-variable SCALEFAC to compensate for the fact that emissions data uses non-Standard units with a “…per grid cell” denominator – in this case, the ratio (5/12)^2 = 0.173611111 of the cell-areas:

setenv SCALEFAC 0.173611111

Agree with what Carlie said. I’m not as familiar with mtxcalc but he standard procedure would be to process all your emissions on the grid for which you want to run the model. This is a lot of work. If you need to use premade emissions data that you downloaded, I recommend sticking with 12km. You may be able to subset the grid without too much work.

Hi @eyth.alison
Thank you for your response.
I need the simulation to be for 5 Km resolution. How can I subset the grids after running CCTM with 12 Km? Is the result the same as I change the grid resolution from the beginning?

Hi @cjcoats
Thank you for your response.
In the mtxcalc script, what is BIN pointing out?

Dear @cjcoats
I have some difficulties to work with mtxcalc script.
I am now trying to re grid the emission files of the NEI to my model domain.
for this purpose I filed the scripts

setenv BIN /opt/praetorium/ioapi-3.2/Linux2_x86_64gfort11
setenv DATA /home/ubuntu/CMAQ/data/2017/emis
setenv SCALEFAC 0.173611111
setenv GRIDDESC {DATA}/GRIDDESC setenv MATRIX {DATA}/emis_mole_all_20171002_12US1_nobeis_norwc_2017gb_17j.ncf
setenv MATTXT ${DATA}/MATTXT
unsetenv LOGFILE
set UI=/tmp/MTXCALC.$$
echo “Yes, continue with program” > {UI} echo "Grid_name of the emission inventory" >> {UI}
echo “Grid_name of the model domain” >> {UI} echo " " >> {UI}

which is wrong and I keep getting errors. Can you please help me to figure out how should I give it my input and output files?

You could re-sample the 12km outputs at 5km and/or use spatial averaging. Or you could do something similar with the inputs.

Are you running CMAQ? Do you have the merged 2D emissions that you could re-sample onto 5km?

Dear @eyth.alison
Yes, I am running CMAQ and I am using " merged2D_2017_12US1_cmaq_cb6ae7_2017gb_17j" emission inventory.
I have the output of the mcip, icon and bcon with 5Km resolution and now I am need to run CCTM with this emission inventory

OK – I think you can use the point source inventory inln files as-is, because CMAQ will put them in the right grid cells even if they cover a bigger domain.

@cjcoats may be able to comment on the appropriate configurations for the I/O API tool you all were discussing – I don’t have first-hand experience with that one.

BIN is just the processor/OS/compiler type, not the complete path. In this case,

setenv BIN Linux2_x86_64gfort11

For the rest of it, look at the program-manuals linked above. And check your typing: I think you’re missing some $ symbols, e.g., it should be

setenv GRIDDESC ${DATA}/GRIDDESC

To add to @eyth.alison’s comment on inline point source files, CMAQ will place them in the correct cells only if the grid used for SMOKE processing and the grid used for the CMAQ simulation share the same map projection, i.e. GDTYP, P_ALP, P_BET, P_GAM, XCENT, and YCENT all need to match. If this is not the case, you will have to reprocess your inventories through SMOKE for the map projection used in your CMAQ grid.

Hello there. Im having a similar problem.

I get the same error:

ERROR ABORT in subroutine SubhFile_Cell on PE 034
     File header inconsistent with GRIDDESC

The thing is I believe both my gridded and puntual inventories have the correct grid and map projections.

Here is my griddesc:



' '
'ChemGBsAs_d04'
  2       -35.600       -33.600       -58.400       -58.400       -34.600
' '
'ChemGBsAs_d04_cp'
'ChemGBsAs_d04'    -63583.656    -52500.316      1000.000      1000.000  120  114    1
' '

And here my inventories global attributes:


// global attributes:
		:IOAPI_VERSION = "ioapi-3.2: $Id: init3.F90 185 2020-08-28 16:49:45Z coats $                      " ;
		:EXEC_ID = "????????????????                                                                " ;
		:FTYPE = 1 ;
		:CDATE = 2024136 ;
		:CTIME = 174429 ;
		:WDATE = 2024136 ;
		:WTIME = 174429 ;
		:SDATE = 2012320 ;
		:STIME = 10000 ;
		:TSTEP = 10000 ;
		:NTHIK = 1 ;
		:NCOLS = 120 ;
		:NROWS = 114 ;
		:NLAYS = 1 ;
		:NVARS = 22 ;
		:GDTYP = 2 ;
		:P_ALP = -35.6 ;
		:P_BET = -33.6 ;
		:P_GAM = -58.4 ;
		:XCENT = -58.4 ;
		:YCENT = -34.6 ;
		:XORIG = -63583.656 ;
		:YORIG = -52500.316 ;
		:XCELL = 1000. ;
		:YCELL = 1000. ;
		:VGTYP = -9999 ;
		:VGTOP = -9.999e+36f ;
		:VGLVLS = -9.999e+36f, -9.999e+36f ;
		:GDNAM = "ChemGBsAs_d04_cp" ;
		:UPNAM = "M3CPLE          " ;
		:VAR-LIST = "ETHA            ACET            TOL             ETH             OLE             BENZENE         ACROLEIN        KET             ISPD            ALD2            FORM            BUTADIENE13     PAR             CO              TOLU            XYLMN           ETHY            NO              PRPA            ALDX            IOLE            NO2             " ;
		:FILEDESC = "IOAPI inventory for the MABA                                                                                                                                    " ;
		:HISTORY = "" ;

GDTYP, P_ALP, P_BET, P_GAM, XCENT and YCENT all match, so what I am missing here?

Thank you for any help you can provide
Sol

You should also have a log-message detailing the respective values of XCENT, YCENT, etc. for your comparison.

On the other hand, you may have run into one of the more obscure parts of the Fortran Standard: in reading -63583.656
from the GRIDDESC file, the compiler is allowed (but not compelled – this is a compiler-writer’s option) to say:

Umm… no D with an exponent field here, so treat it as a REAL4
and read it in (which gives about 6 significant digits and loses the last couple of significant digits, and then convert that REAL4 to REAL8 and compare it with the value from the file header (which is REAL8 to begin with, and so does have all those significant digits (program ncdump is a C program, and doesn’t use Fortran’s D for an exponent field, which adds to the confusion; for comparison, note that VGTOP is written with a trailing f, to indicate that it is a float (i.e., REAL4) [C types and output default to double (REAL8) unless explicitly declared otherwise…]

So put a D0 after all those numbers in the GRIDDESC.

1 Like

Thank you! Adding the D0 worked perfectly