GitLab

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

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.

In the test programms "MPI_ABORT" has been used incorrectly.

The blocksize should be intent(in) and not intent(inout), since
it should not be changed by solve_evlp_real_2stage

If the user chooeses parameters for the QR-decomposition which are
not allowed an error has been produced. This error is caught now,
and the library aborts with a message

It is now possible to switch on more debug messages via
the environment variable "ELPA_DEBUG_MESSAGES=yes"

Error in configure test program fixed

If the QR-decomposition is used wrongly (matrix size is not a
multiple of block size) the the execution will abort, in
order to prevent the wrong results, discussed in a previous commit

Debug messages are now available by setting the environment variable
"ELPA_DEBUG_MESSAGES" to "yes".

We found a bug in the QR-decomposition, which appears for
some matrix sizes and produces wrong results!

If the QR decomposition is switched on, an appropiate warning
is shown.

This bug is still under investigation

- cleanup of the file
- add more  (optional) timing information

The qr decomposition is now available as a runtime choice.
Some testing has still to be done

At build time it can be specified that the ELPA test
programs give more detailed timing information, which
is usefull for performace measurements

Build servers recommend against calling "abort" functions in a
library. Thus, from now on, ELPA  returns a success flag, which
is a change of ABI!

In order to force the user to honour this, the ELPA drivers
are converted to functions, which implies an adaptation and
rebuild of the user code. The driver functions return a
logical "success", which, if it is false, indicates an
error within the library.

It is advised to check catch and check this
return value in the user code, which calls ELPA.

- 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

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.

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.

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

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

Based on the ELPA 2013.08.001 a development version for ELPA OpenMP
has been created

A bug in ELPA_2013.08 was fixed: due to typo in a preprocessor statement
the kernels optimized for BLUGENE/P could not be used correctly.

In course of this action, also a bugfix versioning scheme was
introduced: in case of bugfixes they are versioned with an extra 3 digit
number in the ELPA release name, i.e ELPA 2013.08 -> 2013.08.001

Consistently any new release of ELPA will from now on start on the minor
level "000".

Due to a wrong preprocessor setting, dependig on the chosen elpa2
kernel, no kernel was called from within elpa2.F90, i. e. the
real computation actually did nothing. The complex case was not
affected.