Yambo Community Forum

Posted: **Mon Apr 06, 2015 4:47 pm**

Dear all:

I found very weird behaviour in G0W0 calculations for spinor case.
In order to reproduce easily this behaviour, I prepared the following (very minimal, but less meaningful) steps.
Although I used my constructed pseudopotentials (PPs), this behaviour is not dependent on PPs. Thus, I made the following input using PPs from pslibrary 1.0.0 (http://www.qe-forge.org/gf/project/psli ... kage_id=41):

1. Quantum ESPRESSO scf calculation using the following input:

Code: Select all

&control
  calculation = 'scf'
  prefix = 'InP'
  outdir = './'
  pseudo_dir = '../'
  wf_collect = .true.
  verbosity ='high'
/
&system
  ibrav = 2
  celldm(1) = 11.0492287
  nat = 2
  ntyp = 2
  ecutwfc = 45.0
  nbnd = 16
  noncolin = .true.
  lspinorb = .true.
/
&electrons
  conv_thr = 1.0d-8
/
ATOMIC_SPECIES
  In  114.818     In.rel-pbe-n-nc.UPF
   P   30.973762   P.rel-pbe-n-nc.UPF
ATOMIC_POSITIONS alat
  In  0.000000  0.000000  0.000000
   P  0.250000  0.250000  0.250000
K_POINTS automatic
  6 6 6  0 0 0

2. Creation of Yambo database:

Code: Select all

p2y -N -S

3. Yambo initialisation:

Code: Select all

yambo -N

4. Yambo G0W0 calculation using the following input:

Code: Select all

#   __   __     _        __  __       ____      U  ___  u
#   \ \ / / U  /"\  U u |" \/ "| u U | __") u    \/"_ \/
#    \ V /   \/ _ \/   \| |\/| |/   \|  _ \/     | | | |
#   U_|"|_u  / ___ \    | |  | |     | |_) | .-,_| |_| |
#     |_|   /_/   \_\   |_|  |_|     |____/   \_)-\___/
# .-,//|(_   \\    >>  <<,-,,-.     _|| \\_        \\
#  \_) (__) (__)  (__)  (./  \.)   (__) (__)      (__)
#
#             GPL Version 3.4.1 Revision 3187
#                http://www.yambo-code.org
#
em1d                         # [R Xd] Dynamical Inverse Dielectric Matrix
gw0                          # [R GW] GoWo Quasiparticle energy levels
ppa                          # [R Xp] Plasmon Pole Approximation
HF_and_locXC                 # [R XX] Hartree-Fock Self-energy and Vxc
EXXRLvcs= 10           Ry    # [XX] Exchange RL components
Chimod= "Hartree"            # [X] IP/Hartree/ALDA/LRC/BSfxc
% BndsRnXp
  1 | 16 |                   # [Xp] Polarization function bands
%
NGsBlkXp= 10           Ry    # [Xp] Response block size
% LongDrXp
 1.000000 | 0.000000 | 0.000000 |        # [Xp] [cc] Electric Field
%
PPAPntXp= 27.21138     eV    # [Xp] PPA imaginary energy
% GbndRnge
  1 | 16 |                   # [GW] G[W] bands range
%
GDamping= 0.100000     eV    # [GW] G[W] damping
dScStep= 0.100000      eV    # [GW] Energy step to evalute Z factors
DysSolver= "n"               # [GW] Dyson Equation solver (`n`,`s`,`g`)
%QPkrange                    # [GW] QP generalized Kpoint/Band indices
  1| 16|  1| 16|
%
%QPerange                    # [GW] QP generalized Kpoint/Energy indices
  1| 16| 0.0|-1.0|
%

When proceeding in this way, the following "NaN" occurs already in the section, " [04] Bare local and non-local Exchange-Correlation".
For example,

Code: Select all

 [04] Bare local and non-local Exchange-Correlation
 ==================================================

 [EXS] Plane waves : 181

 QP @ K 001 - 016 : b 001 - 016

 [Distribute] Average allocated memory is [o/o]: 100.0000
 [FFT-HF/Rho] Mesh size: 20  20  20

 [WF loader] Normalization (few states)  min/max  :0.379E-16  1.00

 [xc] Functional Perdew, Burke & Ernzerhof(X)+Perdew, Burke & Ernzerhof(C)
 [xc] LIBXC used to calculate xc functional

 XC HF and DFT [eV] @ K [1] (iku): 0.00      0.00      0.00
 <1|HF|1> =       NaN       NaN <1|DFT|1> = -10.80910  0.000000
 <2|HF|2> =       NaN       NaN <2|DFT|2> = -10.80910  0.000000
 <3|HF|3> =       NaN       NaN <3|DFT|3> = -11.56662 0.826E-16
 <4|HF|4> =       NaN       NaN <4|DFT|4> = -11.56662 0.708E-16
 <5|HF|5> =       NaN       NaN <5|DFT|5> = -11.58541  0.000000
 <6|HF|6> =       NaN       NaN <6|DFT|6> = -11.58541  0.000000
 <7|HF|7> =       NaN       NaN <7|DFT|7> = -11.58540 0.944E-16
 <8|HF|8> =       NaN       NaN <8|DFT|8> = -11.58541  0.000000
 <9|HF|9> =       NaN       NaN <9|DFT|9> = -9.636819  0.000000
 <10|HF|10> =       NaN       NaN <10|DFT|10> = -9.636781 -.189E-15
 <11|HF|11> =       NaN       NaN <11|DFT|11> = -8.970842 0.177E-16
 <12|HF|12> =       NaN       NaN <12|DFT|12> = -8.970907 0.236E-16
 <13|HF|13> =       NaN       NaN <13|DFT|13> = -8.958719  0.000000
 <14|HF|14> =       NaN       NaN <14|DFT|14> = -8.958805 0.189E-15
 <15|HF|15> =       NaN       NaN <15|DFT|15> = -8.958759 -.189E-15
 <16|HF|16> =       NaN       NaN <16|DFT|16> = -8.958873  0.000000

However, when I reduced the number of significant figures in celldm(1) in QE scf input in the following way,

Code: Select all

  celldm(1) = 11.049229

the "NaN" completely disappears.

I am not sure, but I guess this might be related to the previously-mentioned issue, "viewtopic.php?f=14&t=444&start=20".

Sincerely,

Posted: **Mon Apr 06, 2015 5:40 pm**

Dear Hyungjun Lee.
thank you for the very detailed report.

Unfortunately I've not been able to reproduce the error

Code: Select all

 [04] Bare local and non-local Exchange-Correlation
 ==================================================

 [EXS] Plane waves : 181

 QP @ K 001 - 016 : b 001 - 016

 [FFT-HF/Rho] Mesh size: 20  20  20

 [WF loader] Normalization (few states)  min/max  :0.4165E-8  1.000

 [xc] Functional Perdew, Burke & Ernzerhof(X)+Perdew, Burke & Ernzerhof(C)
 [xc] LIBXC used to calculate xc functional

 XC HF and DFT [eV] @ K [1] (iku): 0.00      0.00      0.00
 <1|HF|1> = -17.53226 0.4996E-8 <1|DFT|1> = -10.80911 0.3664E-8
 <2|HF|2> = -17.53225 0.1935E-7 <2|DFT|2> = -10.80912 -.4600E-8
 <3|HF|3> = -13.05592 0.1132E-7 <3|DFT|3> = -11.56662 -.1792E-8
 <4|HF|4> = -13.05592 -.1148E-7 <4|DFT|4> = -11.56663 0.2958E-8
 <5|HF|5> = -13.00587 -.2617E-8 <5|DFT|5> = -11.58541 0.1131E-8
 <6|HF|6> = -13.01768 0.1060E-7 <6|DFT|6> = -11.58539 0.6047E-8
 <7|HF|7> = -13.00340 0.7025E-8 <7|DFT|7> = -11.58542 -.2611E-8
 <8|HF|8> = -13.01692 0.6038E-8 <8|DFT|8> = -11.58540 -.330E-09
 <9|HF|9> = -6.266348 -.1583E-8 <9|DFT|9> = -9.636870 -.480E-09
 <10|HF|10> = -6.266330 -.1640E-8 <10|DFT|10> = -9.636841 -.1264E-8
 <11|HF|11> = -4.679672 0.1322E-8 <11|DFT|11> = -8.970870 -.1326E-8
 <12|HF|12> = -4.679695 0.1662E-8 <12|DFT|12> = -8.970882 0.2588E-8
 <13|HF|13> = -4.603092 -.831E-09 <13|DFT|13> = -8.958641 0.2166E-8
 <14|HF|14> = -4.624555 -.450E-09 <14|DFT|14> = -8.958642 -.233E-09
 <15|HF|15> = -4.621089 0.223E-09 <15|DFT|15> = -8.958677 -.4372E-8
 <16|HF|16> = -4.612974 -.644E-09 <16|DFT|16> = -8.958772 -.1037E-8

In order to reproduce the problem I ask you few more informations:
1) which version of yambo are you using, the one you can download via tar.gz file or the one on the svn repository ?
2) Could you provide the configure line you used for the pre-compiling configuratio and also the log (as in the following example)

