[GRASS-user] v.generalize: does it take forever?

[Fábio Dias]

Hi,

Running r64249, with a couple of stuff in parallel using &. It seems
to be considerably slower. More than 100h, no 1% printed. To be fair,
I'm not entirely sure I'll see it when it prints, 10 v.generalize
running (5 for each year) + 1 v.in.ogr for 2012. That v.in.ogr is
running for almost 100h too. I'm loading the shps directly, as advised
way, way back in this thread.

AFAIK, no disk is been used, the whole thing is cached (after more
than 24h processing, cumulative iotop shows only a few mb
written/read). I'm no longer using a ramdisk for the grassdata dir.

However, it appears to be considerably slower, probably because of the
parallel running jobs.

My question then would be, considering the thread I saw about sqlite,
should I be using something else as backend? When it starts to make
sense to change it?

F

-=--=-=-
Fábio Augusto Salve Dias
ICMC - USP
http://sites.google.com/site/fabiodias/


On Wed, Jan 14, 2015 at 1:06 PM, Markus Neteler <neteler at osgeo.org> wrote:
> On Wed, Jan 14, 2015 at 3:54 PM, Fábio Dias <fabio.dias at gmail.com> wrote:
> ...
>> What would be the best way to do that in parallel? One mapset for each
>> year? Can I run multiple v.generalizes on the same input with
>> different outputs?
>
> Yes sure.
>
>> My first thought was to run completely separated grass processes for
>> each simplification, but I didn't find a way to make it search
>> something different than .grass / .grass70 for the configuration
>> stuff....
>
> Maybe take a look at this approach
> http://grasswiki.osgeo.org/wiki/Parallel_GRASS_jobs#Grid_Engine
>
> but even sending different v.generalize jobs to background (&) should
> work if you have enough RAM.
>
> markusN