[GRASS-dev] creating temporary mapsets in a parallelized python script

[Helmut Kudrnovsky]

wenzeslaus wrote
> On Mon, Apr 11, 2016 at 5:19 PM, Helmut Kudrnovsky <

> hellik@

> > wrote:
> 
>> > I see, then it's easier to fix the script and use grass.use_temp_region
>>
>> From the manual:
>>
>> script.core.use_temp_region()[source]¶
>> Copies the current region to a temporary region with “g.region save=”,
>> then
>> sets WIND_OVERRIDE to refer to that region. Installs an atexit handler to
>> delete the temporary region upon termination.
>>
>> Does this function mean that: while concurrent r.basin runs on different
>> CPUs in the same mapset, there is no interefering by region settings
>> change
>> interefering?
>>
> 
> Setting WIND_OVERRIDE (environmental variable) will happen for the current
> process, so it won't affect other processes only subprocess which is
> desired. (In your case, this won't work if you would use this function
> outside of r.basin.) So yes, parallel processes (including g.region) won't
> see WIND_OVERRIDE, so they will see and use the original computational
> region.
> 
> The documentation describes just what happens in the background but not
> the
> usage. Feel free to update that with your understanding.
> 
> Generally, use_temp_region should be used by any module which calls
> g.region.
> 
> Vaclav

thanks for the hints and clarifications.

are there examples of the correct use of script.core.use_temp_region()
around?

I've found it in [1]:

124	    # clone current region
125	    grass.use_temp_region()
126	
127	    grass.run_command('g.region', res=panres, align=pan)

anything else to do?

[1]
https://trac.osgeo.org/grass/browser/grass/trunk/scripts/i.pansharpen/i.pansharpen.py#L124

thanks



-----
best regards
Helmut
--
View this message in context: http://osgeo-org.1560.x6.nabble.com/creating-temporary-mapsets-in-a-parallelized-python-script-tp5260753p5260826.html
Sent from the Grass - Dev mailing list archive at Nabble.com.