* Nikos Alexandris <[email protected]> [2019-01-26 00:13:38 +0100]:
* Ken Mankoff <[email protected]> [2019-01-25 11:50:29 -0800]:
Hi Nikos,
On 2019-01-25 at 07:18 -0800, Nikos Alexandris <[email protected]>
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
_______________________________________________
grass-user mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/grass-user
