[QE-users] symmetry traces in sym_band.f90

Mon Mar 7 14:10:03 CET 2022

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 <gersonjferreira at ufu.br>
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 <hongyi.zhao at gmail.com> wrote:
>
>> On Mon, Mar 7, 2022 at 10:00 AM Gerson J. Ferreira
>> <gersonjferreira at ufu.br> 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
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quantum-espresso.org/pipermail/users/attachments/20220307/91ca309a/attachment.html>