[GRASS-user] Overlapping pixels among DEM tiles to compute the LS factor for RUSLE

[Nikos Alexandris]

* Nikos Alexandris <nik at nikosalexandris.net> [2019-01-26 00:13:38 +0100]:

>* Ken Mankoff <mankoff at gmail.com> [2019-01-25 11:50:29 -0800]:
>
>>Hi Nikos,
>>
>>On 2019-01-25 at 07:18 -0800, Nikos Alexandris <nik at nikosalexandris.net> wrote...
>>>A billion-pixel scaled DEM is the main input to compute the slope length
>>>and steepness (LS) factor for RUSLE (`r.watershed`), only.
>>>
>>>Tiling this DEM in tiles of 5K^2 pixels (`r.tile`), appears to be a
>>>reasonable approach to parallelise this process.
>
>As I learn more, it seems that it's completely wrong to tile this in
>squares and that catchment/basin borders need to be essentially
>respected.
>
>
>>Do you need to parallelise it? I just ran r.watershed on a 4.5 billion-pixel DEM w/o a problem on my laptop and I think it took ~6 hours, but I'm not sure. It might have been closer to 12. I have 32 GB of ram and gave half to the process, but told it to use disk instead of memory via the -m flag:
>>
>>r.watershed -s -m elevation=phi threshold=1000000 drainage=dir memory=16384 --v --o
>
>I just launched an all-in-one go, ~9e8 pixels finally. RAM is not an
>issue here. Let's see the timing.

So, it worked out in 40 minutes! 

If I recall correctly, my initial attempt on my laptop (with 8GM of RAM
and without checking further options to use other available space)
wouldn't start the process.  And I rushed over to read something like
8960000000 instead of 896000000. I am happy to have it done in 40
minutes now as well as mis-reading the number of pixels and having read
now a few things more on the subject.  "We" also have this related
tutorial:
https://ncsu-geoforall-lab.github.io/erosion-modeling-tutorial/index.html

Nikos