<div dir="ltr"><div><br><br>On Sun, Feb 25, 2018 at 9:44 AM, Nikos Alexandris <<a href="mailto:nik@nikosalexandris.net">nik@nikosalexandris.net</a>> wrote:<br>><br>> * Markus Neteler <<a href="mailto:neteler@osgeo.org">neteler@osgeo.org</a>> [2018-02-24 23:00:32 +0100]:<br>><br>>> On Sat, Feb 24, 2018 at 10:31 PM, Markus Metz<br>>> <<a href="mailto:markus.metz.giswork@gmail.com">markus.metz.giswork@gmail.com</a>> wrote:<br>>>><br>>>> On Sat, Feb 24, 2018 at 10:06 PM, Nikos Alexandris <<a href="mailto:nik@nikosalexandris.net">nik@nikosalexandris.net</a>><br>>>>><br>>>>> * Markus Metz <<a href="mailto:markus.metz.giswork@gmail.com">markus.metz.giswork@gmail.com</a>> [2018-02-24 21:39:40 +0100]:<br>>>>>><br>>>>>> On Sat, Feb 24, 2018 at 9:25 PM, Nikos Alexandris<br>>>>>> <<a href="mailto:nik@nikosalexandris.net">nik@nikosalexandris.net</a>><br>>><br>>> ...<br>>>>><br>>>>> Looking at jobs logs, I read lots of ".gislock" lines.<br>>>>> It might be some permission related issue. I partially operated directly<br>>>>> (with my user-id) on many Locations.<br>>>>><br>>>>> The operateor of the scheduler, has naturally, another user-id. I wonder<br>>>>> if I should apply GRASS_SKIP_MAPSET_OWNER_CHECK=1 everywhere.<br>>>><br>>>><br>>>> No, you need to run each process in a unique temporary mapset.<br>>><br>>><br>>> Yes, only that works. Be sure to have a sufficiently long random<br>>> string to be used as temporary mapset name.<br>>><br>>> You can for example the outout of<br>>> mktemp --dry-run<br>>><br>>> and add the machine name to it (and maybe the current time stamp<br>>> cleaned for special chars) to avoid race conditions if you use a<br>>> shared network storage.<br>><br>><br>> Thanks M1/2.<br>><br>><br>>>> Once you have<br>>>> the final result, change the current mapset with g.mapset to the common<br>>>> mapset where final results should stored and copy the final result from the<br>>>> temporary mapset to the current mapset (the mapset to hold the final<br>>>> results).<br>>><br>>><br>>> (we have processed terabytes of LST data like this :-)<br>><br>><br>> Just a pseudo-example: it would suffice then to,<br>><br>> save current region<br><br></div>does not work, you should be still outside GRASS<br><div><br>> for loop over something<br>>    ...<br>><br>>    CURRENT_MAPSET=$(g.mapset -p)<br><br>does not work, you should be still outside GRASS<br><div><br></div>><br>>    # a temporary Mapset<br>>    RANDOM_STRING=$(mktemp --dry-run |cut -d"." -f2)<br><br>now you start GRASS ...<br>>    grass -c $RANDOM_STRING<br><br></div><div>missing is --exec<br><br></div><div>... and are out of GRASS again<br></div><div><br></div><div>put this in a script to be called with grass -c ... --exec myscript.sh<br>--><br></div><div>><br>>    # do something<br>>    r.mask vector=VectorMap where="Attribute='Here'" &&<br>>    g.region zoom=MASK &&<br>>    r.zonal.stats cover=covermap base=basemap method=average output=outputmap<br>><br>>    # back to "valid" Mapset<br>>    g.mapset $CURRENT_MAPSET<br>><br>>    g.copy raster=outputmap@${RANDOM_STRING},outputmap<br>>    r.stats -acp in=outputmap out=report<br>>    r.mask -r<br><--<br><br>> restore region<br><br>does not work, you should be again outside GRASS<br><div></div><br></div><div>All outside GRASS, try to<br><br></div><div>1. create a script with commands and parameters to be executed, e.g. myscript.sh<br></div><div>2. create a unique name of a temporary mapset (full path), store it in an env var, e.g. TMPMAPSET<br></div><div>3. run grass -c $TMPMAPSET --exec myscript.sh<br></div><div>4. remove the temporary mapset simply with rm -fr $TMPMAPSET<br></div><div><br></div>>>> Alternatively/additionally, don't use the script grassXY to start a GRASS<br><div>>>> session, instead define the GRASS environment with custom scripts (one for<br>>>> the GRASS version to use, one for the database/location/mapset to use). This<br>>>> avoids race conditions on a HPC system. A unique temporary mapset for each<br>>>> process helps to avoid all sorts of concurrent access problems.<br>><br>><br>> It mostly works for me with --exec. Mostly. That is, there are missing<br>> or empty WIND files, here and there, and .gislock related issues.<br><br></div><div>I found a confusing message about a missing WIND file in the startup script, fixed in trunk and relbr74 with r72277,8<br><br></div><div>.gislock issues can only appear if 1) you attempt to run several instances in the same mapset, 2) there is an old .gislock file left from a previous run that failed.<br><br></div><div>g.mapset mapset=$TARGET_MAPSET<br></div><div>might avoid the .gislock issue, but it should only be used for copying results with e.g.<br></div><div>g.copy rast=outputmap@$TMPMAPSET,outputmap<br><br></div><div>>><br>>> Let's expand this Wiki section a bit with our findings (I'll try to<br>>> find my notes):<br>>> <a href="https://grasswiki.osgeo.org/wiki/Parallel_GRASS_jobs#Cluster_and_Grid_computing">https://grasswiki.osgeo.org/wiki/Parallel_GRASS_jobs#Cluster_and_Grid_computing</a></div><div>>><br>>> markusN<br><br><div>It's on my TODO list...<br><br></div><div>Markus M<br></div><br></div></div>