Code: Select all

FC_FLAGS_DEBUG="-g -pg -Wall -fbounds-check -fbacktrace -O0"

ABINIT_LIB="/data/sangalli/Lavoro/Codici/abinit/abinit-7.4.1/compiled_abi_etsf/fallbacks/exports/"
PW_LIB="/data/sangalli/Lavoro/Codici/pwscf/svn_repository/iotk/"

./configure FCFLAGS="$FC_FLAGS_DEBUG"  --enable-keep-src  --with-iotk=5.0 --with-iotk="$PW_LIB" --with-etsf-io-lib="$ABINIT_LIB/lib" --with-etsf-io-include="$ABINIT_LIB/include" --with-netcdf-lib="/usr/lib/" --with-netcdf-include="/usr/include/" --with-netcdf-link="-lnetcdff -lnetcdf -lhdf5_hl -lhdf5 -lcurl -lz" --with-fftw="/usr/lib/x86_64-linux-gnu/"  --with-blas="/usr/lib" --with-lapack="/usr/lib" #--with-scalapack="-L/usr/lib/libscalapack-openmpi.a"

#
# [VER] 3.4.1 r.3187
# 
# [SYS] linux@x86_64
# [SRC] /home/sangalli/data/Lavoro/Codici/yambo/GPL_released/stable
# [BIN] /home/sangalli/data/Lavoro/Codici/yambo/GPL_released/stable/bin
# [FFT] FFTW Fast Fourier transform
#
# [ ] Double precision
# [X] Redundant compilation  
# [X] MPI 
# [ ] OpenMP 
# [X] PW (5.0) support
# [X] ETSF I/O support
# [ ] SCALAPACK
# [X  ] NETCDF/HDF5/Large Files 
# [  X] Built-in BLAS/LAPACK/LOCAL
#
# [ CPP ] gcc -E -P  
# [  C  ] gcc -g -O2 -D_C_US -D_FORTRAN_US
# [MPICC] mpicc -g -O2 -D_C_US -D_FORTRAN_US
# [ F90 ] gfortran -g -pg -Wall -fbounds-check -fbacktrace -O0   
# [MPIF ] mpif90 -g -pg -Wall -fbounds-check -fbacktrace -O0   
# [ F77 ] gfortran -g -pg -Wall -fbounds-check -fbacktrace -O0
# [Cmain] 
# [NoOpt] -O0 -mtune=native
#
# [ MAKE ] make
# [EDITOR] vim
#

