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

[Jens Jørgen Mortensen]

On 1/7/19 8:43 AM, Kuisma, Mikael via gpaw-users wrote:
>
> 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?
>

I think that's a good idea.


Jens Jørgen


>
> 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
> /
> /
>
>
> _______________________________________________
> gpaw-users mailing list
> gpaw-users at listserv.fysik.dtu.dk
> https://listserv.fysik.dtu.dk/mailman/listinfo/gpaw-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listserv.fysik.dtu.dk/pipermail/gpaw-users/attachments/20190109/7e6719eb/attachment.html>