[Pw_forum] Possible bugs in the electron-phonon calculation
Andreas Linscheid
andreas.linscheid at fu-berlin.de
Tue Nov 23 18:51:53 CET 2010
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://www.democritos.it/pipermail/pw_forum/attachments/20101123/5f19de7d/attachment.asc
More information about the Pw_forum
mailing list