GitLab

Point more clearly to the usage of ELPA under the terms of the LGPL.

Intel (thanks, especially A.Heinecke from Intel) there exists an
optimized version of ELPA with AVX2 support.

This merge includes all the optimizations done by Intel plus some
smaller changes which were necessary to incorperate these modifications.

A build without autotools is not officially supported anymore.
Thus this --- broken since long time --- Makefile.example is removed

The examples, how to invoke ELPA from a c program have been updated.
There are now examples for ELPA1 and ELPA2 both real and complex case.
The test cases are still with less functionality than their Fortran
counter parts, they are just ment as a "proof-of-concept".

- enabling fusing iterations of stage 5 in ELPA2 for every configuration
- Changed reduction bandwidth in ELPA2 to be at least 64
- partial OpenMP parallelization of the QR factorization in bandred_real
- OpenMP parallelization of SYMM
- OpenMP parallelization of SYR2K in bandred_real
- OpenMP parallelization for elpa1_reduce_add_vectors and elpa1_transpose_vectors
- AVX2 support in backtransformation elpa2_kernels (FMA3 instructions introduced with Haswell microarchitecture)

Inge Gutheil from FZ Juelich pointed out, that the
configure test for BGQ failed due to typos.
These are corrected now

complex cases

Create automatically two independent routines for real and complex
valued matrices

This commit is not ABI compatible

This commit is not ABI compatible, since it changes the interfaces
of some routines

Also, introduce type checking for transpose and reduce_add routines

These files are always automatically generated by autooconf and should
not be in version control.

Andreas Gloess informed us about a memory leak in ELPA, which was
introduced in version 2013.11.008.

This memory leak is removed now again.

Note, that older versions of ELPA will not be fixed right now.

An "dangling" fi has been removed

Remove variables which are not needed (anymore)

The macros which define the functionality to test
for
 - a specific real/complex kernel (not all available kernels)

are now defined in files in the m4 directory

Just polishing of text
Signed-off-by: Andreas Marek <amarek@rzg.mpg.de>

There was an inconsistency when the OpenMP flag was different for the
Fortran and C compiler (e.g. -openmp for ifort and -fopenmp for gcc).

This led to strange errors when linking the example program with the C
main() routine when using Intel Fortran, Intel MPI, and GCC together, a
typical error message was

  /usr/bin/ld: MPIR_Thread: TLS definition in [...]/intel64/lib/libmpi_dbg_mt.so section .tbss mismatches non-TLS definition in [...]/intel64/lib/libmpi_dbg.so section .bss
  [...]/intel64/lib/libmpi_dbg_mt.so: could not read symbols: Bad value

The reason seems to be that the various MPI wrapper shell scripts
(mpicc, mpiifort) need the correct OpenMP option to select the
thread-safe Intel MPI debug library. Previously, always OPENMP_FCFLAGS
was appended to LDFLAGS, which did not trigger this when linking a C
main program with mpicc.

Sourcecode in AC_LINK_IFELSE must now be guarded by AC_LANG_SOURCE
statements.

Just adding -maxv works on many systems which have compiler that can
produce AVX code but do not necessarily have processors with AVX
support.

If not, abort with an #error (this means that configure failed to detect
the lack of AVX support for C++)

The flag -mavx was not removed from C/CXXFLAGS again if AVX is unusable

- provide C interface for ELPA Library

- correct an error in the test case for QR-decomposition

Some compilers detected the static out-of-bounds condition present in
the test code and refused to compile it.

C interfaces are now available and definied in the header
elpa.h