[tuhopuu-devel] UV-LSCM

Bruno Levy tuhopuu-devel@blender.org
Fri, 05 Mar 2004 15:03:34 +0100


Hi there,

I've been in contact with Brecht about LSCM,
I've just seen some questions about why I used
SuperLU in Graphite, here is a few answers that
may help :

My initial implementation of LSCM was based on CG (there is still an 
implementation of CG in Graphite,  and changing PERMSUPERLU
to CG in Graphite should have worked, maybe there is one or two 
parameters to tune). I've tested several preconditioners,
SSORCG is the best in most situations (JacobiCG is not sufficient, and
Incomplete Cholesky CG dramatically reduces the required number of
iterations, but it takes too much time to construct).
The reason why I'm using SuperLU is that SuperLU is between 10x and 100x 
faster than CG !!! SuperLU is a direct solver, most people (including me 
a few years ago) think that a direct solver cannot be faster than an 
iterative one. SuperLU is an exception, it is developped by the Los
Alamos research lab on supercomputing, those people know what they are
doing (at least I hope so, they are also doing nuclear bomb 
simulations...). You cannot redo 10 men years during your free time...
There is also another even faster solver called MUMPS that I'll try (it 
was written by J.Y. Lexcellent, who works also at the Inria, the same 
institute as me). The only problem with MUMPS is that it's written in 
Fortran 90 :-(
SuperLU is really worth it (even if it requires including a few C
and fortran-to-C converted files included in the distribution). It
is much more than the LU decomposition algorithm, it includes what
they call the "Super Nodal" approach (they consider "matrices of
matrices" recursively ...).


 > bjornmose:
 >i am not willing to look at graphite's code any longer since i poked > 
 >evre=
 > y=20
 > now and then to find there is ugly redundant code all over (nice > 
 >formatti=
 > ng=20
 > does not make clean code ) and not beeing able to solve a simple 
linear > /=
 > =20
 > square optimization problem ( needing a superLU, which is definitely=20
 > unefficient on a sparse matrix  like this, to do ) shoots the bird.
 >
 > sorry for beeing that harsh!

No problem, I'm used to that (when you write scientific papers, you 
often receive reviews that can be worse than that :-)
BTW, where did you find "ugly redundant code" in Graphite ? We
will fix that.

Best regards,
-- Bruno.