Torsiondrive speed

[jthorton]

Currently, we collect the torsion QM data using the CLI interface to torsiondrive and we run each grid point optimisation in series which can be quite slow even for simple small molecules. Here I want to collect together some ideas on how we can try and improve this.

QCArchive support

We plan to add this any way to allow us to reuse calculations, this framework also would allow us to parallelize torsiondrives and run multiple optimisations at the same across multiple dihedrals provided we have multiple workers set up which can execute the jobs. This would also work better if we supply multiple diverse conformers which sample the targeted rotatable bond allowing us to take advantage of parallel optimisations from the start and should help reduce the number of optimisations spawned by wavefront propagation. The downside would be that we lose the ability to use gaussian as only programs supported by qcengine can be used.

Torsiondrive Json API

Here we would be rebuilding some of the logic that qcarchive uses to parallelize the optimisations, but we would choose how to run them allowing us to still have access to gaussian. The API would give us a list of optimisations to run and the starting conformer, we would then have to build out a queue system and use subprocess to spawn multiple optimisations (replicating qcfractal workers). The upside is that we would not need a qcfractal instance to run the torsiondrive.

Initial torsiondrive using a xtb/ani

We could do the majority of the work using ani or xtb to get us conformers which are close to the qm minimum very quickly by running an initial torsiondrive with one of these methods. These conformers would then be used as input into the full QM optimisation which should only take a few optimisation steps to converge.

Fragmentation

Fragmentation should mean that the QM calculations are much faster and optimisations should converge in fewer steps, this would be great if we could combine it with one of the parallel methods above.

Are there any other methods which could help speed this up?

[djcole56]

I think pretty much all of the above offers improvement in its own way. I don't have a huge problem with the serial optimisation, as one can instead trivially parallelise molecules across processors (1 molecule in 12 hours sounds bad, but 100 molecules in 12 hours is then easy to do), but see the plus sides. I don't think I have anything to add, though I need to pick your brain on how supplying diverse conformers to TD works in practice.

[jthorton]

Just a reminder that I have added support for the torsiondrive API which now allows torsion grid point optimisations to run in parallel. I need to come back to multiple input conformer support once we improve the conformer generation method using RDKit.

[jthorton]

Multi conformer input is now supported and we can look at pre-optimisation and fragmentation next.

[jthorton]

Fragmentation is now complete and being tested!