#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

Reply via email to