Semiempirical Van der Waals correction and EPW

[Marti]

Dear developers,

I would like to use EPW for a VdW layered compound.

I know that as stated in the technical lectures of workshop 2018, EPW does not work for functionals beyond LDA/GGA (so non-local VdW functionals cannot be used).
However, I want to know if GGA + Semiempirical Grimme's DFT-D2 correction for VdW would work in EPW. I am saying this because as I see it the D2 correction is a numerical addition to the total energy; so, I do not see any fundamental reason why EPW should not work.
Is that correct or am I missing something?

Thank you,

Mart

[sponce]

Dear Mart,

It could work (as in, the code might run without complaining).

However, I'm not sure if this would be correct. I guess the D2 change the total energy but also the force (to do relaxations).

Therefore it changes the potential felt by the atoms and their response to it. The dvscf might therefore not be correct.

This is speculative as I'm not an expert in vdW corrections.
Best wishes,
Samuel

[hlee]

Dear Samuel Ponc:

I am also interested in the electron-phonon with vdW.
To the best of my knowledge, the only necessary inputs to EPW are dvscf and dynamical matrix in addition to ones related to Wannier function (WF).

I am not sure when these features were implemented in QE, but currently QE can generate dvscf with non-local vdW corrections.
See the relevant files in /LR_Modules/ ( dv_of_drho.f90 -> dnonloccorr.f90 -> dv_vdW_DF.f90 , dv_rVV10.f90 ).

