[GRASSLIST:1255] Re: r.cost whine

[Eric G . Miller]

On Tue, Dec 12, 2000 at 12:25:19PM -0600, bob at math.umn.edu wrote:
> It's r.cost again, and me again.
> 
> Doing this ...
> 
> GRASS:~/grass > r.cost -vkn input=veg.prod5n.inv
> output=veg.prod5n.inv.cost start_sites=s.cost.start.test
> stop_sites=s.cost.stop.test 
> Null cells excluded from cost evaluation.
> Source map is: Integer cell type, 2400 rows, 2400 cols.  Creating some
> temporary files ...
> 
> leads to a long wait.  During this wait, I noted that the size of my
> map area grew.  A lot.  Doing du -s ~/mymaps showed an increase in
> disk usage from 365189 to 388949, or about 33Mb, when I finally killed
> r.cost.  Rooting around in the directories, I was unable to find out
> where these temporary files might be located.

They're sneakily hidden in $LOCATION/$MAPSET/.tmp/$HOST/.  Exiting GRASS
*should* force them to be clean-up if the program terminates abnormally
or is sloppy about cleaning up it's messes.

> Taking the number of rows and columns, I might expect to need around
> 23Mb total.  My concern is that in the past r.cost has continued to
> suck up more and more disk space for these temporary files, files
> which are also BTW not deleted when r.cost is killed - a trap needed
> here?
> 
> I note that for larger source maps a G_malloc error appears.
> 
> It might be handy to be able to specify a different default for the
> temporary files, so that an auxiliary hard drive might be used for
> this purpose.  Just a thought.

Don't know that anyone has tried to tackle r.cost bugs.  I'm not sure
how much temp space it needs to do it's job.  Is the G_malloc error of
the "Out of Memory" kind? 

Well, I just tried it. Yup, it's foobar'ed. I got some other errors
before the program died.  Sorry, can't be more help at the moment.
It's still on the Release Critical bugs list...

-- 
Eric G. Miller <egm2 at jps.net>