GitLab

Now this is done consistently both in autoconf and automake. One can now
safely call make clean and the header files are re-generated
automatically.

Automake does not easily allow to use the same source in a libtool
library and in a program

The issue why these test programs are simply not build
has to be investigated

It turned out that if a CPU supports SSE the already existing
test for SSE assembly instructions always passes.
However, the compilation of gcc SSE intrinic instructions might
nevertheless fail if gcc is not called with one of the options
"-msse3", "-msse4" , "-msse4.1", "-msse4.2", "-mavx", or "-mavx2"!

Obviously gcc does still not consider SSE as a standard on X86_64
Intel CPUs.

An additional configure test has been introduced, which test for
gcc intrinsic sse instructions. If this test fails, the corresponding
kernels are switched off.

The C++ kernels can be written as C kernels, which simplifies the build
procedure

In order to increase type safty all ELPA2 kernels provide now
an interface. The interfaces for the C/C++ kernels are automatically
generated during the configure step

The test programs are just needed at the build step (make check),
they are useless for users and will not be installed anymore

For the Intel compiler, this was assured with the pragma

  !DEC$ ATTRIBUTES ALIGN: 64:: a

however, other compilers such as gcc of course did not honour this,
which could result in SIGSEGVs in case the variable was not aligned to
32 bytes (by chance!).

This fixes issue #11, thanks to Nico Holmberg for reporting this.

The SSE kernels with blocking of 2,4,6 (real case) and 1,2 (complex)
case are now available by default

Thus the following changes have been done
- introduce new macros in configure.ac and Makefile.am
- renmae the AVX kernels in AVX_AVX2 (they also support AVX2)
- introduce new files with SSE kernel
- introduce new kernel parameters !
- make the SSE kernels callable

The results are identical with previous kernels

- The SSE part will be available in different files.
- Specify whether AVX or AVX2 was used to build

The single precision version of the SSE assembly kernel is about 1.8
times faster than the double precision version

library

It the configure option "--enable-single-precision" is specified,
ELPA will also be build for single precision usage. The double precision
and single precision will be available at the same time with names
"solve_evp_real_1stage_double" or "solve_evp_real_1stage_single" and
so on...

This change immplied some major refactoring of the ELPA code:
1.) functions/procedures had to be renamed with suffix "_double"

2.) If necessary the same functions have to be available with suffix
"_single"

3.) Variable kind definitions have to be consistent with the
intented use

To avoid uneccessary code duplication this is done (most of the time)
with preprocessor string substitution.

The documentation has been updated.

NOT SUPPORTED are at the moment:

- single precision usage of ELPA2 with kernels, others than "generic"
  and "generic_simple"

- single precision usage of GPU

The test programs include the same template now, the
printed messages are thus unified

The configure flag "--enable-shared-memory-only" triggers a build
of ELPA without MPI support:

- all MPI calls are skipped (or overloaded)
- all calls to scalapack functions are replaced by the corresponding
  lapack calls
- all calls to blacs are skipped

Using ELPA without MPI gives the same results as using ELPA with 1 MPI
task!

This version is not yet optimized for performance, here and there some
unecessary copies are done.

Ths version is intended for users, who do not have MPI in their
application but still would like to use ELPA on one compute node

With the configure option "--enable-single-precision" ELPA1 is build
with single-precision (half-words) only.

The best precision in single-precision (float or complex) is
2^-23 ~ 1.2e-7. The accuracy of the error residual of ELPA1 in
single-precision mode is of the order 1e-4 to 1e-5. The orthogonality of
the EV's is fullfilled up to about ~1e-6.

Thus the precision of ELPA1 in single-precision mode is roughly 100 -
1000 times less than the best achievable precison. This is consistent
with the double-precision mode, where also a factor of 100 - 1000 less
precision than the theoretical best one is found.

The float EVs are identical to the double EVs to at least 1e-2, the
precision of the EVs is thus about 1e-7/1e-2 = 1e5 times lower than the
best theoretical precision. If the same holds for the double precision
calculations, this implies that the double precision results can also
be only trusted on the level 1e-11 (5 orders of magnitude larger
than the best theoretical precision)

The best speed-up compared to the double precision calculation is
a factor of two. This is by far not achieved yet, since the singl
precision version is not at all optimized at the moment