[GRASS-dev] [GRASS GIS] #3104: Parallelize tools like r.cost

[GRASS GIS]

#3104: Parallelize tools like r.cost
--------------------------+-------------------------
  Reporter:  belg4mit     |      Owner:  grass-dev@…
      Type:  enhancement  |     Status:  new
  Priority:  normal       |  Milestone:  7.3.0
 Component:  Raster       |    Version:  unspecified
Resolution:               |   Keywords:  r.cost
       CPU:  Unspecified  |   Platform:  Unspecified
--------------------------+-------------------------

Comment (by mmetz):

 Replying to [comment:3 belg4mit]:
 > Hmm, the algorithm used is different than I imagined. However it seems
 like one possibility, although it would not necessarily scale easily
 beyond two cores, would be to have a pair of threads iterating over the
 raster cells: One beginning at the top left and the other working
 backwards from the bottom right.

 r.cost, like least cost search path methods in general, do not iterate
 over items. Instead, r.cost starts with the start cells, calculates costs
 to the neighbors and continues with the cell with the least cost,
 calculating the costs to its neighbors, granted that the neighbors have
 not yet been processed. It stops when all cells have been processed or if
 all stop points have been reached. That means random access to cells, the
 order in which cells are processed is determined by the cost to reach a
 cell.

--
Ticket URL: <https://trac.osgeo.org/grass/ticket/3104#comment:4>
GRASS GIS <https://grass.osgeo.org>