Kind regards,
Davide

Posted: **Mon Apr 06, 2015 7:30 pm**

Dear Davide Sangalli:

Thank you very much for your quick reply.

In advance I would like to mention about my used cluster and compiler: Intel Ivy Bridge based cluster and Intel compiler v. 15.0.0 with Intelmpi v. 5.0.1

1) which version of yambo are you using, the one you can download via tar.gz file or the one on the svn repository ?

I used the revision of 65 of Yambo v. 3.4.1 (GPL Version 3.4.1 Revision 3187) which was downloaded from the svn repository.

2) Could you provide the configure line you used for the pre-compiling configuratio and also the log (as in the following example)

I attached below your requested infos:

Code: Select all

  $ ./configure --with-mpi --enable-dp --with-editor=emacs --with-iotk=~/espresso-5.1.1/iotk/ --with-p2y=5.0 --with-blas=-L/ssoft/intel/15.0.0/RH6/all/x86_E5v2/composer_xe_2015.0.090/mkl/lib/intel64 -lmkl_core -lmkl_intel_lp64 -lmkl_sequential --with-lapack=-L/s\
soft/intel/15.0.0/RH6/all/x86_E5v2/composer_xe_2015.0.090/mkl/lib/intel64 -lmkl_core -lmkl_intel_lp64 -lmkl_sequential --with-blacs=-L/ssoft/intel/15.0.0/RH6/all/x86_E5v2/composer_xe_2015.0.090/mkl/lib/intel64 -lmkl_scalapack_lp64 -lmkl_blacs_intelmpi_lp64 --with-scalapa\
ck=-L/ssoft/intel/15.0.0/RH6/all/x86_E5v2/composer_xe_2015.0.090/mkl/lib/intel64 -lmkl_scalapack_lp64 -lmkl_blacs_intelmpi_lp64 --with-fftw=/ssoft/intel/15.0.0/RH6/all/x86_E5v2/composer_xe_2015.0.090/mkl/lib/intel64 --with-fftw-lib=-lmkl_core -lmkl_intel_lp64 -lmkl_seque\
ntial

