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
