Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 6 Current »

\uD83D\uDDD3 Date

\uD83D\uDC65 Participants

\uD83D\uDDE3 Discussion topics

Item

Presenter

Notes

water models, non-mainline FFs, and calendar versioning in openff-forcefields?

Matt Thompson (backup Jeff Wagner)

continuing from 2022-09-14 Meeting notes

  • Note from previous meeting, with new slides summarizing previous meeting and existing unresolved questions

  • Seems to be strong consensus for switching the repo “version” to “calendar versioning”, where releases are of the form 2022.09.14 instead of 2.0.0. The file names would remain unchanged (Sage = openff-2.0.0, Rosemary = openff-3.0.0, etc), but the git tags, python module, and conda packages would reflect the “calendar version” instead of the “force field version”.

  • Qs from slides:

    • Who is approver?

    • What level of validation?

    • How to version “ports” of external FFs/FFs whose reference implementations are defined elsewhere?

    • Would we want to add different ion models as well? Would we bundle them with compatible water parameters? How would we define compatible?

    • Process for patching?

    • Process for external contributions?

  • MS (chat): Nobody uses TIP5P currently, I don't think.

  • MT: Ship water + ions models?

    • DM (chat): The issue with ions is that for your simple sodium, potassium, etc, they actually need to have slightly differnet parameters depending on the water model. e.g. Joung-Cheatham ion parameters for example. So... if you're gonna ship a water model you kind of want an associated set of ion parameters.
      Not that we should develop those parameters, just bring them in from the relevant paper.

    • CB (chat): Another key issue for ions is ions making "covalentish" bonds in biological contexts, like Zn++ making 4 bonds (tetrahedrally) with e.g.histidine residues.

    • JW: No ions but water models seem to be the consensus.

    • DM: I think we may need Na, Cl and K at least for ions.

    • MT: Is there a canonical set?

    • DM – Jeong-cheatham is basically ubiquitous

    • CC – CHARMM people use something other than J-C

    • DM – table 5 in JC paper (10.1021/jp8001614)

    • DM – should associate ions with water models, in same file or with same name. But only monoatomic ions

    • CBy – On behalf of industry and consortium partners - I’d like to make you aware that there’s a domain of applicatiblity limitation of OpenFF – Our FFs can’t be used with any biological system that has a coordinated metal. If you can’t deal with those, you’re basically requiring users to find arbitrary values to use there.

    • DM – That’s beyond the scope of the current conversation. The immediate question is “what non-OpenFF-made FFs do we need to distribute to avoid trainwrecks?”, and the next step is “how do we do it?”

      • CBy – Other FFs have terms for treating coordinated metals. So even if you add monoatomic ions, people will still be unable to handle coordinated metals.

      • DM – It would still be possible within the SMIRNOFF spec, but you’d need to bring in the parameters. And I think the parameters are low quality so we don’t want to endorse them.

      • CBy – Ok, but people would really like to model coordinated metals.

    • CC – I don’t see why distributing divalent ions is so different from monovalent. Grad students who want to simulate something with a divalent ion will find a way to do it, it’s just more likely that they’ll do something wrong if we don’t provide parameters for those.

      • DM – I think the treatment of divalent ions is less well resolved than monovalent.

    • MG – CBy, do you have any thoughts?

      • CBy – Divalent ions are in real biological systems. And if we leave them out then we’re constraining our domain of applicability.

      • MG – I share Chapin’s perspective - Maybe we could provide something tolerable/workable that lets people run simulations at all, that would be better than nothing.

      • DM – The downside is that then we become responsible for when they don’t work or lead to bad behavior.

      • MG – What if we said “use at your own risk?”

      • MS – This could have a warning in the file. Or we could host

      • JW – we may not have bandwidth to support user problems

      • MS – We don’t have to endorse these parameters

      • DM – I’m fine with us distributing stuff outside of main OpenFF channels, like as a repo associated with a publicaiton. But I’m not fine with us hosting these parameters because that gets us on the hook for support.

      • MG – What if we have a spot for “community contributed files” - that would be a clear place with a disclaimer.

      • MS – Agree

      • CBy – What I’m hearing is that we want to support users doing this stuff, but we can’t provide even dummy parameters without sanctioning it. So having a separately-distributed set of files that are clearly not endorsed by OpenFF could solve this.

      • MS – It’s important for user retention - If pharma partners get into a situation where they can’t parameterize a system and have to figure out how to add these parameters, they’ll turn to another tool and have less justification to support OpenFF.

      • CBy – This could also be a way to show what additional industry support could finance.

    • DN – We can discuss this at the lead team meeting. I can’t guarantee that this item will be added to the backlog but we will discuss how to prioritize this.

