[Q-e-developers] ELPA and QE

Thu Sep 22 14:17:31 CEST 2016

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.

Index: dspev_drv.f90
===================================================================

--- dspev_drv.f90       (revision 12981)
+++ dspev_drv.f90       (working copy)
@@ -720,7 +720,7 @@
      CALL BLACS_Gridinfo(ortho_cntx,nprow, npcol, my_prow,my_pcol)

 #if defined(__ELPA_2016)
-     success = get_elpa_row_col_comms(ortho_comm, my_prow,
my_pcol,mpi_comm_rows, mpi_comm_cols)
+     ierr    = get_elpa_row_col_comms(ortho_comm, my_prow,
my_pcol,mpi_comm_rows, mpi_comm_cols)
      success = solve_evp_real_1stage(n,  n,   s, lds,    w,  vv,
lds,SIZE(s,2),nb  ,mpi_comm_rows, mpi_comm_cols)
 #elif defined(__ELPA_2015)
      ierr = get_elpa_row_col_comms(ortho_comm, my_prow,
my_pcol,mpi_comm_rows, mpi_comm_cols)
Index: zhpev_drv.f90
===================================================================
--- zhpev_drv.f90       (revision 12981)
+++ zhpev_drv.f90       (working copy)
@@ -1522,7 +1522,7 @@
 #if defined(__ELPA) || defined(__ELPA_2016) || defined(__ELPA_2015)
      CALL BLACS_Gridinfo(ortho_cntx,nprow, npcol, my_prow,my_pcol)
 #if defined(__ELPA_2016)
-     success = get_elpa_row_col_comms(ortho_comm, my_prow,
my_pcol,mpi_comm_rows, mpi_comm_cols)
+     ierr    = get_elpa_row_col_comms(ortho_comm, my_prow,
my_pcol,mpi_comm_rows, mpi_comm_cols)
      success = solve_evp_complex(n, n, h, size(h,1), w,  v, size(h,1),
size(h,2), nb, &
                            mpi_comm_rows, mpi_comm_cols)
 #elif defined(__ELPA_2015)





On 20 September 2016 at 17:42, Lorenzo Paulatto <
lorenzo.paulatto at impmc.upmc.fr> wrote:

> Hello,
> 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.
>
> On 20 September 2016 at 00:01, Filippo SPIGA <filippo.spiga at quantum-
> espresso.org> wrote:
>
>> 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-espress
>> o.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
>>
>>
>> _______________________________________________
>> Q-e-developers mailing list
>> Q-e-developers at qe-forge.org
>> http://qe-forge.org/mailman/listinfo/q-e-developers
>>
>
>
>
> --
> Dr. Lorenzo Paulatto
> IdR @ IMPMC -- CNRS & Université Paris 6
> phone: +33 (0)1 44275 084 / skype: paulatz
> www:   http://www-int.impmc.upmc.fr/~paulatto/
> mail:  23-24/4é16 Boîte courrier 115, 4 place Jussieu 75252 Paris Cédex 05
>



-- 
Dr. Lorenzo Paulatto
IdR @ IMPMC -- CNRS & Université Paris 6
phone: +33 (0)1 44275 084 / skype: paulatz
www:   http://www-int.impmc.upmc.fr/~paulatto/
mail:  23-24/4é16 Boîte courrier 115, 4 place Jussieu 75252 Paris Cédex 05
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quantum-espresso.org/pipermail/developers/attachments/20160922/95cd2b4b/attachment.html>
