GitLab

Now all functions, which were "contained" in anoter one are moved
to seperate modules. This allows for strict interface checking and
debugging

This routine has been contained in a subroutine.
It has been moved to a module and and renamed to
"single_hh_trafo_real" to make it's intention more clear

All variables (real, integer, complex) are now declecared with the
appropiate kind statement. The definition of the kind types is done
in src/mod_precision.f90

To ensure interoperability with C, the kind types are decleared via
iso_c_binding to C variables

In some C test programs the function declaration header files
have been missing

The Fortran variable declerations "variable type*[4,8,16]" is non
Fortran standard. It might cause problem in the future.
Furthermore, the usage of Fortran and C togehther is more clean
if variables are defined according to C variable types.

This is done, now for all the test programs

fdep per subtree, fixed wrong argument order



See merge request !1

git-subtree-dir: fdep
git-subtree-mainline: 38fe3a85
git-subtree-split: f81bd5c8

Previously, the list of modules used or defined by a source file was
assumed to be the same regardless for which target the file was used
(except for library/non-library compilation). Now, every target has its
own list of defined and required modules per source file

Will be added in the subsequent commit as a 'subtree' from upstream

This commit does not change the interfaces defined in ELPA_2015.11.001 !
All functionality is available via the interface names and definitions
as in ELPA_2015.11.001

But some new interfaces have been added, in order to unfiy the
references from C and Fortran codes:

- The procedures to create the ELPA (row/column) communicators are now
  available from C _and_ Fortran with the name "get_elpa_communicators".
  The old Fortran name "get_elpa_row_col_comms" and the old C name
  "elpa_get_communicators" are from now on deprecated but still available

- The 1-stage solver routines are available from C _and_ Fortran via
  the names "solve_evp_real_1stage" and "solve_evp_complex_1stage".
  The old Fortran names "solve_evp_real" and "solve_evp_complex" are
  from now on deprecated but still functional.

All documentation (man pages, doxygen, and example test programs) have
been changed accordingly.

This commit implies a change in the API versioning number, but no
changes to codes calling ELPA (if they have been already updated to the
API of ELPA_2015.11.001)

For the library functions which are accessible by the user
man pages decribing the Fortran and C interface exist:

-get_elpa_row_comms
-solve_evp_real , solve_evp_complex
-solve_evp_real_2stage, solve_evp_complex_2stage

For the "service binary" print_available_elpa2_kernels,
also a man page exists.

TODO: extend man pages to test-binaries, or do not install test-binaries

- the contact email is now: elpa-library@mpcdf.mpg.de
- the official website is now hosted at http://elpa.mpcdf.mpg.de

I forgot to update this file in time

The Rechenzentrum Garching (RZG) has been renamed into
the Max Planck Computing and Data Facility (MPCDF).

This is reflected now in the adapted headers.

In the near future, all references to the ELPA webside and
the ELPA email will also be adapted.

The user functions of ELPA are now documented with doxygen tags.
At the moment the interface of ELPA 2015.11.001 is decribed.

The documentation has step by step to be implemented for all functions
and test programms.

As in a previous commit for elpa1.F90, for automatic generation of
documentation elpa2.F90 has been splitted in two files, in order to
have a lean, easy-to-understand user interface:

elpa2.F90
the visible user functions, which provide the library calls.
The usage is the same as before

elpa2_compute.F90
all internal routines, which are used by ELPA2, but which are never
called external of the library by a user. These functions are now
"hidden" in the module elpa2_compute, which is used by ELPA2.

The procedures in elpa2_compute.F90 are identical to the ones in
elpa2.F90 before this split commit. The only -- but quite a lot of them
-- changes are intendation changes.

For automatic generation of documentation, the file elpa1.F90
has been splitted into two files, in order to have a lean,
easy-to-understand user interface:

elpa1.F90
the visible user functios, which provide the library calls.
The usage is the same as always

elpa1_compute.F90
all internal routines, which are used by ELPA1 and ELPA2, but
which are never called by the user. These functions are now "hidden"
in the module elpa1_compute, which is used by ELPA1 and ELPA2.

The procedures in elpa1_compute.F90 are identical to the ones in
elpa1.F90 before this split commit. The only -- but lot of --
changes are intendation.

This variables, do not have to be global, they can be parsed along
internally in ELPA. Removing them makes debugging more easy and
the public interface more lean

Current fix does as much blocking as possible, which should be
beneficial from both a compute and communication point of view.

Additionally, a second possible fix was added which just calls
the blocked version if the local matrix has a sufficient size.
This might create smaller and more messages at scale.

For some matrix/block size combinations the real case of ELPA2
crashes, e.g:

mpiexec -n 1 ./elpa2_test_real 50 50 32

leads to an error message
 ** On entry to DGEMM parameter number  3 had an illegal value
 and a crash.

This only seems to happen with matrix size smaller than 64*64.
he code path responsible for this has been identified, but the problem
tself is not yet solved!

The part of the code, which causes these crashes, has been switched on
as default by Intel in commit fe63372d. The rest of the commit fe63372d
seems to be fine, and is performance critical.

As an intermediate step, the responsible code path is switched off again
as default, this will be changed again once the underlying root cause
has been solved.

The API versioning number was not updated correctly at the release.
This lead to a wrong soname.

This is fixed now

Due to the efforts of Intel, ELPA features now build-in
support of AVX2 and FMA for the latest Intel processors

Point more clearly to the usage of ELPA under the terms of the LGPL.

Point more clearly to the usage of ELPA under the terms of the LGPL.

Intel (thanks, especially A.Heinecke from Intel) there exists an
optimized version of ELPA with AVX2 support.

This merge includes all the optimizations done by Intel plus some
smaller changes which were necessary to incorperate these modifications.

A build without autotools is not officially supported anymore.
Thus this --- broken since long time --- Makefile.example is removed