Re: [GRASS-user] r.flow Terminates With Error
On Sat, 13 Feb 2010, Micha Silver wrote: In GRASS 6.5, Markus Metz has implemented a new r.watershed which is much faster as also handles memory better, (and also can do Multi Flow Direction analysis). I'll bet that the numbers above for memory requirements also would apply to GRASS 6.4 Micha, Perhaps. My region is not large (9550 ha), but at 3m resolution has 307,443,024 cells. At 1M RAM/31,000,000 cells that would be about 9.5M memory required. Checking top before starting I saw 1.5G free memory, yet I ran out processing dsout in r.flow. Of course, that's r.flow and not r.watershed. I appreciate the pointer; I've been working with 6.4 since this is production work. Toda raba, Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.flow Terminates With Error
Rich Shepard wrote: On Sat, 13 Feb 2010, Markus Neteler wrote: Did you compile with LFS (large file support) enabled? Markus, Yes. This came up before and Glynn ensured that LFS was enabled in my build. In general, is there a way to predict memory and disk space requirements before initiating processing? In GRASS 6.5, Markus Metz has implemented a new r.watershed which is much faster as also handles memory better, (and also can do Multi Flow Direction analysis). In his manual it says: --quote- In-memory mode and disk swap mode There are two versions of this program: ram and seg. ram is used by default, seg can be used by setting the -m flag. The ram version requires a maximum of 31 MB of RAM for 1 million cells. Together with the amount of system memory (RAM) available, this value can be used to estimate whether the current region can be processed with the ram version. The ram version uses virtual memory managed by the operating system to store all the data structures and is faster than the seg version; seg uses the GRASS segmentation library which manages data in disk files. seg uses only as much system memory (RAM) as specified with the memory option, allowing other processes to operate on the same system, even when the current geographic region is huge. Due to memory requirements of both programs, it is quite easy to run out of memory when working with huge map regions. If the ram version runs out of memory and the resolution size of the current geographic region cannot be increased, either more memory needs to be added to the computer, or the swap space size needs to be increased. If seg runs out of memory, additional disk space needs to be freed up for the program to run. The r.terraflow module was specifically designed with huge regions in mind and may be useful here as an alternative. --quote- I'll bet that the numbers above for memory requirements also would apply to GRASS 6.4 -- Micha What I wanted to do (but will back off doing for valid time constraint reasons) was to improve the resolution of the DEM from 5m because one of the modules I wanted to explore recommended a grid resolution in centimeters (much too fine for my needs). I tried r.resamp.rst to create 1m results, but temporary file sizes were excessively large. Next I tried 3m, but it turns out that r.flow cannot calculate the flow density map despite the available memory and swap space. So, I'll stick with 5m resolution. Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.flow Terminates With Error
On Sat, 13 Feb 2010, Markus Neteler wrote: Did you compile with LFS (large file support) enabled? Markus, Yes. This came up before and Glynn ensured that LFS was enabled in my build. In general, is there a way to predict memory and disk space requirements before initiating processing? What I wanted to do (but will back off doing for valid time constraint reasons) was to improve the resolution of the DEM from 5m because one of the modules I wanted to explore recommended a grid resolution in centimeters (much too fine for my needs). I tried r.resamp.rst to create 1m results, but temporary file sizes were excessively large. Next I tried 3m, but it turns out that r.flow cannot calculate the flow density map despite the available memory and swap space. So, I'll stick with 5m resolution. Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.flow Terminates With Error
On Fri, Feb 12, 2010 at 9:22 PM, Rich Shepard wrote: > On Fri, 12 Feb 2010, Rich Shepard wrote: > >> I had no problems running r.flow with in the input elevation map >> resolution >> of 5m x 5m. However, now it won't run (even with the -m switch) on a DEM >> with 3m x 3m resolution: > > Must be a memory issue (with 2G installed and top reporting Mem: 2041212k > total, 1989652k used, 51560k free, 40576k buffers) > > Anyway, it's running when I specify one output map at a time. Flow lengths > are being calculated now and consuming 95% of the CPU and 70% of memory, > with disk swapping turned on for the module. Did you compile with LFS (large file support) enabled? Markus ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] r.flow Terminates With Error
On Fri, 12 Feb 2010, Rich Shepard wrote: I had no problems running r.flow with in the input elevation map resolution of 5m x 5m. However, now it won't run (even with the -m switch) on a DEM with 3m x 3m resolution: Must be a memory issue (with 2G installed and top reporting Mem: 2041212k total, 1989652k used,51560k free,40576k buffers) Anyway, it's running when I specify one output map at a time. Flow lengths are being calculated now and consuming 95% of the CPU and 70% of memory, with disk swapping turned on for the module. Rich ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
