Opened 10 years ago

Closed 10 years ago

Last modified 8 years ago

#2331 closed enhancement (fixed)

parallelize r.horizon

Reported by: zarch Owned by: grass-dev@…
Priority: normal Milestone: 7.2.0
Component: Default Version: unspecified
Keywords: r.horizon Cc:
CPU: All Platform: 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 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 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.

  1. 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.
  1. 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.

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?

Attachments (1)

rhorizon.diff (4.0 KB ) - added by zarch 10 years ago.
r.horizon adding horizon_start and horizon_end parameters

Download all attachments as: .zip

Change History (4)

by zarch, 10 years ago

Attachment: rhorizon.diff added

r.horizon adding horizon_start and horizon_end parameters

comment:1 by annakrat, 10 years ago

Keywords: r.horizon added

That seems to be the easiest and safest option. I agree with renaming output maps, I remember it bothered me once.

comment:2 by zarch, 10 years ago

Resolution: fixed
Status: newclosed

Done in r61096.

comment:3 by neteler, 8 years ago


Milestone renamed

Note: See TracTickets for help on using tickets.