2022-06-22 BespokeFit Meeting notes

General update

• JW – Issue tracker handling

  • #189?

    • JW – I’d advocate not fitting any torsion where any point in the torsiondrive has a proton transfer

    • JH – Would be preferable to allow some slack for torsiondrives where only one or two structures had proton transfers

    • DM – Agree with JH, it’d be great to have smart criteria for this

    • JW – Agree, but it would be really hard to figure out the criteria, and as a first step we could just quickly prune this out

    • DC – Could we move the proton over before the scan?

      • JW – I don’t think so.

      • PB – Chaya saw that some molecules do have significantly different electronic properties based on zwitterionic state

        • figure 1 here: https://chayast.github.io/wbo-manuscript/

      • DM – It could be useful to have a “chemistry checker” to warn users about inputs like this.

  • #175?

    • DC – JH, could you run these numbers through arsenic?

      • JH – Sure

      • JW – I think we can also decide that we won’t work on this - It’s complex and may be hard to root out

      • DC – Let’s just do the arsenic post and then plan to discontinue effort.

• DC – JH presented poster at CCPBioSim conference. One big takeaway from the feedback is that we may have been lucky in which targets we tested against - Another group showed no improvements against p38.

  • JW – p38 is in protein ligand benchmarks set:

  • DM – Important to note that improved FFs may not always improve binding free energies. There are several other factors involved. So it’s fair to just measure torsion accuracy. So while I’d expect a general improvement in binding accuracy over many targets, I wouldn’t expect every target to improve.

  • JH – Other folks expressed interest in having an openFF training session/workshop, in the UK in 2023.

  • JW – I’d love to do that. Note that realistic use cases will require interchange importers.

  • DM – We need swails to cut a release of ParmEd, since that’s how folks will be using bespokefit for a while, and we’re still getting atom type collision bugs.

  • JW – This sounds like a situation where we’ll end up maintaining parmed I’ll figure this out

• DC – Was supposed to see venkata but there was a train strike

  • V – Reschedule?

  • DC – Next week or the week after

• DC – Thanks for the paper feedback - I’m still reviewing all of it. Was there more data that needed to be collected or anything that could have been more understandable?

  •  

Double exponential nonbonded form

• DC – We’d circulated slides on this after ad board presentation a few months ago. That summary is still current. We’re not far from having a complete study there. The next thing would be to refit valence terms using the new form and PB had offered to work on that. Is there anything else you need, PB?

  • PB – Nope, I have the FF file and it looks good.

  • DC – Great. I’m not sure what to expect - Hopefully comparable/improved accuracy for conformations, but improved accuracy for physical properties

  • JH – Do we want to start from sage valence parameters, or modified-seminario valence parameters?

  • DC – I’d say that we should start with Sage

  • PB – I can do both.

  • DC – You should do the sage params first.

  • JH – Did sage use vibfreq in sage fitting?

    • PB – No

• JH – We’ve set up a confluence page to track a DEXP paper, but we need someone with a premium overleaf account to get the template started

  • PB – I’ll do this.

  • 
    
    

Boron parameterization

• DC – I realized that I’ve lost track of what we want to deliver. We have condesned phase properties from boron compounds form reaxys. We’ve been generating bespoke params for those and the simulations seem reasonable. But I’m wondering whether we need to fit torsions - What’s the minimum amount of information that we need to include boron in openff infrastructure?

  • DM – I was thinking that the initial target is condensed phase properties. I’d go for very generic BAT parameters for compounds involving boron, without too much elaboration.

  • DC – We do have generic BAT parameters fit, but the torsions are all zero.

  • DM – I think ther’es kinda a chicken and egg problem - We can’t make boron parameters until we can make boron conformers, but we can’t make boron conformers until we have boron parameters. So what we really need is just a FF starting point for iteration, and then we can send that to OpenEye and have them implement that in omega.

  • DC + JH – Right now we’re using RDKit to generate the conformers and they seem good.

  • DC – I’ll connect up JH with the person who is working on this.

  • JH – Ok, so it looks like we need:L

    • boron sets on QCA

    • a first pass FF with boron BAT terms

    • ?BCCs for boron?

      • AM1 works for boron, but there are no BCCs, so we’d need to use a chargeincrementmodel in the OpenFF toolkit

      • However, if we get graph charges into Rosemary, then we almost certainly won’t add a chargeincrementmodel to a main-line ff.

      • JH – Ok, I won’t aim to make BCCs for boron. Just training sets for an eventual graph charge model.