[GRASS-dev] lidar tools update in grass7

[Soeren Gebbert]

Hello,

2010/2/8 Hamish <hamish_b at yahoo.com>:
> Markus Metz wrote:
>> The core of the lidar tools is the lidarlib, that is AFAICT
>> robust and working. Bugs are most likely in modules, so I'll try
>> to add comments there. I have reorganized the code for v.surf.bspline
>> in the hope that it is now easier to read.
>
> Slightly off-topic, but while we are thinking about this code ...
>
> A while back I did some crude profiling of the v.lidar tools and found
> that it was spending lots and lots of time in the Tcholetsky decomposition
> loop (3-for loops deep).
>
> It seemed like a good & simple test case for using OpenMP to multi-thread
> it, but I got stuck with it segfaulting. AFAIR the problem was that OpenMP
> wanted you to malloc the entire thing before starting, and this could
> get big.

There is an OpenMP version of a bandwidth optimized cholesky
decomposition algorithm in gmathlib.
I will have a look on the lidarlib to evaluate if we can use the
existing OpenMP tuned
cholesky. Besides of that, i will move the lidar linear equation
solver and the inversion algorithm into
the gmath library, so more modules may benefit from it.

I have made some performance tests with the OpenMP tuned linear
equation solver (cholesky, gauss, lu) in gmathlib,
there is unfortunately not much speedup, which is related to the
design of the solver algorithms.
The solver benchmarks are available in the grass7 lib/gmath/tests directory.
I have had only measurable speedup with the intel compiler (which is
free for open source projects),
the speedup with the gcc OpenMP implementation is little.

Additionally it would be interesting to consider the use of the OpenMP
tuned conjugate gradient solver from gmath within the lidar tools.
This solver has an excellent linear speedup (related to the
parallelzied matrix-vector multiplication), is quite fast (non-linear
convergence)
and works with sparse matrices.

Best regards
Soeren

>
> if it interests you, see the attached patch and
>  https://trac.osgeo.org/grass/ticket/657
>  http://lists.osgeo.org/pipermail/grass-dev/2009-June/044709.html
>  http://lists.osgeo.org/pipermail/grass-dev/2009-June/044705.html
>  http://grass.osgeo.org/wiki/OpenMP
>
>
>> I forgot to mention, there is a problem with sqlite, it is much slower
>> than dbf, no idea if this is a problem of my system or of the grass
>> sqlite driver or of the way auxiliary tables are accessed by the lidar
>> tools.
>
> that sounds vaguely familiar, but as a general thing not necessarily
> to do with v.lidar. probably something about it in the archives?
>
>
> Hamish
>
>
>
>
> _______________________________________________
> grass-dev mailing list
> grass-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/grass-dev
>