Hi everybody!

I am a first-time user of Eigen2 and have a little trouble here using it. My problem I want to solve is to find *all* eigenvalues of a sparse matrix which is real and symmetric. I considered the SparseMatrix class and plugged it into the SelfAdjointEigenSolver which did not work. Some functions in SparseMatrix are missing which are required by the solver. So I turned to a dense matrix representation which works but is definetley not optimal. Will there be a sparse ev solver like slepc for petsc? Did I miss something in the sources? I saw these solvers for sparse matrices in the code, but none looked promising to me.

Furthermore, are there options for parallelizing things? I wanna use all my cores on my cpu. The Todo page says a little bit about it, but not too much.

Best regards,

Sebastian Weber

Hi,

no currently there is no eigenvalue solver for sparse matrix, and no multicore support. Both are on the todo, but don't expect them soon. For the former we'll certainly use other libs just like I write wrappers for suitesparse, superlu, taucs. Do you have a good library to suggest ? Perhaps you might even be able to write the respective wrapper ! I've heard about ARPACK++ but it is very difficult yo use.

gael.

I read that slepc is supposed to be very good at solving sparse problems, but I suspect that the license is too restrictive for wrapping it into eigen. The ARPACK++ lib seems to be rather old and not maintained, so I would hesitate using it. Additionally the docs say that it computes only a few eigenvalues with some characteristics and not all. I guess I will just keep my matrices small for the moment - the Eigen SSE stuff makes things quite fast ...

sweber wrote:I read that slepc is supposed to be very good at solving sparse problems, but I suspect that the license is too restrictive for wrapping it into eigen. The ARPACK++ lib seems to be rather old and not maintained, so I would hesitate using it. Additionally the docs say that it computes only a few eigenvalues with some characteristics and not all. I guess I will just keep my matrices small for the moment - the Eigen SSE stuff makes things quite fast ...

hm, both slepc and ARPACK are not very good candidates for us. slepc depends on petsc which itself depends on a ton of libraries. Just like ARPACK, this seems to be a nightmare to use. Actually, once we have good linear solvers, then writing a high-level sparse eigen solver seems not to be so difficult. With this respect, a template library like IETL seems to be a good candidate. We'll see...

Well, luckily we got apt to resolve these dependencies which is ok for me. By now I even found a C++ wrapper for slepc - dolfin from the fenics project sounds promising. BTW, another candidate is the trilinois package for which one has to write an Epetra-matrix wrapper which should be manageable as there is wrapper for petsc matrices. Once an Epetra wrapper for eigen is available, one can use all those shiny trilinos packages with eigen!

Hi!

Just wanted to note that gsl is about 2-3x times faster than the eigen library at calculating all my eigenvalues (real symmetric matix). What could I have been doing wrong?

Greetings,

Sebastian

sweber wrote:Hi!

Just wanted to note that gsl is about 2-3x times faster than the eigen library at calculating all my eigenvalues (real symmetric matix). What could I have been doing wrong?

Greetings,

Sebastian

hm, this does not make sense. If your matrix is symmetric make sure you are using the SelfAdjointEigenSolver:

Code: Select all

SelfAdjointEigenSolver eig(mat);
mat.eigenvalues();

You can also reuse the allocated eigensolver:

Code: Select all

eig.compute(othermat);

or if you don't want the eigenvectors:

Code: Select all

mat.marked().eigenvalues()

Then make sure you are compiling in release mode (-O2 -DNDEBUG) and if that's still slow for you please paste your piece of code and tell us which compiler you are using.

Wow, thanks! I only needed the Eigenvalues and now Eigen is a little bit faster (roughly 1.3x) than the gsl. Did I miss something in the docs or is this

L.marked().eigenvalues();

a undocumented trick? Anyway, I think a small hint in the docs would not hurt!

sweber wrote:Wow, thanks! I only needed the Eigenvalues and now Eigen is a little bit faster (roughly 1.3x) than the gsl. Did I miss something in the docs or is this

L.marked().eigenvalues();

a undocumented trick? Anyway, I think a small hint in the docs would not hurt!

hm, you're right this is not very clear in the doc. Actually adding .marked() allows Eigen to know that the matrix is selfadjoint and so it will use the implementation optimized for self-adjoint matrices.

BTW, I just found SuiteSparseQR which is GPLed software and C++ code aimed at exactly this type of problem: See http://www.cise.ufl.edu/research/sparse/SPQR/ . I sounds like a very hot candidate to me as it is free and C++. The advertisement sounds *very* appealing, cutting down calculation sizes considerably. Furthermore, the library supports threading via intels tbb.

Let me add a few notes since I believe this thread is quite interesting. A colleague recommended the use of IETL as well. His main reason was its flexibility. he noted, the final speed of an eigensolver based on IETL does not primarily depend on the algorithms used by IETL, but on the underlying Linalg lib, i.e. Eigen2 in our case.

When considering GPLed sparse solvers I go in trouble when using it at my academic work. Moreover, it brings a lot of new dependencies which are aimed to be replaced by Eigen...

If asking me on chosing an Eigen solver, not only its efficiency, but also its usuability convenience is important. In the past I needed a solver which:
o computes all eigenvalues
o computes a few eigenvalues within a given range or given by their number
o computes a predefined number of eigenvalues below or above a certain value
o computes a certain number of eigenvalues where the number of required eigenvalues may be changed during their computation (for example, one wants to compute 50 eigenvalues and at the end one decides that one needs 20 more or so; or: one wants to compute max. 50 eigenvalues, but only those which are in a given range)

In the past we used eigensolvers which either solve the first use case or the 2nd+3rd usecase well. For the 4rth we did not find a suitable (freely to use) engine. I would love to see Eigen catching all of these...

I second that motion, those features would be great. Eventually it would sometimes be helpful to get only the largest eigenvalue as well.