#3166: Parallelization with tiling for grass.script
--------------------------+------------------------------
Reporter: wenzeslaus | Owner: grass-dev@…
Type: enhancement | Status: new
Priority: normal | Milestone: 7.4.0
Component: Python | Version: unspecified
Resolution: | Keywords: script, parallel
CPU: Unspecified | Platform: Unspecified
--------------------------+------------------------------
Comment (by huhabla):
IMHO, the for-loop to setup the processing commands for the TiledWorkflow
can be avoided when using the PyGRASS Module and MultiModule approach. The
PyGRASS Module objects allows to alter the input and output settings
before running, so that the TiledWorkflow class could take care of the
tile names, altering the user pre-configured Module objects. The user
simply initiates the Modules that should be used with the original raster
names. The PyGRASS Module allows deep copy operation to clone the existing
Module objects, hence the TiledWorkflow can create any number of copies
and replacing the raster names with tile names.
Please have a look at the PyGRASS Module initialization in
t.rast.neighbors:
https://trac.osgeo.org/grass/browser/grass/trunk/temporal/t.rast.neighbors/t.rast.neighbors.py#L135
Cloning and adding to the parallel queue:
https://trac.osgeo.org/grass/browser/grass/trunk/temporal/t.rast.neighbors/t.rast.neighbors.py#L168
Cite:
>
> The implementation is now 300 lines. MultiModule alone has 200
>
Well it is not much "Code". The doctests and the description of
MultiModule are more than 100 lines. ;)
--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3166#comment:4>
GRASS GIS <https://grass.osgeo.org>
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
