- 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.

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.

It is more user friendly if the configure steps aborts in
the case that the user did not define which ELPA kernel to use

It is more user friendly if the configure steps aborts in the case
that the user did not define which ELPA kernel to use

A few kernels could not be used together with OpenMP:
an interface error prohibited the compilation.

Removed a forgotten C-preprocessor error flag.
Futhermore, describe in the documentation why at the moment a
build of Bluegene P/Q kernels and OpenMP is not allowed.

Removed a forgotten C-preprocessor error flag.
Futhermore, describe in the documentation why at the moment a
build of Bluegene P/Q kernels and OpenMP is not allowed.

Automake does normally not understand the dependencies of Fortran 90
modules, thus a parallel build will almost certainly fail.

As in ELPA 2011.12.002, the ELPA_development_version_qr  now
includes scripts from the fdep project (see git.schokokeks.org/fdep)
which cirumvents this problem.

Thanks to Lorenz Huedepohl, now a parallel build works.

Automake does normally not understand the dependencies of Fortran 90
modules, thus a parallel build will almost certainly fail.

As in ELPA 2011.12.002, ELPA 2013.08.004  now includes scripts from
the fdep project (see git.schokokeks.org/fdep) which cirumvents this
problem.

Thanks to Lorenz Huedepohl, now a parallel build works.

Automake does normally not understand the dependencies of Fortran 90
modules, thus a parallel build will almost certainly fail.

ELPA 2011.12.002 now includes scripts from the fdep project
(see git.schokokeks.org/fdep) which cirumvents this problem.

Thanks to Lorenz Huedepohl, now a parallel build works.

Identical to ELPA 2013.11.001 the build procedure is updated

  - updated INSTALL documentation
  - improved description of kernels src/elpa2_kernels/README_elpa2_kernels.txt
  - improved OpenMP builds:
      * usage of OpenMP can now be specified with
        "--enable-openmp" or "--with-openmp"
  - improved checks for AVX build (identical to ELPA 2013.08.003):
     * if AVX kernels are specified AVX compilation is tested
     * the option "--with-avx-optimization" automatically updates
       CFLAGS and CXXFLAGS with optimization flags

The Fortran standard requires a maximum line length of 132 characters.
Linefeeds are introduced where necessary

- updated INSTALL documentation
- improved description of kernels src/elpa2_kernels/README_elpa2_kernels.txt
- improved OpenMP builds:
   * usage of OpenMP can now be specified with
     "--enable-openmp" or "--with-openmp"
- improved checks for AVX build (identical to ELPA 2013.08.003):
   * if AVX kernels are specified AVX compilation is tested
   * the option "--with-avx-optimization" automatically updates
     CFLAGS and CXXFLAGS with optimization flags

 - The INSTALL documentation was updated a bit
 - the documentation of the ELPA kernels was improved
 - the configure script was improved:

   if usage of an AVX kernel is specified, at configure time
   it is checked whether such a kernel can be build
   If not, it is checked whether the kernel can be build if the
   option "-mavx" is added to the CFLAGS and CXXFLAGS. If this is
   still not possible an error is thrown.

   if the option "--with-avx-optimization" than the CFLAGS and CXXFLAGS
   are automatically updated with some necessary flags (which are
   described in the kernel documentation file)

Now, the branch ELPA_development_version_qr contains the full QR
functionality, which was introduced by Auckenthaler in the (obsolete)
ELPA_development_version_branch

Changes are:
- build procedure with configure like the other branches/releases
- renaming of a few files

The QR decomposition was tested for a few matrices and gave correct
results

- the files in the sub-dir src/elpa_qr from the ELPA_development_branch
  are introduced in the branch ELPA_development_version_qr

- the file tum_utils.f90 is renamed to qr_utils.f90

This is the release of the ELPA_development_version_OpenMP
If OpenMP support is not used, this version has the same
functionality as ELPA_2013.08.

If OpenMP support is used, obviously, a hybrid version of ELPA will be
build.

Allthough this is a release, version ELPA_2013.11 is far from complete!
During the next week optimizations of the OpenMP part will be published,
however, the basic functionality is set by this commit

If ELPA is compiled with OpenMP the MPI_INIT_THREAD with
level THREAD_MULIPLE must be called. This is changed in the test
programs

- install (if build) test binaries in installdir/bin
- finish the test examples with a clean blacs_grid_exit

ELPA 2013.08.002

- install (if build) test binaries in installdir/bin
- finish the test examples with a clean blacs_grid_exit

ELPA_development_version_OPENMP
- install (if build) test binaries in installdir/bin
- rename files from *.f90 to *.F90 (later needed)

A developement version for MRRR algorithm is created;
Based on ELPA_development_version_OpenMP

ELPA_development_version_branch

Since the new, tested branch ELPA_development_version_OpenMP is
now in place, the still buggy OpenMP functionality from the branch
ELPA_development_version is removed.

The branch ELPA_development_version now only contains the untested
support of the MRRR algorithm

The test examples are a little bit more verbose if OpenMP is
used

This commit introduces OpenMP functionality in the
ELPA_development_version_OpenMP branch.

It contains several bugfixes to the OpenMP functionality in the
branch "ELPA_development_version", the later will soon be deleted
since the new branch is the new reference implementation.

The current branch contains the following features/bugfixes:
- building of the OpenMP version of ELPA via configure and the
  "--with-openmp" flag. The build library contains a "_mt"
  (multi-threaded) in its name.
  The configure procedure should (hopefully) determine for each
  compiler the neccessary OpenMP flags.
  If the "--with-openmp" flag is ommitted exactly the same code
  as in the ELPA 2013.08.001 release is used and build in the
  same way
- The example test cases print which kernels have been used and
  how many OpenMP threads are used at runtime
- correct handling of OpenMP stack arrays: the previous implementation
  caused compiler dependent segmentation faults
- OpenMP capability with all available kernels: the correctness of
  the computations have been checked for all kernels except the
  Bluegene (P/Q) versions