GitLab

The flag -mavx was not removed from C/CXXFLAGS again if AVX is unusable

- provide C interface for ELPA Library

- correct an error in the test case for QR-decomposition

Some compilers detected the static out-of-bounds condition present in
the test code and refused to compile it.

C interfaces are now available and definied in the header
elpa.h

Error in configure test program fixed

As obvious from the previous commits, this release of ELPA
introduces a (optional) QR-decomposition for real valued
matrices. This option can be used at run-time by either setting
an environment variable, or by calling the ELPA-2 solver for
real matrices with an additional flag.

Thus the ABI changed, w.r.t. previous versions.

Furthermore, the build process of ELPA has been made more
consistent. All optimization flags (especially O1, O2 etc.)
have to be set at build time by the user via the CFLAGS, FCFLAGS,
and CXXFLAGS variables. The configure script does not set
automatically the "O-Flags" anymore.

Some users where "clever" enough to supply a library in LDFLAGS/LIBS
thath contained omp_get_num_threads, therefore tricking configure into
thinking that we do not need any flags to enable OpenMP.

Now the Fortran test only works if "use omp_lib" and "!$" OpenMP
conditional compilation work.

Also, if no valid OpenMP flag could be detected configure silently
continued. I changed this to an explicit error.

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

If specified in the configure step, the test programs
redirect their stdout and stderr output of each MPI
task in a seperate file, which will be stored in a
subdirectory "mpi_stdout".

This will only be done if the environment variable
"REDIRECT_ELPA_TEST_OUTPUT" is set to "true"

These programs have not been updated correctly

It was decided that the version number shall be all of 2014.06.001, that
is including the release version.

Sadly, pkg-config is not too flexible with different versions of
libraries, therefore the pkg-config file will have the full version
number including the release. This might be a bit cumbersome for
dependent projects.

It was decided that the library file shall be called

  libelpa.so.*

without an explicit version string. Version information will be encoded
by using the -version-info parameter of libtool, resulting in an actual
filename as defined by your flavor of Unix.

The file LIBRARY_INTERFACE documents the changes, the current interface
has number 1 and is binary incompatible with the previous version 0.

_mt implies thread-safety, which is not what the OpenMP version does.

Additionally, only install a subset of the test-programs

libtool was too smart and mixed Intel and GNU OpenMP libraries

The Intel MPI g++ compiler wrapper otherwise links with the
non-threadsafe mpi libary instead of mpi_mt, leading to link errors.

The library will thus be called libelpa-2014.06.so

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