- 19 May, 2021 1 commit
-
-
Andreas Marek authored
-
- 13 May, 2021 1 commit
-
-
Andreas Marek authored
-
- 12 May, 2021 1 commit
-
-
Andreas Marek authored
It turned out that users ignored the warnings of the test programs if their MPI library did not provide "MPI_THREAD_SERIALIED" or "MPI_THREAD_MULTIPLE". Thus for safty reasons, ELPA does from now on during the call to "elpa_setup" check the provided threading level of the MPI library. If the provided level is too low, ELPA will do the following - limit the number of OpenMP threads **internal** to ELPA to 1 - print a warning about this - ignore the settings of the user via -- the OMP_NUM_THREADS variable -- calling the set-method set("omp_threads", value) These settings will **not** affect the run-time of a threaded blas and lapack library, **if** the number of threads for these libraries can be controlled independently of the OMP_NUM_THREADS variable (for example for Intel's MKL one can use MKL_NUM_THREADS)
-
- 06 May, 2021 1 commit
-
-
Andreas Marek authored
-
- 05 May, 2021 1 commit
-
-
Andreas Marek authored
-
- 04 May, 2021 1 commit
-
-
Soheil Soltani authored
expand the intervals between the levels to prevent the optimization algorithm from picking a value that bears insignificant improvement compared to one lower factor
-
- 03 May, 2021 1 commit
-
-
Soheil Soltani authored
Default is now 256. Also, the autotune levels were adjusted to more suitable values.
-
- 23 Mar, 2021 1 commit
-
-
Andreas Marek authored
-
- 11 Mar, 2021 1 commit
-
-
Andreas Marek authored
-
- 04 Mar, 2021 2 commits
-
-
Andreas Marek authored
-
Andreas Marek authored
-
- 03 Mar, 2021 1 commit
-
-
Andreas Marek authored
-
- 02 Mar, 2021 1 commit
-
-
Andreas Marek authored
-
- 26 Feb, 2021 1 commit
-
-
Andreas Marek authored
- Rename keyword "gpu" -> "nvidia-gpu" - Add keyword "amd-gpu"
-
- 24 Feb, 2021 1 commit
-
-
Andreas Marek authored
-
- 15 Feb, 2021 1 commit
-
-
Andreas Marek authored
-
- 21 Jan, 2021 1 commit
-
-
Andreas Marek authored
-
- 18 Nov, 2020 1 commit
-
-
Andreas Marek authored
-
- 17 Nov, 2020 1 commit
-
-
Andreas Marek authored
-
- 10 Aug, 2020 1 commit
-
-
Andreas Marek authored
-
- 31 Jul, 2020 2 commits
- 03 Apr, 2020 1 commit
-
-
Andreas Marek authored
-
- 24 Mar, 2020 1 commit
-
-
Andreas Marek authored
-
- 02 Mar, 2020 1 commit
-
-
Andreas Marek authored
-
- 28 Feb, 2020 1 commit
-
-
Andreas Marek authored
-
- 28 Oct, 2019 1 commit
-
-
Pavel Kus authored
This commit addresses several issues. It essentially forbids the use of the GPU kernel, which become obsolete and caused problems. But it does not complete remove the related code, nor does it forbid from explicitly selecting the GPU kernel. However, if the user does select it, the warning will be issued and the GENERIC kernel would be used instead. In the more details: * Commentin out operations in the GPU kernel, which do not compile with CUDA 10.1. This makes the kernel deffinitely not ussable (but it was true even before) * removing the gpu_tridiag_band option, sincie the tridiag->banded routine is actually not ported to GPU at all. This step will thus always be run on the CPU * removing the gpu_trans_ev_tridi_to_band option, since the GPU version of this step cannot run without the GPU kernel and it is not usable. This step will thus also be performed on the CPU * modifying REAL_GPU_KERNEL_ONLY_WHEN_GPU_IS_ACTIVE and COMPLEX_GPU_KERNEL_ONLY_WHEN_GPU_IS_ACTIVE such that the GPU kernel is not considered during the autotuning * TODO however, the GPU kernel can still be enforced by the user. In this case, during the calculation, a warning is issued and the kernel is switched to the GENERIC one. This should be improved and there should not even be the possibility to choose the GPU kernel at the begining.
-
- 14 Oct, 2019 1 commit
-
-
Wenzhe Yu authored
-
- 26 Jun, 2019 1 commit
-
-
Andreas Marek authored
-
- 25 Apr, 2019 2 commits
- 06 Feb, 2019 1 commit
-
-
Andreas Marek authored
-
- 23 Jan, 2019 2 commits
-
-
Lorenz Huedepohl authored
lfind() expects a proper comparison function where the order of the arguments does not matter. Previously it was assumed that the first argument is always a pointer to an unspecific "key" object and the second argument a pointer to an array member to compare against. However, the standard requires the two arguments to be interchangeable pointers to array-member like objects. Surfaced as musl-libc does in fact call it the other way around, compared to glibc.
-
Lorenz Huedepohl authored
-
- 11 Dec, 2018 1 commit
-
-
Pavel Kus authored
-
- 03 Dec, 2018 1 commit
-
-
Pavel Kus authored
-
- 21 Nov, 2018 1 commit
-
-
Pavel Kus authored
mpi_comm_parent is allways requred (it was not required before, but actually the code internals expected it to be supplied, at least for ELPA 2 calculation OR whenever GPU was used)
-
- 13 Nov, 2018 2 commits
-
-
Andreas Marek authored
-
Andreas Marek authored
-
- 07 Nov, 2018 1 commit
-
-
Carolin Penke authored
-