Re: [Cppqed-support] FLENS

[Andras V. <and...@ui...>]

Dear Michael,

I have just run the testsuite with your latest commits on my ARCH box, and
everything seems to be fine. I used gcc 4.8.2.

As to USE_CXXLAPACK: what you say makes me suspect that I do not understand
the fundamental structure of FLENS-LAPACK :) . I thought that FLENS-LAPACK
needs some backend, which can be either cxxlapack (distributed together
with flens) or some lapack library already present on the system. I thought
that by defining USE_CXXLAPACK, we instruct FLENS to use cxxlapack, which
we need to do if we do not have any other lapack library. What is it that I
misunderstand?

Whether there is something missing that we need:

   - *Without *USE_CXXLAPACK (that I tried now after you said we don't
   necessarily need this #define) everything works (compiles, links and runs
   correctly) except Hermitian eigenproblem, which doesn't find the correct
   overload for the function ev.
   - *With* USE_CXXLAPACK Hermitian eigenproblem also compiles, but it
   fails to link, issuing the error

/usr/local/include/cxxlapack/interface/heev.tcc:91: error: undefined
reference to 'zheev_'


The good news is that we have released the new, shiny Milestone 10 release,
which optionally depends on the header-only FLENS, we have completely
deprecated our (optional) dependence on the old FLENS! We also have a very
shiny new API documentation whose entry point is the SourceForge C++QED
page:
http://cppqed.sourceforge.net

Thanks a lot for your help in this with bringing FLENS to a useable state
for us. Compile time is not an issue in our case
at the moment
, but if it ever becomes so, precompiled headers sound like a good idea
(although I have no experience whatsoever with them).

Keep in touch!
Best regards,
András




On Tue, Apr 8, 2014 at 9:07 PM, Michael Lehn <mic...@un...>wrote:

> Hi Andras and Raimar,
>
> I am done with merging the latest modification.  Could you check if FLENS
> passes
> the LAPACK tests on your machines?  I tested with gcc 4.7, 4.8 and 4.9.
>  But only
> on Mac OS X.  On my Ubuntu machine I only have gcc 4.6 which does not
> support all
> required C++11 features and clang++.  But clang++ does complex arithmetic
> different
> from gfortran (as there is no IEEE standard that is legal) and therefore I
> get
> different roundoff errors.
>
> For testing set and export CXX, CC, FC and run make && make check.
>
> Andras also mentioned that he compiled with USE_CXXLAPACK.  That is only
> required
> if some LAPACK function is not re-implemented in FLENS-LAPACK or if you
> want to
> compare results with netlib's LAPACK.  So is there anything missing in
> FLENS-LAPACK
> that you need?
>
> Furthermore, if compile time becomes an issue (the drawback of
> header-only) we
> could think about using precompiled headers.  This would have to be
> integrated
> into your build process.
>
> Cheers,
>
> Michael
>
>
> Am 28.02.2014 um 17:28 schrieb Andras Vukics <and...@ui...>:
>
> Hi Michael,
>
>  Thanks for the prompt reply, it's good to see that FLENS-LAPACK is so
> well supported! The requirement of bitwise correspondence is indeed
> impressive.
>
> It would be very nice if we could use a fixed upstream version of FLENS in
> our new release of C++QED that we plan to publish in about a month.
>
> But I don't want to press you :) .
>
> Cheers,
> András
>
>
>
>
> On Fri, Feb 28, 2014 at 4:53 PM, Michael Lehn <mic...@un...>wrote:
>
>> Hi Andras,
>>
>> thanks for the hints!  ZGEEV has two workspaces work and rWork.  The
>> dimension
>> of rWork should always be 2*N.  The wrapper with implicit workspace
>> creation
>> should create an internal vector of correct size.  The actual
>> computational
>> routine should have an assertion that ensures the correct size.  An
>> actual workspace
>> query for calculating optimal workspace size is only needed for the
>> workspace work.
>>
>> As the LAPACK test suit does not use the implicit workspace creation this
>> was
>> undetected.
>>
>> The ZGEEV passed all the LAPACK tests.  In this process I also compare
>> results
>> bit-by-bit with calls to the original Netlib implementation (Version
>> 3.3.1).  Also
>> in each call of any subroutine the results get compared this way.  So if
>> there still
>> should be a bug it is also in LAPACK 3.3.1
>>
>> And having cout's in my repository is a really annoying weakness of me
>> ... grrr
>>
>> Cheers,
>>
>> Michael
>>
>>
>> Am 28.02.2014 um 15:42 schrieb Andras Vukics <and...@ui...>:
>>
>> Dear Michael,
>>
>> Recently, we have started to migrate C++QED to the header-only
>> FLENS-LAPACK. The most important feature for us is the generic complex
>> eigenvalue solver (zgeev). I guess it is also among the most problematic
>> ones from the C++ implementation point of view.
>>
>> How would you evaluate the present maturity of the complex eigen solver?
>> I see that in the public upstream branch, it still emits a note to cout at
>> entering the routine.
>>
>> I noticed that the internal workspace query doesn't work correctly, so
>> e.g. this fails:
>>
>>   typedef GeMatrix<FullStorage<dcomp> > Matrix;
>>   typedef DenseVector<Array<dcomp> >    Vector;
>>
>>   Matrix a(3,3);
>>
>>   a=dcomp(0.89418418,0.88510796),dcomp(0.09935077,0.0955461
>> ),dcomp(0.19438046,0.77926046),
>>
>> dcomp(0.54987465,0.76065909),dcomp(0.07944067,0.34810127),dcomp(0.55701817,0.03426611),
>>
>> dcomp(0.80508047,0.48160102),dcomp(0.06586927,0.75840275),dcomp(0.15394400,0.99410489);
>>
>>   Vector v(3);
>>
>>   lapack::ev(false,false,a,v,a,a);
>>
>>   cout<<v<<endl;
>>
>> with:
>>
>> flens_d: /usr/local/include/flens/vectortypes/impl/densevector.tcc:253:
>> View flens::DenseVector<flens::Array<double, flens::IndexOptions<int, 1>,
>> std::allocator<double> > >::operator()(const Range<IndexType> &) [A =
>> flens::Array<double, flens::IndexOptions<int, 1>, std::allocator<double>
>> >]: Assertion `range.lastIndex()<=lastIndex()' failed.
>> Aborted (core dumped)
>>
>>
>> But this works fine:
>>
>>   typedef GeMatrix<FullStorage<dcomp> > Matrix;
>>   typedef DenseVector<Array<dcomp> >    Vector;
>>
>>   Matrix a(3,3);
>>
>>   a=dcomp(0.89418418,0.88510796),dcomp(0.09935077,0.0955461
>> ),dcomp(0.19438046,0.77926046),
>>
>> dcomp(0.54987465,0.76065909),dcomp(0.07944067,0.34810127),dcomp(0.55701817,0.03426611),
>>
>> dcomp(0.80508047,0.48160102),dcomp(0.06586927,0.75840275),dcomp(0.15394400,0.99410489);
>>
>>   Vector v(3), work(12); DenseVector<Array<double> > rwork(6);
>>
>>   lapack::ev(false,false,a,v,a,a,work,rwork);
>>
>>   cout<<v<<endl;
>>
>>
>> This is all with USE_CXXLAPACK defined.
>>
>> Best regards,
>> András
>>
>>
>>
>>
>> On Wed, Oct 3, 2012 at 11:14 PM, Michael Lehn <mic...@un...>wrote:
>>
>>> Hi András!
>>>
>>> I am using gcc 4.7.1, gcc 4.7.2 and clang 3.2.  All of them support all
>>> the
>>> C++11 features I ever needed so far.  However, I never tested things
>>> like lamda,
>>> regexp so far.  Just the few thing that were very handy for FLENS:
>>>
>>> - rvalue-references
>>> - auto
>>> - alias templates
>>> - variadic templates
>>> - some type traits
>>>
>>> You are absolutely right about clang.  It's error messages but also
>>> warnings are
>>> amazing and very useful!  And its complete concept (from font-end to
>>> back-end) is
>>> amazing.  I also use the clang parser for creating the tutorial.  For
>>> example
>>> creating cross references in listings like in
>>>
>>>
>>> http://apfel.mathematik.uni-ulm.de/~lehn/FLENS/flens/examples/lapack-gelqf.cc.html
>>>
>>> I also used to compile the examples in the tutorials with clang in the
>>> past.  But
>>> because of a problem with how MacPort installed clang I had to switch to
>>> gcc.  At
>>> the moment I switch the examples back to clang.  (Yes I admit that I
>>> converted from
>>> Linux to Mac, but I still use VIM in fullscreen).
>>>
>>> For testing FLENS-LAPACK I use g++ and gfortran.  The combination clang
>>> and gfortran
>>> should also work except for complex numbers.  Both g++ and clang++
>>> compute the complex
>>> arithmetic operations by falling back to their C99 implementation.  And
>>> they seem to
>>> use different algorithms for that.  Consequently you get different
>>> roundoff errors.
>>>
>>> Clang seems to implement the algorithm proposed in Appendix G in
>>>
>>>    http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf
>>>
>>> the division of two double complex numbers (p. 470) caused my tests to
>>> fail (ok, the
>>> difference was really small).  It finally found out the gcc uses the
>>> following algorithm
>>> that merely avoids overflow:
>>>
>>>    complex<double>
>>>    c_div(complex<double> a, complex<double> b)
>>>    {
>>>        complex<double> c;
>>>        if (fabs(b.real()) < fabs(b.imag())) {
>>>            double r = b.real() / b.imag();
>>>            double den = b.imag() + r * b.real();
>>>            c.real() = (a.real() * r + a.imag()) / den;
>>>            c.imag() = (a.imag() * r - a.real()) / den;
>>>        } else {
>>>            double r = b.imag() / b.real();
>>>            double den = b.real() + r * b.imag();
>>>            c.real() = (a.real() + r * a.imag()) / den;
>>>            c.imag() = (a.imag() - r * a.real()) / den;
>>>        }
>>>        return c;
>>>    }
>>>
>>> If you run the FLENS-LAPACK test let me know your results.
>>>
>>>
>>> Sorry, I just realize that I am really giving long answers to short
>>> questions ;-)
>>>
>>> Cheers,
>>>
>>> Michael
>>>
>>>
>>>
>>>
>>> Am 03.10.2012 um 22:02 schrieb Andras Vukics:
>>>
>>> > Hi Michael,
>>> >
>>> > It's really kind of you to have a look into C++QED from an FLENS point
>>> of view.
>>> >
>>> > I have a question on a slightly other note: What compiler would you
>>> > recommend to be able to use as much of C++11 as possible today? I
>>> > myself have found that llvm-clang has already a lot of these features
>>> > implemented. I incidentally often use it for another purpose: its
>>> > error messages are often much nicer that those of gcc.
>>> >
>>> > What compiler do you use to test FLENS-LAPACK?
>>> >
>>> > Thanks with best regards,
>>> > András
>>> >
>>> >
>>> > On Sat, Sep 22, 2012 at 10:18 PM, Michael Lehn <
>>> mic...@un...> wrote:
>>> >> Hi Andras,
>>> >>
>>> >> thanks for your kind reply and sorry for my last response.  I am
>>> >> very happy that FLENS is of use for you!
>>> >>
>>> >> You are right about the C++11 requirements and I completely understand
>>> >> your point.  Luckily time will solve the problem of lacking C++11
>>> >> support for us.  I will try to use the interim time to have a closer
>>> >> look on what FLENS features and LAPACK functions you need in C++QED.
>>> >> For example, I think it would be a useful feature for you if FLENS
>>> >> already contains generic implementations for all the LAPACK functions
>>> >> you need.
>>> >>
>>> >> Best wishes and greetings from Ulm,
>>> >>
>>> >> Michael
>>> >>
>>> >>
>>> >>
>>> >>
>>> >> Am 01.09.2012 um 18:57 schrieb Andras Vukics:
>>> >>
>>> >>> Hi Michael,
>>> >>>
>>> >>> Thanks for your mail. Not only in the past, but also presently C++QED
>>> >>> optionally depends on FLENS (recently we've even prepared some ubuntu
>>> >>> packages, cf. https://launchpad.net/~raimar-sandner/+archive/cppqed
>>> ).
>>> >>> All the eigenvalue calculations of the framework are done with LAPACK
>>> >>> *through* FLENS, and if the FLENS dependency is not satisfied, then
>>> >>> these tracts of the framework get disabled. (Earlier, we used to use
>>> >>> our own little C++ interface to LAPACK, but soon gave it up -- you of
>>> >>> all people probably understand why.)
>>> >>>
>>> >>> However, it is not your new FLENS/LAPACK implementation, but your old
>>> >>> project that we use, namely the 2011/09/08 version from CVS. For
>>> >>> months now, we've been aware of your new project, and it looks very
>>> >>> promising to us.
>>> >>>
>>> >>> The reason why we think we cannot switch at the moment is that our
>>> >>> project is first of all an application programming framework, in
>>> which
>>> >>> end-users are expected to write and compile their C++ applications in
>>> >>> the problem domain of open quantum systems. This means that when they
>>> >>> compile, they also need to compile the FLENS parts that they actually
>>> >>> use. Now, as far as I understand, the new FLENS/LAPACK uses c++11
>>> >>> features, which at the moment severely limits the range of suitable
>>> >>> compilers.
>>> >>>
>>> >>> But we are definitely looking forward to be able to switch, and are
>>> >>> glad that the project is well alive!
>>> >>>
>>> >>> Best regards,
>>> >>> András
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Sat, Sep 1, 2012 at 2:26 AM, Michael Lehn <
>>> mic...@un...> wrote:
>>> >>>> Hi,
>>> >>>>
>>> >>>> I am a developer of FLENS.  Browsing the web I saw that C++QED was
>>> using FLENS
>>> >>>> for some optional modules in the past.  There was quite a list I
>>> always wanted to
>>> >>>> improve in FLENS.  Unfortunately other projects were consuming too
>>> much time.
>>> >>>> Last year I finally found time.  If you are still interested in
>>> using LAPACK/BLAS
>>> >>>> functionality from within a C++ project some of its features might
>>> be interesting
>>> >>>> of you:
>>> >>>>
>>> >>>> 1) FLENS is header only.  It comes with generic BLAS
>>> implementation.  By "generic" I
>>> >>>> mean template functions.  However, for large problem sizes you
>>> still have to use
>>> >>>> optimized BLAS implementations like ATLAS, GotoBLAS, ...
>>> >>>>
>>> >>>> 2) FLENS comes with a bunch of generic LAPACK function.  Yes, we
>>> actually re-implemented
>>> >>>> quite a number of LAPACK functions.  The list of supported LAPACK
>>> function include LU,
>>> >>>> QR, Cholesky decomposition, eigenvalue/-vectors computation, Schur
>>> factorization, etc.
>>> >>>> Here an overview of FLENS-LAPACK:
>>> >>>>
>>> >>>>
>>> http://www.mathematik.uni-ulm.de/~lehn/FLENS/flens/lapack/lapack.html
>>> >>>>
>>> >>>> These LAPACK ports are more then just a reference implementation.
>>>  It provides the same
>>> >>>> performance as Netlib's LAPACK.  But much more important we
>>> carefully ensure that it
>>> >>>> also produces exactly the same results as LAPACK.  Note that LAPACK
>>> is doing some cool
>>> >>>> stuff to ensure stability and high precision of its result while
>>> providing excellent
>>> >>>> performance at the same time. Consider the caller graph of LAPACK's
>>> routine dgeev which
>>> >>>> computes the eigenvalues/-vectors of a general matrix:
>>> >>>>
>>> >>>> http://www.mathematik.uni-ulm.de/~lehn/dgeev.pdf
>>> >>>>
>>> >>>> The routine is pretty sophisticated and for example switches forth
>>> and back between
>>> >>>> different implementations of the QR-method (dlaqr0, dlaqr1, dlaqr2,
>>> ...).  By this
>>> >>>> the routine even converges for critical cases.  We ported all these
>>> functions one-by-one.
>>> >>>> And tested them as follows:
>>> >>>> (i) On entry we make copies of all arguments.
>>> >>>> (ii) (a) we call our port
>>> >>>> (ii) (b) we call the original LAPACK function
>>> >>>> (iii) We compare the results.
>>> >>>> If a single-threaded BLAS implementation is used we even can
>>> reproduce the same roundoff
>>> >>>> errors (i.e. we do the comparison bit-by-bit).
>>> >>>>
>>> >>>> 3)  If you use FLENS-LAPACK with ATLAS or GotoBLAS as BLAS backend
>>> then you are on par
>>> >>>> with LAPACK from MKL or ACML.  Actually MKL and ACML just use the
>>> Netlib LAPACK and optimize
>>> >>>> a few functions (IMHO there's a lot of marketing involved).
>>> >>>>
>>> >>>> 4) You still can use an external LAPACK function (if FLENS-LAPACK
>>> does not provide a needed
>>> >>>> LAPACK port you even have to).
>>> >>>>
>>> >>>> 5) Porting LAPACK to FLENS had another big advantage: It was a
>>> great test for our matrix and
>>> >>>> vector classes:
>>> >>>> (i)  We now can prove that our matrix/vector classes do not
>>> introduce any performance penalty.
>>> >>>>    You get the same performance as you get with plain C or Fortran.
>>> >>>> (ii) Feature-completeness of matrix/vector classes.  We at least
>>> know that our matrix/vector
>>> >>>>    classes allow a convenient implementation of all the algorithms
>>> in LAPACK.  An in our
>>> >>>>    opinion the FLENS-LAPACK implementation also looks sexy.
>>> >>>>
>>> >>>> I hope that I could tease you a little to have a look at FLENS on
>>> http://flens.sf.net
>>> >>>>
>>> >>>> FLENS is back,
>>> >>>>
>>> >>>> Michael
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>>
>>> ------------------------------------------------------------------------------
>>> >>>> Live Security Virtual Conference
>>> >>>> Exclusive live event will cover all the ways today's security and
>>> >>>> threat landscape has changed and how IT managers can respond.
>>> Discussions
>>> >>>> will include endpoint security, mobile security and the latest in
>>> malware
>>> >>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
>>> >>>> _______________________________________________
>>> >>>> Cppqed-support mailing list
>>> >>>> Cpp...@li...
>>> >>>> https://lists.sourceforge.net/lists/listinfo/cppqed-support
>>> >>>
>>> >>>
>>> >>
>>> >
>>> >
>>>
>>>
>>
>>
>
>