GW not fixing the gap!

Post here any question you encounter when running the scripts of the yambo-py suite. Post here problem strictly to the python interface as problem coming from the yambo runs should go in the appropriate subforum.

Moderators: palful, amolina, mbonacci

Post Reply
mhammou
Posts: 5
Joined: Fri May 11, 2018 6:27 pm

GW not fixing the gap!

Post by mhammou » Fri May 11, 2018 11:04 pm

I'm running GW for one of the ferroelectrics. I first ran scf and nscf and got the correct DFT gap as published. Then I ran p2y then I
I ran gw of the given input using the command mpirun -np 32 yambo -F gw.in _J GW, but I noticed GW does not fix the gap. Why?
==================================================================================================
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
NLogCPUs= 1 # [PARALLEL] Live-timing CPU`s (0 for all)
EXXRLvcs=90 Ry # [XX] Exchange RL components
Chimod= "Hartree" # [X] IP/Hartree/ALDA/LRC/BSfxc
% BndsRnXp
1 | 500 | # [Xp] Polarization function bands
%
NGsBlkXp= 15 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 | 500 | # [GW] G[W] bands range
%
GDamping= 0.10000 eV # [GW] G[W] damping
dScStep= 0.10000 eV # [GW] Energy step to evaluate Z factors
DysSolver= "n" # [GW] Dyson Equation solver ("n","s","g")
%QPkrange # [GW] QP generalized Kpoint/Band indices
1| 18| 49|50|
%



Mahmoud
California State University, Los Angeles

User avatar
Daniele Varsano
Posts: 3816
Joined: Tue Mar 17, 2009 2:23 pm
Contact:

Re: GW not fixing the gap!

Post by Daniele Varsano » Sat May 12, 2018 6:25 am

Dear Mahmoud,
please note that your post is not related at all with the yambo-py utility but it is a question about a GW calculation.
Posting in the right subforum helps both the administrators and other users searching in the forum.

Now, It is not clear to me what do you mean by "GW does not fix the gap": The gap is the same as the KS one? does not match the experiments? differ substantially from the literature? Can you be more explicit? otherwise, it is hard to help you with so few information.

Best,

Daniele
Dr. Daniele Varsano
S3-CNR Institute of Nanoscience and MaX Center, Italy
MaX - Materials design at the Exascale
http://www.nano.cnr.it
http://www.max-centre.eu/

mhammou
Posts: 5
Joined: Fri May 11, 2018 6:27 pm

Re: GW not fixing the gap!

Post by mhammou » Sat May 12, 2018 6:47 pm

Thank you Daniele!
Sorry I tried to find the GW sub-forum but couldn't.
I meant the KS gap is about 1.12 eV, I tired to see the PPA correction but ends up with 1.2 eV. Then I tried the COHSEX and it seems this approach is better, I mean I got gap of 1.9 eV. I guess this value is accepted more, since I got almost the same gap using the mBJ approximation. I thought PPA gives better results compared to CHOSEX in solids.

