On Tue, Jul 23, 2013 at 12:57 PM, John Peterson <jwpeterson@...:
>>> There is some good stuff in here, particularly
>>> the _nonhermitian_eig_lapack stuff.
>>> I'd like to get it into libmesh, do you have any test codes that verify
>>> it is working?
>> I am not sure if I have verified this code. I had started to add this a
>> few months ago, but then it became unnecessary and I never got around to
>> veryfying the code.
>> I can test it at my end, and send you an updated patch if needed?
> That would be good, but it would be even better if we had a very short
> libmesh code that also demonstrated it working (not a full application
> It looks like it's designed to work when Number=Real, but I wonder if
> you've tested that it compiles with Number=std::complex?
> Also, what do you envision the user-facing interface for _nonhermitian_eig_lapack
> should be? For example, lu_solve, cholesky_solve, and svd call some
> underlying Lapack routines. DenseMatrix::eig() maybe?
Good observation about the real/complex design. After looking at the code,
I now realize that I never really instantiate the method (shows that I
never got around to using it).
I think that I was porting this implementation from some of my other codes,
but stopped because I was able to get analytical expressions for the
eigenvalues/eigenvectors of the matrix of interest.
So, to answer your question, I have not verified that it works, and
certainly not verified that it compiles with complex numbers. Both of these
should not be difficult to do. A specialization to interface with complex
lapack routines could also be added, but I have no experience with
interfacing std::complex with the complex number representation for lapack.
Any thoughts here?
I like DenseMatrix::eig(). Perhps with arguments to return the eigenvalues
I will try to put together this code and a small example and send it your