On 27/10/16 23:47, Anna Petrášová wrote:
On Thu, Oct 27, 2016 at 3:47 PM, Moritz Lennert
<[email protected]> wrote:
Le Thu, 27 Oct 2016 20:33:23 +0100,
James Duffy <[email protected]> a écrit :
On 27 October 2016 at 17:48, Moritz Lennert
<[email protected]> wrote:
Running:
r.univar -et gp_ortho.1 zones=gp_seg_optimum_clump
output=testoutput2.csv
Returns:
Current region rows: 12627, cols: 23991
ERROR: G_realloc: unable to allocate 224000 bytes of memory at
raster/r.univar/r.univar_main.c:324
Ok, so the issue is with r.univar (although the issue has made me
aware that i.segment.stats could be made way more memory efficient
as well).
How much RAM do you have on your machine ?
It's a virtual machine which I have dedicated about 10GB.
This warrants a bug report. Would you be willing to file one on
http://trac.osgeo.org/grass ?
I'm happy to submit it if you can guide me as to what exactly should
go into it please?
The bug report should concentrate on r.univar
You should provide:
- region settings (output of g.region -p)
- info about the two maps going into the command, i.e. r.info, plus the
info that the segment map is an output of r.clump and thus
sequentially numbered
- the error message
I don't know how difficult it will be to allow for lower memory usage
in r.univar, so we'll have to see if an improvement is possible.
I haven't read this thread carefully, so sorry if this is unrelated,
but I think the -e flag might require a lot of memory. Also, is this
64bit?
No, James is working on "GRASS 7.0.4 in the osgeolive 32bit
operating system."
So, yes, memory limits are expected. The question is whether it would be
possible to reduce r.univar's memory usage.
Moritz
_______________________________________________
grass-user mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-user
