[Q-e-developers] Integration of EPW into QE 5
Samuel Poncé
samuel.pon at gmail.com
Mon Jun 29 20:34:22 CEST 2015
Dear Paolo,
Thank you for the quick reply and suggestions.
I've try them. I'm quite confuse by the results:
1) replace only set_irr.f90 and random_matrix.f90 with the previous versions
elphmat(:,:,:)**2 0.1192375
elphmat(:,:,:)**2 0.9861288
elphmat(:,:,:)**2 1.354492
elphmat(:,:,:)**2 0.3075966
We get the old behaviour. Therefore only changing those two routines solves
it ... but:
2 ) remove the "arg = randy(0)" line
elphmat(:,:,:)**2 0.1192376
elphmat(:,:,:)**2 0.9861288
elphmat(:,:,:)**2 1.419427
elphmat(:,:,:)**2 0.2426619
3)in set_irr.f90
arg = randy(987654321)
elphmat(:,:,:)**2 0.1192376
elphmat(:,:,:)**2 0.9861287
elphmat(:,:,:)**2 1.522261
elphmat(:,:,:)**2 0.1398291
4 ) in set_irr.f90
call set_rndm_seed(1)
but keep randy in random_matrix.f90
elphmat(:,:,:)**2 0.1192375
elphmat(:,:,:)**2 0.9861287
elphmat(:,:,:)**2 1.419427
elphmat(:,:,:)**2 0.2426619
As you can see the last two elements only are affected. Actually the two
first one corresponds to irreducible modes that are non-degenerate and the
two last one are irreducible with two degenerate modes (the sum of the
degenerate mode should be fine though...).
In diamond we have 6 modes, the two first are non degenerate (and fine for
all q-points) and the two lasts are doubly degenerate for this q-point and
change with the random routine.
Moreover, ONLY the irr. q-points 5, 10 and 16 (from the table below) are
affected. This is quite weird as other q-points also have doubly degenerate
modes.
( 16q-points):
N xq(1) xq(2) xq(3)
1 0.000000000 0.000000000 0.000000000
2 -0.166666667 0.166666667 -0.166666667
3 -0.333333333 0.333333333 -0.333333333
4 0.500000000 -0.500000000 0.500000000
5 0.000000000 0.333333333 0.000000000
6 -0.166666667 0.500000000 -0.166666667
7 0.666666667 -0.333333333 0.666666667
8 0.500000000 -0.166666667 0.500000000
9 0.333333333 0.000000000 0.333333333
10 0.000000000 0.666666667 0.000000000
11 0.833333333 -0.166666667 0.833333333
12 0.666666667 -0.000000000 0.666666667
13 0.000000000 -1.000000000 0.000000000
14 0.666666667 -0.333333333 1.000000000
15 0.500000000 -0.166666667 0.833333333
16 -0.333333333 -1.000000000 0.000000000
In conclusion, I can commit the required changes to QE (I do not have a
developer branch though) by modification of set_irr and dynamical_matrix to
get the old behaviour back but I have no idea which
one is the physically correct result. Do you have an idea on how to test
that?
PS: I registered to the q-e-developers at qe-forge.org mailing list.
Thank you,
Samuel Ponce
2015-06-29 17:49 GMT+01:00 Paolo Giannozzi <paolo.giannozzi at uniud.it>:
> Dear Samuel
>
> sure I remember you, I noticed your efforts on the phonon code and I was
> suspecting that you were working on EPW.
> Happy to see that you made some serious progress. I also tried some time
> ago to re-align EPW to the svn version, but I quickly realized that it
> required more time and effort than I could afford.
>
> While making the port, I realized that the Eliashberg lambda were very
>> different between the two code (more than 25% difference). I tracked the
>> problem down to the electron-phonon matrix element computed with QE [...]
>>
> the problematic revision seems to be the 5272 that seems to have been
>> committed by you:
>> r5272 | giannozz | 2008-11-05 20:25:20 +0000 (Wed, 05 Nov 2008) | 4 lines
>> Only one random number generator is used everywhere ("randy", which seems
>> to be the most uniform). Beware all kinds of unexpected side effects
>>
>
>> Therefore the problem seems to be related with the use of 'randy'. This
>> should in theory not affect any physical quantity like the electron-phonon
>> matrix element squared but it does.
>>
>> Do you think it is a bug or that a bug was solved by using randy ? What
>> should be the physically correct quantity (before or after revision 5272)?
>>
>
> short answer: i don't know (I cannot see any good reason why
> electron-phonon coefficients should be affected while phonons aren't), but
> it is easier to add a bug without noticing than to remove a bug without
> noticing.
>
> As far as I know both randy and rndm should do the job, since "the job"
> shouldn't be very critical in terms of randomness: fill a random matrix or
> something like this, to be diagonalized to produce the irreps or something
> like that. My suggestion is to try the following (no, I am not going to
> try, because I haven't access to any serious machine right now and I have a
> number of things to do that I cannot postpone, although most of them are
> way less amusing than finding a bug):
> - replace only set_irr.f90 and random_matrix.f90 with the previous
> versions (you will need to put somewhere the previous random-number
> routines as well), just to verify if that is the origin of the discrepancy
> (I cannot see other reasons)
> If so, please try the following:
> - remove the "arg = randy(0)" line
> - change "0" in "arg = randy(0)" to some weird number, 987654321 or
> something like this
> - replace "arg = randy(0)" with "call set_random_seed ( )" which should
> set a really random number.
> I don't know if it is really needed to have the "arg = randy(0)" line (or
> equivalent initialization) in the "set_irr.f90" file (or in any other file)
> instead of having it inside "random_matrix.f90". Please check if these
> routines are called more than once, and if so, if they are supposed to
> produce the same irreps: I vaguely remember that in order to perform some
> calculations one has to save irreps to file because there is no guarantee
> to have exactly the same numbers in subsequent runs (a common problem of
> nondeterministic algorithms ... ).
>
> I am sending a copy of this message to q-e-developers at qe-forge.org as
> well because that is the place where this kind of questions should be
> discussed. Best regards
>
> Paolo
>
> --
> Paolo Giannozzi, Dept. Chemistry&Physics&Environment,
> Univ. Udine, via delle Scienze 208, 33100 Udine, Italy
> Phone +39-0432-558216, fax +39-0432-558222
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.quantum-espresso.org/pipermail/developers/attachments/20150629/c0c028b5/attachment.html>
More information about the developers
mailing list