[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 users
mailing list