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

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

For debugging purposes the test examples of the ELPA library can
now write the Eigenvectors in an ascii file, e.g
a call of "test_real 4000 1500 16 output" will envoke the test
case for real matrices of the ELPA1 library. A matrix of 4000x4000
values will be created an 1500 EV's will be computet with a 16 blocking.
And the results will be --- due to the output flag --- written to a
text file

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.

It is pointed out that setting the rpath in the linkline for
the blacs/scalapack installation is useful

The configure process in ELPA_2013.08 did not work, since
I forgot to upload some files

It is pointed out that it is mandatory to set the variables
"BLACS_LDFLAGS" and "BLACS_FCFLAGS" at build time.

Furthermore, it is clarified how to set individual optimization
flags at build time

Thanks to a comment to the Debian community, the versioning
of the ELPA library and its API are changed:

- the API version nummer starts now with 0.0.0 and not
  anymore with the version number of the first ELPA release,
  i.e. 2011.12

- if ELPA is installed as library, the files are now named
  elpa.so.API_VERSION. All references to the ELPA version
  and the used compiler vanished, since these are considered
  harmeful.

Note, that at a later stage, if neccessary, the library name might
also contain the uses MPI version.

This commit releases ELPA version 2013.08

It is identical with the latest commit version 2013.02_BETA, except:

- rename ELPA_2013.02.BETA -> ELPA_2013.08
- update of configure.ac
- remove of src/elpa2.f90_save
- remove of test/Makefile

This version has been tested extensivly, however, there might always
be some bugs.
In case of questions please contact elpa-library@rzg.mpg.de or via
the ELPA forum on http://elpa-lib.fhi-berlin.mpg.de/forum/index.php

This is the version as obtained from Peter Messmer from Nvidia.
This version is not yet consolidated or very well tested.
The build process is a little tricky.

But next commits will start cleaning up

Similiar to ELPA_2011.12 this version of ELPA now supports automake.

To the _source_ code of ELPA the following changes had to be made:

-elpa2.F90 now use the create "config-f90.h" file to choose via
 preprocessor switches which kernel was defined by the user

- the SSE-AVX intrinsic kernels of A. Heinecke had to be changed such
  that they support "internal linkage" for the building of a shared
  library.

The following other changes were made to the documentation

- elpa2_kernels/README_elpa2_kernels.txt was updated; the new configure
  targets are explained

- README, INSTALL were updated

To high propability this commit is the last one, before this beta
version	will become an official release

As in ELPA_2011.12 the files in ./test now
check for the size of the residual and orthogonality and either
return exit code 0, or 1. Needed for automake check target

For package maintaining it is more reasonable to name the tar-balls
ELPA-version-year-month-day-of-tar-ball-creation.tar, since then
comparisions work better

ELPA version 2011.12 can now be build with automake into
a shared/static library. This should help the bundling in
linux distributions

The other versions of ELPA will be updated soon

In addition to the "normal" ELPA git directories, I created
a directory tar-archives.
In this directory one should put tar-balls of the different versions
of the ELPA library.

Since the tar-balls "loose" the git history and are only a snapshot
of the respective version at the time of creation, one should name
the tar balls accordingly.

I opted now for the naming of

ELPA_VERSION_day_month_year_of_creation.tar.gz, e.g with the commit
from today (17/06/2013) I created from the ELPA_VERSION "ELPA_2011.12"
a tar ball named "ELPA_2011.12_17062013.tar.gz".

When changing the license of ELPA to LGPL, it was
forgotten to update the README files accordingly.
However, the license was and still is LGPL

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

created 2013.02 release