[Q-e-developers] [Pw_forum] Test on the WF phase in QE

stefano de gironcoli degironc at sissa.it
Sat Oct 31 20:17:03 CET 2015


On 31/10/2015 19:45, Samuel Poncé wrote:
> Dear all,
>
> I would like to present the following test:
> 1) Diamond with the normal 48 sym (incl frac translation)
>
> VS
>
> 2) Diamond where the code is tricked into having two different type of 
> atom with two psp (24 sym & no frac translation). The two psp are the 
> same with a different name.
>
> The input files are join to this email (first I do a scf calc followed 
> by a nscf calc where I put by hand all the kpoints).
>
> The two case should in theory give exactly the same physical observable.
wavefunctions are not physical observables.

random global phases appear due to numerical noise, random non-global 
phases appear among degenerate wavefunctions.

my suggestion is to formulate your problem in a gauge invariant way...
which should be the only thing that make sense physically.

If you insist in attaching a meaning to a specific wavefunction you 
should use a guiding function to fix the phases and break the tie caused 
by degeneracy.

I think you could use some concepts developed to align wfcs in 
neighboring points in Wannier functions construction (either in the 
Wannier90 code or in the PP/src/poormanwannier.f90 tool) and/or in the 
band-tracking bit coded in  PP/src/bands.f90

stefano

>
> However, when I print the ground state WF summed on G-vectors and 
> bands for each k-points: SUM(evc(:,:)) where the evc dim are 
> evc(npw,nbnd).
> I get for the first case:
>  ik            1
>  SUM(evc) (0.524554603771020,-0.985842296616562)
>  ik            2
>  SUM(evc) (-0.210256090577016,0.545845252785036)
>  ik            3
>  SUM(evc) (-0.239028680198133,-1.83612435123587)
>  ik            4
>  SUM(evc) (-0.565218210001339,-0.820699742516653)
>  ik            5
>  SUM(evc) (1.42454745428565,-0.957929628317023)
>  ik            6
>  SUM(evc) (-0.274745448323905,1.09643888529245)
>  ik            7
>  SUM(evc) (-0.933074272062335,1.16077508535444)
>  ik            8
>  SUM(evc) (0.989923346231570,-1.58533060259471)
>  ik            9
>  SUM(evc) (-1.26782798392043,-0.150960156635521)
>  ik           10
>  SUM(evc) (-0.401891345164427,1.27585476000084)
> .......
> For the second case
>  ik            1
>  SUM(evc) (0.116807098229033,-1.11058471838606)
>  ik            2
>  SUM(evc) (-0.215236454279303,0.546415812538992)
>  ik            3
>  SUM(evc) (-0.239955952913802,-1.83623414069791)
>  ik            4
>  SUM(evc) (-0.566091061918831,-0.820097940655045)
>  ik            5
>  SUM(evc) (1.42304578433157,-0.960163474240552)
>  ik            6
>  SUM(evc) (-0.281026989151429,1.09416630115645)
>  ik            7
>  SUM(evc) (-0.933137702445232,1.16063633276210)
>  ik            8
>  SUM(evc) (0.989188453055074,-1.58571465239844)
>  ik            9
>  SUM(evc) (-1.26782806755424,-0.150960132814025)
>  ik           10
>  SUM(evc) (-0.401891332187340,1.27585476604143)
>
> You can see that their norm is well the same but for some k-point the 
> phase is exactly the same whereas for other k-point the phase is 
> strongly different.
> I must also add that the values that are different cannot be found at 
> other k-point in the other example. It is therefore not a problem of 
> k-ordering.
>
> This lead to a problem for me because I try to look at
> <\Psi_k+q| might be something here or not |\psi_k>.
>
> Therefore if the k are the same but the k+q point happen to have a 
> phase difference, such phase does not cancels out.
>
> Is there a way to impose to have the same phase for the two case or a 
> maximum have a global phase that does not depend on the k-point?
>
> Best Regards,
>
> Samuel Ponce
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> Q-e-developers mailing list
> Q-e-developers at qe-forge.org
> http://qe-forge.org/mailman/listinfo/q-e-developers

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quantum-espresso.org/pipermail/developers/attachments/20151031/cf5a284c/attachment.html>


More information about the developers mailing list