<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Apr 11, 2016 at 5:19 PM, Helmut Kudrnovsky <span dir="ltr"><<a href="mailto:hellik@web.de" target="_blank">hellik@web.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">> I see, then it's easier to fix the script and use grass.use_temp_region<br>
<br>
</span>From the manual:<br>
<br>
script.core.use_temp_region()[source]¶<br>
Copies the current region to a temporary region with “g.region save=”, then<br>
sets WIND_OVERRIDE to refer to that region. Installs an atexit handler to<br>
delete the temporary region upon termination.<br>
<br>
Does this function mean that: while concurrent r.basin runs on different<br>
CPUs in the same mapset, there is no interefering by region settings change<br>
interefering?<br>
<span class=""></span></blockquote></div><br>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.<br><br></div><div class="gmail_extra">The documentation describes just what happens in the background but not the usage. Feel free to update that with your understanding.<br><br></div><div class="gmail_extra">Generally, use_temp_region should be used by any module which calls g.region.<br><br></div><div class="gmail_extra">Vaclav<br></div></div>