results difference between epw5.1 and epw5.2

[jqhuang]

Dear EPW developers,

I run EPW5.2(qe6.5) and EPW5.1(qe6.4.1) with the completely same input files(scf.in, nscf.in, epw.in, phonon/save) to get the e-p vertex,
but the phonon frequency of two versions in output files can be very different, up to ~7cm-1(~0.9meV)at some q points.

Following is the epw.in in two calculations:
--
&inputepw
system_2d = .true.
lpolar = .true.
lifc = .true.
asr_typ = 'simple'
prefix = 'MoTe2'
amass(1) = 95.96
amass(2) = 127.6
outdir = './'
dvscf_dir = '../phonon/save'
filukk = 'MoTe2.ukk'

iverbosity = 0

etf_mem = 2

ep_coupling = .true.
elph = .true.
use_ws = .true.
num_iter = 2000
iprint = 2
proj(1) = 'Mo:l=2'
proj(2) = 'Te:l=1'
nbndsub = 22
nbndskip = 32
dis_win_min = -8
dis_win_max = 10
dis_froz_min= -2
dis_froz_max= 4.1


efermi_read = .true.
fermi_energy= 1.0253
fsthick = 3 ! eV
eptemp = 300 ! K (same as PRB 76, 165108)
degaussw = 0.005 ! eV
degaussq = 0.01 ! meV

wdata(1) = 'guiding_centres=.true.'
wdata(2) = 'use_ws_distance = .true.'
wdata(3) = 'dis_mix_ratio = 0.5'
wdata(4) = 'dis_num_iter = 2000'
wdata(5) = 'conv_window = 3'
wdata(6) = 'trial_step = 1.0'


epbwrite = .true.
epbread = .false.
epwwrite = .true.
epwread = .false.
kmaps = .false.
wannierize = .true.

prtgkk = .true.

nkf1 = 45
nkf2 = 45
nkf3 = 1
nqf1 = 45
nqf2 = 45
nqf3 = 1

nk1 = 16
nk2 = 16
nk3 = 1
nq1 = 8
nq2 = 8
nq3 = 1
/
10 {cartesian}
0.000000000000000E+00 0.000000000000000E+00 0.000000000000000E+00
0.000000000000000E+00 0.144337567297396E+00 0.000000000000000E+00
0.000000000000000E+00 0.288675134594792E+00 0.000000000000000E+00
0.000000000000000E+00 0.433012701892189E+00 0.000000000000000E+00
0.000000000000000E+00 -0.577350269189585E+00 0.000000000000000E+00
0.125000000000000E+00 0.216506350946094E+00 0.000000000000000E+00
0.125000000000000E+00 0.360843918243491E+00 0.000000000000000E+00
0.125000000000000E+00 0.505181485540887E+00 0.000000000000000E+00
0.250000000000000E+00 0.433012701892189E+00 0.000000000000000E+00
0.250000000000000E+00 0.577350269189585E+00 0.000000000000000E+00

I noticed that dmedate.fmt in EPW5.1 has gone and is replaced by vmedate.fmt in EPW5.2 (maybe they are the same thing in a physical sense).

It is strange that dmedate.fmt file is normal as follows:
(5.136796004771528E-006,2.272028861662918E-005)
(2.892201462303629E-006,-1.226356373239952E-006)
(1.782074204963529E-011,-2.369778190474230E-011)
(-4.154739721377699E-006,1.056601084293195E-011)
(4.850202537877077E-012,4.322976548843746E-007)
(2.038068391136785E-011,-6.021966268537016E-012)
(-1.799612482102541E-006,2.015288205219882E-005)
(-6.975830618110693E-006,-8.136778270005097E-006)
(-1.336234596050945E-011,8.134634011961389E-012)
(-1.329297411725360E-005,-3.512722917950183E-005)

while all in vmedate.fmt is zero as follows:
(0.000000000000000E+000,0.000000000000000E+000)
(0.000000000000000E+000,0.000000000000000E+000)
(0.000000000000000E+000,0.000000000000000E+000)
(0.000000000000000E+000,0.000000000000000E+000)
(0.000000000000000E+000,0.000000000000000E+000)
(0.000000000000000E+000,0.000000000000000E+000)
(0.000000000000000E+000,0.000000000000000E+000)
(0.000000000000000E+000,0.000000000000000E+000)

