[prev in list] [next in list] [prev in thread] [next in thread] 

List:       grass-user
Subject:    Re: [GRASS-user] i.segment.stats memory usage error
From:       Moritz Lennert <mlennert () club ! worldonline ! be>
Date:       2016-10-28 7:08:44
Message-ID: f2de059d-cf18-5664-9832-05b8f42645fd () club ! worldonline ! be
[Download RAW message or body]

On 27/10/16 23:47, Anna Petrášová wrote:
> On Thu, Oct 27, 2016 at 3:47 PM, Moritz Lennert
> <mlennert@club.worldonline.be> wrote:
>> Le Thu, 27 Oct 2016 20:33:23 +0100,
>> James Duffy <james.philip.duffy@gmail.com> a écrit :
>>
>>> On 27 October 2016 at 17:48, Moritz Lennert
>>> <mlennert@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
_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-user
[prev in list] [next in list] [prev in thread] [next in thread]