[GRASS-user] i.segment.stats memory usage error

[Moritz Lennert]

On 27/10/16 23:47, Anna Petrášová wrote:
> On Thu, Oct 27, 2016 at 3:47 PM, Moritz Lennert
> <mlennert at club.worldonline.be> wrote:
>> Le Thu, 27 Oct 2016 20:33:23 +0100,
>> James Duffy <james.philip.duffy at gmail.com> a écrit :
>>
>>> On 27 October 2016 at 17:48, Moritz Lennert
>>> <mlennert at club.worldonline.be> 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