Re: [GRASS-dev] Fwd: [GRASS-user] Re: grass-user Digest, Vol 30, Issue 22
On Thu, Oct 9, 2008 at 11:13 PM, Michael Barton [EMAIL PROTECTED] wrote: Below is a recent exchange between Markus (Neteler) and me about the new r.watershed.fast. The gist is the question: is it ready to go into the develbranch_6 and trunk (7) svn or does it need more testing. I thought it was already in the main svn, but Markus pointed out that it is still in Addons. Indeed it is not even in Addons - I tried to point out that Addons would be a good place to facilitate testing. @Markus: if you are interested, please check here: http://trac.osgeo.org/grass/wiki/HowToContribute#WriteaccesstotheGRASS-Addons-SVNrepository - Write access to the GRASS-Addons-SVN repository Markus ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
Re: [GRASS-dev] Fwd: [GRASS-user] Re: grass-user Digest, Vol 30, Issue 22
Markus Metz wrote: assuming that GRASS runs today on systems where at least 500MB RAM are available 500MB total, 500MB per user, or 500MB per process? It's safe to assume 500MB for the system (although much of GRASS can run on a PDA, it's reasonable to assume that people won't be performing complex analysis on such systems), but that doesn't mean that a single process can use all of it. Still, the seg mode is slow and testing would require a lot of patience. GRASS' segement library (which r.watershed.seg uses) is quite inefficient. For the segmented r.proj (r.proj.seg in 6.3/6.4, r.proj in 7.0), I wrote my own tile cache. If it can fit the entire map within the specified amount of RAM, then it will do so (reading the map directly into RAM without creating the segment file), without any noticeable performance impact caused by the extra level of indirection. If you can't fit the working set into RAM, it's going to be slow whichever approach you take. Reading into memory which is actually swap isn't going to be any quicker. Also, using a tile cache allows you to handle maps which exceed the size of the address space (i.e. maps larger than 4GiB on a 32-bit system). OTOH, r.proj does have reasonable locality of reference, so the working set tends to be small relative to the total amount of data. I don't know whether the same is true of r.watershed. -- Glynn Clements [EMAIL PROTECTED] ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
[GRASS-dev] Fwd: [GRASS-user] Re: grass-user Digest, Vol 30, Issue 22
Below is a recent exchange between Markus (Neteler) and me about the new r.watershed.fast. The gist is the question: is it ready to go into the develbranch_6 and trunk (7) svn or does it need more testing. I thought it was already in the main svn, but Markus pointed out that it is still in Addons. Michael Begin forwarded message: From: Markus Neteler [EMAIL PROTECTED] Date: October 9, 2008 1:38:37 PM GMT-07:00 To: Michael Barton [EMAIL PROTECTED] Subject: Re: [GRASS-user] Re: grass-user Digest, Vol 30, Issue 22 Please post it to the list, too. :) On Thu, Oct 9, 2008 at 10:22 PM, Michael Barton [EMAIL PROTECTED] wrote: We're almost at a point of recompiling GRASS on our main modeling box. When we do that, we will certainly test the new r.watershed.fast. However, if others test and want to include this in the svn, it's fine by me to go ahead and replace the old module. Michael __ C. Michael Barton, Professor of Anthropology Director of Graduate Studies School of Human Evolution Social Change Center for Social Dynamics Complexity Arizona State University Tempe, AZ 85287-2402 USA voice: 480-965-6262; fax: 480-965-7671 www: http://www.public.asu.edu/~cmbarton On Oct 9, 2008, at 1:04 PM, Markus Neteler wrote: On Thu, Oct 9, 2008 at 9:39 PM, Michael Barton [EMAIL PROTECTED] wrote: Ah. But I did think that it was tested last summer, that it worked well, and the commentators on the list thought that it should be moved into the main svn. Do you think we need more testing? If so, I'll try to have some done here. I am fine with all - if results are identical to old r.watershed and the paramters/flags are compliant, we can replace it even in 6.4. If not, put into 7. I am out of time to do tests unfortunately. Markus -- Open Source Geospatial Foundation http://www.osgeo.org/ http://www.grassbook.org/ ___ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
