2023-06-08 Force Field Release Meeting notes

 

 Date

Jun 8, 2023

 Participants

  • @Lily Wang

  • @Jeffrey Wagner

  • @Jeffry Setiadi

  • @Trevor Gokey

  • @Pavan Behara

  • @Matt Thompson

  • @David Mobley

  • @Chapin Cavender

  • @Michael Shirts

  • @Christopher Bayly

 Discussion topics

Item

Notes

Item

Notes

 

  • LW – I’ve worked on some improvements to nagl - some things about charge equilibration, etc. Still in progress so I don’t want to muddle the topic with early results.

Standardising simulation settings across benchmarks

  • Default setup in OpenFF Evaluator (used for small molecule properties and current protein benchmarks):

    • BAOAB Langevin integrator in openmmtools

    • 1/ps collision frequency

    • no HMR

    • 2 fs timestep

    • constraints on covalent bonds to H

  • Protein-ligand benchmarks currently run with HMR

  • LW – Should we standardize this for further training/benchmarking?

  • CC – Something else we could discuss is “what the goal of our benchmarking settings should be”? JC proposed that they should be the “most correct”, whereas this might not be the same as “what people will actually use”. Anecdotally most practical simulations lag behind best practices, since those take time to diffuse through generations of grad students.

    • DM – Specific things we should be doing but aren’t yet? As I said on slack I don’t want this to turn into “settling best practices in more areas”.

    • CC – JC talked about using HMR with 4fs timestep vs. no-HMR with 2fs timestep. Another was the different integrator. Another was LJPME/PME settings.

    • DM – Shouldn’t HMR not make a difference in the results?

      • CC – Yes

      • MS – Right, you can get faster sims. And it should be nearly equivalent.

      • DM/MS – it’s not “best” practices, but “should be equivalent” to

    • MS – I’d say we need to run benchmarks such that we get a protein sim that doesn’t attract criticism. We don’t need to do LJPME right now because most users wouldn’t for proteins (but we need to revisit this when we go it interfaces)

    • DM – If we use LJPME in the fitting, that means it should work for all cases (including interfaces). Butif we don’t train wiht LJPME then we can’t endorse it for interfaces.

    • MS – Yes. Also important that interface FFs use the same cutoff as they were trained on.

    • DM – Does this imply that we should start fitting using LJPME immediately?

    • MS – I think we can get away with not doing it until we start doing interfaces.

    • MT – Since we can set cutoff, dispersion correction, and LJPME in the FF, that may be within our control. But simulation settings/integrators are beyond our control.

      • MS – Potential switch and force switch.

      • DM – Do current FFs specify LJPME?

      • MT – Right now only cutoff vdW is supported.

  • ….

  • MS – Specifying LJPME may not be sufficient to describe what’s going on. But the same things would be needed to specify coulomb fully.

  • MT – I think we’re asking “which vdW treatment should be in the main-line FF?”. If we make a switch to LJPME, it needs to be added to the spec, and this also …

    • JW – There is a combination of FF settings that will yield a LJPME system.

    • MT – But it’s not in spec. So this may be sufficient for experimentation but it should be formalized in the spec before it goes into a main-lines release. So in the end our LJ should either be cutoff or PME. But in the end it would be a little inconvenient on the interop and deployment side if we switch to LJPME.

    • DM – If JC were here, he’d advocate strongly for LJPME, since the current situation with cutoffs is chaotic and people do whatever they want anyway (regardless of what the FF says to do).

    • LW – Could be worth doing experimentation to see how LJPME compares across implementations.

      • MS – Probably out of scope now. For proteins (and things surrounded isotropixcally by solvent) it shouldn’t be significant. But for membranes it could make a big difference. so we could say “you can use either, but when we start doing lipids we’ll need to make a firmer distinction”

      • CC – What MT was saying is that this would be specified in the FF, so if folks use different settings this’d be a different FF.

      • MS –

    • DM – If I wanted to use binding FE calcs in gromacs using LJPME and have normal runs set up, would this be straightforward? I have a roton who could run this

      • MS – Yes, this should work fine. ~20% slower. We wrote a paper a while back that says there should be a small effect but it may not reach statistical significance.

      • DM – So I’d propose that we keep going with cutoff now, but I’ll have my roton check into whether LJPME affects results.

    • CBy – I thought I heard MS say that, if we want to make a good FF that works for membranes, we have to use LJPME. So if we make a FF with LJPME but don’t train on membranes, aren’t we ruling out applicability for membranes?

      • DM – The current FFs aren’t trained on- or applicable for- membranes.

      • MS – Membrane FFs will need to have different parameters depending on cutoff if we’re using cutoffs at that point. So we’ll need to use LJPME when we start training on membranes. Also will be needed for xtal densities. I’d expect right now that we’d get different outcomes for a cyclohexane-water interface if we used cutoff vs ljpme.

      • CBy – …

      • MS – It’s anisotropies that cause problems which require LJPME. For isotropic systems it’s less important. This is also why it’s important to define a potential switch, since dispersion correction will be a little different in that case.

  • LW – So, the decision sounds like “keep using the current settings for our small molecule FFs, until we have convincing evidence that LJPME would be an improvement, or we move into things like membranes that would need LJPME.

    • MS – Yes, and DM’s roton will test this out.

  • MS – I need to ask which cutoff PMX is using for binding FE calcs.

  • LW – If we want to discuss benchmarks as well, would it be worth moving protien benchmarks onto something faster using HMR?

    • CC – This makes sense to me. Our current 2fs, no-HMR was the default in evaluator, which is why I used it. But I think it would make sense to do 4fs yes-HMR moving forward

    • MS – And it would make sense to make the same change to small molecule condensed phase fitting

    • LW – Should we expect the same results?

    • MS – There’s a “shadow hamiltonian” that you’re conserving if you’re doing NVE, differnet from the “True hamiltonian”. It would basically look like you’re sampling at the wrong tempterature. The middle integrator should mitigate this considerably. So as long as this is stable, it should give results within statistical precision. We could do a test and run the solvation properties to see how it looks. And with proteins we shouldn’t see a major difference in folding/unfolding.

    • JS – Would you partition masses of water Hs as well?

      • MS – Yes. One case where HMR fails is if you start forcing the simulation in some way. We did a metadynamics sim where we were trying to force it into a different configuation, and we saw this failing a bit. This didn’t see failures when using no-HMR and smaller timesteps.

    • LW – I’m looking at mixture properties anyway right now, so I could experiment with this in the next few weeks.

      • MS – Would be good to make sure we don’t duplicate effort - I was going to have TBernat look into this.

      • LW – Let’s set up a separate meeting to discuss or talk at the end of call.

  •  

  • .

 

 

 

 

 

 

 

 

 Action items

 Decisions