2021-03-30 Bespoke Fitting meeting notes (sci)

Update on large torsion fitting dataset using rmsd

@Joshua Horton

• https://openforcefieldgroup.slack.com/archives/C01G0J25S1Z/p1617206402016600

• SB – Are all parameters being fit in these bespoke fits?

  • JH – Only rotatable torsions (which are being torsion-drived)

  • SB – Could you just look at the RMSD of the atoms close to the torsion being driven?

  • JH – Since we use GeomeTRIC, we could choose to just target the ones that are being fitted, or all of them

• SB – Also, it looks like there’s still a Y=X series in the openff-1.3.0 series, and possibly others

• DC – My conclusion from the bar graphs here is that, If I was already using one restraint scheme, I wouldn’t bother switching to a different restraint scheme.

• TG – I’m curious to know the denominator in the torsiondrive targets vs the others

  • JH – It’s still 50, same as when we talked before. It’s hard to properly weight the contribution from energy and geometry.

• DM – Which set of molecules are we looking at?

  • JH – Schrodinger set.

• DM – This seems to align with my expectation

• JH – I’m running QUBEKit to get bond and angle terms. It’s quite complex to keep track of all the optimizations. I think we should put this in QCA.

  • DM – Agree. And we should add the molecules for Hahn’s protein ligand benchmark data.

  • JH – Yes, I’ll put that dataset together.

• DM – What’s next?

  • JH – Bespokefit seems pretty close to finished. Next up is tidying up and helping Cresset get it into production.

  • DM – Paper?

  • JH – Not sure, maybe an application note.

  • DC – I’m happy for this to be a paper. Though I saw a similar one in relevant literature so the impact may be a bit reduced.

  • DM – There’s a checklist for writing papers.

• JH – Do we want to move forward with free energy calculations?

  • SB – Using perses, we may be able to do this on MSKCC Lilac. We’re just queueing up jobs for the Sage release. If you send me your FFs I can include those in the runs

  • JH – I can do the TYK2 systems

  • DC – It’s be good to do that with the ANI stuff as well.

• JH – Should propose

Plan how Cresset can help with fragmenter issues

• JW – Remaining issues:

  • AM1 wiberg bond order calculations

    • Limitations:

      • AM1 calculation are conformer dependent, but we need to provide the same value regardless of input conformer

      • Electrostatically Least Focused-10 (ELF10) implementation. OETK is the only place this is currently implemented, but they deviate from their own spec in unknown ways. So we want to build our own implementation. SB already did some work toward this.

  • Refactoring fragmenter to be based on the OFF toolkit

    • SB – Most of the issues for getting this done are bugs in the OFF Toolkit. Probably not a big opportunity for external contributions here

  • Validation

    • SB – Would be great for someone to run the final product using AT vs. OpenEye to ensure the results are the same.

    • AV – We don’t have an OE license, but could run the AmberTools dataset.

    • JW – The final validation will take some amount of interpretation. Cresset may be able to contribute there.

    • DM – We have access to Chris Bayly who originally made this.

    • SB – For fragmenter, the relative differences are important, not the absolute.

    • VA – I expect relative differences to be comparable.

    • JW – For parameterization, we need matching absolute values

    • SB – I don’t think we can fully match OE’s implementation without reverse engineering. I suspect most of the difference is due to different restraints during AM1 minimization between AT and OE. In some cases, AT rearranges connectivity because it doesn’t restrain with our default settings. In others, the OE minimization is prevented from going far enough toward a minimum and gives a strained bond order.

    • JH – If we use OE’s low-level API, we may be able to control things like the restraint strength and minimization parameters.

    • SB – I’m not sure we want to go that far into the weeds.

    • DM – CBy doesn’t have much confidence that OE is doing AM1 optimally. They could be convinced to change their defaults or expand their API.

    • SB – We’d need to do a study to show that OE should do it differently, and I don’t think we have the personnel to do that study.

    • VA – With mark, I had talked and we think that building a fragmenter should be possible. We’d be happy to share our code and have OFF run it with OE.

    • DM – We’d prefer to stick with out fragmenter implementation.

    • VA – I’ve reviewed some work in this field, particularly the pfizer fragmentation scheme.

    • Once we have an initial fragmenter refactor complete, we will reach out to Cresset to help us select a validation set, run the AmberTools fragmentations, and analyze the differences.

• SB – For getting equivalent AM1 behavior between OE and AT, we could begin a science project on it once the infrastructure to do restraints in an AT AM1 optimization is prepared. So if the software team could figure out how to apply restraints in an AT AM1 calculation, we could initiate a science project to figure out which settings/values produce the desired outcome.

  • JW – Agree

  • OFF Infrastructure team will find how to set AmberTools AM1 optimization restraint parameters and ping Simon once they’re found+exposed.

• SB – It’d be interesting to see how different fragmentation outcomes interact with bespokefit

  • JH – Agree. I’m also interested in looking at how bespokefit performs with different fragmentation schemes.