Colin wrote:
>> A colleague of mine would like to run a cost analysis
>> (with either r.walk or r.cost) on a very very large
>> raster, ~ 1500 km x 800 km with about 30 m resolution
>> equals about 40 billion cells.
>
> [ see my other today's email about r.terracost now in
> Addons ]
>
>> Is there any plan to add multi-threading to these or other
>> modules (I think I remember something about r.mapcalc and
>> another a while back)?
Markus:
> Yann Chemin parallelized i.atcorr for me with openMP which
> required the addition of a few lines and a gcc >= 4.2
> compiler. For hints, see
> http://grass.osgeo.org/wiki/OpenMP
>
> Perhaps this can be introduced at library level at some
> point. The behavior or a pixel oriented module such as
> i.atcorr is of course different from that of r.cost which
> has to consider more than a pixel in a cycle.
Colin wrote:
In my experience, the main drain in computation time is the
IO not the actual calculation of the btree. Is there any way
to parallelize the IO by passing rows to different cores or
something like that ie. "for (row = 0; row < nrows; row++) {"?Or a more efficient segment library sounds good as well. Is
there a way to estimate how much more efficient would it be and
would it make use of multiple cores?
FYI there is a Google Summer of Code student proposal to add
OpenMP support to a number of GRASS modules and/or libraries.
I would encourage anyone interested or knowledgeable in such things to get in touch with Wolf to sign up to be a mentor. Then you can review and comment on the OSGeo applications etc.
The better the plan & the better the mentoring, the more successful the student's application and (if accepted) project
will be.
regards,
Hamish