- 03 Aug, 2016 1 commit
-
-
Andreas Marek authored
-
- 02 Aug, 2016 1 commit
-
-
Andreas Marek authored
-
- 11 Jul, 2016 3 commits
-
-
Lorenz Huedepohl authored
Intel had the bright idea to name their OpenMP command line flag -openmp which of course cannot be distinguished from -o penmp It seems they also realized this and now also allow -fopenmp or -qopenmp as flags. Due to commit 2121b2e5 the autodetected -openmp was now appended into the linker command line at the end, causing all C programs to be named "penmp". Fix by trying the -fopenmp, -qopenmp flags before -openmp in the Fortran compiler flag detection m4 macro.
-
Lorenz Huedepohl authored
-
Lorenz Huedepohl authored
Rewrote the perl-script for the dependency generation to also accept input file names from stdin, in order to avoid excessively large argument lists.
-
- 08 Jul, 2016 5 commits
-
-
Lorenz Huedepohl authored
-
Lorenz Huedepohl authored
The actual reason for the linker problems was that the Fortran libraries where listed before the object files, by modifying the _LINK automake variables. The proper way to do is of course to add the necessary libraries after the object files by appending them to the _LDADD variables. As the MPI module was not responsible for the linker problems it is now used by default, unless explicitly switched off with --disable-mpi-module Also, the C test programs that had these linker errors where previously not compiled in the OpenMP case, for no obvious reason. Now they are also included there.
-
Andreas Marek authored
-
Lorenz Huedepohl authored
For some strange reason this causes linker errors on _some_ openSUSE_Tumbleweed installations..
-
- 07 Jul, 2016 3 commits
-
-
Lorenz Huedepohl authored
Apparently in some compiler/MPI combinations (gcc with impi 5.1.3) the identifier 'mpi_status' is defined and exporeted in their MPI fortran module and it is thus not allowed to name one of your local variables also 'mpi_status'. The confusing error message I got was ../src/elpa2_compute.F90:5780:37: call mpi_wait(ireq_hv,mpi_status,mpierr) 1 Error: Invalid procedure argument at (1) even though everything seemed to be defined correctly
-
Lorenz Huedepohl authored
-
Lorenz Huedepohl authored
-
- 04 Jul, 2016 5 commits
-
-
Andreas Marek authored
-
Andreas Marek authored
-
Andreas Marek authored
-
Andreas Marek authored
-
Andreas Marek authored
-
- 02 Jul, 2016 9 commits
-
-
Andreas Marek authored
-
Andreas Marek authored
-
Andreas Marek authored
-
Andreas Marek authored
-
Andreas Marek authored
-
Andreas Marek authored
-
Andreas Marek authored
-
Andreas Marek authored
-
Andreas Marek authored
-
- 01 Jul, 2016 1 commit
-
-
Andreas Marek authored
-
- 30 Jun, 2016 1 commit
-
-
Andreas Marek authored
-
- 29 Jun, 2016 1 commit
-
-
Andreas Marek authored
-
- 20 Jun, 2016 2 commits
-
-
Andreas Marek authored
-
Andreas Marek authored
Some people had problems finding the ELPA email address, thus is is clearly specified here
-
- 16 Jun, 2016 3 commits
-
-
Andreas Marek authored
-
Andreas Marek authored
-
Andreas Marek authored
-
- 14 Jun, 2016 2 commits
-
-
Andreas Marek authored
The subroutine solve_tridi has NOT been shifted from the private module "elpa1_compute" to the public module elpa1_auxilliary. Instead, a wrapper function solve_tride has been introduced, which calls (via Fortran module association) the private function. This does what it is supposed to do, but should be cleaned up at some time. Public functions (interfaces) should be implemented in a public module
-
Andreas Marek authored
-
- 10 Jun, 2016 2 commits
-
-
Andreas Marek authored
-
Andreas Marek authored
These functions were made private with ELPA releases 2016.05.001 and 2016.05.002, but they should be public
-
- 30 May, 2016 1 commit
-
-
Andreas Marek authored
-