Fermi surface unfolding problem for magnetic hexagonal cell

[yujia-teng]

Dear developers,
I've encountered problems when applying FS unfolding to magnetic hexagonal systems, where magnetic order lowers system symmetry from 6-fold down to 2-fold. So I need to sample half of BZ not just a quarter. Looks like unfolding doesn't work on this system, because unfolded result looks same as original fermi surface of supercell (Slide 10 in attatchment below). And I'm wondering if there's a solution. I've tried extensively but haven't been able to resolve the issues. I'll provide some quick summary points first, followed by more detailed information.

In short, there're following 3 problems: (Edit: I think problem 1 and 2 are solved by retaining PROCAR files. See details in my reply below.)

1. (0.5,0) to (0,0.5) only covers 1/6 of BZ, so we need to use K'(2/3,-1/3) to M'(0,0.5) for hexagonal system. But the path jumps when kx or ky reaches 0.5 due to k range [-0.5,0.5), leading to points appearing outside sampling region and thus wrong FS.
2. Magnetic order lowers the symmetry, from 6-fold down to 2-fold. So I need to sample half of BZ instead of just a quarter, and then apply inversion. SYMPOINT doesn't work here. But I couldn't get correct result outside (0.5,0) -> (0,0.5) region due to 1st problem.
3. The unfolded fermi surface I obtained in slide 10 below seems to be the fermi surface of supercell instead of primitive cell, because it looks same as my manually unfolded one, where fs around center doesn't go away.

If I understand it correctly, the package wants us to sample a quarter of BZ, and then use SYMPOINT1 to apply (x,y) to (-x,y), (x,-y) and (-x,-y) to obtain the whole FS, which means it assumes the FS has mx, my and inversion symmetry, or combine with SYMPOINT2, applying a mirror operation. But if the FS has no mirror symmetry, then looks like SYMPOINT doesn't work.

GdAuGe fs unfolding problem.pdf

input.tar.gz

I attach my result and input files above. There are 3 sections there, which are slide 2-4, 5-12 and 13-16 (The remaining slides are explained in my next reply below). First of all, I've successfully repeated NbSe2 according to post #5 by another user, which is very helpful as a starting point and it's also hexagonal system. Slide 1 is BZ for 2 kinds of lattice vector, with angle 60° and 120° angle. Only section 2 use lattice vector with 60° angle. This choice of BZ affects result as we will see below.

Section 1: FS still has 6-fold symmetry. Slide 2-4

Slide 2 is my crystal structure with 1st kind of magnetic order, called AFM1. Although the spin is in-plane, FS still has 6-fold symmetry because MAE is too small to be visible. FS unfolding seems work here, but we can see the problem in slide 3. I just sampled in 1st quarter of BZ, but only a small portion of points appears there in unfolded FS without SYMPOINT, and most of them are outside the sampling region. The reason I think is because of path jump in slide 4. I used same path in primitive cell, and see that the unfolded band is inconsistent with primitive cell band starting from the gap.

Section 2: FS only has 2-fold symmetry. Slide 5-12

Slide 5 show the magnetic primitive cell of another magnetic state, called AFM5 and its FS. This magnetic primitive cell is a 211 supercell. The right figure is the FS that I manually unfolded to primitive BZ. It's not the actual unfolded fs of AFM5 primitive cell because the fs near the center should be unfolded away, so I put it there just as a reference. My goal is to obtain the unfolded FS of this 211 supercell. The MSG is 4.10, so FS only has a 2-fold rotation symmetry, which is inversion in kx-ky plane. Thus, I need to sample half of BZ and apply inversion to obtain the whole FS. SYMPOINT1 and 2 doesn't work here.

Slide 6 shows the unfolded band and the problem of path jump. Using M(0.5,0) gives wrong path because M-K should be the shortest. This happens because the sampling M-K is from (-0.5,0), not (0.5,0) to (1/3,1/3). So I replace 0.5 by 0.4999999 to avoid the jump in later FS sampling. (Edit: This is solved with recompiled vasp, see details in next reply.)

Slide 7-9 are FS sampling of a quarter of circle. Each of them looks fine separately, and is similar to manually unfolded FS. However, if I combine them in slide 9 (collect their PRJCAR, in directory 1..30 and 31..60 radial. Then run b4vasp --fermi %radial), the result is wrong. The original pattern disappears and points merge along the diagonal. I doubt it's still due to point with kx/ky >= 0.5 maps back, because the coordinate of figure switched from 0.6667/0.7118 to 0.4825.

So in slide 10, I manually plot the fs using the 2 data files (Fermisurface.dat) above. I only used kx and ky data there, because I'm not sure which column is for Bloch character and which are for orbital characters among the other 12 columns. However, it looks almost same as unfolded one, so I doubt unfolding doesn't work on this system.

Slide 11-12 is sampling from (0.5,0) to (0,0.5) and (0,-0.5) to (0.5,0). In the 2nd case, points appear outside sampling region. Slide 11 shows combined FS and is still not correct.

Section 3: Other sampling tests of AFM5. Slide 13-16 (Edit: I think problem of weird looking fs is solved by retaining PROCAR files. See details in my reply below.)

The remaining slides are other sampling test, with 120° lattice vector (left BZ in slide 1). So reciprocal lattice vector spans a smaller region. Only sampling from (0.5,0) to (0,0.5) (slide 13) gives correct result, all others are wrong, where points appears outside sampling region and merge along diagonal.

I really appreciate your help.

