Frequently Asked Questions (FAQ)
Should I use XTB or TorchANI to speed up QC calculations?
The Open Force Field Initiative recommends using the same QC method (or better) as that used for the rest of the force field. For mainline OpenFF force fields, this is B3LYP-D3BJ/DZVP. The semi-empirical GFN and machine learned ANI methods, respectively implemented in XTB and TorchANI, are much faster but do not reach the same level of accuracy as the former DFT method. BespokeFit performs extensive fragmentation and caching for efficiency, which makes the computational expense of the more detailed methods more palatable.
We recommend using B3LYP-D3BJ/DZVP to augment OpenFF force fields, except for teaching purposes or when the quality of a faster method has been firmly established for a particular molecule series.
Folmsbee and Hutchison compared several methods including these to DLPNO-CCSD(T)/cc-pVTZ; see esp. Table 1, compare “B3LYP (SVP)” to “GFN2” and “ANI-2x”.
Why aren’t my torsion scans being cached and re-used?
BespokeFit caches and re-uses torsion scans when it can, but this cache only lasts as long as the executor is running. The entire series of molecules therefore needs to be submitted to the same instance of the executor.
In addition, just being present in a shared fragment is not sufficient to allow reuse of torsion scans. Each torsion generates its own fragment, and the fragment generated by the torsion must be shared for that torsion to be re-used. See the theory page.
If you still think something’s wrong, please file an issue!
Why is --qc-compute-n-cores ignored when I use XTB?
There is a longstanding discrepancy between how XTB uses multiple cores and how QCEngine communicates with underlying programs. This can be worked around by setting the environment variable OMP_NUM_THREADS, which nudges XTB to use multiple cores.