Re: [Cppqed-support] FLENS

[Michael L. <mic...@un...>]

Hi András,

I already started with the heev port.  I hope to finish it this week.

Cheers,

Michael


Am 13.04.2014 um 19:09 schrieb Andras Vukics <and...@ui...>:

> Hi Michael,
> 
> Thanks for your explanation. Far from being confusing, it made me understood the concept.
> 
> My confusion had probably stemmed from the fact that cxxlapack is distributed together with flens (same git repository), so that I thought it’s an integral part (as „default” backend). But then this is used only for testing, benchmarks, etc. And for those parts of lapack that are not yet rewritten in flens.
> 
> Seeing the Hermitian eigenproblem implemented would be great. This has great relevance in quantum physics for calculating energy spectra of systems (eigenvalues of the Hamilton operator, which is normally Hermitian).
> 
> Indeed, the main point for us is to be independent of a pre-installed lapack. C++QED has now cmake for its build system, and with the external-project feature of cmake, we could even achieve that a given git version of flens gets checked out during the build process of C++QED and used by the framework. This is probably the least bothersome way for a user.
> 
> Best regards,
> András
> 
> 
> 
> On Fri, Apr 11, 2014 at 11:08 AM, Michael Lehn <mic...@un...> wrote:
> Hi András,
> 
> thanks for testing FLENS on your ARCH box!  And of course for using FLENS :-)
> 
> About CXXLAPACK and FLENS-LAPACK:
> 
> - CXXLAPACK is a C++ wrapper for LAPACK.  Like CBLAS is a C-wrapper for BLAS
>   or CLAPACK for LAPACK. So this requires a LAPACK backend.  Having a link
>   error like "undefined reference to 'zheev_'" means that the backend is missing.
>   This wrapper is pretty low-level.  It only eases the task of calling Fortran
>   functions from C++.  The wrapper for (z)heev looks like this
> 
>     http://apfel.mathematik.uni-ulm.de/~lehn/FLENS/cxxlapack/interface/heev.tcc.html
> 
> - FLENS-LAPACK is a C++ rewrite of LAPACK.... unfortunately only of a subset
>   of LAPACK.  As you noticed e.g. (z)heev is not yet rewritten.  By rewrite
>   I actually mean that it is a standalone C++ implementation of LAPACK.  So
>   no LAPACK backend is needed.  But for testing my reimplementation of
>   FLENS-LAPACK I compare results against LAPACK.  For users the advantage of
>   FLENS-LAPACK is that you don't have the LAPACK dependency.  Furthermore you
>   can use mpfr data types.  My reason for FLENS-LAPACK is to prove that with
>   C++ & FLENS you can do the same implementation as with Fortran (same speed)
>   just simpler. 
> 
> If you compile with USE_CXXLAPACK then FLENS-LAPACK is preferred over LAPACK.  But
> if a functions is missing in FLENS-LAPACK the LAPACK implementation gets used. That
> means for a non-symmetrix/non-hermitian matrix 'ev' calls the FLENS-LAPACK
> implementation.  And (at the moment) it calls for a symmetric/hermitian matrix the
> LAPACK Version (through the CXXLAPACK wrapper).
> 
> -> So a reimplementation of heev is next on the list.  That would mean that you
>    are independent of LAPACK 
> 
> If you compile with ALWAYS_USE_CXXLAPACK then only the LAPACK beackend gets used.
> Even if a C++ implementation exists in FLENS-LAPACK.  I use this option for
> benchmarking FLENS-LAPACK against LAPACK.
> 
> Speaking of benchmarks.  The performance of LAPACK does not depend on the Fortran
> compiler.  Analogously, neither does the performance of FLENS-LAPACK  depend on
> the C++ compiler.  In both cases it depends on the speed of the BLAS kernel.  In
> FLENS is include a simple default implementation similar to Netlibs REFBLAS. 
> 
> So for high performance there still remains a dependency for a tuned BLAS core.
> 
> Sorry for the long mail.  But I am watching my student taking their math final right
> now so I have a lot of time to type.  I hope it is not confusing even more :-)
> 
> Cheers,
> 
> Michael
>