[Pw_forum] Possible bugs in the electron-phonon calculation

Andrea Dal Corso dalcorso at sissa.it
Wed Nov 24 10:46:47 CET 2010


Dear Andreas,

Thank you very much for reporting this. 
Actually your point 2 is a real bug. ph_restart is not saving on file
and reading the modes when trans=.false. and elph=.true. as it should.
The fix is to change PH/ph_restart.f90 at lines 217, 804 and 862. These
three lines are now:

IF (trans.OR.zeu) THEN

instead they should be:

IF (trans.OR.zeu.OR.elph) THEN

With this change your example is now running on my PC.
I have corrected the cvs version.

HTH,

Andrea 


On Tue, 2010-11-23 at 18:51 +0100, Andreas Linscheid wrote:
> Hello everybody.
> 
> I want to implement a routine that writes out the el-ph matrix elements 
> (no summation!) in order to use it as an input for our SCDFT code. On my 
> way to doing so I think that I have found 2 bugs in the code. (I am 
> working with version 4.2.1 of quantum espresso)
> 
> 1) The first one is rather trivial (I hope ...)
> The Problem appears, if one adds the flags noinv=.true. and nosym=.true. 
> to the scf and scf.fit calculation of example 07. The code crashes with
> 
> "from lint : error #        10 cannot remap grid on k-point list"
> 
> I was able to cure the crashing by simply removing the check of |deltam| 
> < eps in elphon.f90, line 740 like this:
> 
> @@ -740,10 +740,7 @@ subroutine lint ( nsym, s, minus_q, at, bg, npk, 
> k1,k2,k3, &
>               end do
>               if ( sqrt ( deltap(1)**2 + &
>                           deltap(2)**2 + &
> -                       deltap(3)**2 ) < eps .or. ( minus_q .and. &
> -                sqrt ( deltam(1)**2 + &
> -                       deltam(2)**2 + &
> -                       deltam(3)**2 ) < eps ) ) then
> +                       deltap(3)**2 ) < eps ) then
>                  eqBZ(nk) = n
>                  sBZ(nk) = ns
>                  go to 15
> 
> The condition checks for each symmetry also the inversion and stops if 
> the k point matched. I think this is incorrect, as the inversions are 
> separate symmetry operations  that will be checked independently. If 
> then the code is forced by hand to use no symmetry, where there are 
> implicit symmetries not every point in the irreducible BZ is mapped and 
> the check at the end of the routine fails. Clearly this is not a regular 
> case ... (But it is in any case incorrect to store ns in sBZ(nk), where 
> one should store the inversion ns+nsymq/2 ... ;-))
> 
> 2) The second problem is more severe. The flag trans=.false. seems to be 
> not working any more.
> First I want to be a bit verbose why we actually need this.
> In our group, we extensively used trans since the k grid of the electron 
> phonon calculation needs to be converged independently from the k grid 
> for the phonon calculation. An interpolation (The way the elphsum 
> routine works right now) may not always work.
> I don't know whether there are plans to remove that feature from the 
> code in the next version, but I consider it a very useful tool.
> 
> The problem with trans appears if one splits the electron phonon 
> calculation of example 07 into two, (I have attached a slightly modified 
> run script of example 07 ) i.e. does a ph calculation with elph=.false 
> first and then an el-ph calculation with trans=.false and elph=.true.. 
> According to the manual this procedure should be still correct, isn't it?
> The code crashes with:
> 
> forrtl: severe (179): Cannot allocate array - overflow on array size 
> calculation.
> Image              PC                Routine            Line        Source
> ph.x               0000000000EC72B6  Unknown               Unknown  Unknown
> ph.x               0000000000EC64B6  Unknown               Unknown  Unknown
> ph.x               0000000000E4493A  Unknown               Unknown  Unknown
> ph.x               0000000000DF16F2  Unknown               Unknown  Unknown
> ph.x               0000000000E25CE9  Unknown               Unknown  Unknown
> ph.x               00000000004DB755  allocate_pert_             25 
> allocate_pert.f90
> ph.x               0000000000481B04  phq_setup_                324 
> phq_setup.f90
> ph.x               000000000046CDE2  initialize_ph_             55 
> initialize_ph.f90
> ph.x               0000000000452928  MAIN__                     97 
> phonon.f90
> ph.x               0000000000452762  Unknown               Unknown  Unknown
> libc.so.6          00002B387BC8C4CA  Unknown               Unknown  Unknown
> ph.x               00000000004526AA  Unknown               Unknown  Unknown
> 
> 
> I was unable to solve the problem but this how far I got, tracing the error:
>   > the crash is because npertx contains a random large integer when the 
> t array is allocated in allocate_pert.f90 line 25
>   > this is because npert(:) contains random numbers when in 
> init_representations.f90 line 97 npertx is computed
>   > I figured that npert does not get initialized in set_irr.f90 because 
> u_from_file is true (as it should be) and I think it should be read in 
> from the xml file in _ph*.phsave/data-file.xml.[iq] where the data is 
> stored.
>   > I tried to make the code read that file 'by hand', however this file 
> gets overwritten during the initialization of the phonon code and I 
> don't know exactly where.
> 
> I was unable to stop the code from overwriting the file 
> data-file.xml.[iq] and correctly reading the data.
> 
> As a workaround, I hacked the recover branch of the code in a dirty way 
> to make it do what I want. This means to restart with a different k grid 
> and compute el_ph_mat, then spit out the el-ph matrix elements in the 
> basis of the modes.
> However, I would rather work with the trans branch as it is much cleaner 
> and, according to the manual, intended exactly for such purpose.
> Then, if this is also of interest to other people, I can share this 
> version as I am not messing up all the other part of the code.
> 
> Thank you very much for your help!
> 
> Andreas Linscheid
> 
> PhD Student AG Gross --- Max-Planck-Institut für Mikrostrukturphysik
> Weinberg 2, 06120 Halle (Saale), Germany
> 
> 
> _______________________________________________
> Pw_forum mailing list
> Pw_forum at pwscf.org
> http://www.democritos.it/mailman/listinfo/pw_forum
-- 
Andrea Dal Corso                    Tel. 0039-040-3787428
SISSA, Via Bonomea 265              Fax. 0039-040-3787249
I-34136 Trieste (Italy)             e-mail: dalcorso at sissa.it




More information about the Pw_forum mailing list