*** ERROR ABORT in subroutine GRDMAT No source-cell intersections found

There was an error when I ran my own added point source


grdmat.point.nctox.by01-nc.txt (9.5 KB)

It means that your inventory sources are not located within your modeling domain. Please check your point inventory latitude and longitude coordinate to make sure they are formatted correctly and check you domain is also set correctly.

Thank you, I have solved it.

I encountered the same problem, can you share the solution, thank you very much!

Have you checked your inventory lat/lon coordinates and make sure that your modeling domain is set correctly and surrogates are created correctly as well.

Hello,

I met the same situation. I checked that my inventory (FF10 format) has correct lat/lon coodinates. But I’m not sure my PROJ expressions (e.g. DATA_FILE_MAP_PRJN and WEIGHT_FILE_MAP_PRJN) are supported.

setenv DATA_FILE_MAP_PRJN β€œ+proj=tmerc,+lat_0=38,+lon_0=127.5,+k_0=0.9996,+x_0=1000000,+y_0=2000000,+ellps=GRS80”
setenv WEIGHT_FILE_MAP_PRJN β€œ+proj=tmerc,+lat_0=38,+lon_0=127.5,+k_0=0.9996,+x_0=1000000,+y_0=2000000,+ellps=GRS80”

Do my expressions have problem? Thank you.

Is it correct that you are using mercator projection? Most of the grids we use are lambert, but yours may not be.

You might try this online PROJ.4 convertor to check your projection definition to make sure that you are getting coordinates in the right place:

https://mygeodata.cloud/cs2cs/

I checked my map projection EPSG:5179 has the expression

+proj=tmerc +lat_0=38 +lon_0=127.5 +k=0.9996 +x_0=1000000 +y_0=2000000 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs

from https://mygeodata.cloud/cs2cs/
So there seems not to be problem in my definition. And there is my mistake in another(GRIDSPC or surrogate).

Thank you for your comment.

What is your modeling domain description?

Also, can you copy and paste the first headline of your surrogate that holds the domain description?

There info will give us an idea what may happen in your modeling domain setup.

My GRIDDESC is

! coords --line: name; type, P-alpha, P-beta, P-gamma, xcent, ycent
β€˜LAM_36.66N127.5W’
2, 30.0, 60.0, 127.5, 127.5, 36.66
’ ’ ! end coords. grids: name; xorig,yorig,xcell,ycell,ncols,nrows,nthik
β€˜Cheongju_1km’
β€˜LAM_36.66N127.5W’,-124368.695040, -119998.635786, 1000.000000, 1000.000000, 241, 241, 1
’ ’ ! end grids.

And my surrogate of population(100) has the header:

1 #GRID Cheongju_1km -124368.695040 -119998.635786 1000.000000 1000.000000 241 241 1 LAMBERT meters 30.000000 60.000000 127.500000 127.500000 36.660000
2 100 11110 79 219 0.00406217 ! 577.153700 142080.108477 0.004062
3 100 11110 80 219 0.00277164 ! 393.794242 142080.108477 0.006834
4 100 11110 81 219 0.00522229 ! 741.983505 142080.108477 0.012056
5 100 11110 82 219 0.00277579 ! 394.384468 142080.108477 0.014832

The two have the exact same. But the same error occurred still.
I checked that my point source are overlapped with surrogate of population in my domain β€œCheongju_1km”.

For reference, my point inventory is

#FORMAT FF10_POINT
#COUNTRY KOR
#YEAR 2016
#DESC Point Source Inventory
#DESC FF10 Point format
#DESC CAPSS 2016 point
#DESC COUNTRY,FIPS,TRIBAL CODE,FACILITY_ID,UNIT_ID,REL_POINT_ID,PROCESS_ID,AGY_FACILITY_ID,AGY_UNIT_ID,AGY_REL_POINT_ID,AGY_PROCESS_ID,SCC,POLID,ANN_VALUE,ANN_PCT_RED,FACILITY_NAME,ERPTYPE,STKHGT,STKDIAM,STKTEMP,STKFLOW,STKVEL,NAICS,LONGITUDE,LATITUDE,LL_DATUM,HORIZ_COLL_MTHD,DESIGN_CAPACITY,DESIGN_CAPACITY_UNITS,REG_CODES,FAC_SOURCE_TYPE,UNIT_TYPE_CODE,CONTROL_IDS,CONTROL_MEASURES,CURRENT_COST,CUMULATIVE_COST,PROJECTION_FACTOR,SUBMITTER_FAC_ID,CALC_METHOD,DATA_SET_ID,FACIL_CATEGORY_CODE,ORIS_FACILITY_CODE,ORIS_BOILER_ID,IPM_YN,CALC_YEAR,DATE_UPDATED,FUG_HEIGHT,FUG_WIDTH_XDIM,FUG_LENGTH_YDIM,FUG_ANGLE,ZIPCODE,ANNUAL
β€œKOR”,β€œ11110”,β€œβ€,1,1,1,1,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œ10300501”,β€œCO”,0.009444600647999998,β€œβ€,β€œβ€,β€œβ€,48.884516,1.5419947999999999,β€œβ€,β€œβ€,β€œβ€,β€œβ€,126.99754343582636,37.576836163157125,β€œ003”,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€
β€œKOR”,β€œ11110”,β€œβ€,1,2,2,2,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œ10300501”,β€œCO”,0.49281110471124,β€œβ€,β€œβ€,β€œβ€,74.803152,2.952756,β€œβ€,β€œβ€,β€œβ€,β€œβ€,126.99754343582636,37.576836163157125,β€œ003”,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€
β€œKOR”,β€œ11110”,β€œβ€,1,3,3,3,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œ10300501”,β€œCO”,0.5749428312476098,β€œβ€,β€œβ€,β€œβ€,76.771656,3.28084,320.0,β€œβ€,5.2821524,β€œβ€,126.99754343582636,37.576836163157125,β€œ003”,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€,β€œβ€

My files are attached. Thank you in advance.

ptinv.capss2016.FF10.csv (10.9 KB)
GRIDDESC.txt (711 Bytes)
100_NOFILL_Cheongju_1km.txt (3.9 MB)
SRGDESC_Cheongju_1km.txt (1.8 KB)

I need to check your Smkinven log file to be sure but I am pretty sure that your current lat/long coordinates have been treated as western hemisphere. There is a flag in SMOKE that converts any positive longitude values as negative values to treat them as Western Hemisphere longitude values. It was implemented a long long long time ago when we had a big point inventory file with all positive longitude values (standards as that time). So I believe SMOKE was updated to support that.
Please add this flag (WEST_HSPHERE) into your SMOKE area run script and set it to N since the default value is β€œY”

setenv WEST_HSPHERE N

1 Like

It works!. After changing WEST_HSPHERE to N,

setenv WEST_HSPHERE N

I got no error message:

β€”>> Normal Completion of program GRDMAT

Thank you for helpful comment.

Glad to hear that! Great work!

May I ask if you have resolved this issue? I also encountered this problem when I changed the vertical layer height of MCIP settings before running it again. I have always set setenv WEST-HSPHERE N

…big point inventory file with all positive longitude values (standards as that time)…

Just for the record, the relevant Standard should be International Standards Organization (ISO) Standard 6709, so that point-inventory file was in violation of the (treaty-established) relevant standard.