My Community

Hello there!

I computed the band structure of some known semiconductors (AlSb, InP, etc.)
using PBE0, with HFRCUT=-1, and using the method of mixing a uniform grid
of kpoints with a list of zero-weight kpoints on the high symmetry path.

Here what happens:
- without SOC, the bands are correct
- enabling SOC, the bands get deformed, especially the valence bands around the gamma point. The conduction bands look less affected. See attached plot.
- playing around with different values of HFRCUT, the warping of the bands decrease but the
band gap changes considerably with its value.

Now, reading again the wiki page about how to compute bands with hybrids,
wiki/index.php/Band-structure_calculati ... unctionals
I tried the second method suggested to include kpoints along a symmetry path.
The second method says to have a uniform k-grid in the KPOINTS file and the kpoints
on a line in a separate file KPOINTS_OPT. Initially, I thought that this was just a way to
simplify the input of kpoints on a line, but the actual calculation was the same.
Though, between the lines of that page, it seems that the way the eigenvalues for those
k-points in the KPOINTS_OPT are computed in a different way with respect to those
with zero-weight listed in the KPOINTS.

I gave it a try and compute the PBE0+SOC bands using the KPOINTS_OPT file,
finding correct bands with a correct band gap.

Can someone share some thoughts on what's going on here?
Are these methods substantially different and in which way?
Is there a bug when using the first method with PBE0 and SOC?
Or it's some issue with my input?
Is the second method just more robust and hence recommended?

I can provide input file to reproduce these bands.

Hope someone can clarify this and maybe we could make the wiki page more clear.

Dear francesco_ricci,

Could you post the results without SOC? Otherwise it is hard to understand what you mean when you talk about band deformation. Please also attach your input files and the OUTCAR. It is easier to find if something went wrong that way.

Kind regards,
Pedro

Hi Pedro!

Sorry, I thought that the shape of these bands was obvious given the material (InP).
Here the bands without SOC, where the valence bands are degenerate in Gamma.
Applying SOC, there should be a splitting, but not that warping which moves the vbm
off-gamma.
I also attach the bands using the KPOINTS_OPT, still pbe0+soc, which looks good to me.
And the input/output for computing the bands of InP with pbe0 and soc
with zero-weights kpoints method.

Thanks!

Dear Francesco,

I am not familiar with the material in question, but Gamma is a point with time-reversal symmetry, so I would expect that the bands are degenerate at that point. This happens with other systems with SOC, like MoS2 and Bi2Se3. Why is this not supposed to happen for InP?

Kind regards,
Pedro

The degeneracy at Gamma is indeed expected.

The issue here is that, when using PBE0+SOC along with mixing kpoints with different
weights, the bands around Gamma get warped/distorted from a more parabolic-like shape
(see first image posted).

The issue seems to be solved if I use the KPOINTS_OPT file to list the kpoints path
(see third image posted "InP_bands_pbe0_soc_kpoints_opt.png").

I wanted to understand the origin of this different result: some issue with my input,
one method of listing the kpoints is better in some case than other, or some bug/missing
implementation in VASP.

Thanks!

Dear Francesco,

Sorry, I misunderstood the initial question. Initially I thought that there was something physically wrong with the results, but it seems that it is really an issue related to the input files.

I checked your KPOINTS file and everything there seems consistent with the information we provide. I will go ahead and check why you obtain different results compared to when you provide the path in the KPOINTS_OPT file.

Regarding the computation methods themselves, it works basically like this: If the path is provided in KPOINTS with all the points along it having a weight of 0, VASP performs a normal SCF calculation by diagonalising the DFT hamiltonian (using, for example, exact diagonalization or Davidson method) until the total energy (and thus the density) converges. That is why you see several DFT steps as the density converges. But the zero-weighted points are not included in the evaluation of the density or total energy.

However, if you provide them in KPOINTS_OPT, VASP first does the SCF cycle, then uses the obtained density to compute the new states and energies. But it no longer needs to converge the density. In this case VASP just diagonalizes the hamiltonian for the new kpoints, but there is no need to converge the density again.

I will let you know once I have more information.

Kind regards,
Pedro

Thanks Pedro for clarifying this.

Are these two methods suppose to give always the same result?
Or there are case where the output is different and how much?

Anyway, it seems that combining PBE0 and SOC the two methods return
different bands. In particular, the zero-weight method looks like has some issue.

One more hint is that using HSE06 + SOC, the bands with the zero-weight method
did not show any warping. So I feel there's something related to the Coulomb truncation method (HFRCUT flag), but not 100% sure.

Please, keep me posted if you find a possible explanation for this.

Thanks!

Dear Francesco,

Yes, both methods should wield the same results. However, the first method is slower since at each step in the SCF cycle you also include the k-points with 0 weight, instead of using only the k-points inside the irreducible Brillouin zone. With the second

Kind regards,
Pedro

Dear Francesco,

I have noticed that in you calculation the Fock contribution to the total energy is printed as a "NaN" in the OUTCAR, and as a consequence the total forces and stress is also a "NaN". I am trying to research why this happens. Could you tell me which grid you used when you employed the second method, i.e. using a regular k-grid in the KPOINTS and the path for the bands in the KPOINTS_OPT file?

Kind regards,
Pedro

Dear Francesco,

We managed to track the issues related to the problem you reported. There are two issues in total:

1. We think that you are using a list of k-points in the IBZ (i.e. those with finite weight) that came from a previous calculation without spin-orbit coupling. Please be aware that VASP employs different symmetry operations when spin-orbit coupling is activated vs when it is not. We tested with a set of points from a previous calculation with spin-orbit coupling and found that the bands are properly reproduced.

2. At the present, it is not possible to compute stress using HFRCUT=-1 with VASP. We are working on having it available in a future release. For now, please avoid using it together with ISIF=3. Since you are only interested in plotting the bands, you do not need to use ISIF=3 in your INCAR. This will also fix the NaN in the evaluation of the Fock energy.

Let me know if you have more questions.

Kind regards,
Pedro Melo

Hi Pedro.

Sorry for the late reply, this went off of my radar (I just turned on a notification).

Thanks for digging into this. I have the following comments.
Regarding your point 2, you're totally right, ISIF=3 is not needed here
and I see that even if NSW is equal 0, vasp still tries to compute forces.
So better to remove that.

Regarding point 1, the main one, that's interesting. I do not compute any
preliminary calculation to generate the kpoints. I do a single calculation
with the kpoints on uniform grid and those on a line generated via pymatgen
(which internally uses spglib).
So, I guess that, as you tested, if I start with a SOC calculation and let VASP
generating the kpoints on a uniform grid, these kpoints will be different from
those that I get from spglib due to the different symmetries used. I give it a
try and see myself the different kpoints generated by VASP and spglib.
And, I think this could make sense and explain the issue I'm having.

Though, what still puzzles me is that using the KPOINT_OPT method, the bands
does not show any warping but the kpoints on a uniform grid in the KPOINTS file
are exactly the same (generated with spglib). Also, using HSE06+SOC, and
again same kpoint grid from spglib, there is no issue.

Thanks again.

I answer myself to the first puzzle.

I checked carefully the input files and when I use the KPOINTS_OPT method,
the KPOINTS file does not contain a list of kpoints from spglib but a mesh
size, so I'm letting VASP generating the kpoints.
This explains why this method works and confirms what Pedro sad in his post.
Also, I can see that the kpoints in the IBZKPT file are much different from those
I provide in the KPOINTS with mixed-weights.

So, I think the issue is solved here.

Thanks a lot!