error in compilation of Yambo 4.0.0

[hlee]

Dear all:

I am trying to compile the newly-released Yambo v4.0.0, but I have some difficulty with compilation:

I am not sure, but I think that this error might be specific to Intel compiler. I use Intel compiler v15.0.0 with Intel MPI v5.0.1 and below is the part of compilation output including the error message "error #8032: Generic procedure reference has two or more specific procedure with the same type/rank/keyword signature. [PP_REDUX_WAIT]":

Code: Select all

>>>[Making modules]<<<
make[1]: Entering directory `~/yambo-4.0.0-rev71/src/modules'
mod_pars.F mod_units.F mod_stderr.F mod_openmp.F mod_parallel.F(758): warning #6738: The type/rank/keyword signature for this specific procedure matches another specific procedure that shares the same generic-name.   [D0SHARE]
   subroutine d0share(rval,imode,COMM)
--------------^
mod_parallel.F(789): warning #6738: The type/rank/keyword signature for this specific procedure matches another specific procedure that shares the same generic-name.   [D1SHARE]
   subroutine d1share(array,COMM)
--------------^
mod_parallel.F(818): warning #6738: The type/rank/keyword signature for this specific procedure matches another specific procedure that shares the same generic-name.   [D2SHARE]
   subroutine d2share(array,COMM)
--------------^
mod_parallel.F mod_wrapper.F mod_wrapper_omp.F mod_drivers.F mod_FFT.F mod_LIVE_t.F(74): error #8032: Generic procedure reference has two or more specific procedure with the same type/rank/keyword signature.   [PP_REDUX_WAIT]
       call PP_redux_wait(cput_sec,COMM)
------------^
mod_LIVE_t.F(76): error #8032: Generic procedure reference has two or more specific procedure with the same type/rank/keyword signature.   [PP_REDUX_WAIT]
       call PP_redux_wait(cput_sec)
------------^
compilation aborted for mod_LIVE_t.f90 (code 1)
make[1]: *** [mod_LIVE_t.o] Error 1

Below is quoted from configuration output.

Code: Select all

#
# [VER] 4.0.0 r.4325
# 
# - GENERAL CONFIGURATIONS -
# 
# [SYS] linux@x86_64
# [SRC] ~/yambo-4.0.0-rev71
# [BIN] ~/yambo-4.0.0-rev71/bin
# [X] Double precision
# [X] Redundant compilation  
# [-] Run-Time timing profile 
# 
# - PARALLEL SUPPORT -
#
# [X] MPI 
# [X] OpenMP 
# [-] OpenMPI
# [-] Blue-Gene specific procedures
# 
# - INTERFACES -
#
# [X] QE (5.0) support
# [-] ETSF I/O support
#
# - LIBRARIES -
#
# [FFT] FFTW (MKL) Fast Fourier transform
# [ X ] SCALAPACK
# [---] NETCDF/HDF5/Large Files 
# [ - ] LibXC (external)
# [-- ] BLAS/LAPACK (built-in)
# [---] IOTK/NETCDF/ETSF_IO (built-in)
#
# - COMPILERS, MAKE and EDITOR -
#
# [ CPP ] mpiicc -E -ansi  -D_MPI -D_FFTW -D_FFTW_OMP -D_SCALAPACK -D_DOUBLE -D_OPENMP      
# [  C  ] mpiicc -g -O2 -D_C_US -D_FORTRAN_US
# [MPICC] mpiicc -g -O2 -D_C_US -D_FORTRAN_US
# [ F90 ] mpiifort -assume bscc -g -O3 -ip    -openmp
# [MPIF ] mpiifort -assume bscc -g -O3 -ip    -openmp
# [ F77 ] mpiifort -assume bscc -g -O3 -ip  
# [Cmain] -nofor_main
# [NoOpt] -assume bscc -g -O0  
#
# [ MAKE ] make
# [EDITOR] emacs
#

Regards.

[andrea.ferretti]

Dear Hyungjun,

thanks for reporting this problem. It is connected to double precision compilation (triggered by --enable-dp),
which causes an unwanted conflict during the definition of the PP_redux interface.

you can fix it as follows:

edit file yambo/src/modules/mod_parallel.F , around line 325

change

Code: Select all

 interface PP_redux_wait
   module procedure l1share,i1share,i18share,i2share,i3share,&
&                   r0share,r1share,r2share,r3share,d0share,d1share,d2share,&
&                   c0share,c1share,c2share,c3share,c4share,ch0share,PARALLEL_wait
 end interface PP_redux_wait

to

Code: Select all

 interface PP_redux_wait
   module procedure l1share,i1share,i18share,i2share,i3share,&
&                   r0share,r1share,r2share,r3share,&
&                   c0share,c1share,c2share,c3share,c4share,ch0share,PARALLEL_wait
#if ! defined _DOUBLE
   module procedure d0share,d1share,d2share
#endif
 end interface PP_redux_wait

this fix is going to be included in the official release of the code.
take care
Andrea

[andrea marini]

Hi.

Thanks for finding this bug!

You compiled with --enable-dp. Unless you do not really need it we suggest to compile the code in single precision. In this way it should compile smoothly.

Read, also, the announcement.

If you got the source trough the zip file remember that bug-fixes will be first released in the svn repo.

Andrea

[hlee]

Dear Andrea Marini and Andrea Ferretti:

Thank you very much for your quick reply and fix. I managed to compile successfully Yambo v4.0.0 due to your help.

However, I have one question. I just wanted to compile Yambo with double precision since most DFT codes, for example, Quantum ESPRESSO, use internally the double-precision real or complex variables. I understand well the difference between single- and double-precision values and I think that if memory is allowed, it is more reasonable to choose double-precision variables.

As I mentioned in the previous post (viewtopic.php?f=28&t=992#p4482), currently Yambo use both double- and single-precision variables even when enable-dp is used. For example, in mod_parallel.F, for real variables, single-(r*share) or double-precision (d*share) routines can be chosen depending on the enable-dp flag, but for complex variables, only single-precision routines (c*share) exist.

I am not sure, but I am afraid that this might give rise to some potential problem.

Regards.

[andrea.ferretti]

Hi Hyungjun,

when compiling double precision SP is internally remapped to double precision, (as if you were not specifying any precision and were compiling using -r8 or alike). So, when double precision is activated there is no difference between SP and DP.
Hope this answers your question.

see eg. src/modules/mod_pars.F

Code: Select all

!
 ! KINDS
 !
 integer, parameter  :: DP = selected_real_kind(14,200)
#if defined _DOUBLE
 integer, parameter  :: SP = selected_real_kind(14,200)
#else
 integer, parameter  :: SP = selected_real_kind(6,30)
#endif

take care
Andrea

[hlee]

Dear Andrea Ferretti:

Thank you very much for your quick reply.
Your reply completely solves my misunderstanding.

Regards.