[Q-e-developers] ELPA and QE
nicola varini
nicola.varini at epfl.ch
Thu Sep 22 15:20:34 CEST 2016
Hi Lorenzo, I had a little problem with the 2016 version as well with
intel compiler.
/If you compile the following snippet/
program prova
use elpa1
end program prova
/the compiler complains with:/
[nvarini at deneb2 elpa-2016.05.003]$ mpiifort
-I$PWD/include/elpa-2016.05.003/modules prova.f90 -L$PWD/lib
prova.f90(2): error #7002: Error in opening the compiled module file.
Check INCLUDE paths. [PRECISION]
use elpa1
------^
compilation aborted for prova.f90 (code 1)
With the 2016 version there is a new directory called private_modules,
which contain precision.mod:
[nvarini at deneb2 elpa-2016.05.003]$ ls private_modules/precision.mod
private_modules/precision.mod
This bug of the installation procedure should be fixed in the next
release. The workaround is to copy manually
private_modules/precision.mod inside the include/elpa-2016.05.003/modules
Also, if you find a bug by using mkl scalapack during the
diagonalization with the error:
Fatal error in PMPI_Cart_sub: Other MPI error, error stack:
PMPI_Cart_sub(242)...................: MPI_Cart_sub(comm=0xc400fced,
remain_dims=0x7ffe8e4e1f68, comm_new=0x7ffe8e4e1ec0) failed
PMPI_Cart_sub(178)...................:
MPIR_Comm_split_impl(270)............:
MPIR_Get_contextid_sparse_group(1330): Too many communicators (5/16384
free on this process; ignore_id=0)
Fatal error in PMPI_Cart_sub: Other MPI error, error stack:
It is likely to fix this by using elpa.
Nic
On 09/22/2016 02:17 PM, Lorenzo Paulatto wrote:
> 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
> <mailto: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
> <mailto: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
> <http://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
> <mailto: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 <http://www.quantum-espresso.org>
>
>
> _______________________________________________
> Q-e-developers mailing list
> Q-e-developers at qe-forge.org <mailto:Q-e-developers at qe-forge.org>
> http://qe-forge.org/mailman/listinfo/q-e-developers
> <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/
> <http://www-int.impmc.upmc.fr/%7Epaulatto/>
> 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/
> <http://www-int.impmc.upmc.fr/%7Epaulatto/>
> mail: 23-24/4é16 Boîte courrier 115, 4 place Jussieu 75252 Paris Cédex 05
>
>
> _______________________________________________
> Q-e-developers mailing list
> Q-e-developers at qe-forge.org
> http://qe-forge.org/mailman/listinfo/q-e-developers
--
Nicola Varini, PhD
Scientific IT and Application Support (SCITAS)
Theory and simulation of materials (THEOS)
ME B2 464 (Bâtiment ME)
Station 1
CH-1015 Lausanne
+41 21 69 31332
http://scitas.epfl.ch
Nicola Varini
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quantum-espresso.org/pipermail/developers/attachments/20160922/66a3bde0/attachment.html>
More information about the developers
mailing list