Below is the COSEX .qp
========
#
# ____ ____ _ ____ ____ ______ ___
# |_ _||_ _| / \ |_ \ / _||_ _ \ ." `.
# \ \ / / / _ \ | \/ | | |_) | / .-. \
# \ \/ / / ___ \ | |\ /| | | __". | | | |
# _| |_ _/ / \ \_ _| |_\/_| |_ _| |__) |\ `-" /
# |______||____| |____||_____||_____||_______/ `.___."
#
#
#
# GPL Version 4.2.1 Revision 110. (Based on r.14778 h.7b4dc3
# MPI Build
# http://www.yambo-code.org
#
# GW [Newton Solver]
#
# == COHSEX GW ==
# GW SC iterations :0
# X G`s [used]: 315
# X G`s [disk]: 315
# X bands : 1 700
# X poles [o/o]: 100.0000
# X e/h E range [ev]:-1.000000 -1.000000
# X xc-Kernel : none
# X BZ energy Double Grid: no
# X BZ Double Grid points:0
# Sc bands terminator : no
# Sx RL components : 13231
# QP @ K 001 - 018 : b 049 - 050
#
# K-point Band Eo E-Eo Sc|Eo
#
1.00000 49.00000 -0.63396 -2.05142 3.22573
1.00000 50.00000 1.72090 -0.55042 -7.03968
2.00000 49.00000 -0.30336 -2.20497 3.18476
2.00000 50.00000 2.05688 -1.20727 -3.96663
3.00000 49.00000 -0.07098 -2.12167 2.91436
3.00000 50.00000 1.18688 -1.36738 -3.50149
4.00000 49.00000 -0.53003 -2.16322 2.77841
4.00000 50.00000 1.91477 -0.46617 -7.06639
5.00000 49.00000 -0.24976 -2.15412 3.03872
5.00000 50.00000 2.06315 -0.51354 -6.72064
6.000 49.00 -.4426E-1 -2.123 3.092
6.00000 50.00000 1.89994 -1.05097 -4.32459
7.00000 49.00000 -0.25197 -2.09058 2.03486
7.00000 50.00000 2.06587 -0.40858 -7.01575
8.00000 49.00000 -0.31225 -2.17907 3.15644
8.00000 50.00000 1.97085 -0.62413 -6.19802
9.00000 49.00000 -0.17607 -2.19026 3.30700
9.00000 50.00000 2.25059 -0.35413 -7.08537
10.00000 49.00000 -0.47754 -2.15234 2.95237
10.00000 50.00000 2.20414 -0.31017 -7.24028
11.00000 49.00000 -0.14980 -2.09887 2.95538
11.00000 50.00000 2.31775 -0.23980 -7.38849
12.00000 49.00000 0.00000 -2.09450 3.03727
12.00000 50.00000 2.41210 -0.16710 -7.75257
13.00000 49.00000 -0.19100 -2.07237 2.04932
13.00000 50.00000 2.37405 -0.36758 -6.85718
14.00000 49.00000 -0.20674 -2.07508 2.18578
14.00000 50.00000 2.28339 -0.43813 -6.62965
15.00000 49.00000 -0.11195 -2.13867 3.14073
15.00000 50.00000 2.35493 -0.27294 -7.33612
16.00000 49.00000 -0.10849 -2.03739 1.99770
16.00000 50.00000 2.01270 -1.10368 -4.19869
17.00000 49.00000 -0.11103 -2.04991 2.19738
17.00000 50.00000 2.48957 -0.18479 -7.63394
18.00000 49.00000 -0.12962 -2.07144 2.34263
18.00000 50.00000 2.26712 -0.37182 -7.23227
#
# 05/11/2018 at 16:51 YAMBO @ smicro [start]
# 05/11/2018 at 17:09 [end]
#
# Timing [Min/Max/Average]: 17m-46s/17m-46s/17m-46s
#
# .-Input file : yambo.in
# | em1s # [R Xs] Static Inverse Dielectric Matrix
# | HF_and_locXC # [R XX] Hartree-Fock Self-energy and Vxc
# | gw0 # [R GW] GoWo Quasiparticle energy levels
# | cohsex # [R Xp] COlumb Hole Screened EXchange
# | BoseTemp= 0.000000 eV # Bosonic Temperature
# | X_all_q_CPU= "4.2.2.2" # [PARALLEL] CPUs for each role
# | X_all_q_ROLEs= "v.c.k.q" # [PARALLEL] CPUs roles (q,k,c,v)
# | SE_CPU= "4.4.2" # [PARALLEL] CPUs for each role
# | SE_ROLEs= "b.qp.q" # [PARALLEL] CPUs roles (q,qp,b)
# | EXXRLvcs= 90 Ry # [XX] Exchange RL components
# | Chimod= "hartree" # [X] IP/Hartree/ALDA/LRC/BSfxc
# | % BndsRnXs
# | 1 | 700 | # [Xs] Polarization function bands
# | %
# | NGsBlkXs= 7 Ry # [Xs] Response block size
# | % DmRngeXs
# | 0.10000 | 0.10000 | eV # [Xs] Damping range
# | %
# | % LongDrXs
# | 0.1000E-4 | 0.000 | 0.000 | # [Xs] [cc] Electric Field
# | %
# | %QPkrange # [GW] QP generalized Kpoint/Band indices
# | 1| 18| 49| 50|
# | %


