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.
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.
Hope this helps.
Adios,
Chris
--
C.S. Cornuelle
School of Mathematics/MCIM, University of Minnesota
206 Church St. SE, Minneapolis, MN 55455
(612) 626-8930v, (612) 624-2333f, bob at math.umn.edu
Ferventer Vestite
On Tue, Dec 12, 2000 at 12:25:19PM -0600, bob@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...