Different parameters applied to chemically equivalent atoms

Chapin Cavender

  • Specific SMIRKS patterns matching single or double bonds apply differently to chemically equivalent atoms such as nitro groups

  • Suggested fix (by PB): create new, less specific patterns

    • CBy – I think the solution here - This is a good example of why a SMARTS based FF is good.

    • CBy – Phosphate backbones are another likely source of error

    • CBy – Do you need a bugfix release? What is the harm here? Maybe there’s no significant harm.

      • CC – Everything that we know about in these cases sp2 hybridized, so they’re pretty rigid anyway. So even if the parameter applicaiton is random, we know that both will get applied and it shouldn’t have much of an effect on the overall geometry.

      • JW – Agree - Doesn’t seem like much harm

    • MG – Won’t the bond stretches also have a different equilibrium length?

      • CC – The bond stretching terms are OK, the SMIRKS are written more specifically for those.

      • MG – How do other packages handle this?

      • JW – antechamber gives a special bond and atom type for distributed charge on carboxylates

      • MG – Could do resonance structure averaging a la vcharge. The smirks modifications are all patches and this may be a more long-term solution

      • DM – this is why the bond order stuff was important. Maybe we should try again with it, but restrict the scope – maybe only use it for resonance problems

      • MG – why did it stall again?

      • DM – a lot of factors impact torsion barriers unless you have a v. clean dataset. A lot of the datasets we see don’t have torsions that span a lot of bond orders

      • MG – were different functional groups clearly differentiated by WBO?

      • DM – haven’t looked at it for resonance specifically – maybe

      • MG – Quantum methods could be conformation-dependent. But I’d expect to still see signal.

  • Should we make a bugfix release (Sage 2.0.1)?

    • DM – Kind of ambivalent, leaning yes

    • CBy – what’s the harm of no?

    • JW – doesn’t think it warrants bugfix release

    • DM – should queue this up into Rosemary. It should be done, but doesn’t need a bugfix release right now

  • Longer-term solution?

    • DM – WBO torsions, but those have been troublesome.

  • Other functional groups?

    • phosphates

    • sulfates

    • Amidines?

  • MG – Systematic way to search for them?

    • DM – The resonance enumerator could show this.

    • CBy – Could compare WBOs to formal bond orders

    • JW – CIP rank? Like if you looked at each atom and saw whether its neighbors had the same CIP rank but different bond or torison parameters, that would need fixing.

      • CBy – would that only catch the hypervalent sulfur etc cases?

  • We won’t make a bugfix release. In the short term, looking for CIP-equivlaent atoms that get different parameters or in the long term, doing WBO interpolation could solve this. Nobody is assigned for the short-term solutions. CC will put in the suggested patches for carboxylate and guanidium in the protein FF work.

    • LW – We can look at personnel assignment closer to the release of Rosemary. I’ll ping the slack channel.

Additional canary tests

Pavan Behara

  • Molecule with sulfonamide in water that shows a shrinkage in O-S-N angle with 1.3.0, which got resolved in later versions.

  • PB – Any other systems/functional groups that we should have canary tests for?

    • CBy – Hypervalent phosphorous and N-OH. Could just do small molecules like methane sulfonamate… etc

    • PB – Would be good to also start these from a BAD geometry and see if FF corrects them.

    • JW – No suggestions but I like the idea of more quick canary tests

    • DM – Thinking about a thing I’d see with espaloma geometries where aromatic rings didn’t stay planar.

    • CBy – 1-2-3 trimethylbenzene, which makes sterics compete with planarity

    • DM – Maybe it’d be better to only make tests for things that have already gone wrong, rather than try to dream up every possible failure.

    • PB – Yeah, the sulfonamide has come up a few times

    • MG – Did you see this problem in optimizations?

      • PB – It depends on the starting conformation.

      • MG – Maybe multiple starting points.

      • CBy – In some starting conformations, 1-4 interactions kept it in the bad energy well.

  • Insert slides here

✅ Action items

  •  

⤴ Decisions

  • No labels