1. 11 Feb, 2016 1 commit
    • Andreas Marek's avatar
      Enable single-precision calculations for ELPA1 · de6a4fde
      Andreas Marek authored
      With the configure option "--enable-single-precision" ELPA1 is build
      with single-precision (half-words) only.
      
      The best precision in single-precision (float or complex) is
      2^-23 ~ 1.2e-7. The accuracy of the error residual of ELPA1 in
      single-precision mode is of the order 1e-4 to 1e-5. The orthogonality of
      the EV's is fullfilled up to about ~1e-6.
      
      Thus the precision of ELPA1 in single-precision mode is roughly 100 -
      1000 times less than the best achievable precison. This is consistent
      with the double-precision mode, where also a factor of 100 - 1000 less
      precision than the theoretical best one is found.
      
      The float EVs are identical to the double EVs to at least 1e-2, the
      precision of the EVs is thus about 1e-7/1e-2 = 1e5 times lower than the
      best theoretical precision. If the same holds for the double precision
      calculations, this implies that the double precision results can also
      be only trusted on the level 1e-11 (5 orders of magnitude larger
      than the best theoretical precision)
      
      The best speed-up compared to the double precision calculation is
      a factor of two. This is by far not achieved yet, since the singl
      precision version is not at all optimized at the moment
      de6a4fde
  2. 02 Feb, 2016 1 commit
    • Andreas Marek's avatar
      Remove assumed size from generic real kernel · cb4c4ae7
      Andreas Marek authored
      The generic real kernel is now contained in a module, this allows
      strict interface checking! It also does not use assumed size arrays
      anymore. Both points increase the possibility to debug and find errors.
      
      However, this might be performance critical! It is possible to
      switch back to the old implementation if that turns out to
      be beneficial w.r.t. performance. Timings with gfortran 4.9 on Intel
      Haswell showed that the new implementation is about 30 percent faster
      then the previous one
      cb4c4ae7
  3. 22 Dec, 2015 1 commit
  4. 16 Dec, 2015 1 commit
    • Andreas Marek's avatar
      Add interface to unify C and Fortran names · bb046d1c
      Andreas Marek authored
      This commit does not change the interfaces defined in ELPA_2015.11.001 !
      All functionality is available via the interface names and definitions
      as in ELPA_2015.11.001
      
      But some new interfaces have been added, in order to unfiy the
      references from C and Fortran codes:
      
      - The procedures to create the ELPA (row/column) communicators are now
        available from C _and_ Fortran with the name "get_elpa_communicators".
        The old Fortran name "get_elpa_row_col_comms" and the old C name
        "elpa_get_communicators" are from now on deprecated but still available
      
      - The 1-stage solver routines are available from C _and_ Fortran via
        the names "solve_evp_real_1stage" and "solve_evp_complex_1stage".
        The old Fortran names "solve_evp_real" and "solve_evp_complex" are
        from now on deprecated but still functional.
      
      All documentation (man pages, doxygen, and example test programs) have
      been changed accordingly.
      
      This commit implies a change in the API versioning number, but no
      changes to codes calling ELPA (if they have been already updated to the
      API of ELPA_2015.11.001)
      bb046d1c
  5. 11 Dec, 2015 1 commit
  6. 10 Dec, 2015 1 commit
    • Andreas Marek's avatar
      Create doxygen documentation for ELPA · 927f988a
      Andreas Marek authored
      The user functions of ELPA are now documented with doxygen tags.
      At the moment the interface of ELPA 2015.11.001 is decribed.
      
      The documentation has step by step to be implemented for all functions
      and test programms.
      927f988a
  7. 09 Dec, 2015 1 commit
  8. 26 Nov, 2015 1 commit
    • Andreas Marek's avatar
      ELPA_2015.11 release fix · 318ba8e2
      Andreas Marek authored
      The API versioning number was not updated correctly at the release.
      This lead to a wrong soname.
      
      This is fixed now
      318ba8e2
  9. 16 Nov, 2015 1 commit
    • Andreas Marek's avatar
      ELPA_2015.11.001 release · 16ad394d
      Andreas Marek authored
      Due to the efforts of Intel, ELPA features now build-in
      support of AVX2 and FMA for the latest Intel processors
      16ad394d
  10. 05 Nov, 2015 1 commit
  11. 04 Nov, 2015 1 commit
  12. 03 Nov, 2015 1 commit
    • Andreas Marek's avatar
      Update of c test cases · 505004e7
      Andreas Marek authored
      The examples, how to invoke ELPA from a c program have been updated.
      There are now examples for ELPA1 and ELPA2 both real and complex case.
      The test cases are still with less functionality than their Fortran
      counter parts, they are just ment as a "proof-of-concept".
      505004e7
  13. 24 Aug, 2015 1 commit
  14. 16 Jun, 2015 1 commit
  15. 26 May, 2015 1 commit
  16. 21 May, 2015 1 commit
  17. 19 May, 2015 1 commit
  18. 29 Apr, 2015 5 commits
    • Andreas Marek's avatar
      Cleanup of configure.ac · 701a7cff
      Andreas Marek authored
      Remove variables which are not needed (anymore)
      701a7cff
    • Andreas Marek's avatar
      configure.ac: move ELPA specific macros into ./m4 · 93c19c5e
      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
      93c19c5e
    • Andreas Marek's avatar
      Cleanup of configure.ac · 18c83c76
      Andreas Marek authored
      Remove variables which are not needed (anymore)
      18c83c76
    • Andreas Marek's avatar
      configure.ac: move ELPA specific macros into ./m4 · c788ec6b
      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
      c788ec6b
    • Andreas Marek's avatar
      configure.ac: treat GPU kernel as other kernels · 0a27d7c8
      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.
      0a27d7c8
  19. 28 Apr, 2015 1 commit
  20. 27 Apr, 2015 1 commit
    • Lorenz Huedepohl's avatar
      Handle different OpenMP flags for Fortran and C · ba9a188f
      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.
      ba9a188f
  21. 24 Mar, 2015 1 commit
  22. 23 Mar, 2015 2 commits
  23. 19 Mar, 2015 1 commit
  24. 18 Mar, 2015 1 commit
  25. 11 Mar, 2015 2 commits
  26. 11 Feb, 2015 1 commit
  27. 02 Feb, 2015 1 commit
    • Andreas Marek's avatar
      Release version of ELPA_2015.02 · 9aa39397
      Andreas Marek authored
      As obvious from the previous commits, this release of ELPA
      introduces a (optional) QR-decomposition for real valued
      matrices. This option can be used at run-time by either setting
      an environment variable, or by calling the ELPA-2 solver for
      real matrices with an additional flag.
      
      Thus the ABI changed, w.r.t. previous versions.
      
      Furthermore, the build process of ELPA has been made more
      consistent. All optimization flags (especially O1, O2 etc.)
      have to be set at build time by the user via the CFLAGS, FCFLAGS,
      and CXXFLAGS variables. The configure script does not set
      automatically the "O-Flags" anymore.
      9aa39397
  28. 30 Jan, 2015 1 commit
    • Lorenz Huedepohl's avatar
      Improve OpenMP detection in configure.ac · 254bd8ef
      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.
      254bd8ef
  29. 29 Jan, 2015 1 commit
  30. 28 Jan, 2015 1 commit
  31. 27 Jan, 2015 1 commit
  32. 25 Aug, 2014 2 commits
    • Andreas Marek's avatar
      ELPA 2014.06.004 Optional usage of detailed timings · ae473b44
      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
      ae473b44
    • Andreas Marek's avatar
      ELPA 2014.06.003: Allow redirect of MPI task output · 7ddffdbd
      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"
      7ddffdbd
  33. 08 Aug, 2014 1 commit