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. 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 atomsLily Wang | View file |
|---|
| name | 2022-09-29-delocalized-charge-torsions.pdf |
|---|
|
| Chapin Cavender | | Github link macro |
|---|
| link | https://github.com/openforcefield/openff-forcefields/issues/56 |
|---|
|
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? 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.
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.
|