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

[Moritz Lennert]

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