Hi, I think that it is a good idea to have one library matrix/vector calculations. But it is not a good idea to base it on v.generalize matrix code since the suggested methods are more efficient and general. I am not an expert in the field of LA solvers so I really cannot tell which one is better. But I am pretty sure to say that the specially designed and optimised solvers are better than my bunch of LA functions. And also, it would be a great idead and increase in efficiency to use specialised LA library for matrix stuff in v.generalize
Daniel On 8/21/07, "Sören Gebbert" <[EMAIL PROTECTED]> wrote: > > -------- Original-Nachricht -------- > > Datum: Tue, 21 Aug 2007 19:15:48 +0000 > > Von: Brad Douglas <[EMAIL PROTECTED]> > > An: Daniel Bundala <[EMAIL PROTECTED]> > > CC: Wolf Bergenheim <[EMAIL PROTECTED]>, "Sören Gebbert" <[EMAIL > > PROTECTED]>, GRASS developers list <[email protected]> > > Betreff: Re: [GRASS-dev] BLAS/LAPACK (Part II) > > > On Mon, 2007-08-20 at 22:08 +0200, Daniel Bundala wrote: > > > Guys, > > > > > > It is quite interesting, but I have had plans to replace v.generalize > > > matrix code by "yours" library code. I have not studied G_matrix_* > > > code carefully, but it seems to me that it is superior. > > > > BLAS/LAPACK are vastly superior. > > > > I have a couple modules I'm working on that I've either used or in > > process of converting to use G_matrix_*()/G_vector_*() functions that > > call BLAS/LAPACK. I would also like to expand the usage of BLAS/LAPACK > > by making additional functions available (I suspect this may be > > beneficial to you, also). > > > > > Firstly, Soeren wrote that the current code is multithreaded. > > > > Soeren's code does not use BLAS/LAPACK. It probably should. > > Well ... :), > a mathematic Professor (http://www.math.tu-berlin.de/~schwandt/index_en.html) > told me, that some compiler with OpenMP support replace the matrix > and vector stuff with high optimized BLASS/LAPACK functions. > > I guess thats what the intel compiler partly did with my code to get this > nice speedup: > http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/GRASS_PDE_lib_SGI_bench.png > http://www-pool.math.tu-berlin.de/~soeren/grass/modules/screenshots/sgi_altix_cg_bench.png > > I was thinking about this too, but im not sure how to implement this. > I dont know if the BLAS/LAPACK wrapper is thread safe and i dont know if > multi threaded code works correctly together with scalapack libraries. > > There are only a few LAPACK methods available in the gmath library, we need to > extend it. Also many algorithms within the gmath directory do not make use of > the > BLAS/LAPACK stuff, eg: the lu solver. > > Well i think i can use the G_matrix and G_vector constructs within the gpde > library. > I will have a deeper look in the gmath stuff. > > Best regards > Soeren > > > > > > Secondly, someone mentioned, that it supports the sparse matrices. > > > Support of sparse matrices would increase the efficiency of > > > v.generalize since it uses only the sparse matrices. > > > Thirdly, Soeren mentioned that the current code supports many methods > > > my code doesnt support. To tell the truth, I have never heard about > > > many of them (Well, I am still (young) student...) > > > > > > The only thing I am missing in the current code is the direct access > > > to the elements of a matrix. But, this is quite dangerous and I really > > > doubt whether this is a good API-desing. > > > > > > On the other hand, it is true that the current code is quite obscure, > > > say. Also, it is tempting to replace fortran code by C code. > > > Therefore, my suggestons are: clean library code and replace the > > > current code by v.generalize code only if it is really faster. Some > > > benchmarks are probably required, but I doubt that my code beats > > > (optimized) library code. > > > > One way or the other, it doesn't really matter to me. I just don't want > > to have modules with dependency requirements that others do not. > > > > BLAS/LAPACK are superior, but there's no since having it around if > > nobody is going to use it. It just becomes clutter at that point. IMO, > > few will compile it into their build if only a few obscure modules use > > it; leaving those with more specific needs at a disadvantage. > > > > > > -- > > 73, de Brad KB8UYR/6 <rez touchofmadness com> > > > > _______________________________________________ > > grass-dev mailing list > > [email protected] > > http://grass.itc.it/mailman/listinfo/grass-dev > > -- > Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten > Browser-Versionen downloaden: http://www.gmx.net/de/go/browser > _______________________________________________ grass-dev mailing list [email protected] http://grass.itc.it/mailman/listinfo/grass-dev
