[sina_mech]

Hi
I have a large sparse matrix (generated by Poisson Equation in my own C++ Code). I'm looking for a EASY TO EMBED AND USE, fast Sparse solver, witch can receive matrix of elements in sparse modes (to use lesser memory), and solve it by any of common fast methods (like Gmres, Bicgstab and ...).

I'll appreciate if anyone can help me

GoodLuck

[walli]

Consider using PETSc for your code! Even though it is (in my opinion) ugly C code, one can fairly easy write a rudimentary C++ interface if needed. It is really fast, tested and provides a big variety of solvers and preconditioners. Another possibility would be mtl4, which is written in C++, fast, but unfortunately still in alpha development stage. But why do you want to use GMRES, BiCGSTAB and so on? You system is symmetric and positive definite, so use a (preconditioned) CG solver for this.

[dominic]

I would use PETSc for this. Moreover, application of boundary conditions, and/or sources can disrupt the symmetry of the matrix. Thats why probably you cannot use CG.

Dominic

[walli]

Originally Posted by dominic

I would use PETSc for this. Moreover, application of boundary conditions, and/or sources can disrupt the symmetry of the matrix. Thats why probably you cannot use CG.

Sure, that's true. But this clearly depends on the way you incorporate the BC's. A way to do this symmetrically would be e.g. a penalty method.

[jed]

Originally Posted by walli

Sure, that's true. But this clearly depends on the way you incorporate the BC's. A way to do this symmetrically would be e.g. a penalty method.

Penalty is a bad choice with some preconditioners, or if the system is very ill-conditioned. The best way is to remove the Dirichlet degrees of freedom, either explicitly, or by making both] the row and column equal to the identity (with appropriate modification of the right hand side). This is easy to do, especially when using Newton-type iteration, but people still manage to write code in a way that makes this hard. Note that many good preconditioners are nonsymmetric sometimes enough better than the symmetric alternatives to justify using a nonsymmetric Krylov method.

[jed]

Originally Posted by walli

Even though it is (in my opinion) ugly C code

What do you dislike? Perhaps I can explain why certain things are the way they are.

[walli]

Originally Posted by jed

What do you dislike? Perhaps I can explain why certain things are the way they are.

That was more about C style programming than PETSc. Speaking about PETSc, I particularly don't like the inflationary use of the CHKERR-stuff. But don't get me wrong! It is a great library and it does its job very good!

[jed]

Originally Posted by walli

That was more about C style programming than PETSc.

Note that while it is written in C, it is very much object oriented. PETSc objects use a variant of the delagator/pimpl pattern, but see object creation is (by default) managed by an inversion of control known as dependency injection. You might have heard of this in the context of frameworks like Spring. This has the advantage that your code never makes explicit reference to the implementation of your objects, just the interface that they implement. With this design, it is natural that every object has a plugin architecture. That is, you can compile a preconditioner and custom matrix format to a shared library send it to someone else who does not have source for anything, and they can select your preconditioner at run time just like the ones distributed with PETSc.

Speaking about PETSc, I particularly don't like the inflationary use of the CHKERR-stuff.

Yes, I don't even see them anymore. The reason for this (and a couple other macros used within PETSc) is mostly to be able to get full stack traces when something goes wrong, as well as to detect memory corruption and leaks. C++ exceptions have serious interoperability problems and lack the semantics required to get reliable stack traces in parallel, as well as to automatically attach a debugger on the site where the error occurred (even in parallel). You certainly don't have to use these macros, but they really do make debugging easier.