Author Topic: undocumented option for DFT-NL  (Read 7324 times)

acd81

  • Newbie
  • *
  • Posts: 5
  • Karma: +0/-0
undocumented option for DFT-NL
« on: June 03, 2024, 05:26:23 PM »
Dear esteemed colleagues,
I am looking for a nondocumented option to change the parameter employed in a DFT-NL calculation - to be precise, not the option to choose between self-consistent (doscnl) and non-self-consistent (donl), but the way how to specify VV10’s parameter b for an individual DFT functional.
Any advice would be highly appreciated.

Thanks in advance
Paul

uwe

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 583
  • Karma: +0/-0
Re: undocumented option for DFT-NL
« Reply #1 on: June 06, 2024, 12:14:33 AM »
Hi,

try, at your own risk, to add a number behind the keyword for VV10 (either $donl or $doscnl) and check if you find something in the output saying that a 'User defined parameter b' is used.

acd81

  • Newbie
  • *
  • Posts: 5
  • Karma: +0/-0
Re: undocumented option for DFT-NL
« Reply #2 on: June 06, 2024, 02:29:51 PM »
Thanks Uwe,
specifying one parameter seems to work - the RIDFT output says:  User defined parameter b  X.X
Unfortunately, a second parameter (which would be parameter C used in the VV10 expression) is not recognised - does this mean that parameter C is generally considered to be 0.01 ?
Thanks again for your assistance.
Cheers, Paul

acd81

  • Newbie
  • *
  • Posts: 5
  • Karma: +0/-0
undocumented option for DFT-NL
« Reply #3 on: June 06, 2024, 03:11:26 PM »
In a somewhat related matter - as it turns out the VV10 contribution for DFT-NL can be assessed in two different ways: (I) via built-in libxc routines (current version 6.0.0) or alternatively via routines implemented by the Grimme group.
The usage of Grimme’s routines seems to be indicated by the following output in RIDFT

using self-consistent NL method
 ------------------------------------------------------------
 You are using the DFT-NL method please cite
 Vydrov, O. A.; Van Voorhis, T.; J. Chem. Phys. 2010 133, 244103
 Hujo, W.; Grimme, S.; J. Chem. Theory Comput. 2011, 7, 3866
 Functional parameter b  X.XX   YY
 ------------------------------------------------------------

As an example: a RIDFT calculation using the wb97m-v functional can be performed in two different ways

(A) $dft
        functional  wb97m-v
      $doscnl or $donl

or

(B) $dft
        functional  wb97m
      $doscnl or $donl


Case (A) uses the libxc routines, whilst Grimme’s implementation is employed in case (B).
When compared with each another, Grimme’s implementation of the VV10 contribution appears to be more efficient that gives rise to a reduction in compute time of substantial magnitude.

Is there a way (another undocumented option) to generally opt for using Grimme’s implementation for treating the VV10 contribution?

Any recommendations/hints would be highly appreciated.
Thanks, Paul

uwe

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 583
  • Karma: +0/-0
Re: undocumented option for DFT-NL
« Reply #4 on: June 06, 2024, 10:24:40 PM »
Hi,

only parameter b is read in, there is no option to change C (at least I did not find one).

libxc does not come with an own implementation of VV10, but it provides the parameters needed for the selected functional. Both options you have described will use the same VV10 routines (those originally implemented by Hujo and Grimme). The difference in speed might come from non-self-consistent vs. self-consistent treatment of VV10. But that could be seen by a diff on both output files.
To compare timings it is important to start from the very same input including input orbitals (I once fell into the trap myself and didn't realize that one of two job I compared was using the converged orbitals from the job before...).

acd81

  • Newbie
  • *
  • Posts: 5
  • Karma: +0/-0
Re: undocumented option for DFT-NL
« Reply #5 on: June 06, 2024, 11:22:29 PM »
Thanks for the reply, Uwe
the same job (identical start orbitals plus identical VV10 treatment) leads to almost identical results but with quite different timings - none of the described usual "NewBie faults" are responsible for the described behaviour

the calculations are significantly speeded up, if the already mentioned lines appear in the output:

using self-consistent NL method
 ------------------------------------------------------------
 You are using the DFT-NL method please cite
 Vydrov, O. A.; Van Voorhis, T.; J. Chem. Phys. 2010 133, 244103
 Hujo, W.; Grimme, S.; J. Chem. Theory Comput. 2011, 7, 3866
 Functional parameter b  X.XX   YY
 ------------------------------------------------------------

I just wanted to know, what the reason behind this favourable speedup is and how one can opt in general for the faster VV10 treatment - a look into the source code would certainly be helpful, which however cannot be granted to a common user ...

Please take a reasonably large molecule (not water please) and see for yourself the difference in wall-times for two runs:
(A) $dft functional wb97m-v; $doscnl or $donl   AND
(B) $dft functional wb97m; $doscnl or $donl

I would be more than happy to hear if you have managed to replicate the different timings for otherwise identical runs (except wb97m-v vs wb97m).

Cheers, Paul

uwe

  • Global Moderator
  • Hero Member
  • *****
  • Posts: 583
  • Karma: +0/-0
Re: undocumented option for DFT-NL
« Reply #6 on: June 10, 2024, 07:21:16 PM »
Hi,

I can reproduce the difference in speed and it seems to be related to the gridsize which is used for the VV10 part. If you select a functional which is enforcing VV10 (like wB97M-V), ridft will use the same grid for the DFT functional and the VV10 dispersion. If you use wB97M and add $donl or $doscnl, an additional grid is constructed just for the VV10 part - with less grid points.
So in case of wB97M-V it is indeed beneficial not to specify wB97M-V as functional, but wB97M and add $donl or $doscnl (for full self-consistent VV10) to the control file.

As a test case I tried Indinavir with def2-TZVP basis set, gridsize m4, RI and senex. It took 15 SCF iterations to convergence and I used 40 cores on a typical AMD CPU. 

Functional$donlVV10 energy(Hartree)time(sec)
wB97M-Vno1.20841186310
wB97M-Vyes1.20841186317
wB97Myes1.20847498176
FunctionalVV10 gridVV10 energy(Hartree)time(sec)
wB97Mfiner grid1.20841186304
FunctionalVV10 $doscnlVV10 energy(Hartree)time(sec)
wB97Mself-consistent1.207459217
wB97M-Vself-consistent1.207401526

Seems that the grid size for VV10 set by the functional name wB97M-V is larger (or finer) than it needs to be for this case. Might be that some guest-host systems from the S30L test set will show much larger dispersion energies and probably show larger deviations between the different grid sizes for VV10

Please note that wB97M was not re-fitted for wB97M-V, so it is your choice which functional to use and to add VV10 for wB97M. But that is not true for all functionals, some are re-fitted when being used with dispersion correction (I think wB97X + VV10 and wB97X-V are different for example).



acd81

  • Newbie
  • *
  • Posts: 5
  • Karma: +0/-0
Re: undocumented option for DFT-NL
« Reply #7 on: June 11, 2024, 10:22:31 AM »
Dear Uwe,
I am delighted you discovered the same behaviour - thus, it wasn't born out of imagination on my side ...
Following the warning you already have given, forum members are advised to carefully check as to whether the treatment of available DFT-NL functionals could be substituted by the "seemingly faster" treatment outlined above. It works well for wB97M-V, but indeed doesn't work for wB97X-V.
Cheers, Paul