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.
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
