- 22 Dec, 2015 2 commits
-
-
Andreas Marek authored
Similiar to commits 2998fac3 and 9710bf08 split elpa1.F90 and elpa2.F90 to make merge easier
-
Andreas Marek authored
-
- 17 Jun, 2015 2 commits
-
-
Andreas Marek authored
"Merging" the NVIDIA code by hand , introduced errors.
-
Andreas Marek authored
-
- 16 Jun, 2015 4 commits
-
-
Andreas Marek authored
-
Andreas Marek authored
complex cases Create automatically two independent routines for real and complex valued matrices
-
Andreas Marek authored
This commit is not ABI compatible
-
Andreas Marek authored
This commit is not ABI compatible, since it changes the interfaces of some routines Also, introduce type checking for transpose and reduce_add routines
-
- 02 Jun, 2015 1 commit
-
-
Andreas Marek authored
-
- 01 Jun, 2015 3 commits
-
-
Andreas Marek authored
-
Andreas Marek authored
-
Andreas Marek authored
-
- 28 May, 2015 3 commits
-
-
Lorenz Huedepohl authored
These files are always automatically generated by autooconf and should not be in version control.
-
Lorenz Huedepohl authored
-
Lorenz Huedepohl authored
-
- 26 May, 2015 5 commits
-
-
Andreas Marek authored
-
Andreas Marek authored
-
Andreas Marek authored
-
Andreas Marek authored
-
Andreas Marek authored
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.
-
- 21 May, 2015 4 commits
-
-
Andreas Marek authored
-
Andreas Marek authored
-
Andreas Marek authored
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
-
Andreas Marek authored
- The compiler options for nvcc are changed - The include paths are updated
-
- 19 May, 2015 3 commits
-
-
Andreas Marek authored
-
Andreas Marek authored
An "dangling" fi has been removed
-
Andreas Marek authored
-
- 29 Apr, 2015 5 commits
-
-
Andreas Marek authored
Remove variables which are not needed (anymore)
-
Andreas Marek authored
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
-
Andreas Marek authored
Remove variables which are not needed (anymore)
-
Andreas Marek authored
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
-
Andreas Marek authored
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.
-
- 28 Apr, 2015 7 commits
-
-
Andreas Marek authored
-
Andreas Marek authored
-
Andreas Marek authored
-
Andreas Marek authored
-
Andreas Marek authored
-
Andreas Marek authored
-
Andreas Marek authored
Just polishing of text Signed-off-by:
Andreas Marek <amarek@rzg.mpg.de>
-
- 27 Apr, 2015 1 commit
-
-
Lorenz Huedepohl authored
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.
-