GitLab

Similiar to commits 2998fac3 and 9710bf08 split elpa1.F90 and elpa2.F90
to make merge easier

complex cases

Create automatically two independent routines for real and complex
valued matrices

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

Also, introduce type checking for transpose and reduce_add routines

The procedure "get_elpa_row_col_comms" is now a function instead
a subroutine and returns an error code.

This should have been done previously when all the other ELPA
function have been updated to return an error code.

This requires an ABI change in the next ELPA release !

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

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.

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

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

On behalf of the Elpa Consortium and due to a remark of
Volker Blum the license model of ELPA is "corrected"

- each file now contains the appropiate header
- the files in the subdirectory "COPYING" are now
  in accordance with LGPL v. 3, the license we choose
  to use

We have taken the unusual (one-time) step to modify the structure
of the ELPA git repository as follows:

1) The current ELPA version has been designated as a "stable"
   version. It has proven to be rock solid for us so far, and
   deserves this name.

2) We have decided on a stable version naming scheme,
   "ELPA_year.month". The first such version is
   ELPA_2011.12. This version will only ever be updated
   for clear and unambiguous bug fixes.

3) All further development will happen in the directory named
   ELPA_development_version. At this time, ELPA_2011.12 is an
   exact copy of ELPA_development_version.

No substantial changes have been made to either repository as yet.
(But we are happy to say that the present "ELPA" publication, which
we hope ELPA users will cite, now has its final volume and page
numbers.)

We apologize if this change causes any inconvenience for you. Please
try to make sure that any changes you might make really affect the
development version, and not the stable version. We do not plan any
structural changes of a similar scope at any point in the future,
but it had to be done once.

Happy ELPA stable version day!

     now reflect the current status of ELPA for any future developments.