Water and ions
davidlmobley opened this issue · 3 comments
At one point, we had separate FF files floating around for water (TIP3P) and ions. Currently, this does not seem to be the case (at least not in this repo) which means that someone applying our FF to a full system (e.g. a host-guest system for example) that is solvated will likely end up with flexible force field water and, I THINK, no parameters for their ions.
We should probably provide auxiliary libraries here for ions and TIP3P. (When we switch to another water model that should also be provided.)
(OTOH I think these are available in the openforcefield
repo, e.g. tip3p.offxml
is at least. Not seeing the ions offhand.)
What is OpenFF's relation to openmm-forcefields
? To the best of my knowledge, SMIRNOFF/OFFTK has no particular advantages regarding the existing water/protein/ion models. So if we'd just end up maintaining the same parameters in different formats, we might officially endorse that package (and use it in examples) to avoid duplication of effort.
OFFTK has test_forcefields/tip3p.offxml
file. But the OFFXMLs in that directory are explicitly not for use in production simulations, and the files inside (including tip3p.offxml
) have been hand-modified several times. So, I think the first step on this issue is to define a process for
- How do we decide that we want to add a new FF to
openforcefields
? (probably quorum among maintainers) - If another implementation of the parameters exists, what validation of the new file is required, and who reviews it? (this should become one of the duties of a SS or PI)
- How are new FFs stored in the package hierarchy (do they go into the same folder as parsley? Do we attempt some other organization?)
- How are new FFs versioned (do we make it
tip3p-1.0.0.offxml
, to let us keep up with bugfixes/spec changes?)
What is OpenFF's relation to
openmmforcefields
?
openmmforcefields
is a stop-gap solution to delivering SMIRNOFF and GAFF force fields within the legacy OpenMM ForceField
ecosystem. It is intended to be replaced wholly by the openforcefield
toolkit in the future.
To the best of my knowledge, SMIRNOFF/OFFTK has no particular advantages regarding the existing water/protein/ion models. So if we'd just end up maintaining the same parameters in different formats, we might officially endorse that package (and use it in examples) to avoid duplication of effort.
We should not let the existence of the stop-gap openmmforcefields
preclude us from continuing to develop the openforcefield
toolkit as an independent approach to delivering a complete force field parameterization solution. In particular, we need to start integrating water and ions in SMIRNOFF format as a first step toward expanding SMIRNOFF to support biomolecules and biopolymers.
The openforcefields
repo would be a sensible place to put these, but it's possible we want to reserve this for force fields we have generated ourselves, and hence may want a legacy-forcefields
repo that will provide SMIRNOFF versions of legacy force fields.
OFFTK has
test_forcefields/tip3p.offxml
file. But the OFFXMLs in that directory are explicitly not for use in production simulations, and the files inside (including tip3p.offxml) have been hand-modified several times.
Agreed that we do not want to use test_forcefields/
for anything but testing.
How do we decide that we want to add a new FF to openforcefields? (probably quorum among maintainers)
For legacy force fields, we need a way to start integrating these now to achieve the aims of our NIH grant. We need not put them in openforcefields
; they can go into a repository for legacy force field conversions.
If another implementation of the parameters exists, what validation of the new file is required, and who reviews it? (this should become one of the duties of a SS or PI)
This depends on the aims of the conversion, which might be to
- test the scalability of the
openforcefield
toolkit to parameterize solvent, ions, biomolecules, and biopolymers - provide an independent route to delivering accurate legacy force fields w
- make improvements to (or fix bugs within) legacy force fields
For now, additional fields in the .offxml
file might be useful for indicating what level of validation has been carried out. We could even add a tag that issues a warning if we are only at level 1 (unvalidated energies) so the parameters should not be used for production.
How are new FFs stored in the package hierarchy (do they go into the same folder as parsley? Do we attempt some other organization?)
I would vote for something like legacy/tip3p-and-ions.offxml
or legacy/unvalidated/tip3p.offxml
or some explicit path that makes it clear (1) the parameters are not new parameter sets from OFF, and (2) whether or not the energies have been validated.
How are new FFs versioned (do we make it tip3p-1.0.0.offxml, to let us keep up with bugfixes/spec changes?)
Good question. Not sure about this one.