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

[Amir Hajibabaei]

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/78beae83/attachment.html>