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