I've tested Andrea's suggestion now, and it fixes the bug in the classes of D_3h. The modification was
(quoting Andrea's email) In PW/src/divide_class_so.f90 at line 653 there is now: IF (nelem(iclass)>1) THEN > which_irr(iclass)=9 > ELSE > which_irr(iclass)=6 > END IF This test should be IF (nelem(iclass)>2) THEN > which_irr(iclass)=9 > ELSE > which_irr(iclass)=6 > END IF Best, -- Gerson J. Ferreira Prof. Dr. @ InFis - UFU ---------------------------------------------- gjferreira.wordpress.com Institute of Physics Federal University of Uberlândia, Brazil ---------------------------------------------- On Mon, Mar 7, 2022 at 9:57 AM Gerson J. Ferreira <[email protected]> wrote: > Easy answer first: I'm sorry for the formatted code. I've copy/pasted > directly from the VSCode and it went like this. It was not on purpose, just > a lack of attention to detail. > > Now regarding the irreps, notice that you are describing the characters of > the representations, and not the matrices. I agree that if all we want is > to identify the irreps that describe each band, it is sufficient to look at > the characters / trace, and that's what the sym_band.f90 routine already > does. > > These traces are invariant under unitary transformations (change of > basis), but the full matrix representation DΓ(S) for S in G is not. In > other words, let's call A a 2x2 matrix representation of the C3(z) > operator under a certain basis set {ψ0, ψ1}, which transforms as some > irrep Γ. If U is an unitary transformation that gives a new basis (within > the same subspace) denoted {ϕ1, ϕ2} = U ⋅ {ψ0, ψ1}, then under this new > basis the matrix representation of C3(z) becomes B = U.A.U†, which is > also a rep of the same irrep Γ, same traces. > > I need the full matrices DΓ(S), and not just the characters / trace, > because I need to make sure that numerical wave-functions from QE match the > representations I'll use later in a separate python code. Is it clear now? > So I'm editing this routine to get what I need. > > Regarding the bug, don't worry. One of the QE devs has already replied to > me. It is indeed a bug in the D_3h classes that was unnoticed because both > s_v and s_h classes have characters equal to zero in the double group, so > it does not affect the identification of the irreps. I'll try some > suggestions he sent me to fix this. > > But if you want to reproduce this, simply run bands.x for graphene (full > relativistic) or any other D_3h material and use the sym_band.f90 file > attached here. But notice that in this code I'm printing a bunch of stuff > to stdout for testing purposes. The relevant section for this bug is > between lines 870--876. > > Best, > -- > Gerson J. Ferreira > Prof. Dr. @ InFis - UFU > ---------------------------------------------- > gjferreira.wordpress.com > Institute of Physics > Federal University of Uberlândia, Brazil > ---------------------------------------------- > > > On Mon, Mar 7, 2022 at 12:14 AM Hongyi Zhao <[email protected]> wrote: > >> On Mon, Mar 7, 2022 at 10:00 AM Gerson J. Ferreira >> <[email protected]> wrote: >> > >> > Thanks for the answer and the links. But if I understand correctly, >> these codes only give us the irreps, and I need the specific representation >> matrices calculated from the QE wave-functions. The best way to get these >> seem to be editing this routine. >> >> Let us discuss this in more detail. An irreps is short for irreducible >> representation [1], which is a component of a character table [2]: a >> two-dimensional table whose rows correspond to irreducible >> representations. The specific representation matrices calculated from >> the QE wave-functions should also can be derived from the character >> table. >> >> So, I still don't quite understand what you mean above. Any more >> hints/explanations/comments will be greatly appreciated. >> >> [1] https://en.wikipedia.org/wiki/Irreducible_representation >> [2] https://en.wikipedia.org/wiki/Character_table >> >> > I've found my mistake, and a bug (I'll report for the developers as >> well). My mistake was that I was not using the "which_irr_so(iclass)" to >> identify the class. I was assuming that "iclass" would already list the >> classes in the correct order. >> > >> > Now, the bug is that "which_ir_so" is returning the class 9 two times >> here, but one of these should be 6 instead. This can be checked with the >> following code >> > >> > PRINT *, "======================================================" >> > PRINT *, "which_ir_so:", (which_irr_so(iclass), iclass=1, nclass) >> > PRINT *, "classes:", (name_class_so(iclass), iclass=1, nclass) >> > DO irap=1,nrap >> > PRINT *, ">>", (char_mat_so(irap, which_irr_so(iclass)), iclass=1, >> nclass) >> > ENDDO >> > PRINT *, "======================================================" >> >> I want to know how you can make the above code display black >> background color in this email. >> >> > Which prints >> > >> > which_ir_so(iclass): 1 5 3 9 >> 9 7 2 4 8 >> > classes: E -E 2C3 -2C3 3C2' s_h 2S3 -2S3 3s_v >> > >> > So, the classes are ordered as {E, 3C2', 2C3, 3s_v, 3s_v, 2S3, -E, >> -2C3, -2S3} >> > >> > Notice that 3s_v appears twice, and s_h does not appear in the list. >> >> What's your patched code? Could you please show the detailed steps to >> reproduce the above example? >> >> Best, >> Hongyi >> >>
_______________________________________________ The Quantum ESPRESSO community stands by the Ukrainian people and expresses its concerns about the devastating effects that the Russian military offensive has on their country and on the free and peaceful scientific, cultural, and economic cooperation amongst peoples _______________________________________________ Quantum ESPRESSO is supported by MaX (www.max-centre.eu) users mailing list [email protected] https://lists.quantum-espresso.org/mailman/listinfo/users
