[Q-e-developers] ELPA and QE

[Filippo SPIGA]

Dear everyone,

I did several tests in the past days to verify results match between SCALAPACK, ELPA 2015, ELPA 2016 and the "custom diagonalization". I generated a lot of outputs, I did not compare every single one of them but all of those I have been inspected are all good and consistent.

Because the current ELPA library structure, self-detect the ELPA version using autoconf is quite complex and I cannot guardantee it works every time on every machine. Things need to be simplified a bit on QE side (and as consequence rely more on the ability of the user to compile a library for his/her own environment).

Instead of support both "2015" API and "2016" API, I suggest to support via configure only the 2016 version. I propose the following changes in the configure:
- deprecate generic "--with-elpa"
- add "--with-elpa-lib=<path>" which point to the directory of the ELPA library 
- add "--with-elpa-include=<path>" which point to the directory of the ELPA Fortran module 

ELPA is enabled ("__ELPA_2016" in DFLAGS) iff both  "--with-elpa-lib=<path>" (".so" or ".a" library present in <path>) and "--with-elpa-include=<path>" ("elpa1.mod" present in <path>) are specified. If someone wants to use the "2015" API then it is always possible to edit manually make.in ("__ELPA_2016" will continue to exhist in the code).

I am planning to commit changes around Wed or Thu unless there are particular objections.

Cheers


On Sep 11, 2016, at 2:37 PM, Filippo SPIGA <filippo.spiga at quantum-espresso.org> wrote:
> Dear all,
> 
> ELPA (Eigenvalue SoLvers for Petaflop-Applications) is a parallel eigen-solver library working with QE and provided natively via a self-hosted package under "archive/". This package contains a old version of ELPA. The latest official ELPA release available on the web adopts different routine API (small changes but enought to require a change in the code).
> 
> After some changes in the code, we now support two versions: ELPA 2015.11.001 (__ELPA_2015) and ELPA 2016.05.003 (__ELPA_2016). Again, these two versions have different routine API and these discrepancies force us to maintain two API in the code. It is ugly but it is nothing we can do about.
> 
> The old ELPA in the code will be deprecated by v6.0 is going to be released. I am working on a configure step that transparently detects ELPA 2015 versus ELPA 2016. If I fails, I will work around a mechanism that allows to pass to the configure both the location of the shared library and the location of the Fortran modules associated with it.
> 
> Stay tuned
> 
> Cheers

--
Filippo SPIGA ~ Quantum ESPRESSO Foundation ~ http://www.quantum-espresso.org