#
# [VER] 3.4.1 r.3187
# 
# [SYS] linux@x86_64
# [SRC] ~/yambo-3.4.1-rev65/
# [BIN] ~/yambo-3.4.1-rev65/bin
# [FFT] External Fast Fourier transform
#
# [X] Double precision
# [X] Redundant compilation  
# [X] MPI 
# [ ] OpenMP 
# [X] PW (5.0) support
# [ ] ETSF I/O support
# [X] SCALAPACK
# [   ] NETCDF/HDF5/Large Files 
# [  X] Built-in BLAS/LAPACK/LOCAL
#
# [ CPP ] mpiicc -E -ansi  
# [  C  ] mpiicc -g -O2 -D_C_US -D_FORTRAN_US
# [MPICC] mpiicc -g -O2 -D_C_US -D_FORTRAN_US
# [ F90 ] mpiifort -assume bscc -O3 -ip -xHost   
# [MPIF ] mpiifort -assume bscc -O3 -ip -xHost   
# [ F77 ] mpiifort -assume bscc -O3 -ip -xHost
# [Cmain] -nofor_main
# [NoOpt] -assume bscc -O0 -xHost
#
# [ MAKE ] make
# [EDITOR] emacs
#

I am not sure, but as I mentioned in my previous post, I guess this might be related to the precision; There is difference in precision between my config (Double precision) and yours (not Double precision).

Sincerely,

Posted: **Mon Apr 06, 2015 8:15 pm**

Ok, the problem is due to the --enable-dp (double precision) option.
I still have to figure out how to fix it.
However if you compile without this option everything should work fine.

D.

Posted: **Mon Apr 06, 2015 8:28 pm**

Dear Davide Sangalli:

Thank you very much for your kindly effort.

