[GRASS-dev] r.watershed failing: seg fault and exit code 35584

[Markus Metz]

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_filled at 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 <w.ccarleton at gmail.com> 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 <markus.metz.giswork at googlemail.com>
>> 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
>>>
>>
>
>