Best regards.

[yujia-teng]

Dear David,
I would like to give two more updates of this problem, which could solve some problems above, but the main problem is still unresolved.

GdAuGe fs unfolding problem.pdf

Missing PROCAR* files gives different result

First of all, I want to mention that there is a bug in vasp6 about LKPROJ tag, which leads to the 'segment fault' error #6. Thus, some output files are not complete, including PROCAR & PROCAR.prim. So I made a post on vasp forum, https://www.vasp.at/forum/viewtopic.php?t=20281. They provide a solution there to recompile vasp. After recompiling vasp according to the admin's reply, all strange looking problems (jumps, weird fs) are gone.

Only calculations in section 2 were done after the bug is fixed. Previously, which is section 1 and 3 results, I need to delete PROCAR and PROCAR.prim to use the package, otherwise it would report error on them because PROCAR & PROCAR.prim just have header lines.

Slide 18-19 shows the effect of PROCAR* files. As can be seen there, missing PROCAR* files gives wrong result, with points appear outside the sampling region.

Use Cartesian coordinate

Slide 20-21 is the result of using Cartesian coordinate. This also gives correct result. I also tested by removing PROCAR* files there in slide 21, and it again gives wrong result with points merge along diagonal.

So overall, these two tests should show that the strange looking fs in section 3 above is due to missing PROCAR* files. Use Cartesian or usual reciprocal position doesn't matter. But the main issue that unfolding seems doesn't work is still there.

Best regards.

[DavidDirnberger]

Hi there,

thanks for the very thorough analysis! I haven’t had much time to dig deeply into this issue yet because I first want to finish the fix for Issue #17 . That bug might already account for part of what you’re seeing here. Still, I’d like to share a few observations:

Only PROCAR.prim and PRJCAR contain the data needed for unfolding.
The plain PROCAR file gives the folded band structure of the super‑cell. In contrast to PRJCAR, PROCAR.prim also carry orbital information (see the unfolding patch wiki and the official VASP PROCAR docs).

The spectral‑function routine runs mostly independently of the Fermiroots algorithm used in bands4vasp and in most cases produces a similar structure. That suggests the root cause may already lie in the original VASP calculation or in how the vasp files were prepared.

All of which brings me back to the beginning: a clean, fully fixed --pre- logic might resolve the whole chain of problems. I plan to push an update with that rewrite in the next few days.

Best,
David

[yujia-teng]

Hi David,
Thanks for your analysis. I will redo the fs unfolding once the --pre- logic is fixed and will post my new test result here.

My problem here is a little bit more complicated due to the lower magnetic symmetry. So it's a good idea to fully resolve issue #17 first.

Best regards.

[yujia-teng]

Hi David,
I redid the calculation of my system with new version v0.5 and would like to report the updates here.

In short, the whole procedure starting from --pre- till the end --fermi is fine, but the main problem that unfolding seems doesn't work is still there. And I think this problem is unrelated to the procedure. The more detailed explanation of the main problem I have is at the end of this section.

GdAuGe fs unfolding problem - v0.5.pdf

I attach my tested results here. To help reading, I bolded questions/problems I have below.

Slide 1-4 120° reciprocal lattice vector

Slide1 is the slide shown in previous file. In slide2, I redo the same sampling region with new version. So in new version, if the radius is different, looks like it would automatically convert to a sampling with same radius. I think it's a good feature. But the preview of sampling region for my hexagonal system isn't correct, because the axis is perpendicular, not hexagonal axis. So the preview region isn't the shaded part shown in my BZ. But anyway, this doesn't affect result and we can modify python script by ourselves.

Slide3 and 4 are comparison of results from 2 versions, and it's same.

Slide 5-7 60° reciprocal lattice vector

Slide 5 and 7 are comparing results from 2 versions, and it's same

In slide 6, I sampled same region in 2 cases, 120° and 60° reciprocal lattice vector, but the 120° case, points are missing. I don't understand why. INPAR is same for both cases.

Slide 8-10 221-cell

Because the unfolding seems doesn't work for 211-cell, I also did unfolding on 221-cell in slide 8. It's fermi surface and unfolded to primitive cell fs is shown. It's same as 211 unfolded result, so unfolding should work for 221-cell. But I still don't understand why it's still same as 211-cell fs.

Slide 9 shows the effect of missing PROCAR and PROCAR.prim files. I'm still not sure why missing orbital info gives wrong band.

Slide 10 shows unfolded band from 221-cell to primitive cell. I compared it with vaspkit unfolded result and it's same. So it should be correct. And it also looks match unfolded fs. This is more confusing.

Slide 11-12 Explanation of main problem

These two slides show why I think unfolding doesn't work correctly. Slide11 is about fs of NbSe2. From left to right, the figrues are fs of primitive and 211-cell, manually folded fs from primitive to 211-cell, and unfolded fs with v0.5 from 211-cell. So when unfolding works, the fs lines marked by red arrows in 3rd figure should be shifted away, rather than staying their in primitive cell fs.

However, in my system in slide 12, the unfolded fs looks same as 211-cell fs, with no fs lines shifted away. So in slide 12, top left is fs of 211-cell, and top right is manually unfolded fs of primitive cell. Bottom left is unfolded fs from b4vasp. Bottom middle is the 211-cell fs in sampling region. For bottom right, I overlap unfolded fs with 211-fs and they match very well, with no lines shifting away in unfolded fs. So I doubt unfolding doesn't work here.

Best regard.