Hi list!
The following attempt segfaults on GRASS 6.4.3svn (nearly in the end of the
process, if I am not wrong), running on Core i7 with 32GB of RAM.
# mdenoise ASTER GDEM2 over Greece
r.denoise in=aster_gdem2_ellas out=aster_gdem2_ellas_smoothed iterations=1
threshold=0.8 epsg=2100
The computational area comprises (Rows: 32401, Columns: 36001) 1166468401
cells. Is this too much?
Would (re-)running this on GRASS 7.0.svn make any difference?
I should better perform the process on a per (ASTER GDEM2) tile(s) basis,
shouldn't I?
Thank You, Nikos
neteler
2
On Fri, Dec 14, 2012 at 8:05 PM, Nikos Alexandris
<nik@nikosalexandris.net> wrote:
Hi list!
The following attempt segfaults on GRASS 6.4.3svn (nearly in the end of the
process, if I am not wrong), running on Core i7 with 32GB of RAM.
# mdenoise ASTER GDEM2 over Greece
r.denoise in=aster_gdem2_ellas out=aster_gdem2_ellas_smoothed iterations=1
threshold=0.8 epsg=2100
Since it is a script, you could add -x to the first line and see
where it rerally crashes.
The computational area comprises (Rows: 32401, Columns: 36001) 1166468401
cells. Is this too much?
Would (re-)running this on GRASS 7.0.svn make any difference?
I expect that "mdenoise" crashes which is not part of GRASS.
So an inspection of that code would be needed in case.
I should better perform the process on a per (ASTER GDEM2) tile(s) basis,
shouldn't I?
Not sure - you may create artifacts at the tile boundaries.
Markus