Openff-toolkit: TIP3P parameters have incorrect units

Created on 10 May 2019  路  3Comments  路  Source: openforcefield/openff-toolkit

@SimonBoothroyd found a discrepancy in our tip3p.offxml file. It looks like we may have lost track of TIP3P parameter units during conversion to the 0.2 spec. Namely, the vdW section's sigma and epsilon units got switched from kJ to kCal and nanometer to angstrom.

We should patch this up for now, but generally this raises the question of "how can we develop a formal FF release process to minimize the chances of this sort of error"? Under current plans, this file will fall under the umbrella of what will be our conspicuously-labeled "test_forcefields", which come bundled with the toolkit. But soon, we'll want to migrate it to the up-and-coming FF repo (#249), so we should consider a process by which a few people review contents before we make an "official" release.

bug low high

Most helpful comment

One other thing that can help: Currently, files like tip3p.offxml appear in multiple repositories (including the property estimator). Once we have a single, versioned, conda-installable supplier of OFF force fields, the potential for these errors slipping by un-caught diminishes.

All 3 comments

I think this also argues for the sense in ensuring each parameter has units attached, rather than having global units at the beginning of each section.

We should patch this up for now, but generally this raises the question of "how can we develop a formal FF release process to minimize the chances of this sort of error"? Under current plans, this file will fall under the umbrella of what will be our conspicuously-labeled "test_forcefields", which come bundled with the toolkit. But soon, we'll want to migrate it to the up-and-coming FF repo (#249), so we should consider a process by which a few people review contents before we make an "official" release.

It seems like regression tests---where a number of computations are performed (e.g. potential energies evaluated on a variety of systems) and compared to historical results---might help in this case. But we are aiming for future parameter optimization workflows to completely remove human interference in the chain of custody from parameterization to assessment to release.

One other thing that can help: Currently, files like tip3p.offxml appear in multiple repositories (including the property estimator). Once we have a single, versioned, conda-installable supplier of OFF force fields, the potential for these errors slipping by un-caught diminishes.

Was this page helpful?
0 / 5 - 0 ratings