2023-02-16 Force Field Release Meeting notes

 

 Date

Feb 16, 2023

 Participants

  • @Lily Wang

  • @Jeffrey Wagner

  • @Pavan Behara

  • @Christopher Bayly

  • Bill Swope

  • @Michael Shirts

  • @Chapin Cavender

  • @David Mobley

  • @Jeffry Setiadi

  • @Michael Gilson

 Discussion topics

Item

Presenter

Notes

Item

Presenter

Notes

Force field roadmap

LW

  • LW – slides uploaded

  • LW – There will be an LJ re-fit for Rosemary and it will be standard going forward

  • LW – fo

    • The current plan is to re-fit BCCs and virtual sites for Thyme, in the following order:

      • re-fit BCCs to HF/6-31G* electric fields or ESPs (EFs having shown more promise)

      • also fit virtual sites to HF/6-31G*

      • re-fit LJs

      • eventually/potentially fit to different levels of theory, e.g. the QMug dataset has a lot of wavefunction data at ωB97X-D/def2-SVP

 

 

  • (Rosemary slide)

  • CC – Per slides, making a choice based on some benchmarking

  • CBy – Back when I was studying how people protein FFs, there was a lot of special tuning to get helical propensity and stuff right. How is that going to be done here?

    • CC – Our first pass will not be fit to NMR properties, instead it will just be fit to QM geometries and torsiondrives. Then we’ll just benchmark against NMR. In future generaitons we may fit to NMR stuff

    • CBy – So do we expect to be inferior to other protien ffs?

    • MS – I think it’s possible that we’d make up ground in other areas by being more generally self-consistent.

    • CBy – Is there a specified cutoff for quality for “MVP”?

    • CC – I’m running NMR benchmarks with the SMIRNOFF models I’m making and FF14SB. So I’m looking for noninferiority there.

    • MS – The final criteria is when industry people want to use it.

    • CBy – If you can show parity with ff14sb then that should be good enough for industry.

    • MG - For the proposal, we also want to have a folded protein running that doesn’t misbehave.

  • (Graph charges slide)

  • (Roadmap plans slide)

    • MG – So the big goals for thyme are to refit BCCs, vsites…

      • MS – So will nagl make am1bcc charges? I thought we were going to make AM1 and then apply BCCs.

    • MG – I think this is fair game to mention in the proposal. I do wonder how this interacts with the current writing of the grant - Currently here we’re taking aobut FFs, but in the grant we’re talking about infrastructure to make FFs

    • MS – … Aim 2 is about supporting infrastructure to test new funcitonal forms, and vsites would be first in line for that

    • MG – But this is about releasing actual FFs. Is there a time release that we should mention in the proposal. If so, would that go under aim 4?

      • MS – We could talk about how we’re going to release FFs in conjunction with the consortium as the sciene is validated

      • MG – I’m thinking we should make a crisper decision on whether we’re going to release FFs.

      • MS – Maybe we could say we’ll do it “in conjunction with” the consortium

      • DM –

  • CBy – Roadmap slide - There’s rosemary 3.0.0 and 3.1.0. It looked like the only difference was the charge model (am1bcc vs. nagl charges). I think this will be really interesting to see how FFs change when all the training is the same and only charge changes.

    • JW – Yeah, I think 3.1.0 may also have a LJ refit

    • CBy + MS – And then it’d be desirable to do a full refit

    • DM – Yeah, we’d probably do a full refit.

  • CBy – I really look forward to vsites. And also DEXP nonbonded/soft cores. Is DEXP currently ruled out?

    • DM – There are holes in element coverage for the DEXP refit. Also existing free energy frameworks don’t (yet) support DEXP.

    • MS – Main focus is on FFs that most people can use. We picked our specific sorts of vsites with interoperability in mind. So this would be a big hit to our usability/interoperability.

    • DM – I think we could make an OpenMM-only DEXP FF for interested users.

    • MS – …

    • MG – …

    • MS – The proposal should state that we can prove whether there’s a better funcitonal form is something we should do

    • MG – And that could convince people to implement it

    • MS – And we need large scale testing to provide enough evidence to get people (other devs) interested in implementing it.

    • CBy – Having worked in industry for a long time, we want FFs that address this longstanding defect (non 12-6 vdW and soft cores). And it needs to be robust. But on behalf of industry, this is the team that could do it.

    • DM – Scientifically we’re very interested in this, but to gauge industry interest we should discuss with the ad board. A lot of people are stuck with their engines for a while, so it could be a problem of timescale with getting implementation to our funders. Right now a lot of people are just beginning to have an alternative to FEP+, and if we changed our functional form (even based on good evidence of improvement) then we’d lose them.

    • CBy – …

    • MS – Also a question of how much better this will be. There’s some threshold of improvement that we need to clear.

    • DM – …

    • CBy – Thanks

    • BS – For the sake of the proposal, you want ot pint out that this is a good platform to do these proof-of-concepts that can provide convincing evidence that drive implementation through the ecosystem

    • .

    • MG – And also the benefit of openly providing the infrastructure so other people can do new research.

    • MS – Re: DEXP – It’s important to co-optimize water. I expect we’ll see better performance in some of the weaker benchmarks once that’s done.

 

 

 

 

 

 

 

 Action items

 Decisions