<div dir="ltr"><div><div><div>Dear Paolo, <br><br></div>Thank you for the quick reply and suggestions. <br></div>I've try them. I'm quite confuse by the results:<br><br>1) replace only set_irr.f90 and random_matrix.f90 with the previous versions<br>elphmat(:,:,:)**2 0.1192375<br>elphmat(:,:,:)**2 0.9861288<br>elphmat(:,:,:)**2 1.354492<br>elphmat(:,:,:)**2 0.3075966<br><br></div>We get the old behaviour. Therefore only changing those two routines solves it ... but:<br><div><br>2 ) remove the "arg = randy(0)" line<br><br>elphmat(:,:,:)**2 0.1192376<br>elphmat(:,:,:)**2 0.9861288<br>elphmat(:,:,:)**2 1.419427<br>elphmat(:,:,:)**2 0.2426619<br><br>3)in set_irr.f90<br>arg = randy(987654321)<br><br>elphmat(:,:,:)**2 0.1192376<br>elphmat(:,:,:)**2 0.9861287<br>elphmat(:,:,:)**2 1.522261<br>elphmat(:,:,:)**2 0.1398291<br><br>4 ) in set_irr.f90<br>call set_rndm_seed(1)<br>but keep randy in random_matrix.f90<br><br>elphmat(:,:,:)**2 0.1192375<br>elphmat(:,:,:)**2 0.9861287<br>elphmat(:,:,:)**2 1.419427<br>elphmat(:,:,:)**2 0.2426619<br><br></div><div>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...). <br><br></div><div>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.<br><div><div><div><br></div><div>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. <br></div><div><br> ( 16q-points):<br> N xq(1) xq(2) xq(3)<br> 1 0.000000000 0.000000000 0.000000000<br> 2 -0.166666667 0.166666667 -0.166666667<br> 3 -0.333333333 0.333333333 -0.333333333<br> 4 0.500000000 -0.500000000 0.500000000<br> 5 0.000000000 0.333333333 0.000000000<br> 6 -0.166666667 0.500000000 -0.166666667<br> 7 0.666666667 -0.333333333 0.666666667<br> 8 0.500000000 -0.166666667 0.500000000<br> 9 0.333333333 0.000000000 0.333333333<br> 10 0.000000000 0.666666667 0.000000000<br> 11 0.833333333 -0.166666667 0.833333333<br> 12 0.666666667 -0.000000000 0.666666667<br> 13 0.000000000 -1.000000000 0.000000000<br> 14 0.666666667 -0.333333333 1.000000000<br> 15 0.500000000 -0.166666667 0.833333333<br> 16 -0.333333333 -1.000000000 0.000000000<br><br></div><div>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 <br></div><div>one is the physically correct result. Do you have an idea on how to test that?<br><br></div><div>PS: I registered to the <a href="mailto:q-e-developers@qe-forge.org">q-e-developers@qe-forge.org</a> mailing list.<br><br></div><div>Thank you, <br><br></div><div>Samuel Ponce<br></div><div><br></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-06-29 17:49 GMT+01:00 Paolo Giannozzi <span dir="ltr"><<a href="mailto:paolo.giannozzi@uniud.it" target="_blank">paolo.giannozzi@uniud.it</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Dear Samuel<div class="gmail_extra"><div class="gmail_quote"><div> <br></div><div>sure I remember you, I noticed your efforts on the phonon code and I was suspecting that you were working on EPW. <br></div><div>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.<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>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 [...] <br></div></div></div></blockquote><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>the problematic revision seems to be the 5272 that seems to have been committed by you:<br>r5272 | giannozz | 2008-11-05 20:25:20 +0000 (Wed, 05 Nov 2008) | 4 lines<br>Only one random number generator is used everywhere ("randy", which seems to be the most uniform). Beware all kinds of unexpected side effects <br></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div><br></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div>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. <br><br></div><div>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)?<br></div></div></div></blockquote><div><br></div></span><div>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.<br><br></div><div>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):</div><div>- 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)<br>If so, please try the following:<br></div><div>- remove the "arg = randy(0)" line</div><div>- change "0" in "arg = randy(0)" to some weird number, 987654321 or something like this<br></div><div>- replace "arg = randy(0)" with "call set_random_seed ( )" which should set a really random number.<br></div><div>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 ... ).<br><br></div><div>I am sending a copy of this message to <a href="mailto:q-e-developers@qe-forge.org" target="_blank">q-e-developers@qe-forge.org</a> as well because that is the place where this kind of questions should be discussed. Best regards<span class="HOEnZb"><font color="#888888"><br><br></font></span></div><span class="HOEnZb"><font color="#888888"><div>Paolo<br><br></div></font></span></div><span class="HOEnZb"><font color="#888888">-- <br><div><div dir="ltr"><div><div dir="ltr"><span><font color="#888888">Paolo Giannozzi, Dept. Chemistry&Physics&Environment,<br>
Univ. Udine, via delle Scienze 208, 33100 Udine, Italy<br>Phone <a href="tel:%2B39-0432-558216" value="+390432558216" target="_blank">+39-0432-558216</a>, fax <a href="tel:%2B39-0432-558222" value="+390432558222" target="_blank">+39-0432-558222</a><br>
</font></span></div></div></div></div>
</font></span></div></div>
</blockquote></div><br></div>