Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error in symetries from dmftproj #148

Open
johanjoensson opened this issue Sep 18, 2020 · 3 comments
Open

Error in symetries from dmftproj #148

johanjoensson opened this issue Sep 18, 2020 · 3 comments
Assignees
Labels

Comments

@johanjoensson
Copy link

When doing a calculation with Wien2k 18.2 with spin polarization and spin-orbit coupling, the symmetries generated by dmftproj are not correct.

We performed Wien2k calculations with the full BZ ("x kgen -fbz"), in order to get quantities that are already symmetric.
In python we read in the Wien2k data and when calculating lhe local Hamiltonian and the density matrix we printed the matrix and its eigenvalues before and after symmetrisation. Since the matrix is already symmetrised from us using the full BZ the symmetrisation should not change it at all. However we found that the eigenvalues were different before and after symmetrisation.

The error seems to be the sign of the "ephase factor" when the symmetries are calculated, in outputqmc.f for instance. Just reversing the sign of the variable "factor" seems to have solved the issue for cubic symmetries, but we might just have been lucky.

This is a git diff showing the changes (adding the '-'-signs) we made:

diff --git a/fortran/dmftproj/outputqmc.f b/fortran/dmftproj/outputqmc.f
index f0df75d..0122da3 100644
--- a/fortran/dmftproj/outputqmc.f
+++ b/fortran/dmftproj/outputqmc.f
@@ -755,7 +755,7 @@ C
                factor=srot(isym)%phase/2.d0
 C We remind that the field phase is (g-a) in this case.
 C Up/up block :
-               ephase=EXP(CMPLX(0.d0,factor))
+               ephase=EXP(CMPLX(0.d0,-factor))
 C As a result, ephase = -exp(i(alpha-gamma)/2)
                spinrot(1:2*l+1,1:2*l+1)=
      =           ephase*srot(isym)%rotrep(l,isrt)%mat(-l:l,-l:l)
@@ -771,7 +771,7 @@ C
                factor=srot(isym)%phase/2.d0
 C We remind that the field phase is (a+g) in this case.
 C Up/up block :
-               ephase=EXP(CMPLX(0.d0,factor))
+               ephase=EXP(CMPLX(0.d0,-factor))
 C As a result, ephase = -exp(-i(alpha+gamma)/2)
                spinrot(1:2*l+1,1:2*l+1)=
      =           ephase*srot(isym)%rotrep(l,isrt)%mat(-l:l,-l:l)
@@ -1302,7 +1302,7 @@ C
                factor=srot(isym)%phase/2.d0
 C We remind that the field phase is (g-a) in this case.
 C Up/up block :
-               ephase=EXP(CMPLX(0.d0,factor))
+               ephase=EXP(CMPLX(0.d0,-factor))
 C AS a result, ephase = -exp(i(alpha-gamma)/2)
                spinrot(1:2*l+1,1:2*l+1)=
      =           ephase*srot(isym)%rotrep(l,isrt)%mat(-l:l,-l:l)
@@ -1318,7 +1318,7 @@ C
                factor=srot(isym)%phase/2.d0
 C We remind that the field phase is 2pi-(alpha+gamma) in this case.
 C Up/up block :
-               ephase=EXP(CMPLX(0.d0,factor))
+               ephase=EXP(CMPLX(0.d0,-factor))
 C As a result, ephase = -exp(-i(alpha+gamma)/2)
                spinrot(1:2*l+1,1:2*l+1)=
      =           ephase*srot(isym)%rotrep(l,isrt)%mat(-l:l,-l:l)

This fix does nothing for the case when the user supplies their own (non-spin-diagonal) basis transformation (using the "fromfile" option in case.indmftpr).

This issue is present both in the py2_compat release, and the 3.0.0 release.

70akaline added a commit to 70akaline/dft_tools that referenced this issue Nov 28, 2020
Follow the suggestion from TRIQS#148
@hschnait
Copy link
Contributor

hschnait commented Nov 9, 2021

Thank you SO MUCH for pointing this out!
I'm currently searching for a bug that breaks some SOC+SP calculations of mine, and at first glance these minus-signs seem to fix it. I'll take a look into the derivation of the formalus to see if I can find the source of this error.

And sorry for the late response, but I guess no one here wants to touch this old fortran code... :)
However, this might have huge implications on calculations including SOC, so I'll guess I have to bite the bullet.

@hschnait hschnait self-assigned this Nov 9, 2021
@the-hampel
Copy link
Member

the-hampel commented Feb 10, 2023

Hi,
I know this issue is quite old, but I guess this has not been fixed yet. Since a solution has been proposed, I wanted to ask if we can simply fix this by making the suggested changes to the dmftproj program? @aichhorn do you know if someone already tested this? Thanks!

Best,
Alex

@aichhorn
Copy link
Member

Hi,
I dont know what the status of this is, but I check with Hermann what he thinks. I did not test this myself.

Best,
Markus

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

4 participants