GitLab

The library will thus be called libelpa-2014.06.so

Rename all binaries to have an elpa1_, or elpa2_ prefix.
Additionally, also ship a README and license file.

With this, the pkg-config installation can be verified

This includes a number of changes:

- ScaLAPACK2 on from the openSUSE:science repository is now correctly
  auto-detected. As ScaLAPACK2 already includes BLACS, an additional
  BLACS library must not be linked!

- The resulting library is now called elpa-2014.06.000.so, as was
  probably originally intended anyway

- The pkg-config file was renamed to elpa-2014.06.000.pc and filled with
  correct values. With this, a package using ELPA can easily get the
  necessary compilation and library flags.

In this commit, only the "precious" files (Makefile.am, configure.ac,
etc.) are included, to make clear what has been changed by hand.

In the subsequent commit also all autoconf generated files will follow.

Without this, automake tries to be smart and rebuilt the autoconf
generated files such as configure, aclocal.m4, etc., in case the
timestamps of files such as configure.ac are newer.

This only makes trouble for end users with out-of-date autoconf versions
that cannot produce these files.

If one species a kernel with the "--with-kernel-name" option,
this means that only this (real/complex) is configured and
installed. All other available real/complex kernels are not considered.

Thus the help messages (see ./configure --help) is changed
such that the option is called

"--with-only-kernel-name"

- the library version number is changed due to change in ABI
- the INSTALL ascii file is updated
- a RELEASE_NOTES file is introduced

This includes fixes necessary to please gfortran as well as a slight
change in the way the various libraries are tested in configure.ac

- the library version number is changed due to change in ABI
- the INSTALL ascii file is updated
- a RELEASE_NOTES file is introduced

Now it is possible
- to choose the kernel (real and complex independently) at run-time
  via environment variables, or
- to specify the kernel (real and complex independently) at runtime
  via specifing the kernel in the call to ELPA

This has a few implications
1) The ELPA 2014.06 release has a change in the API and is thus not
   binary compatible with previous versions
2) if no kernels are specified, a default kernel is choosen
3) if a wrong kernel is specified, a default kernel is choosen

For sake of simplicity it is still possible to build ELPA with
support for only one kernel, as in previous versions. However, it is
still not binary compatible to previous versions

Configure checks whether the Fortran environment module
is available. If yes, the library is build such, that all
messages (from within the library) are printed at the correct
stderr unit. If not, then the stderr unit is set to unit=6

The configure.ac of ELPA_2013.11 is cleaned up a bit
Also, ELPA_2013.11 is copied to ELPA_2014.06 in order to have
the base for the next ELPA release

By mistake the complex kernel with blocking 2 was not called
in parallel if OpenMP was used.

Due to an error in a preprocessor statement, the results for
real matrices were wrong if the kernels "avx-real-block6" or
"avx-real-block4" were chosen. No other kernels are affected.

The test programms always correctly stated that the results for
these kernels are wrong.

Due to an error in a preprocessor statement, the results for
real matrices were wrong if the kernels "avx-real-block6" or
"avx-real-block4" were chosen. No other kernels are affected.

The test programms always correctly stated that the results for
these kernels are wrong.

Due to an error in a preprocessor statement, the results for
real matrices were wrong if the kernels "avx-real-block6" or
"avx-real-block4" were chosen. No other kernels are affected.

The test programms always correctly stated that the results for
these kernels are wrong.

The Intel Fortran compiler accepts the flag "-fopenmp" for compilation
with OpenMP. However, the Intel MPI compiler wrapper does not.
With the Intel compiler, this leads to the fact, that if ELPA is compiled
with the "-fopenmp" flag a not thread-save version of the Intel MPI
library is used and the test (with make check) fails.

Intel promised to solve this in the future.

However, for now the problem is solved in the user friendly way that no
manipulation of the MPI compiler wrappers have to be done:

For detecting the OpenMP compiler flags, instead of the predefined
macro "AC_OPENMP" of autoconf a modified macro "AX_ELPA_OPENMP"
is used, which first checks "-openmp" and only then "-fopenmp".
Thus it is ensured that the Intel compiler (and mpi compiler wrapper)
does not get confused.

This is invisible for users calling "configure" during the installation
process.

If the ELPA library is compiled with OpenMP, the tests check
whether the MPI library provides the neccessary threading
level.

There has been the error, that if the required threading level
was not available the test programs aborted, put no explicit
error code was set. This is changed now.

The Intel Fortran compiler accepts the flag "-fopenmp" for compilation
with OpenMP. However, the Intel MPI compiler wrapper does not.
With the Intel compiler, this leads to the fact, that if ELPA is compiled
with the "-fopenmp" flag a not thread-save version of the Intel MPI
library is used and the test (with make check) fails.

Intel promised to solve this in the future.

However, for now the problem is solved in the user friendly way that no
manipulation of the MPI compiler wrappers have to be done:

For detecting the OpenMP compiler flags, instead of the predefined
macro "AC_OPENMP" of autoconf a modified macro "AX_ELPA_OPENMP"
is used, which first checks "-openmp" and only then "-fopenmp".
Thus it is ensured that the Intel compiler (and mpi compiler wrapper)
does not get confused.

This is invisible for users calling "configure" during the installation
process.