GitLab

a preprocessor flag was missing

This closes issue #23

Remove all references to private functions and symbols from the public
Fortran modules. Install also only the public modules

In principle we don't want any stop statements in the library, but for now its
better to abort with an error than to abort successfully

Remove all references to private functions and symbols from the public
Fortran modules. Install also only the public modules

The ELPA1 gpu version changes from branch "ELPA_development_version_GPU"
have been integrated in the branch "ELPA_GPU".

However, at the moment these changes exist only as a comment (and are
deactivated), due to the following missing points:

- the flag useGPU must be passed along the ELPA1 function calls
- the GPU device arrays must be allocated as pointers (and not use
  the deprecated Cuda Fortran style)
- the calls to cublas have to be changed from the cublasFortran API
  to the cublas C API

The QR decomposition test program can now called with parameters for
matrix size, nev, and block size.
This closses issue #20

- Do not leak "ik", "rk", ..., parameters to use namespace
- Change required ELPA version on configure.ac of test_project

Both real and complex single-precision GPU versions are fixed now.
This closses issue #8

Apparently with "-check all" some versions of the Intel compiler
complain about the use of

  C_SIZEOF(a(1,1,1))

and similar, when a is not already allocated.

In case of single precision calculations the stripe_width needs to
be a multiple, which differs from the double precision by a factor of 2
since one needs 32 bytes alignment and the sizeof(float) and sizeof(double)
is different by a factor of two

This commit closes issue #18

The sub-kernels _8_ and _4_ were wrong
This also solves problems with single precision SSE Block 6 kernel,
since it also uses the Block 4 kernel

The correct type is "float complex" for single precision, not
"complex". Double precision should be "double complex"

This closes issue #17

In case of SSE/AVX/AVX2 it could happen that more than one kernel
(since some depend on other kernels, e.g. block 6 on block 4 and
block 2) were called

setting default kernels

This fixes issue #16: due to a mess in setting the default kernels,
several kernels were called at the same time, which produces wrong
results

It turned out that if a CPU supports SSE the already existing
test for SSE assembly instructions always passes.
However, the compilation of gcc SSE intrinic instructions might
nevertheless fail if gcc is not called with one of the options
"-msse3", "-msse4" , "-msse4.1", "-msse4.2", "-mavx", or "-mavx2"!

Obviously gcc does still not consider SSE as a standard on X86_64
Intel CPUs.

An additional configure test has been introduced, which test for
gcc intrinsic sse instructions. If this test fails, the corresponding
kernels are switched off.