GitLab

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

"Merging" the NVIDIA code by hand , introduced errors.

complex cases

Create automatically two independent routines for real and complex
valued matrices

This commit is not ABI compatible

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

Also, introduce type checking for transpose and reduce_add routines

These files are always automatically generated by autooconf and should
not be in version control.

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.

1. The dimensions of an array have been wrong in cuda calls.
2. Start to get rid of "assumed-size" arrays in the real case
   They are a nightmare to debug and easily lead to a conceptional
   error as in 1.

   Furthermore, the compiler can generally optimize code better if
   "assumed-shape" arrays are used, since more information is available
   at compile time

- The compiler options for nvcc are changed
- The include paths are updated

An "dangling" fi has been removed

Remove variables which are not needed (anymore)

The macros which define the functionality to test
for
 - a specific real/complex kernel (not all available kernels)

are now defined in files in the m4 directory

Remove variables which are not needed (anymore)

The macros which define the functionality to test
for
 - GPU support only (no CPU based kernels)
 - a specific real/complex kernel (not all available kernels)

are now defined in files in the m4 directory

Configure treats the GPU kernels now as any other kernel, i. e.
if GPU support is enabled (and it is possible to build it) then
it will be build in ADDITION to all other possible kernels for
the desired hardware.

Also, it is possbile to configure the build process for
the GPU version ONLY (as it was already possible to trigger the
build for only ONE specific real/complex kernel).

Note: The sources at the moment CANNOT handle this, i.e. if
GPU support is configured, the GPU only code path is compiled.
This will be changed in the near future.

Just polishing of text
Signed-off-by: Andreas Marek <amarek@rzg.mpg.de>

There was an inconsistency when the OpenMP flag was different for the
Fortran and C compiler (e.g. -openmp for ifort and -fopenmp for gcc).

This led to strange errors when linking the example program with the C
main() routine when using Intel Fortran, Intel MPI, and GCC together, a
typical error message was

  /usr/bin/ld: MPIR_Thread: TLS definition in [...]/intel64/lib/libmpi_dbg_mt.so section .tbss mismatches non-TLS definition in [...]/intel64/lib/libmpi_dbg.so section .bss
  [...]/intel64/lib/libmpi_dbg_mt.so: could not read symbols: Bad value

The reason seems to be that the various MPI wrapper shell scripts
(mpicc, mpiifort) need the correct OpenMP option to select the
thread-safe Intel MPI debug library. Previously, always OPENMP_FCFLAGS
was appended to LDFLAGS, which did not trigger this when linking a C
main program with mpicc.