[GRASS-dev] [GRASS GIS] #2331: parallelize r.horizon

[GRASS GIS]

#2331: parallelize r.horizon
-------------------------+--------------------------------------------------
 Reporter:  zarch        |       Owner:  grass-dev@…              
     Type:  enhancement  |      Status:  new                      
 Priority:  normal       |   Milestone:  7.1.0                    
Component:  Default      |     Version:  unspecified              
 Keywords:               |    Platform:  All                      
      Cpu:  All          |  
-------------------------+--------------------------------------------------
 I would like to parallelize the module when start to generate several
 raster maps for each horizon_step.
 I see three main options:

   1. parallelize r.horizon using openMP.

     a) start to make r.horizon parallel at
 [https://trac.osgeo.org/grass/browser/grass/trunk/raster/r.horizon/main.c#L1112
 line 1112] in this way each raster map is computed and written
 independently, but take into account the fact that the raster write
 function is not thread safe, I should rewrite the main logic of the module
 to call the write function after the whole parallel computation...

     b) make parallel only the computational part
 [https://trac.osgeo.org/grass/browser/grass/trunk/raster/r.horizon/main.c#L1125
 line 1125], so basically, make parallel only the computation row by row
 that are already loaded into memory. But still, as pointed out from a off-
 list message of Sören, G_projection() and the pj_do_proj() functions may
 not be thread safe and the speedup may be very small in case the
 horizon_raster arrays are not large enough.


   2. instead of parallelize using openMP I could simply run several
 processes using the direction parameter. But in this way for each
 direction we are reading the elev_in raster map from the HD.

   3. or I could add two more options (horizon_start and horizon_end angle)
 at the r.horizon module and parallelize only these processes, reading the
 input raster map only once for your each group of directions.

   To avoid that each process overwrite the output of the other processes
 we should modify also the logic on how the raster outputs are named...

   {{{
 $ r.horizon elev_in=elevation horizon=h hrorizon_step=10 horizon_start=200
 horizon_end=240
 }}}

   Generate these raster maps: h_0, h_1, h_2, h_3

   Instead could generate: h_20, h_21, h_22, h_23 reporting the absolute
 index that depend only by the step.

 [[BR]]

 I believe that option 3 could be useful not only to make easier to
 parallelize the r.horizon process. I attached a patch that implement the
 option 3.

 What do you think?

-- 
Ticket URL: <http://trac.osgeo.org/grass/ticket/2331>
GRASS GIS <http://grass.osgeo.org>