On 12/04/16 11:29, Helmut Kudrnovsky wrote:
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?
https://grasswiki.osgeo.org/wiki/GRASS_Python_Scripting_Library#Using_temporary_region_for_computations
Moritz
_______________________________________________
grass-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/grass-dev
