[GRASS-user] Grass save on cluster?
neteler at osgeo.org
Mon Mar 23 12:06:06 EDT 2009
On Mon, Mar 23, 2009 at 4:51 PM, Rainer M Krug <r.m.krug at gmail.com> wrote:
> On Sat, Mar 21, 2009 at 4:31 PM, Markus Neteler <neteler at osgeo.org> wrote:
>> On Thu, Mar 19, 2009 at 2:14 PM, Rainer M Krug <r.m.krug at gmail.com> wrote:
>>> how save is GRASS 6.3.2 to be used on a cluster? I am starting several
>>> instances of grass on a single node, they all have their own grass
>>> database (but they share a linked PERMANENT and the name of the mapset
>>> and location is the same). I am asking as I experience from time to
>>> time crashes in my simulation because certain files can not be found,
>>> and these crashes are not reproducible when only one GRASS instance
>> I cannot say for 6.2.3, but I have run > 100k jobs in parallel with 6.4.0x,
>> also having the sharing nodes (using PBs and lately only Grid Engine).
> Are these in different mapsets? I am asking because we might be using
> grass as a backend for a web-application - and when it can handle that
> many parallel jobs, it should work.
I create a tmp mapset for each job. Then I use a g.copy-job with
check for race condition to get over the calculated stuff into the
target mapset. Works well. I have 128 parallel jobs,
so far nothing lost AFAIK (the competition arises when more than
one job tries to write to the target mapset - hence I made it a loop
to sleep and try again for 3 times - see wiki).
>> Certain files can not be found didn't happen at all.
>> Which are these files?
> I am running a simulation, and these are layers which should have been
> created before.
I assume that you just need to add a
to each job script since new (tmp) mapsets see only PERMANENT.
Note that we fixed a bug in g.mapsets for this in GRASS 6.4.
>>> In addition, how safe is it to execute several r.mapcalc and other map
>>> operations in the same mapset in parallel (obviously with different
>> You can do that unless the current region isn't touched. But it is
>> not really recommended.
> I am definitely not changing the region, so the error must be somewhere else.
Which error? need to know more details...
>>> Again, I experienced severe problems with that, wherefore I
>>> abandoned it (although it increases my simulation time considerable).
>>> I would have expected it to work, but again, I had non reproducible
>>> (and inconsistent) crashes.
>>> Can somebody comment on that or provide some pointers?
> Thanks - this looks very intersting - I'll look into it.
More information about the grass-user