[Pw_forum] Possible bugs in the electron-phonon calculation

[Andreas Linscheid]

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


-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: run_example
URL: <http://lists.quantum-espresso.org/pipermail/users/attachments/20101123/5f19de7d/attachment.ksh>