Requirements for sing vsites in a fit: (General) – It seems like, after the GeomeTRIC PR above, we should be able to do optimized geometry and torsiondrive fits immediately. ESP grid fits should be possible after some updates to openff-recharge HJ – Would we fit them all simultaneously? Areas of likely developerment TG – SB – How feasible is it to change the vsite geometry during ESP fits? If we do a 2-step process, then it’s possible that vsite changes from one stage would mess with things from other stages (eg changing positions based on torsiondrives would screw up electrostatics) SB – (connectivity issues) JH – It’d probably be best to optimize positions before charges SB – It should be possible TG – Ok. I’m thinking about which targets will deal with vdW and which will do ES. JH – Can we tell FB to not fit particular vsite properties for particular targets? TG – Yes. SB – openff-Evaluator should do vdW, recharge should do charges. SB – Could have a final step where BOTH evaluator and recharge run and both vdW and charges are co-optimized (with heavy regularization).
TG – Should we use qubekit to get initial guesses for vsites? Right now we haven’t selected a starting point CR – That should be possible. SB – Could run bespoke fitting on a variety of molecules, and see what patterns vsites commonly come up in, and then come up with an average for series.
SB – Similar to chargeincrements, where the FF requires specifying all degrees of freedom, would we want something similar for vsites? So like the ability to define N-1 chargeincrements? JW – N-1 chargeincrements should be doable. Are there other redundant/overdefined parameters? TG – Concerned about the possibility that optimized places all vsites on a particular parent in the same spot CR – We’ve added logic to remove overlapping vsites. This is a bit comlex, since it depends on whether the vsites are on the same vector happen to overlap for a specific distance SB – Is it necessarily a problem if they overlap? CR – Not really, we just want to keep things simple/avoid overfitting. TG – VSites in openff – one parameter definition can encode multiple particles. (General) – This seems like a rare occurrence SB – Could start a confluence page on this. Implementation would probably be as a post-processing step for after one stage of fitting, determining whether two vsites ar functionally redundant.
JH – Benchmarking w/ vsites: We’ll need openmmforcefields and qcengine to be updated. JW – openmmforcefields work might be somewhat significant MT – Will we continue using openmmforcefields for much longer? JH – It’s mostly a requirement for interfacing with Perses and other benchmark infrastructures TG – Update openmmforcefields is general issue since it’s a requirement for using QCEngine, which will keep any vsite stuff out of QCArchive until we implement it. MT – We should think about whether we will take ownership of openmmforcefields, whether OpenFF system will replace it, or whether a new piece of infrastructure will take its place. JH – OpenMMForcefields also gives access to GAFF. JH – For QCEngine, we’ll need to done reshaping/padding of the coordinates array going in, and squish down the gradients and such coming out.
Major blockers:
|