What can be the reason why the phonon frequency has a such big difference w.r.t the same input files?
Did I miss something in the latest version EPW5.2 that leads to the zero vmedate.fmt?

[hlee]

Dear jqhuang:

First, I assume you are using the official EPW v5.2 included in the official release of QE v6.5 which can be downloaded at https://gitlab.com/QEF/q-e/-/releases . That is, I assume that you are not referring to the more recent development version of EPW v5.2 which can be downloaded at https://gitlab.com/QEF/q-e .

I don't know about EPW v5.1 since I joined in the team in Jan. this year, but I think that there might be some changes and bug fixes between EPW v5.1 and EPW v5.2 which can lead to some difference.

I am not sure, but one possibility might be related to lpolar=.true.
Could you compare the subroutine of rgd_blk in rigid_epw.f90 in EPW v5.1 and that in EPW v5.2?

Regarding vme (velocity matrix elements) and dme (dipole matrix elements):
They are different ones and they are calculated differently.
However, I think that this can't lead to the difference since in your case, both of them are not used. The reason why vme is zero is that there is an issue which I fixed recently (See https://github.com/wannier-developers/w ... 0/pull/337 ).

Sincerely,

H. Lee

[jqhuang]

Dear H. Lee,

Thanks for your detailed reply.
I'm using the official EPW v5.2, not the more recent development version of EPW v5.2.
As you suggest, I compare the subroutine of rgd_blk in rigid_epw.f90 in EPW v5.1 and that in EPW v5.2.
Since I'm not very familiar with programming, here are two maybe seemingly dumb questions.

1. It seems that "system_2d" already work in the official EPW v5.2, but why is there no value assigned to 'fac' in case of "system_2d = .true." ?

Code: Select all

    IF (system_2d) THEN
      !fac = (signe * e2 * fpi) / omega*0.5d0*alat/bg(3,3)
      !reff=0.0d0
      !DO i=1,2
      !   DO j=1,2
      !      reff(i,j)=epsil(i,j)*0.5d0*tpi/bg(3,3) ! (eps)*c/2 in 2pi/a units
      !   ENDDO
      !ENDDO
      !DO i=1,2
      !   reff(i,i)=reff(i,i)-0.5d0*tpi/bg(3,3) ! (-1)*c/2 in 2pi/a units
      !ENDDO
    ELSE 
      ! (e^2 * 4\pi) / Volume
      fac = (signe * e2 * fpi) / omega
    ENDIF

2. In the G-space sum for long-range term, why drop the estimate of nrx1,nrx2,nrx3 and directly adopt the coarse q-point grid instead ?
That is to say, how to understand the statement "Using nrx1 is overkill" in the description of subroutine ?

Code: Select all

    !-----------------------------------------------------------------------
    !! This is adapted from QE PH/rigid.f90 
    !!
    !! compute the rigid-ion (long-range) term for q 
    !! The long-range term used here, to be added to or subtracted from the
    !! dynamical matrices, is exactly the same of the formula introduced
    !! in:
    !! X. Gonze et al, PRB 50. 13035 (1994) . Only the G-space term is 
    !! implemented: the Ewald parameter alpha must be large enough to 
    !! have negligible r-space contribution
    !!
    !! This implements Eq. 98 of Rev. Mod. Phys., 73, 515 (2001)
    !! SP: April 2019 - Using nrx1 is overkill.
    !!
    !! SP - 11/2019 - Addition of system_2d (we assume z is the vacuum direction).  
    !!

Best regards,
jqhuang

[hlee]

Dear jqhuang:

I will answer only to your 2nd question since I don't know much about the calculations of 2D materials using EPW.

I thought that it was coded in that way to reduce the computing time and heard that it worked in tests for materials.

However, recently I found that the reduced ranges of the summation can lead to the issue in the rigid-ion (long-range) term when studying some materials.
You can easily confirm whether or not it is problematic by comparing the phonon dispersion from EPW with that from matdyn.x in Quantum ESPRESSO.
If you obtain the different phonon dispersion, you need to restore the ranges of the summation in EPW v5.2 to those in EPW v5.1 .

In the near future, we plan to release the patch for this.

Sincerely,

H. Lee