- 30 Jan, 2015 1 commit
-
-
Lorenz Huedepohl authored
Some users where "clever" enough to supply a library in LDFLAGS/LIBS thath contained omp_get_num_threads, therefore tricking configure into thinking that we do not need any flags to enable OpenMP. Now the Fortran test only works if "use omp_lib" and "!$" OpenMP conditional compilation work. Also, if no valid OpenMP flag could be detected configure silently continued. I changed this to an explicit error.
-
- 27 Jan, 2015 1 commit
-
-
Lorenz Huedepohl authored
-
- 25 Aug, 2014 2 commits
-
-
Andreas Marek authored
At build time it can be specified that the ELPA test programs give more detailed timing information, which is usefull for performace measurements
-
Andreas Marek authored
If specified in the configure step, the test programs redirect their stdout and stderr output of each MPI task in a seperate file, which will be stored in a subdirectory "mpi_stdout". This will only be done if the environment variable "REDIRECT_ELPA_TEST_OUTPUT" is set to "true"
-
- 08 Aug, 2014 1 commit
-
-
Andreas Marek authored
These programs have not been updated correctly
-
- 02 Jul, 2014 2 commits
-
-
Lorenz Huedepohl authored
It was decided that the version number shall be all of 2014.06.001, that is including the release version. Sadly, pkg-config is not too flexible with different versions of libraries, therefore the pkg-config file will have the full version number including the release. This might be a bit cumbersome for dependent projects.
-
Lorenz Huedepohl authored
It was decided that the library file shall be called libelpa.so.* without an explicit version string. Version information will be encoded by using the -version-info parameter of libtool, resulting in an actual filename as defined by your flavor of Unix. The file LIBRARY_INTERFACE documents the changes, the current interface has number 1 and is binary incompatible with the previous version 0.
-
- 01 Jul, 2014 3 commits
-
-
Lorenz Huedepohl authored
-
Lorenz Huedepohl authored
_mt implies thread-safety, which is not what the OpenMP version does. Additionally, only install a subset of the test-programs
-
Lorenz Huedepohl authored
-
- 27 Jun, 2014 2 commits
-
-
Lorenz Huedepohl authored
-
Lorenz Huedepohl authored
-
- 25 Jun, 2014 2 commits
-
-
Lorenz Huedepohl authored
-
Lorenz Huedepohl authored
-
- 16 Jun, 2014 1 commit
-
-
Lorenz Huedepohl authored
libtool was too smart and mixed Intel and GNU OpenMP libraries
-
- 13 Jun, 2014 1 commit
-
-
Lorenz Huedepohl authored
The Intel MPI g++ compiler wrapper otherwise links with the non-threadsafe mpi libary instead of mpi_mt, leading to link errors.
-
- 12 Jun, 2014 1 commit
-
-
Lorenz Huedepohl authored
-
- 11 Jun, 2014 1 commit
-
-
Lorenz Huedepohl authored
The library will thus be called libelpa-2014.06.so
-
- 10 Jun, 2014 1 commit
-
-
Lorenz Huedepohl authored
This includes a number of changes: - ScaLAPACK2 on from the openSUSE:science repository is now correctly auto-detected. As ScaLAPACK2 already includes BLACS, an additional BLACS library must not be linked! - The resulting library is now called elpa-2014.06.000.so, as was probably originally intended anyway - The pkg-config file was renamed to elpa-2014.06.000.pc and filled with correct values. With this, a package using ELPA can easily get the necessary compilation and library flags. In this commit, only the "precious" files (Makefile.am, configure.ac, etc.) are included, to make clear what has been changed by hand. In the subsequent commit also all autoconf generated files will follow.
-
- 08 Jun, 2014 1 commit
-
-
Lorenz Huedepohl authored
Without this, automake tries to be smart and rebuilt the autoconf generated files such as configure, aclocal.m4, etc., in case the timestamps of files such as configure.ac are newer. This only makes trouble for end users with out-of-date autoconf versions that cannot produce these files.
-
- 06 Jun, 2014 1 commit
-
-
Andreas Marek authored
-
- 05 Jun, 2014 2 commits
-
-
Andreas Marek authored
-
Andreas Marek authored
-
- 28 May, 2014 3 commits
-
-
Andreas Marek authored
If one species a kernel with the "--with-kernel-name" option, this means that only this (real/complex) is configured and installed. All other available real/complex kernels are not considered. Thus the help messages (see ./configure --help) is changed such that the option is called "--with-only-kernel-name"
-
Andreas Marek authored
-
Andreas Marek authored
- the library version number is changed due to change in ABI - the INSTALL ascii file is updated - a RELEASE_NOTES file is introduced
-
- 27 May, 2014 3 commits
-
-
Lorenz Huedepohl authored
-
Lorenz Huedepohl authored
This includes fixes necessary to please gfortran as well as a slight change in the way the various libraries are tested in configure.ac
-
Andreas Marek authored
- the library version number is changed due to change in ABI - the INSTALL ascii file is updated - a RELEASE_NOTES file is introduced
-
- 26 May, 2014 3 commits
-
-
Andreas Marek authored
Now it is possible - to choose the kernel (real and complex independently) at run-time via environment variables, or - to specify the kernel (real and complex independently) at runtime via specifing the kernel in the call to ELPA This has a few implications 1) The ELPA 2014.06 release has a change in the API and is thus not binary compatible with previous versions 2) if no kernels are specified, a default kernel is choosen 3) if a wrong kernel is specified, a default kernel is choosen For sake of simplicity it is still possible to build ELPA with support for only one kernel, as in previous versions. However, it is still not binary compatible to previous versions
-
Andreas Marek authored
Configure checks whether the Fortran environment module is available. If yes, the library is build such, that all messages (from within the library) are printed at the correct stderr unit. If not, then the stderr unit is set to unit=6
-
Andreas Marek authored
The configure.ac of ELPA_2013.11 is cleaned up a bit Also, ELPA_2013.11 is copied to ELPA_2014.06 in order to have the base for the next ELPA release
-
- 21 Mar, 2014 1 commit
-
-
Andreas Marek authored
-
- 03 Mar, 2014 1 commit
-
-
Andreas Marek authored
By mistake the complex kernel with blocking 2 was not called in parallel if OpenMP was used.
-
- 27 Feb, 2014 1 commit
-
-
Andreas Marek authored
Due to an error in a preprocessor statement, the results for real matrices were wrong if the kernels "avx-real-block6" or "avx-real-block4" were chosen. No other kernels are affected. The test programms always correctly stated that the results for these kernels are wrong.
-
- 26 Feb, 2014 1 commit
-
-
Andreas Marek authored
The Intel Fortran compiler accepts the flag "-fopenmp" for compilation with OpenMP. However, the Intel MPI compiler wrapper does not. With the Intel compiler, this leads to the fact, that if ELPA is compiled with the "-fopenmp" flag a not thread-save version of the Intel MPI library is used and the test (with make check) fails. Intel promised to solve this in the future. However, for now the problem is solved in the user friendly way that no manipulation of the MPI compiler wrappers have to be done: For detecting the OpenMP compiler flags, instead of the predefined macro "AC_OPENMP" of autoconf a modified macro "AX_ELPA_OPENMP" is used, which first checks "-openmp" and only then "-fopenmp". Thus it is ensured that the Intel compiler (and mpi compiler wrapper) does not get confused. This is invisible for users calling "configure" during the installation process.
-
- 24 Feb, 2014 1 commit
-
-
Andreas Marek authored
It is more user friendly if the configure steps aborts in the case that the user did not define which ELPA kernel to use
-
- 18 Dec, 2013 1 commit
-
-
Andreas Marek authored
A few kernels could not be used together with OpenMP: an interface error prohibited the compilation.
-
- 10 Dec, 2013 2 commits
-
-
Andreas Marek authored
Removed a forgotten C-preprocessor error flag. Futhermore, describe in the documentation why at the moment a build of Bluegene P/Q kernels and OpenMP is not allowed.
-
Andreas Marek authored
Automake does normally not understand the dependencies of Fortran 90 modules, thus a parallel build will almost certainly fail. As in ELPA 2011.12.002, the ELPA_development_version_qr now includes scripts from the fdep project (see git.schokokeks.org/fdep) which cirumvents this problem. Thanks to Lorenz Huedepohl, now a parallel build works.
-