openforcefield/openff-forcefields

Water and ions

davidlmobley opened this issue · 3 comments

davidlmobley commented

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.)

davidlmobley commented

(OTOH I think these are available in the openforcefield repo, e.g. tip3p.offxml is at least. Not seeing the ions offhand.)

j-wags commented

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?)
  • 👍1
jchodera commented

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

  1. test the scalability of the openforcefield toolkit to parameterize solvent, ions, biomolecules, and biopolymers
  2. provide an independent route to delivering accurate legacy force fields w
  3. 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.