<div dir="ltr">Thanks to both,<div>I will have a look at your advices/ideas and tell you if I can solve!</div><div><br></div><div>All the best,</div><div>Annalisa</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
2014-06-30 20:17 GMT+02:00 Javier Martínez-López <span dir="ltr"><<a href="mailto:javi.martinez.lopez@gmail.com" target="_blank">javi.martinez.lopez@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi Annalisa,<br>
<br>
I still need to learn a lot about this and have not tested Vaclav's<br>
advice yet, which is probably the best way to go, but you can take a<br>
look at some scripts I wrote for doing this:<br>
<br>
<a href="https://github.com/javimarlop/eHabpy/blob/master/pas/tmp/parallel_segmentation_pca.py" target="_blank">https://github.com/javimarlop/eHabpy/blob/master/pas/tmp/parallel_segmentation_pca.py</a><br>
<br>
<a href="https://github.com/javimarlop/eHabpy/blob/master/pas/parallel_grass_example.py" target="_blank">https://github.com/javimarlop/eHabpy/blob/master/pas/parallel_grass_example.py</a><br>
<br>
They are working for me, but as Markus Metz also mentioned me once, if<br>
you are not using a cluster and there is a lot of writing/reading from<br>
the same hard disk, you will probably not speed up considerably the<br>
processing. In any case, I am also very interested in further<br>
developing this script, so any ideas are welcome!<br>
<br>
Cheers,<br>
<br>
Javier<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On Mon, Jun 30, 2014 at 4:05 PM, Vaclav Petras <<a href="mailto:wenzeslaus@gmail.com">wenzeslaus@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Mon, Jun 30, 2014 at 5:21 AM, Annalisa Minelli <<a href="mailto:annagrass6@gmail.com">annagrass6@gmail.com</a>><br>
> wrote:<br>
>><br>
>> Hi all,<br>
>> I'm attempting to parallelize a job in a python script using multiprocess<br>
>> library in grass70.<br>
>> I had a look at the following links:<br>
>> <a href="http://grasswiki.osgeo.org/wiki/Parallel_GRASS_jobs" target="_blank">http://grasswiki.osgeo.org/wiki/Parallel_GRASS_jobs</a><br>
>> and <a href="http://grasswiki.osgeo.org/wiki/Parallelizing_Scripts" target="_blank">http://grasswiki.osgeo.org/wiki/Parallelizing_Scripts</a>.<br>
>><br>
>> I would like to work in the same location but in different mapsets because<br>
>> my jobs touch the region settings, but I don't know how to set separate<br>
>> mapset for separate jobs.<br>
>><br>
>> Since now I discovered that this processes, if run in the same mapset,<br>
>> clean all the environmental variables (GISDBASE, LOCATION, MAPSET) so then<br>
>> GRASS does not start anymore and I have to restore the .grass70/rc file..<br>
>><br>
>> can anyone hint me on how to set different mapsets for different jobs?<br>
>><br>
><br>
> First, look at the PyGRASS GridModule [1] whether this can help you.<br>
><br>
> For general case, there is unfortunately no API. From what I understand, you<br>
> have to create a file "gisrc" somewhere and then do something like env =<br>
> copy(os.environ) and change GISRC there to your custom "gisrc". Then you the<br>
> change the mapset and region by standard GRASS means but you must pass `env`<br>
> parameter to all command/module calls (env is used by Python subprocess to<br>
> set environment just for one process).<br>
><br>
> Note that GISRC, GISBASE and LOCATION are (system) environmental variables<br>
> while GISDBASE, LOCATION_NAME and MAPSET are GRASS GIS session/environment<br>
> variables and are stored in "gisrc" file. I don't have an idea what LOCATION<br>
> variable is for (it contains full path to the mapset).<br>
><br>
> I would be glad to hear what others think about this.<br>
><br>
> You can of course read source code of GridModule, rendering in wxGUI,<br>
> g.gui.animation, or the following snipped but I don't say that it will be<br>
> easy to understand and there might be a lot of imperfections.<br>
><br>
> Vaclav<br>
><br>
>     # we rely on the tmp dir having enough space for our map<br>
>     tgt_gisdbase = tempfile.mkdtemp()<br>
>     # this is not needed if we use mkdtemp but why not<br>
>     tgt_location = 'r.out.png.proj_location_%s' % epsg_code<br>
>     # because we are using PERMANENT we don't have to create mapset<br>
> explicitly<br>
>     tgt_mapset_name = 'PERMANENT'<br>
><br>
>     src_mapset = Mapset(src_mapset_name)<br>
><br>
>     # get source (old) and set target (new) GISRC enviromental variable<br>
>     # TODO: set environ only for child processes could be enough and it<br>
> would<br>
>     # enable (?) parallel runs<br>
>     src_gisrc = os.environ['GISRC']<br>
>     tgt_gisrc = gsetup.write_gisrc(tgt_gisdbase,<br>
>                                    tgt_location, tgt_mapset_name)<br>
>     # we should use a copy and pass it but then it would not be possible to<br>
> use create_location<br>
>     os.environ['GISRC'] = tgt_gisrc<br>
>     if os.environ.get('WIND_OVERRIDE'):<br>
>         old_temp_region = os.environ['WIND_OVERRIDE']<br>
>         del os.environ['WIND_OVERRIDE']<br>
>     else:<br>
>         old_temp_region = None<br>
>     # these lines looks good but anyway when developing the module<br>
>     # switching location seemed fragile and on some errors (while running<br>
>     # unfinished module) location was switched in the command line<br>
><br>
>     try:<br>
>         # the function itself is not safe for other (backgroud) processes<br>
>         # (e.g. GUI), however we already switched GISRC for us<br>
>         # and child processes, so we don't influece others<br>
>         gcore.create_location(dbase=tgt_gisdbase,<br>
>                               location=tgt_location,<br>
>                               epsg=epsg_code,<br>
>                               datum=None,<br>
>                               datum_trans=None)<br>
><br>
>         # Mapset object cannot be created if the real mapset does not exists<br>
>         tgt_mapset = Mapset(gisdbase=tgt_gisdbase, location=tgt_location,<br>
>                             mapset=tgt_mapset_name)<br>
>         # set the current mapset in the library<br>
>         # we actually don't need to switch when only calling modules<br>
>         # (right GISRC is enough for them)<br>
>         tgt_mapset.current()<br>
> ...<br>
><br>
><br>
><br>
> [1] <a href="http://grass.osgeo.org/grass71/manuals/pygrass/modules_grid.html" target="_blank">http://grass.osgeo.org/grass71/manuals/pygrass/modules_grid.html</a><br>
><br>
><br>
>><br>
>> All the best,<br>
>> Annalisa<br>
>><br>
>> _______________________________________________<br>
>> grass-dev mailing list<br>
>> <a href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a><br>
>> <a href="http://lists.osgeo.org/mailman/listinfo/grass-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-dev</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> grass-dev mailing list<br>
> <a href="mailto:grass-dev@lists.osgeo.org">grass-dev@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/grass-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/grass-dev</a><br>
</div></div></blockquote></div><br></div>