<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 01/11/2015 21:03, Samuel Poncé
wrote:<br>
</div>
<blockquote
cite="mid:CAESzT+6ktfqumNngUeFiMQnSbFicuLURtTd2nzkYcZuv1EjqoQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>Dear Stefano, <br>
<br>
</div>
Thank you for you fast reply. <br>
<br>
</div>
Thank you for the suggestions. I will look
into those routine to place a perturbation a
lift the degeneracies. <br>
<br>
</div>
But before that, just to be sure. <br>
</div>
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. <br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
yes.<br>
for a non degenerate band the difference in the two calculations
should be a global <br>
(in general k-dependent) phase.<br>
<br>
<blockquote
cite="mid:CAESzT+6ktfqumNngUeFiMQnSbFicuLURtTd2nzkYcZuv1EjqoQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div><br>
</div>
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. <br>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
not really. each k point is solved separately.<br>
the degeneracy creating problems is the one due to the small group
of the k-point under consideration.<br>
It's true that if you were to make a calculation in a supercell and
some equivalent k-points<br>
were to be folded in the same k-point of the sucercell (for instance
the 3 X points of the fcc,<br>
if you use 4 times larger simple cubic supercell) then yes the
supercell wavefunctions will be a mixture of all of them.<br>
<br>
<blockquote
cite="mid:CAESzT+6ktfqumNngUeFiMQnSbFicuLURtTd2nzkYcZuv1EjqoQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>Would it be possible to lift that degeneracy by
removing the symm (nosym=.true. and noinv = .true.)?
<br>
</div>
In that case I could compare the wf?<br>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
<br>
i don't think so.<br>
the symmetry is in the Hamiltonian and the degeneracy would still be
present.<br>
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.<br>
<br>
<blockquote
cite="mid:CAESzT+6ktfqumNngUeFiMQnSbFicuLURtTd2nzkYcZuv1EjqoQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div><br>
</div>
In passing, while looking into that, I found a bug
PW/src/init_us_2.f90<br>
<br>
</div>
At the beginning of the routine the out variable vkb_
should be initialized<br>
vkb_(:, :) = (0.d0,0.d0)<br>
<br>
</div>
I had some NaN due to that and adding the zeroing solved it.
<br>
<br>
</div>
</div>
</div>
</blockquote>
thanks for reporting. <br>
I thought that having defined the variable INTENT(OUT) it should be
zeroed automatically<br>
but probably it is not always like that. thanks.<br>
<br>
best<br>
<br>
stefano<br>
<br>
<blockquote
cite="mid:CAESzT+6ktfqumNngUeFiMQnSbFicuLURtTd2nzkYcZuv1EjqoQ@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>Best, <br>
<br>
</div>
Samuel
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div><br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 31 October 2015 at 19:17, stefano de
gironcoli <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:degironc@sissa.it" target="_blank">degironc@sissa.it</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"><span class="">
<div>On 31/10/2015 19:45, Samuel Poncé wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>Dear all, <br>
<br>
</div>
I would like to
present the
following test:<br>
</div>
1) Diamond with the
normal 48 sym (incl
frac translation)<br>
<br>
</div>
VS<br>
<br>
</div>
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. <br>
<br>
</div>
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). <br>
<br>
</div>
The two case should in theory
give exactly the same physical
observable. <br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</span> wavefunctions are not physical observables.<br>
<br>
random global phases appear due to numerical noise, random
non-global phases appear among degenerate wavefunctions.<br>
<br>
my suggestion is to formulate your problem in a gauge
invariant way... <br>
which should be the only thing that make sense physically.<br>
<br>
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.<br>
<br>
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<br>
<br>
stefano <br>
<br>
<blockquote type="cite">
<div>
<div class="h5">
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div>
<div><br>
</div>
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).<br>
</div>
I get for the first case:<br>
ik 1<br>
SUM(evc)
(0.524554603771020,-0.985842296616562)<br>
ik 2<br>
SUM(evc)
(-0.210256090577016,0.545845252785036)<br>
ik 3<br>
SUM(evc)
(-0.239028680198133,-1.83612435123587)<br>
ik 4<br>
SUM(evc)
(-0.565218210001339,-0.820699742516653)<br>
ik 5<br>
SUM(evc)
(1.42454745428565,-0.957929628317023)<br>
ik 6<br>
SUM(evc)
(-0.274745448323905,1.09643888529245)<br>
ik 7<br>
SUM(evc)
(-0.933074272062335,1.16077508535444)<br>
ik 8<br>
SUM(evc)
(0.989923346231570,-1.58533060259471)<br>
ik 9<br>
SUM(evc)
(-1.26782798392043,-0.150960156635521)<br>
ik 10<br>
SUM(evc)
(-0.401891345164427,1.27585476000084)<br>
.......<br>
</div>
For the second case<br>
ik 1<br>
SUM(evc)
(0.116807098229033,-1.11058471838606)<br>
ik 2<br>
SUM(evc)
(-0.215236454279303,0.546415812538992)<br>
ik 3<br>
SUM(evc)
(-0.239955952913802,-1.83623414069791)<br>
ik 4<br>
SUM(evc)
(-0.566091061918831,-0.820097940655045)<br>
ik 5<br>
SUM(evc)
(1.42304578433157,-0.960163474240552)<br>
ik 6<br>
SUM(evc)
(-0.281026989151429,1.09416630115645)<br>
ik 7<br>
SUM(evc)
(-0.933137702445232,1.16063633276210)<br>
ik 8<br>
SUM(evc)
(0.989188453055074,-1.58571465239844)<br>
ik 9<br>
SUM(evc)
(-1.26782806755424,-0.150960132814025)<br>
ik 10<br>
SUM(evc)
(-0.401891332187340,1.27585476604143)<br>
<br>
</div>
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. <br>
</div>
<div>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. <br>
</div>
<div><br>
</div>
This lead to a problem for me because
I try to look at <br>
</div>
<\Psi_k+q| might be something here or
not |\psi_k>. <br>
<br>
</div>
Therefore if the k are the same but the
k+q point happen to have a phase
difference, such phase does not cancels
out. <br>
<br>
</div>
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?<br>
<br>
</div>
Best Regards, <br>
<br>
</div>
Samuel Ponce<br>
</div>
<div>
<div>
<div>
<div>
<div><br>
<br>
<br>
<div>
<div>
<div>
<div>
<div>
<div><br>
<div>
<div><br>
<br>
<div>
<div><br>
<br>
<br>
<br>
<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset></fieldset>
<br>
</div>
</div>
<pre>_______________________________________________
Q-e-developers mailing list
<a moz-do-not-send="true" href="mailto:Q-e-developers@qe-forge.org" target="_blank">Q-e-developers@qe-forge.org</a>
<a moz-do-not-send="true" href="http://qe-forge.org/mailman/listinfo/q-e-developers" target="_blank">http://qe-forge.org/mailman/listinfo/q-e-developers</a>
</pre>
</blockquote>
<br>
</div>
<br>
_______________________________________________<br>
Q-e-developers mailing list<br>
<a moz-do-not-send="true"
href="mailto:Q-e-developers@qe-forge.org">Q-e-developers@qe-forge.org</a><br>
<a moz-do-not-send="true"
href="http://qe-forge.org/mailman/listinfo/q-e-developers"
rel="noreferrer" target="_blank">http://qe-forge.org/mailman/listinfo/q-e-developers</a><br>
<br>
</blockquote>
</div>
<br>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Q-e-developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Q-e-developers@qe-forge.org">Q-e-developers@qe-forge.org</a>
<a class="moz-txt-link-freetext" href="http://qe-forge.org/mailman/listinfo/q-e-developers">http://qe-forge.org/mailman/listinfo/q-e-developers</a>
</pre>
</blockquote>
<br>
</body>
</html>