<div dir="ltr">By the way, when I finished managed to compile elpa 2016 (thanks to Andreas Marek for helping) I noticed that the __ELPA_2016 interface does not match a couple of calls, notably  get_elpa_row_col_comms returns an integer. Here is the patch, I'm not uploading it on SVN, in case it does not match your findings.<br><br>Index: dspev_drv.f90<br>===================================================================<br>--- dspev_drv.f90       (revision 12981)<br>+++ dspev_drv.f90       (working copy)<br>@@ -720,7 +720,7 @@<br>      CALL BLACS_Gridinfo(ortho_cntx,nprow, npcol, my_prow,my_pcol)<br> <br> #if defined(__ELPA_2016)<br>-     success = get_elpa_row_col_comms(ortho_comm, my_prow, my_pcol,mpi_comm_rows, mpi_comm_cols)<br>+     ierr    = get_elpa_row_col_comms(ortho_comm, my_prow, my_pcol,mpi_comm_rows, mpi_comm_cols)<br>      success = solve_evp_real_1stage(n,  n,   s, lds,    w,  vv, lds,SIZE(s,2),nb  ,mpi_comm_rows, mpi_comm_cols)<br> #elif defined(__ELPA_2015)<br>      ierr = get_elpa_row_col_comms(ortho_comm, my_prow, my_pcol,mpi_comm_rows, mpi_comm_cols)<br>Index: zhpev_drv.f90<br>===================================================================<br>--- zhpev_drv.f90       (revision 12981)<br>+++ zhpev_drv.f90       (working copy)<br>@@ -1522,7 +1522,7 @@<br> #if defined(__ELPA) || defined(__ELPA_2016) || defined(__ELPA_2015)<br>      CALL BLACS_Gridinfo(ortho_cntx,nprow, npcol, my_prow,my_pcol)<br> #if defined(__ELPA_2016)<br>-     success = get_elpa_row_col_comms(ortho_comm, my_prow, my_pcol,mpi_comm_rows, mpi_comm_cols)<br>+     ierr    = get_elpa_row_col_comms(ortho_comm, my_prow, my_pcol,mpi_comm_rows, mpi_comm_cols)<br>      success = solve_evp_complex(n, n, h, size(h,1), w,  v, size(h,1), size(h,2), nb, &<br>                            mpi_comm_rows, mpi_comm_cols)<br> #elif defined(__ELPA_2015)<br><br><br><br><br></div><div class="gmail_extra"><br><div class="gmail_quote">On 20 September 2016 at 17:42, Lorenzo Paulatto <span dir="ltr"><<a href="mailto:lorenzo.paulatto@impmc.upmc.fr" target="_blank">lorenzo.paulatto@impmc.upmc.fr</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>Hello,<br></div>I've just spent several hours trying to compile elpa 2016 on BlueGENE (and I did not manage...). I'm pretty skeptical about the ability of the average user to compile it at all on anything else than intel compiler/mpi/mkl, but this is a common problem, hence I'm not against the change in principle.<br></div><div class="gmail_extra"><div><div class="h5"><br><div class="gmail_quote">On 20 September 2016 at 00:01, Filippo SPIGA <span dir="ltr"><<a href="mailto:filippo.spiga@quantum-espresso.org" target="_blank">filippo.spiga@quantum-<wbr>espresso.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear everyone,<br>
<br>
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.<br>
<br>
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).<br>
<br>
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:<br>
- deprecate generic "--with-elpa"<br>
- add "--with-elpa-lib=<path>" which point to the directory of the ELPA library<br>
- add "--with-elpa-include=<path>" which point to the directory of the ELPA Fortran module<br>
<br>
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 <a href="http://make.in" rel="noreferrer" target="_blank">make.in</a> ("__ELPA_2016" will continue to exhist in the code).<br>
<br>
I am planning to commit changes around Wed or Thu unless there are particular objections.<br>
<br>
Cheers<br>
<div><div><br>
<br>
On Sep 11, 2016, at 2:37 PM, Filippo SPIGA <<a href="mailto:filippo.spiga@quantum-espresso.org" target="_blank">filippo.spiga@quantum-espress<wbr>o.org</a>> wrote:<br>
> Dear all,<br>
><br>
> 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).<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> Stay tuned<br>
><br>
> Cheers<br>
<br>
--<br>
Filippo SPIGA ~ Quantum ESPRESSO Foundation ~ <a href="http://www.quantum-espresso.org" rel="noreferrer" target="_blank">http://www.quantum-espresso.or<wbr>g</a><br>
<br>
<br>
______________________________<wbr>_________________<br>
Q-e-developers mailing list<br>
<a href="mailto:Q-e-developers@qe-forge.org" target="_blank">Q-e-developers@qe-forge.org</a><br>
<a href="http://qe-forge.org/mailman/listinfo/q-e-developers" rel="noreferrer" target="_blank">http://qe-forge.org/mailman/li<wbr>stinfo/q-e-developers</a><br>
</div></div></blockquote></div><br><br clear="all"><br></div></div><span class="HOEnZb"><font color="#888888">-- <br><div data-smartmail="gmail_signature"><div>Dr. Lorenzo Paulatto </div><div>IdR @ IMPMC -- CNRS & Université Paris 6</div><div>phone: +33 (0)1 44275 084 / skype: paulatz</div><div>www:   <a href="http://www-int.impmc.upmc.fr/~paulatto/" target="_blank">http://www-int.impmc.upmc.fr/~<wbr>paulatto/</a></div><div>mail:  23-24/4é16 Boîte courrier 115, 4 place Jussieu 75252 Paris Cédex 05</div></div>
</font></span></div>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div>Dr. Lorenzo Paulatto </div><div>IdR @ IMPMC -- CNRS & Université Paris 6</div><div>phone: +33 (0)1 44275 084 / skype: paulatz</div><div>www:   <a href="http://www-int.impmc.upmc.fr/~paulatto/" target="_blank">http://www-int.impmc.upmc.fr/~paulatto/</a></div><div>mail:  23-24/4é16 Boîte courrier 115, 4 place Jussieu 75252 Paris Cédex 05</div></div>
</div>