Tested with a 144 million cells DEM and threshold=10, r.watershed completes successfully here. Can you try to debug with gdb or valgrind? See [1] for some info on GRASS debugging.
Markus M [1] http://grass.osgeo.org/wiki/GRASS_Debugging Markus Metz wrote: > Chris Carleton wrote: >> >> As for the r.watershed problem, it's occurring >> again and I'm now using GRASS 6.4 RC6 with 64bit support. > > Apparently you are comfortable to build from source. No need to use > outdated RC6, use the latest weekly snapshot instead, available at [1] > >> >> Here are the region settings I'm using; >> zone: 16 >> datum: wgs84 >> ellipsoid: wgs84 >> north: 1942292.77488498 >> south: 1798172.56898554 >> west: 174812.49733566 >> east: 382055.4579663 >> nsres: 15.00002143 >> ewres: 15.00021429 >> rows: 9608 >> cols: 13816 >> cells: 132744128 >> >> And here is the output in the terminal from strace and r.watershed; >> >> GRASS 6.4.0RC6 (ccarleton.minanha.utm):~/ > strace r.watershed >> elevation=aster_srtm_dem_fil...@cloudremoval threshold=100 >> stream=aster_srtm_streams >> >> ... >> >> SECTION 1b (of 5): Determining Offmap Flow. >> 100% >> SECTION 2: A * Search. >> 100% >> SECTION 3: Accumulating Surface Flow. >> 100% >> SECTION 4: Watershed determination. >> Segmentation fault > > I will test it myself next week, currently on the road. > > Markus M > > [1] http://grass.osgeo.org/grass64/source/snapshot/ > > >> >> I've attached the whole strace stdout to this email. Again, I'm using Ubuntu >> 10.04 LTS 64bit. Does anyone have any ideas about where to start >> troubleshooting this? Thanks, >> >> Chris >> >> >> On 24 August 2010 09:55, Chris Carleton <[email protected]> wrote: >>> >>> Okay thanks. I was using a 'trial-and-error' method for determining the >>> threshold, but I think I ought to start large and proceed toward smaller >>> values. I haven't come across any analytical method for determining the best >>> threshold value for stream extraction. Some smart person needs to develop a >>> statistically sound method for assessing the uncertainty associated with >>> geophysical feature extraction so that multiple results can be compared >>> meaningfully and we're not left to assess the validity of a result on the >>> basis of whether or not it 'looks okay' and preferably that doesn't involve >>> going into the field to count streams. I'm going to compile GRASS from >>> source with the latest stable release and configure for 64bit support. I >>> think the current install was done through the repository so it's behind and >>> not optimized. On that note, I'm trying to figure out what the appropriate >>> configure flag(s) is(are) for HDF4 and HDF5 support in GDAL so that I can >>> open HDF files in GRASS. The only like that I can find that seems to be >>> discussing it formally is here: >>> >>> http://trac.osgeo.org/gdal/wiki/HDF >>> >>> Does anyone have the answer handy or another link with instructions that >>> are more clear? Thanks, >>> >>> Chris >>> >>> On 24 August 2010 05:39, Markus Metz <[email protected]> >>> wrote: >>>> >>>> Martin Landa: >>>> > >>>> > Chris Carleton: >>>> >> I haven't been able to find something in the mailing lists about this, >>>> >> but >>>> >> if you know of somewhere that I can find a solution I'd appreciate the >>>> >> link. >>>> >> I'm running GRASS 6.4 RC5 on Ubuntu LTS 10.04 with a Dell Precision >>>> >> T7500 >>>> >> Workstation. The region settings are as follows; >>>> > >>>> > RC5 is quite old - please try RC6 or better fresh SVN. >>>> > >>>> The Ubuntu version and grass version used are both true 64bit? >>>> Processing over 130 million cells with r.watershed in memory and 12GB >>>> is possible, but only if grass is compiled as a 64bit application. >>>> >>>> SECTION 4: Watershed determination is pretty much unchanged since RC5, >>>> the segfault might also happen in current 6.4. >>>> >>>> The combination of threshold=10 and over 130 million cells is a bit >>>> unusual, producing a very large number of stream segments, but AFAICT >>>> not large enough to trigger a segfault. >>>> >>>> Markus M >>>> >>> >> >> > _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