-------
Mahmoud
California State University, LA

User avatar
Daniele Varsano
Posts: 3816
Joined: Tue Mar 17, 2009 2:23 pm
Contact:

Re: GW not fixing the gap!

Post by Daniele Varsano » Sun May 13, 2018 8:39 am

Dear Mahmoud,
Sorry I tried to find the GW sub-forum but couldn't.
There is a subforum called Runnin yambo/self-energy.
I thought PPA gives better results compared to CHOSEX in solids.
I assume you checked all the relevant convergences.

Indeed PPA can be considered a better approximation as it includes dynamical effects, anyway I do not know what system you are dealing with, and considering the fact you are calculating non self-consistent quasi-particle energies, inaccuracy can originate from the starting Kohn Sham electronic structure (strong dependnece from the used xc functioanl.

Best,

Daniele
Dr. Daniele Varsano
S3-CNR Institute of Nanoscience and MaX Center, Italy
MaX - Materials design at the Exascale
http://www.nano.cnr.it
http://www.max-centre.eu/

mhammou
Posts: 5
Joined: Fri May 11, 2018 6:27 pm

Re: GW not fixing the gap!

Post by mhammou » Mon May 14, 2018 11:32 pm

The structure is BiZnTiO3. I think my KS run is okay since the results matche other DFT codes. I'm using PBE with ONCV PP.
I noticed something weird, I found the input variable EXXRLvcs changed after the job is terminated. I began with EXXRLvcs= 90 in the input file, but after the job was finished I found EXXRLvcs= 3 in the o-GW.qp file! how could this be possible?
&control
calculation='nscf',
prefix='bizntio3',
outdir='./'
pseudo_dir= './',
wf_collect=.true.,
verbosity ='high',
/&end
&system
ibrav=6
celldm(1)=10.213968968,
celldm(3)=0.8562525860,
nat=10,
ntyp=4,
ecutwfc=60.0,
nbnd=500,
force_symmorphic= .true.,

/&end
&electrons
diago_thr_init = 1.0d-5
/&end
ATOMIC_SPECIES
Bi 208.98 Bi_ONCV_PBE-1.0.upf
Zn 65.38 Zn_ONCV_PBE-1.0.upf
Ti 47.867 Ti_ONCV_PBE-1.0.upf
O 15.999 O_ONCV_PBE-1.0.upf
ATOMIC_POSITIONS crystal
Bi 0.500000000 0.000000000 0.433800012
Bi 0.000000000 0.500000000 0.433800012
Zn 0.000000000 0.000000000 0.000000000
Ti 0.500000000 0.500000000 0.000000000
O 0.000000000 0.000000000 0.617799997
O 0.500000000 0.500000000 0.617799997
O 0.750000000 0.250000000 0.125799999
O 0.750000000 0.750000000 0.125799999
O 0.250000000 0.250000000 0.125799999
O 0.250000000 0.750000000 0.125799999
K_POINTS (automatic)
4 4 4 0 0 0

User avatar
Daniele Varsano
Posts: 3816
Joined: Tue Mar 17, 2009 2:23 pm
Contact:

Re: GW not fixing the gap!

Post by Daniele Varsano » Tue May 15, 2018 11:12 am

Dear Mahmmou,
The structure is BiZnTiO3. I think my KS run is okay since the results matche other DFT codes. I'm using PBE with ONCV PP.
What I was meaning it was not that your DFT calculation is not ok, but just the PBE could not be a good starting point for G0W0.
I began with EXXRLvcs= 90 in the input file, but after the job was finished I found EXXRLvcs= 3
Could you please post your report file? Here you mean 90 Ry or 90 RL?
If you assign the EXXRLvcs in RL, it can slightly change it as yambo needs to close G vector shells in order to respect the symmetries of the system, and it considers the number that closes shells nearest to your input settings. Here anyway it does no seems the case. If you post your report file we can have a look to see what happened.

Best,
Daniele
Dr. Daniele Varsano
S3-CNR Institute of Nanoscience and MaX Center, Italy
MaX - Materials design at the Exascale
http://www.nano.cnr.it
http://www.max-centre.eu/

mhammou
Posts: 5
Joined: Fri May 11, 2018 6:27 pm

Re: GW not fixing the gap!

Post by mhammou » Fri May 18, 2018 11:25 pm

In the input file (gw.in) I specified EXXRLvcs = 90 Ry, NGsBlkXp=7 Ry but they came after as 3 Ry and 0 Ry. This sounds strange, see the attachments.
You do not have the required permissions to view the files attached to this post.

User avatar
Daniele Varsano
Posts: 3816
Joined: Tue Mar 17, 2009 2:23 pm
Contact:

Re: GW not fixing the gap!

Post by Daniele Varsano » Sat May 19, 2018 10:00 pm

Dear Mhammou,
what happened here is essentially that for some reason that now I do not understand the keyword "Ry" has been not recognized and yambo assumed your values as RL.
As you can see in the report:

[WR./7Ry_200//ndb.HF_and_locXC]---------

Code: Select all

Exchange RL vectors             :  97
Here 97 is the nearest number to 90 to have closed shell.

Code: Select all

[WR./7Ry_200//ndb.pp]-----
 X matrix size          :  7
This is the size of the screening matrix given by NGsBlkXp=7

A the end of the report these numbers are then converted in Ry (so 3 and 0). Note that 7 RL corresponds to 258 mHa: in the report file:

Code: Select all

[S3]:7( 258.0696)
so less then 1Ry.

I will try to see what's going wrong, in the meanwhile you can use wither RL or Ha units.

Best,
Daniele

PS: Please sign your posts with your affiliation. You can do once for all by filling the signature in your profile.
Dr. Daniele Varsano
S3-CNR Institute of Nanoscience and MaX Center, Italy
MaX - Materials design at the Exascale
http://www.nano.cnr.it
http://www.max-centre.eu/

mhammou
Posts: 5
Joined: Fri May 11, 2018 6:27 pm

Re: GW not fixing the gap!

Post by mhammou » Sun May 20, 2018 4:35 pm

Hi Daniele,
In the report file:
[WR./7Ry_200//ndb.pp]
RL vectors (WF): 8703
Do you think this number is small, I've seen people say you need to pick EXXRLvcs equals to maybe half or one third of the G-vectors [RL space] which is reported 57275.

Thank you!

--------
Mahmoud
Cal State LA

User avatar
Daniele Varsano
Posts: 3816
Joined: Tue Mar 17, 2009 2:23 pm
Contact:

Re: GW not fixing the gap!

Post by Daniele Varsano » Mon May 21, 2018 8:27 am

Dear Mahmoud,

Code: Select all

[WR./7Ry_200//ndb.pp]
RL vectors (WF): 8703
These are the G components used to represent the wfs these are read from your ground state calculation (QE). You found it at the beginning in the report
when the ns.db1 is read:

Code: Select all

 [RD./SAVE//ns.db1]
The big number 57275 is the G vector needed for the density that has energy cutoff 4 times larger than the one for wfs when norm-conserving pseudopotentials are used.
Anyway, the parameter that you need to check in the ndb.pp (screening in plasmon pole approximation) is the matrix size and the band range. The matrix size is given by the NGsBlkXp variable.
EXXRLvcs govern the G vectors summed in the exchange part and you find them reported in the ndb.HF_and_locXC database as Exchange RL vectors, while RL vectors (WF) is again the G vector used for the wave function.

Best,
Daniele
Dr. Daniele Varsano
S3-CNR Institute of Nanoscience and MaX Center, Italy
MaX - Materials design at the Exascale
http://www.nano.cnr.it
http://www.max-centre.eu/

Post Reply