Bug in graphene. Works for K but not for K'?

[gersonjferreira]

We are doing some test here, and the spacegroup.get_irreps_from_table(...) routine only works for the K point in graphene, and not for the K'. I understand this is because the tables only have K and not K'.

RuntimeError: the kpoint [ 0.66666667 -0.33333333  0.        ] does not correspond to the point K ([0.333 0.333 0.   ] in refUC [0.33333 0.33333 0.     ] in primUC) in the table

The unusual kpoint [2/3, -1/3] above occurs when we use Quantum Espresso with k-path as

K_POINTS tpiba_b
3
gG 30
K  30
M   1

To fix this, we can set refUC = -np.eye(3), which basically flips everything: K becomes K' and vice-versa.

However, I wonder if it would be possible to include K' in the character tables to simplify this. Similarly, it would be helpful to have all (nearly equivalent) high-symmetry points in the tables. For instance, still on graphene, those would be M, M' and M'' instead of just M. And so on...

[MIraola]

Dear Gerson,

thank you for your message. As you pointed out, the routine does not work for the K’ point because the tables distributed with the code don’t contain this point.

Nevertheless, it is possible to use the code to help the identification of irreps at K’. For that, it should be called without specifying —kpnames. This way, IrRep will calculate the traces of symmetry operations at K’, which can be used to identify the irreducible representations there. Moreover, notice that the little group of K’ is identical to the little group of K, so the irreducible representations are also identical for both k-points. Therefore, you can use the irreps of K to identify those at K based on the traces of symmetries.

I hope this text helps you with your task. Otherwise, don’t hesitate to write back, please.

Best regards, Mikel I.

On 17 Jul 2023, at 21:18, Gerson J. Ferreira @.***> wrote:

We are doing some test here, and the spacegroup.get_irreps_from_table(...) routine only works for the K point in graphene, and not for the K'. I understand this is because the tables only have K and not K'.

RuntimeError: the kpoint [ 0.66666667 -0.33333333 0. ] does not correspond to the point K ([0.333 0.333 0. ] in refUC [0.33333 0.33333 0. ] in primUC) in the table Is it possible to circumvent this without changing the tables?

This is relevant because there are many approaches to list the k points in Quantum Espresso. For instance, option 1 below gives a K point compatible with the irepp package, for for option 2, the tpiba_b K label actually points to K' point [2/3, -1/3, 0].

Option 1:

K_POINTS crystal_b 3 +0.0000000000 0.000000000 0.000000000 30 ! G +0.3333333333 0.333333333 0.000000000 30 ! K +0.0000000000 0.500000000 0.000000000 30 ! M

Option 2:

K_POINTS tpiba_b 3 gG 30 K 30 M 1

— Reply to this email directly, view it on GitHub https://github.com/stepan-tsirkin/irrep/issues/63, or unsubscribe https://github.com/notifications/unsubscribe-auth/AJUEUPG22DVL6G25RQTGRXLXQWFZ7ANCNFSM6AAAAAA2NL5FBE. You are receiving this because you are subscribed to this thread.

[gersonjferreira]

Dear Mikel,

I had updated the issue and I think you replied to the original content. But overall idea is the same.

I understand that I can omit the kpnames option and it works. But I would like to use the kpnames to have the irrep names identified as (-K7)(-K9) and so on...

I have a suggestion that might work. I'll test in my code first, then I'll show it here. For now, a quick description:

For any space group, I understand that the "missing" kpnames are related to the existing ones by some group operation. For instance, in graphene we get K' from K by inversion. Consequently, the issue is fixed if I use refUC = -np.eye(3).

So, instead of returning the RuntimeError: the kpoint... above, the code could loop over the space group symmetries to search for the refUC matrix that would transform the incorrect k point into the desired kpname properly. Then, the RuntimeError could include the suggested refUC, such that the user could run again with the fixed refUC.

[gersonjferreira]

The code in the PR above is working fine here.

I'm using/testing something similar in my code, check the dev branch, file pydft2kp/irrepwrapper.py, on the __init__(...) method of the irrep class, lines 172 -- 208.

https://gitlab.com/dft2kp/dft2kp/-/blob/dev/pydft2kp/irrepwrapper.py

In this PR I'm simply suggesting to add refUC and shiftUC candidates to the RuntimeError message so it does not break anything in the workflow.

In my code I actually try to detect the issue, search for the refUC/shiftUC, and restart the BandStructure object automatically.