GRDMAT Error due to GRIDDESC

SMOKE Emissions Inventory
1

Looking at one of the sample GRIDDESC file entries:
‘POL_HEMI’
6, 1.D0, 45.D0, -98.D0, -98.D0, 90.D0
‘HEMI_108k’
‘POL_HEMI’, -10098D3, -10098D3, 108.D3, 108.D3, 187, 187, 1
’ ’ ! end grids.

What is the significance of D0 or D3 in these entries. The specifications mentioned at https://www.cmascenter.org/ioapi/documentation/all_versions/html/GRIDS.html do not mention about D0 or D3 in this file.

I am configuring following UTM modelling grid
‘UTM_43’ !name; type, P-alpha, P-beta, P-gamma, xcent, ycent
5, 43.0D0, 0.0D0, 0.0D0, 0.0D0, 0.0D0
’ ’ ! end coords.

‘MY_DOMAIN_UTM’
‘UTM_43’, 368094.521D0, 2037825.542D0,2000.0D0, 2000.0D0,12,11,1
’ ’ ! end grids.

I am getting following error in GRDMAT:
File “GRIDDESC” opened for input on unit: 94
/data/SMOKE/SMOKE_V4.7/data/ge_dat/GRIDDESC_PMC

 >>--->> WARNING in subroutine DSCGRID
 Error   5010  reading coord descriptions at line      3
 
 
 *** ERROR ABORT in subroutine GRDMAT
 Could not get Models-3 grid description.

In case of UTM co-ordinate system what shall be the units of XORIG and YORIG, the specification mentions it as METERS.

Please Help.

2

The map projection and grid parameters should be double precision; that’s what the “D0” (etc.) says.

Note that this is indeed significant; behind the scenes, Fortran is doing something like: “OK, I’m looking at a digit, and this is the start of a number. Look ahead: if there is a “D” followed by what could be an exponent, it should be processed as double precision; else if there is either a decimal point or an “E” followed by what could be an exponent, then process it as a (single-precision) real; else process it as an integer.” As a result, “0.1” and “0.1D0” are NOT equal, for example (the former being accurate to about 7 significant digits, the latter to about 17 digits).

As for the “Error 5010”, the error numbers are compiler specific; we need to know what compiler is being used (with which flags) to be able to determine what is wrong.

Following GIS practice, all non-Lat-Lon coordinates are standardized as meters. BTW, for UTM coordinates, the next number (the P_ALPHA) should be the UTM zone (as a double); 43 is not a valid value (the zones for the continental US range from 10 for the Pacific west through 19 for eastern New England…)
See for example UTM Zones of the World

1 Like
3

Thanks for the reply.
I am using gfortran and gcc compilers.

I am configuring grid over Indian subcontinent, so as per the map utm zone shall be 43.

5

@cjcoats
Here are the entries in Makeinclude file used to compile the SMOKE on my system
##Architecture dependent stuff

include {IODIR}/Makeinclude.{BIN}

F90 = $(FC)

IFLAGS = -I${IOINC} -I${INCDIR} -I${IOBIN} # GNU Fortran

EFLAG = -ffixed-line-length-132 -fno-backslash # GNU Fortran
FFLAGS = {IFLAGS} {EFLAG} {DEFINEFLAGS} {PARFLAGS} {FOPTFLAGS} {ARCHFLAGS}
LDFLAGS = {IFLAGS} {DEFINEFLAGS} ${ARCHFLAGS}

ARFLAGS = rv

SMKLIB = -L${OBJDIR} -lsmoke

######## netCDF-4 needs “-lnetcdff -lnetcdf”:

IOLIB = -L$(IOBIN) -lioapi -lnetcdff -lnetcdf

Looking forward to help from you.

6

@cjcoats
I also tried using LAT-LON co-ordinate system :
‘PNE_LL’
1, 0.0D0, 0.0D0, 0.0D0, 73.86399D0, 18.52660D0
’ ’ ! end coords.

‘PNE_DOMAIN_LL’
‘PNE_LL’, 73.75104D0,18.42648D0,0.018D0, 0.018D0,12,11,1
’ ’ ! end grids.

this is also generating same error as earlier.

7

Finding gfortran error-numbers historically has been quite difficult; it seems a little better now. http://www.hep.manchester.ac.uk/u/samt/misc/gfortran_errors.html notes that
…
5010 LIBERROR_READ_VALUE
…
which I assume means that it had trouble reading the value at line 3,which would seem to be the blank-value-containing line:
’ ’ ! end coords.

This may be yet another of those places where the gfortran authors think they know better than the authors of the Fortran Standard, according to which your file should be legal. Try putting at least one blank-character between the quotes, and another before the exclamation-mark, and see if that helps.

8

@cjcoats
Thank you for your valuable inputs.
Even after incorporating the changes suggested by you, the error did not resolve.
Then insted of using a new GRIDDESC file, I inserted my grid entries in the default GRIDDESC file and made relevant changes in ASSIGNS file. The error is now resolved and logfile shows NORMAL COMPLETION of GRDMAT.
This is surprising but error is now resolved.
Thanks once again for your support.