Separate handling of empirical geometry-dependent corrections

[annulen]

There are a few empirical corrections which are often used in DFT computations and depend solely on geometry of the system, for example DFT-Dn (with n < 4 [*]), gCP, DFT-C. Normally, they are computed by underlying QC code and included into values of energy and gradient. However, I think it might be beneficial to treat correction value (or sum of correction values) separately from electronic energy when computing steps because of the following:

• near minimum changes in values of electronic energy and empirical correction very often became comparable and go into opposite directions;
• electronic energy and its gradient may be affected by multiple sources of numerical noise, e.g. imperfect SCF convergence, low precision of integral calculations, numeric approximations like COSX, etc., while at the same time empirical corrections and their gradients are defined by analytical expressions and are always precise;
• empirical corrections are very cheap as compared to DFT and can be easily computed for target geometry before step is made.

For example I guess it shouldn't be too expensive to calculate empirical correction for target geometry on each iteration when step is optimized to fit into trust radius. Another approach I can imagine is using a separate Hessian for correction, which could be exactly recomputed whenever it's needed.

Alternatively, this feature could be helpful simply for using empirical corrections which are unavailable in particular QC code. For example, DFT-C is not available in most QC packages I'm aware of, and there are packages that don't implement gCP and/or DFT-D4.

[*] DFT-D4 depends on partial atomic charges so its case is more complicated

[leeping]

Thanks a lot for the input, and sorry for the very late reply as I've been quite busy lately. I think your feature suggestion could be implemented conceptually as a "composite engine" whose energy / gradient is a function of multiple energies / gradients from different programs. I've noted the feature request, but I think fixing the issue with ORCA jobs we were working on last year, and implementing periodic boundary conditions takes higher priority.