Hello all
We recently installed GRASS5.0beta2 on an SGI Origin 2000 with 512 MB of RAM.
When we tested the r.surf.contour command using data that we used previously on
a SGI Indy with 64 MB RAM using GRASS4.2.1, the r.surf.contour command suddenly
turned into a memory hog, failing after about 5 minutes with an out of memory
error. We have tools to monitor memory usage and the command run on the
GRASS4.2.1 system shows very little memory usage during the first 5 minutes or
so. However, the GRASS5.0 system continually allocates more memory (eventually
swapping) from the start of the program until it finally runs out of memory.
Does anyone know why r.surf.contour now needs so much memory? Has anyone else
seen this problem? Does anyone know of a solution?
Any help would be greatly appreciated. Thank you for your time.
--
Sincerely,
Jazzman (a.k.a. Justin Hickey) e-mail: jhickey@hpcc.nectec.or.th
High Performance Computing Center
National Electronics and Computer Technology Center (NECTEC)
Bangkok, Thailand
People who think they know everything are very irritating to those
of us who do. ---Anonymous
Jazz and Trek Rule!!!
Hello everybody,
I run into an annoying problem while running i.rectify on a linux RH6.0
platform. I was trying to rectify a digitalized imported tiff image. Exiting from
the i.rectify module the program promises to send an e-mail on completition. And
the e-mail arrived indeed but with incomprensible characters:
GISERROR: ##########
where "#" stands for characters with no 7-bit representation, so probably binary
spures.
So I went to the c source and after suppressing the background forking and
inserting some debugging breaks I discovered that the error is in the write_map
routine.
More precisely I found one strange thing: file <write.c> lines 53-58
...........
if(read(temp_fd,rast,target_window.cols * G_raster_size(map_type))
!= target_window.cols * G_raster_size(map_type));
{
printf(buf, "error writing row %d\n", row);
G_fatal_error(buf);
}
...........
I noted the column at the end of line 54. This column shouldn't be there, at least
it seemed to me.
So I canceled the column. But the "read" call continued to report error (exit code
-1).
Inserting some debugging code with fprinfs to stderr I found that:
In write_map:
Opened the raster: cory3
ChkP row: 0
ChkP row: 1
error writing row 1,bytes read=-1 while expecting 11304
The error reported by read is: Bad file descriptor
Does anybody have already incurred in such a problem and know how to solve this.
Thanks a lot
LP