#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>