[Wavepacket-ng-devel] Tensor libraries

[Ulf L. <ul...@wa...>]

Hi,

so I had a look at the candidates for tensor libraries. You can have a
more detailed view by looking at the discussion thread of the task (
https://sourceforge.net/p/wavepacket/cpp/tickets/5/). Here only a short
summary, since ... let me put it this way, it does not look like a tie:


I did a google search for tensor libraries and stopped on page 20 or so
when projects started to be repeated the third time or so. Most tensor
libraries are either restricted to 3 or 4 dimensions (for modern
computers and not too unusual problems, this can become too low), or
they are based on template programming (vastly increasing the
compilation time, requiring us to write everything using template
metaprogramming as well, and being a pain to test).

Apart from these, I found three libraries:
1. The Portable Science Toolkit is more for solving huge partial
   differential equations on parallel machines. I do not know how far
   Andrea has come with checking it out, but it was a bit of a long
   shot. The advantage would be that things like parallel computing
   would be included (though we still would have to layout our data for
   that), and it includes e.g. a lot of solvers. The disadvantage is
   that it would be pretty much overkill (including installation for
   single workstation users).
2. ITensor. What I did not like here is the installation, which
   requires some non-standard libraries, the code, which is among other
   things mostly undocumented, and the fact that my first test gave
   wrong results. Besides, the library does about the same as candidate
   #3 with 6x the amount of code. In any case, this library requires a
   lot of developer resources to make it usable.
3. Tensor C++ library. It is modeled relatively close to Matlab. I do
   not like or agree with everything there, and there are also things
   that need to be done, but the library itself is pretty mature (8
   years productive use), usable and stable. With about 5.000 lines of
   code, it is also not too big. I also contacted the developer and he
   is open-minded to feedback or code from our side.

As a consequence I would suggest to go with the third candidate. We
will have to dig into it and contribute to the library (some
documentation is missing, there were some bugs in the head, we need fft
sooner of later), but from the testing so far, it looks the most
suitable one.

Comments?


Ulf