[Q-e-developers] [Pw_forum] Test on the WF phase in QE
stefano de gironcoli
degironc at sissa.it
Sun Nov 1 21:39:16 CET 2015
On 01/11/2015 21:03, Samuel Poncé wrote:
> Dear Stefano,
>
> Thank you for you fast reply.
>
> Thank you for the suggestions. I will look into those routine to place
> a perturbation a lift the degeneracies.
>
> But before that, just to be sure.
> Would it make sense to compare the wavefunction if we look at a
> non-degenerate band. For example the first one in diamond is non
> degenerate throughout the BZ.
yes.
for a non degenerate band the difference in the two calculations should
be a global
(in general k-dependent) phase.
>
> Then, there is the degeneracy due to symmetries. The WF a one k-point
> could be any linear combination of the WF at the other k-points
> related by symmetry.
>
not really. each k point is solved separately.
the degeneracy creating problems is the one due to the small group of
the k-point under consideration.
It's true that if you were to make a calculation in a supercell and some
equivalent k-points
were to be folded in the same k-point of the sucercell (for instance the
3 X points of the fcc,
if you use 4 times larger simple cubic supercell) then yes the supercell
wavefunctions will be a mixture of all of them.
> Would it be possible to lift that degeneracy by removing the symm
> (nosym=.true. and noinv = .true.)?
> In that case I could compare the wf?
i don't think so.
the symmetry is in the Hamiltonian and the degeneracy would still be
present.
the nosym/noinv flags determine whether the code exploit these
symmetries to reduce the number of k-points to be computed but for a
given k-point the Hamiltonian, within numerical noise, should be the same.
>
> In passing, while looking into that, I found a bug PW/src/init_us_2.f90
>
> At the beginning of the routine the out variable vkb_ should be
> initialized
> vkb_(:, :) = (0.d0,0.d0)
>
> I had some NaN due to that and adding the zeroing solved it.
>
thanks for reporting.
I thought that having defined the variable INTENT(OUT) it should be
zeroed automatically
but probably it is not always like that. thanks.
best
stefano
> Best,
>
> Samuel
>
>
> On 31 October 2015 at 19:17, stefano de gironcoli <degironc at sissa.it
> <mailto:degironc at sissa.it>> wrote:
>
> 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 <mailto:Q-e-developers at qe-forge.org>
>> http://qe-forge.org/mailman/listinfo/q-e-developers
>
>
> _______________________________________________
> Q-e-developers mailing list
> Q-e-developers at qe-forge.org <mailto:Q-e-developers at qe-forge.org>
> http://qe-forge.org/mailman/listinfo/q-e-developers
>
>
>
>
> _______________________________________________
> 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/20151101/a7d64d45/attachment.html>
More information about the developers
mailing list