[gpaw-users] questions and issues regarding bandgap calculation using GLLBSC functional

[Kuisma, Mikael]

Hi!


>I didn't go over theory of the GLLBSC functional, so I am treating it as a black-box.
I recommend that you do, there are some pitfalls using GLLBSC as a black-box (for example, it does not have well defined total energy i.e. forces are not well defined).


>While I have checked that (for nonzero gaps) these two numbers usually match (gap=Eks), sometimes they don't (and when they don't they differ too much).


Let's see. GLLBSC gets the value of the Kohn-Sham band gap directly from wfs.get_homo_lumo(). So the question is, why does GPAW's get_homo_lumo differ from ASE.


I see wfs.get_homo_lumo() assumes an even number of electrons


    n = self.nvalence // 2,


and also it assumes that there are only full bands below fermi level. This also explains the negative band gaps on metallic systems, as the band gap is calculated for example as

min( eps_kn[LUMO, :] ) - max( eps_kn[HOMO, :]) which is negative on some metals.


On the other hand, ASE's dft.bandgap directly sets bandgap to zero if a band crosses Fermi level.


Thanks for bringing this up! I think one should move to using ase.bandgap for GPAW also instead of the assumptions done by wfs.get_homo_lumo. Ask, Jens, what do you think?

BR,
Mikael Kuisma

Academy of Finland Post Doc

Nanoscience Center
Department of Chemistry
University of Jyväskylä
P.O. Box 35
FIN-40014 University of Jyväskylä
Finland

E-mail: mikael.j.kuisma (at) jyu.fi
Phone: +358 40 077 4114

https://scholar.google.se/citations?user=w0eP9esAAAAJ

Visiting address: NSC, 3rd floor, YN320


________________________________
Lähettäjä: gpaw-users-bounces at listserv.fysik.dtu.dk <gpaw-users-bounces at listserv.fysik.dtu.dk> käyttäjän Amir Hajibabaei via gpaw-users <gpaw-users at listserv.fysik.dtu.dk> puolesta
Lähetetty: maanantai 7. tammikuuta 2019 7.04
Vastaanottaja: gpaw-users at listserv.fysik.dtu.dk
Aihe: [gpaw-users] questions and issues regarding bandgap calculation using GLLBSC functional

Dear all,

I didn't go over theory of the GLLBSC functional, so I am treating it as a black-box.
I have done about ~1000 bandgap calculations using this functional in GPAW and,
now I am facing the problem of tossing the unreliable numbers .

Consider this piece of code:
                    calc = GPAW(...,   xc='GLLBSC',  ...)
                    atom.set_calculator(calc)
                    atom.get_potential_energy()
                    gap, _, _ = ase.dft.bandgap.bandgap(calc)
                    dir_gap, _, _ = ase.dft.bandgap.bandgap(calc,direct=True)
                    response = calc.hamiltonian.xc.xcs['RESPONSE']
                    response.calculate_delta_xc()
                    EKs, Dxc = response.calculate_delta_xc_perturbation()

I have three questions:

First, ideally the numbers "gap" and "Eks"  should be equal, right?
While I have checked that (for nonzero gaps) these two numbers usually match (gap=Eks), sometimes they don't (and when they don't they differ too much).
Should I treat such cases as convergence issue with GPAW or is it allowed to happen?

Second, if the "gap" returned by the ase.dft.bandgap module is zero does that mean that I can skip the rest of the lines and just set Eks=0 and Dxc=0?

Third, what is the recipe for calculation of the direct bandgap with GLLBSC?
Is the following correct (considering variable in the code)?
gllbsc_dir_gap = dir_gap + Dxc


I also have two issues which I think may be bugs in GPAW:

First, why GPAW never returns EKs=0 ?!
Clearly many crystals will have zero bandgap, but the GLLBSC implemented in GPAW hates the number zero.

Second, why does GPAW returns negative numbers (by no means small) for EKS and Dxc so frequently?

Best,
Amir Hajibabaei


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listserv.fysik.dtu.dk/pipermail/gpaw-users/attachments/20190107/6eb063cf/attachment.html>