Hi Daniel,

2007/8/20, Daniel Bundala <bundala@gmail.com>:

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.

Unfortunately there are two libraries which handle

the solution of linear equation systems.

The gmath library with the G_math_* and G_vector_* functions

and the higher level gpde library with several multi threaded solvers

(N_solver_cg ...).

I have implemented the matrix vector functionality in the gpde library

again, because i wanted them multi threaded and i have had no idea

if the gmath functions are thread safe and easy to parallele.

Firstly, Soeren wrote that the current code is multithreaded.

Yes, the code from the gpde library is multi threaded, but you can

link parallelled lapack and blas libraries to the gmath interface (scalapack).

Secondly, someone mentioned, that it supports the sparse matrices.

The gpde library supports a simple sparse matrix implementation

and the matrix vector product functions.

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...)

Of what kind are your matrices? There are two very efficient

solver within the gpde lib:

1.) for sparse symmetric and positive definite matrices (conjugate gradients

with preconditioning cg/pcg)

http://en.wikipedia.org/wiki/Conjugate_gradient_method

and

2.)for sparse non symmetric, non definite matrices (stabilized bi

conjugate gradients)

http://en.wikipedia.org/wiki/Biconjugate_gradient_method

Those two methods are the most efficient linear equation solvers

available for large matrices.

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.

The matrix implementation within the gpde library offers direct access

to the matrix entries and supports row shuffling by setting the

row pointer (important for for pivoting). So the programmer

have to assure thread safe access by himself.

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.

The gpde library implementation is IMHO not faster than

the gmath and BLAS/LAPACK stuff. Eg: the gmath lu solver

is 30% faster than the gpde lu solver with pivoting.

But the gmath lu solver is code from the numerical recipes,

we have to rewrite this method. And the gpde lu solver runs on

multi processor machines.

I will present an implementation of several matrix-vector functions

in some days. And I'm open for any suggestions about API design.

Best regards

Soeren

--

Psssst! Schon vom neuen GMX MultiMessenger gehört?

Der kanns mit allen: http://www.gmx.net/de/go/multimessenger