BMS is declining to support OpenFF in year 5, but will support OpenFE
DD (chat) – Did Kaushik provide a rationale that you can share?
DN – I don’t know
DM – It’d be good if we could get their rationale so we can understand how to improve.
DN – He mentioned that OpenFF did a good job, but that they’re choosing to support OpenFE instead.
DM – It’s frequently the case that there isn’t a real limit on internal funding - these companies can be convinced to support multiple things - but it requires more pressure/proof of value internally.
DN will follow-up to get their rationale so we can understand how to improve.Karmen just emailed Kaushik to follow-up on that.
DM (chat) – The other note, which has probably been said before, is that AstraZeneca is just joining for the first time (at the highest funding tier), we're just waiting for signatures. So... that replaces some of the folks who have dropped.
PB – Does "external/" include the amber ports as well, ff14sb and such, or just water models?
MT – What I’d do in a situation like this is to consider the long-term effects. TIP5P is clearly something we should provide. The amber FF port is a bit experimental and we may later want to deprecate support. So I’d support leaving the amber ports where they are.
JW – How do we decide when to include a release candidate/research FF? We’re a FF research shop and will have lots of experimental/non-spec FFs floating around all the time
DM – Could require that there be a publication associated with them. So stuff like PB’s current experimental FFs wouldn’t be included until publication/main-line release.
MT – I think it’s also important to keep research clear of the OpenFF advertising zone - Nobody benefits if industry users try to use an in-progress FF and distract a researcher with support requests/usage questions.
DM – Largely agree. We don’t want to become responsible for validating everything that lives here. Like, when external folks publish a paper on a new water model, even if they go as far as opening a PR to openff-forcefields, is it our responsibility as reviewer to validate that it yields the published energy values?
MT – I’m happy to be restrictive - I’m envisioning this initially just being a few water models - so like the 80% solution for 20% of the effort.
JW – I’m generally in support of calendar versioning – will help during periods where we may simultaneously have openff-3.0.0rc1 out at the same time as making openff-2.1.0
CC – This proposal sounds good, will help researchers from inadvertently getting errors in their work.
CC – Would we want to add different ion models as well?
DM – I could see us providing those, especially because different water models are optimized for different ion models.
CC – Agree. It seems like some people play fast and loose and swap ion models out, and it’s not clear what’s valid. So maybe we just offer fixed combinations and nothing else. Would recommend offering a few valid combination ion and water ffs in the same OFFXML.
JW – I’d be worried that consensus may change on this, and it’s not clear how we’d “bless” combinations of ion+water models
CC – I see the issue there, but I also agreewith Matt that people who want to do this will grab whatever’s in reach, and if we make sure that only correct things are in reach then there’s more likely to be a good outcome.
JW – I’ll add this to the ff-release agenda.
DN – BSwope will also be presenting at this meeting re: deficiencies in Sage.
TG (chat) – When I brought up FF versioning a few months ago in the release call, I wanted clarity on the following points:
If I update an FF, how do I know if the parameters changed? Is b1 from X the same b1 in Y?
Is the update only changes in physical parameters?
Is the update changing the number of parameters?
I think doing a rolling release throws any/all of this info out of the window.
MT (chat) – The software would be calver but the force fields would still be semver, i.e. Rosemary is still expected to be 3.0.0 and I'm not looking to change that
Add Comment