Soeren Gebbert wrote: > Hello, > >>> 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). >>> >> >> That's better now because the matrix is a bit smaller. > > Yes, its a nice symmetric band matrix. Was a bit puzzling for me to > understand the creation of the matrix without any documentation!
I added documentation where I understood the code but honestly, the inner workins of the lidar_lib are still a mystery to me. > So, i have implemented some conversion functions into the gmath > library while moving the tchol* code from lidar lib into the gmath > lib There are still bugs in the code, mostly minor concerning warning and error messages, one major in v.surf.bspline for very large raster output regions. I'm busy fixing it, also converting it to a new module r.resamp.bspline that does particularly well for filling NULL cells, a real alternative to (the much slower) r.fillnulls. >[...] i would suggest to use MPI parallelization or something else on > process base, to concurrently compute the subregions which are created > by default. Maybe a python script using overlapping tiling and > subprocess can do the job? I think that should be integrated into the current lidar tools because they make use of the current subregion tiling and C code is still faster than Python code (right?). Treatment of overlapping zones of neighbouring subregions is done sometimes in the lidar_lib, sometimes by the modules themselves. It took me quite some time to understand it and fix it, therefore I would advise against code porting/duplication. My 2c, Markus M _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev
