Grumble, grumble...
Steve Wangen
---------------------------------------------------
Steven Wangen
PhD Candidate
Bio-Protection Research Centre
Lincoln University
http://tinyurl.com/lepidulum-spread
http://www.bioprotection.org.nz
If possible, please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
Joel Pitt
> I don't know if there's an easy fix for this or not, but I'm running out of
> memory with some simulations. The weird thing is that its hitting a wall
> telling me that "exiting with code 1, stderr: 'ERROR: G_realloc: unable to
> allocate 1966080000 bytes at main.c:112'" - which implies that it's maxing
> out at 2 gig. The machine I'm running has 2.5 gig of ram, and I even tried
> increasing the capacity of the swap, but still get the same error.
> From a bit of googling around, all I can find is that it looks like windows
> limits processes to 2 gig of memory space on a 32 bit machine, but I'm
> running ubuntu. Is there a way to expand this? Even if I get some keywords
> pointing me in the right direction I could possibly execute that.
You might be able to move to 64 bit... you'll need to ensure you are
running 64 bit Ubuntu, and that GRASS is compiled in 64 bit mode too.
Although I think gcc (the compiler) should automatically compile in 64
bits if you are in a 64 bit OS.
If that doesn't make a difference, it might be worth checking the
mailing list archives etc. to see if GRASS supports 64 bit memory
allocation (it should, but you never know...), if it doesn't you could
directly use the raw malloc/realloc() functions.
Another option is to modify the code to obtain the memory it needs
immediately instead of reallocating memory (which is what G_realloc()
does) when too many dispersal events are created. Reallocating memory
(e.g. trying to get bigger sections of free memory) can result in
fragmentation, so even if there is 2 Gb of memory available, if it's
not in a contiguous block then you might get an out of memory error.
> The other thing I was thinking, if that doesn't work, would be to try and
> separate the writing of the existing_counter (those dispersal events that
> don't leave their cell of origin) from the writing of the jumps_count (those
> that do) in the r.mdig.kernel utility, and then combine them in grass using
> a mapcalc command.
Yes, you could make it get the maximum memory available, and if there
is too many events, it could write a temporary map and flush the
memory. Then at the end it could sum these maps with mapcalc.
> The other option is to try and scale back the simulations, but of course
> that isn't ideal. Let me know if you have any insight.
How many events are you generating out of curiousity? It's worth
determining whether it's just large, or if it's computationally
impractical, before spending too much time on it ;-)
Cheers
J