Therefore, in the case of non-local vdW, I think that we can obtain all relevant inputs for EPW (I don't see any reason not to obtain dynamical matrix and WF-related inputs in this case) and we can proceed.
Do I miss something?

As concerns the semiempirical vdW such as Grimme's flavours, I am not sure whether the dvscf should include the correction since in this case there is no change in the self-consistent potential (Hartree and XC, etc.).
However, even in this case, QE seems to calculate phonon with Grimme's correction included (see d2ionq_mm.f90 in /PHonon/PH/).

Sincerely,

Hyungjun Lee
EPFL

[sponce]

Dear Hyungjun Lee,

If it is implemented in ph.x, then it should be relatively easy indeed.

The only part that might need update is the non local part in EPW (the Ewald part is recomputed on the fly by EPW) but apart from that, it should indeed work. See dvqpsi_us3.f90 and dvqpsi_us_only3.f90 routine in EPW.

Let me know if you manage to make that work and if so, please to send me the few modifications to EPW.
I would be very happy to add this in EPW and to credit you.

Best wishes,
Samuel

[hlee]

Dear Samuel Ponc:

Thank you very much for your kindly reply.

But, I think that the subroutines you mentioned concern the local and non-local potentials related to pseudopotentials (PPs).
I think that the non-local vdW doesn't change these parts since usually we use the same PPs even in the case of non-local vdW; this is the case in QE.

Please correct me if there is something wrong.

Sincerely,

Hyungjun Lee

[MaxS]

Hello, was there any progress on non-local vdW corrections? I tried to execute EPW with input data generated by QE with "input_dft='vdW-DF'" but it simply stucks in the very beginning. Looks like EPW is stuck in a certain loop or routine. There is no error message and CPU load is at 100% while memory load is very low. On another cluster EPW stops after about one minute without generating a CRASH file but with "*** Error in `epw.x': malloc(): memory corruption: 0x000000000aac49d0 ***

Can the non-local vdW density functional be included in EPW? If so, which routines need to be modified? Is it only dvqpsi_us3.f90 and dvqpsi_us_only3.f90? These files look actually pretty much the same in EPW 5.0 and QE 6.3.

Best regards
Maxim Skripnik
University of Konstanz

[MaxS]

After some more try and error I figured out that EPW runs fine if I do the following:
1. relax with input_dft='vdw-DF'
2. scf with input_dft='vdw-DF'
3. do phonon calculations
4. take structure form 1. and do scf/nscf without input_dft='vdw-DF'
5. run EPW

It looks like EPW runs fine if it gets input from pw.x input without vdw-DF and input form ph.x with vdw-DF. The flag vdw-DF leads to non-local corrections to the density functional, which are the implicitly included in dvscf files from ph.x. On the other side these corrections must be disabled for pw.x output which is used by EPW. The question is: How much sense does it make even if EPW runs fine? Do the results represent something meaningful?

[carla.verdi]

Dear Max,

I think that should be a good approximation, since the effect of vdw corrections in the dft calculations should be mainly at the relaxation level.
Anyway, you can verify this by e.g. comparing the band structure that you obtain with and without vdw corrections, of course using the same relaxed structure that you obtained with vdw corrections.

Best,
Carla

[MaxS]

Anyway, you can verify this by e.g. comparing the band structure that you obtain with and without vdw corrections, of course using the same relaxed structure that you obtained with vdw corrections.

Dear Carla, the band structure looks almost identical. There is a very slight shift of several meV of the bands. Otherwise the bands look the same (at least those close to the band gap).

I tried to include vdf-DF into EPW by adding the following lines of code to dvqpsi_us3.f90 (taken from PHonon/PH/dvqpsi_us.f90 of QE v6.3):

Code: Select all

      rho%of_r(:,1) = rho%of_r(:,1) + rho_core

      IF ( dft_is_gradient() ) THEN
        CALL dgradcorr (dfftp, rho%of_r, grho, &
          dvxc_rr, dvxc_sr, dvxc_ss, dvxc_s, xq0, drhoc, 1, 1, g, aux)
      ENDIF

      IF (dft_is_nonlocc()) THEN
        CALL dnonloccorr(rho%of_r, drhoc, xq0, aux)
      ENDIF
      
      rho%of_r(:,1) = rho%of_r(:,1) - rho_core

But that did not help with the malloc(): memory corruption error which I described previously. I am currently trying to trace back the error to a certain line of code. It looks like the line

Code: Select all

CALL mp_min( emin, inter_pool_comm )

in epw_setup.f90 (somewhere around line number 280) is causing trouble. And indeed, if I run epw on only one core with

Code: Select all

mpirun -np 1 epw.x -npool 1 < epw.in

then the malloc error doesn't occur with input_dft='vdw-DF'!

I am not familiar with QE parallelization. Is it possible that the flag input_dft='vdw-DF' somehow influences the parallelization scheme and EPW gets in trouble by using some different scheme?

UPDATE: I executed epw.x on one core and printed out emin and emax, which are -4.234 and 0.14246. I then commented out the lines

Code: Select all

CALL mp_min( emin, inter_pool_comm )

and

Code: Select all

CALL mp_max( emax, inter_pool_comm )

and replaced them by setting manually emin/emax to the values given above. I then executed epw.x on 16 cores and EPW crashes now at some point further in the code. So it is quite obvious that there is something going wrong with the parallelization when using EPW with input_dft='vdw-DF'.

Any hint?

[MaxS]

Hello, when using input_dft=vdw-DF and more than two CPU cores, EPW stalls in the subroutine setup_dgc when allocating memory in these lines:

Code: Select all

  IF(.NOT.ALLOCATED(dvxc_rr)) ALLOCATE (dvxc_rr(dfftp%nnr, nspin_gga , nspin_gga))
  IF(.NOT.ALLOCATED(dvxc_sr)) ALLOCATE (dvxc_sr(dfftp%nnr, nspin_gga , nspin_gga))
  IF(.NOT.ALLOCATED(dvxc_ss)) ALLOCATE (dvxc_ss(dfftp%nnr, nspin_gga , nspin_gga))
  IF(.NOT.ALLOCATED(dvxc_s))  ALLOCATE (dvxc_s (dfftp%nnr, nspin_gga , nspin_gga))
  IF(.NOT.ALLOCATED(grho))    ALLOCATE (grho   (  3    , dfftp%nnr, nspin_gga))
  IF(.NOT.ALLOCATED(rhoout))  ALLOCATE (rhoout ( dfftp%nnr, nspin_gga))

In my case dfftp%nnr=2073600, which matches the dense fft grid (120 by 160 by 108).
Most of the MPI processes reach the second allocation statement, some reach the third and only one or two reach the last line. It looks as if there is lack of allocatable memory. But my test system has 128Gb of RAM and the allocated arrays are not that huge. There is also no error message saying "out of memory". The code simply stalls there. What is also strange, when not using input_dft=vdw-DF, this problem does not occur, even though dfftp%nnr has the same value.

I don't understand this behavior. I tried openmpi and impi. I'm using QE 6.3.

UPDATE: I just tested EPW with input_dft=vdw-DF on a very small system (dfftp%nnr=69120) and it works! Looks like there is indeed a limitation by system size. But it is still not clear why. There is enough memory to allocate those arrays even for the big system.