I tried to compile Yambo just without double precision (others are same) and used it in my same calculation, but I obtained the different behaviour as follows:

Code: Select all

  celldm(1) = 11.0492287

Code: Select all

celldm(1) = 11.049229

For the above two cases, "NaN" still remain.

But, for

Code: Select all

  celldm(1) = 11.04923

"NaN" disappears.

Posted: **Mon Apr 06, 2015 8:41 pm**

Dear Davide Sangalli:

I am not sure whether this is related to my issue or not, but I found another differences in the section "[02.04] K-grid lattice" as follows (in particular, B2 part):
All calculations below have been performed using single precision version of Yambo.
1. NaN disappears for "celldm(1) = 11.04923"

Code: Select all

  [02.04] K-grid lattice
  ======================

  Compatible Grid is 3D
  B1 [rlu]=0.1667    -.7451E-8  0.000
  B2      =0.7451E-8 0.7451E-8 0.1667
  B3      =0.7451E-8 -.1667     0.000
  Grid dimensions               :  6   6   6
  K lattice UC volume       [au]:   0.0034

2. NaN remains for "celldm(1) = 11.049229".

Code: Select all

  [02.04] K-grid lattice
  ======================

  Compatible Grid is 3D
  B1 [rlu]=-0.166667  0.000000  0.000000
  B2      = 0.166667  0.166667  0.166667
  B3      = 0.000000 -0.166667  0.000000
  Grid dimensions               :  6   6   6
  K lattice UC volume       [au]:   0.0034

3. NaN remains for "celldm(1) = 11.0492287".

Code: Select all

  [02.04] K-grid lattice
  ======================

  Compatible Grid is 3D
  B1 [rlu]=-0.166667  0.000000  0.000000
  B2      = 0.166667  0.166667  0.166667
  B3      = 0.000000  0.166667  0.000000
  Grid dimensions               :  6   6   6
  K lattice UC volume       [au]:   0.0034

Sincerely,

Posted: **Mon Apr 06, 2015 9:21 pm**

Well, at least I was obtaining the error just with the --enable-dp option.

In any case I found out a bug and fixed it.
Try to do svn up (revision 70), recompile and see if it fixes the problem for you as well.

D.

Posted: **Tue Apr 07, 2015 10:45 am**

Dear Davide Sangalli:

Thank you very much for your very quick fix; your fix completely solves NaN problem depending on the number of significant figures in celldm(1).
I checked only the calculation with double precision.

However, I have two questions:
(1) Irrespective of your fix, the difference in "[02.04] K-grid lattice" still remains. Why are some vectors in "K-grid lattice" different depending on the number of significant figures of overall scaling factor, celldm(1)?
(2) Currently in Yambo, some floating-point numbers are defined in single precision. Thus, when we compile Yambo with double precision, the coexistence of floating-point variables with single and double precisions inevitably occurs. Is there the potential problem with this?

Sincerely,

Posted: **Tue Apr 07, 2015 9:02 pm**

Dear Hyungjun Lee,
for your questions

(1) If I'm not wrong the vectors are not define in a unique way. I.e. there is an arbitrary factor. So they may be different between different runs. The important thing is that the three calculations give the same results (beside the bug there was before). Do you see any other difference ?

(2) We introduced the option --enable-dp long time ago but we did not put too much attention in keeping the subsequent developments consistent. So I fear you are right, there are pieces of the code where the dp precision is lost. It is not related with the previous question. However if you are interested we can try to restore it. It will take some time but I think it would be a good thing for the code. Let me know in case you have specific indications.

D.

Yambo Community Forum

weird behaviour in spinor case

weird behaviour in spinor case

Re: weird behaviour in spinor case

Re: weird behaviour in spinor case

Re: weird behaviour in spinor case

Re: weird behaviour in spinor case

Re: weird behaviour in spinor case

Re: weird behaviour in spinor case

Re: weird behaviour in spinor case

Re: weird behaviour in spinor case