my system: SuSE 10.2, Dual core processor, 1GP physical memory, 16GB swap (one swap partition of 1GB and one swap file of 15GB)
I have a huge DEM from which I calculated the slopes and categorised them in 10% classes. Now I want to use r.to.vect to convert them into a vector layer of type area. My problem is that I get an out of memory error, even though there is enough memory available. It seems that GRASS 6.2.1 only uses the swap partition and not the swap file (which would be really strange).
by using "free -m" , I got the following memory information (in megabytes) when r.to.vect quit with an out of memory error:
One additional information: huge means:
Rows: 25960
Columns: 23211
Total Cells: 602557560
Rainer
Rainer M. Krug wrote:
Hi
my system: SuSE 10.2, Dual core processor, 1GP physical memory, 16GB swap (one swap partition of 1GB and one swap file of 15GB)
I have a huge DEM from which I calculated the slopes and categorised them in 10% classes. Now I want to use r.to.vect to convert them into a vector layer of type area. My problem is that I get an out of memory error, even though there is enough memory available. It seems that GRASS 6.2.1 only uses the swap partition and not the swap file (which would be really strange).
by using "free -m" , I got the following memory information (in megabytes) when r.to.vect quit with an out of memory error:
> my system: SuSE 10.2, Dual core processor, 1GP physical memory, 16GB
>
> swap (one swap partition of 1GB and one swap file of 15GB)
>
> I have a huge DEM from which I calculated the slopes and categorised
>
> them in 10% classes. Now I want to use r.to.vect to convert them
> into a vector layer of type area. My problem is that I get an out
> of memory error, even though there is enough memory available. It
> seems that GRASS 6.2.1 only uses the swap partition and not the
> swap file (which would be really strange).
>
> by using "free -m" , I got the following memory information (in
> megabytes) when r.to.vect quit with an out of memory error:
>
> total used free shared buffers
> cached
> Mem: 1011 998 12 0 1
> 103
> -/+ buffers/cache: 894 117
> Swap: 17299 1043 16255
>
> Any ideas on how I can avoid this?
>
> By the way: before I started grass, I created the swapfile with
>
> dd ...
> mkswap ...
> swapon ...
..
One additional information: huge means:
Rows: 25960
Columns: 23211
Total Cells: 602557560
does the map contain integers or floats?
(CELL map, FCELL map, or DCELL? [from r.info])
my system: SuSE 10.2, Dual core processor, 1GP physical memory, 16GB
swap (one swap partition of 1GB and one swap file of 15GB)
32 or 64-bit CPU/OS?
I have a huge DEM from which I calculated the slopes and categorised
them in 10% classes. Now I want to use r.to.vect to convert them into a
vector layer of type area. My problem is that I get an out of memory
error, even though there is enough memory available. It seems that GRASS
6.2.1 only uses the swap partition and not the swap file (which would be
really strange).
If you're on a 32-bit system, you may be running into the upper limit
on the amount of memory which can be used by a single process. The
exact figure can vary between systems, but anything over 2GB is
pushing it. Adding more swap (or RAM) won't help if the issue is with
a single process.
swap (one swap partition of 1GB and one swap file of 15GB)
I have a huge DEM from which I calculated the slopes and categorised
them in 10% classes. Now I want to use r.to.vect to convert them
into a vector layer of type area. My problem is that I get an out
of memory error, even though there is enough memory available. It
seems that GRASS 6.2.1 only uses the swap partition and not the
swap file (which would be really strange).
by using "free -m" , I got the following memory information (in megabytes) when r.to.vect quit with an out of memory error:
Was your linux kernel built with CONFIG_HIGHMEM or similar?
I don't think so - I use the standard kernel from SuSE 10.2
(2.6.18.8-0.1 on the one machine - as all updates are done on both
machines, I think that the second one has the same kernel.)
32 or 64bit machine? 64bit linux kernel?
32 bit machine
As I think that the problem is not that easy to solve (according to your
- thanks for the link - and Glynns info) without recompiling the
kernel - I will have to go the other route to solve the problem and to
split the raster into smaller ones. As this is a different topic, please
see my other email.