Long-running process ideas

[coltonbh]

From Kieran:

You’ll see what I’m on about at my group meeting in a couple of weeks. Fire doesn’t solve my xtb problems but that’s fine I’ll just use a terachem on a small molecule.

However, there are good reasons to add an xtb endpoint: one of the interesting ideas is we want to pursue is “multi-level methods” so you might do initial optimisations with a really cheap level theory, like xtb, then refine with terachem dft then nail the energies with terachem at ccsd. This could be neatly packaged into API as a longer-running non-single point calculation.

Likewise, building an interpolated PES on the fly. The idea is to speed up geometry optimisations by building a model of the PES from expensive data, finding the minimum energy point on the interpolated PES, then adding more expensive data points and updating the model. Iterating this uses up to 10x fewer ab initio calls than running directly on the ab initio surface. Likewise reaction path optimisations. The discussion point is where the model that does the interpolation should live. It would make sense for this to be a single API call, but under the hood you’d need to serialise models etc.

[coltonbh]

Consider the tradeoffs between multiple queues being used for different types of work vs private/public computing. If I begin to add more queues for different job types (long running vs. single compute) consider the implications for local clusters that want to add themselves to TeraChem Connect. How many queues will they need to run locally? How will I namespace all these things, etc...?