My Community

Dear Vasp group,
Is there a possibility to selectively exclude atomic kinds in Grimme's DFT-D3 dispersion correction method (IVDW = 11 or 12)?
Thank you,
Marco

As far as I understood from Grimme's paper (https://doi.org/10.1063/1.3382344) the C^8_ij is determined from a recursion relation from C^6_ij.
That would mean that if you deactivate C^6_ij using https://www.vasp.at/wiki/index.php/VDW_C6 then I think you will effectively deactivate the dispersion correction for that atomic kind.

Thank you for the suggestion,
Deactivating the C^6_ij by setting the VDW_C6 tag to zero only works for the older D2 dispersion correction (IVDW = 10). This keyword seems to be ignored entirely when you use the newer D3 correction (IVDW = 11 or 12). I also tried to modify the C^6_ij parameters directly in the source code inside the subdftd3.F file (lines 3865:3878, setting some values to 0), however, this change had zero effect. Do you maybe have some suggestions on what else I could try to modify in the source code?
Thank you,
M

Hi,

The DFT-D3 methods correspond to version=3 or 4 in subdftd3.F (see the "CALL vdw_forces_D3" in vdwforcefield.F). You were looking at the subroutine loadoldpar that is used only by DFT-D2 (corresponding to version=2). A possibility to exclude atoms in DFT-D3 could be, for instance, to set c6=0 just after the "call getc6" in the subroutine pbcedisp. Two of the input arguments (iz(iat) and iz(jat)) of getc6 are the nuclear charges of the pair of atoms.

Hi Fabien and Henrique,

I also am facing this challenge, with a large slab+solvent system (~900 atoms) for which the SCF cycle completes but the D3 dispersion calculation appears to be taking indefinitely long (and sometimes causes an out-of-memory error). I can verify that the D3 calculation completes successfully in a reasonable amount of time if the system contains just the solvent atoms (~400 atoms), so it would help a lot to be able to turn off calculation of the D3 dispersion correction for the slab atoms.

I have the sources for VASP 6.4.3 and 6.5.1, and src/subdftd3.F seems to be identical in both versions. I see that call getc6() appears in both the pbcncoord and pbcedisp subroutines. If I understand correctly, within pbcedisp, the pbcncoord subroutine is first called to populate the arrays (xyz(3, *), cn(*), and lat(3, 3)) storing the nearest-neighbor lists for each atom in the system. Then, pbcedisp uses the neighbor lists in these arrays to add up the pairwise and three-body contributions to the D3 dispersion energy.

When attempting even a single-point calculation on my 900-atom system, both VASP 6.4.3 and 6.5.1 freeze after the SCF loop converges but before forces are printed to OUTCAR. I believe that with my larger system, VASP is stuck deep in the nested lists of subroutine pbcncoord computing these neighbor lists. I'd like to not only omit the D3 energy/force contributions from the slab atoms to the total energy, but stop them from being included in neighbor lists in the first place, as I think this is the only way I can get the D3 dispersion calculation to complete in a reasonable amount of time. You mentioned inserting a c6 = 0 statement directly after the calls to the getc6 subroutine. But this sounds like it would zero out the D3 dispersion energy corrections for all atoms. Can you explain more about how to include this contribution just for selected atoms of interest? Even better, is there a way to enumerate neighbor lists starting only from selected atoms of interest, in order to speed up the D3 calculation generally?

Some details:

• VASP versions: 6.4.3 and 6.5.1, built for CPU.

• Toolchain: Intel oneAPI 2024.1 (compiler 2024.1, Intel MPI 2021.12, MKL 2024.1).

• Additional packages: HDF5 1.14.2, DFT-D4 3.6.0, libxc 6.2.2, libbeef 535ea67, wannier90 3.1.0.

Minimal reproducible example attached. Happy to share my makefile.include if that helps.

Thanks in advance,
Sam

Hi Sam,

I understand you would like to exclude atoms from the calculation but for performance reasons.
Let's maybe try to understand why the D3 part is so slow in your case.
Fabien ran some tests using your INCAR and POSCAR and the runtime is about 80 and 255 seconds with GNU and Intel compilers respectively so perhaps something else is also slow in your calculation.
How did you come to the conclusion that it is the D3 part that is slow?
Does the issue diapear if you turn off vdw corrections, i.e. commenting out IVDW?

For quick tests you can set NELM=0 so that you skip the SCF part and jump directly to the forces + D3 calculation.
You can also set PREC=Normal for a faster calculation of the DFT forces.