Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

draft: Add atom type merging for Interchange.to_gromacs() #962

Closed
wants to merge 29 commits into from

Conversation

pbuslaev
Copy link
Contributor

@pbuslaev pbuslaev commented Apr 9, 2024

Description

This should be solving #961

Checklist

  • Add tests
  • Lint
  • Update docstrings

@pbuslaev
Copy link
Contributor Author

pbuslaev commented Apr 9, 2024

This is a draft of the solution, if anyone can suggest me with optimal tests for it, or other considerations to keep in mind, I will be happy to work on those

Copy link

codecov bot commented Apr 9, 2024

Codecov Report

Merging #962 (4531a75) into main (ee242d5) will decrease coverage by 0.56%.
Report is 18 commits behind head on main.
The diff coverage is 100.00%.

Additional details and impacted files

Copy link
Member

@mattwthompson mattwthompson left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is a good start, it's assuring that no existing tests seem to be passing. My primary worry is something subtly changing with the energies, perhaps in the relationship between nonbonded parameters and bonded parameter housekeeping, but maybe that's not founded.

To keep this moving, we'll definitely want some tests with the flag turned on and off (included in the test suite) for a variety of chemistries and some quick checks that this actually fixes the memory explosion (one-off analysis).

openff/interchange/interop/gromacs/export/_export.py Outdated Show resolved Hide resolved
openff/interchange/interop/gromacs/export/_export.py Outdated Show resolved Hide resolved
openff/interchange/interop/gromacs/export/_export.py Outdated Show resolved Hide resolved
@pbuslaev
Copy link
Contributor Author

So now I added a flag merge_atom_types and I drafted some tests (roundtrip, and energy comparison).

@pbuslaev
Copy link
Contributor Author

It seems that now all tests that do not require OpenEye are passing. I can add a couple of other tests (checking that atom type merging actually occurs)

@@ -60,31 +64,100 @@ def _write_defaults(self, top):
f"{self.system.coul_14:8.6f}\n\n",
)

def _write_atomtypes(self, top):
def _write_atomtypes(self, top, merge_atom_types: bool) -> dict[str, str]:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's great to see work toward the "atom type explosion" problem that's plagued us for years. But given my recollection of the severity of the parmed bug that arose from seemingly innocuous atom type merging, it may make sense to have this be _merge_atom_types(with the leading underscore) or require INTERCHANGE_EXPERIMENTAL=1 for a few releases to communicate that it's new/experimental. Once early adopters have run with it for a while we can remove the underscore and make it a public method.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That is fair, I added underscore to all public methods

@mattwthompson
Copy link
Member

Thanks @pbuslaev - in case I didn't earlier, I wanted to add a note to make it clear that this is probably in good shape but I need to spend some time tinkering with it in tests outside of the test suite. Some small errors in atom type accounting can lead to huge errors (for example, I've seen papers retracted because non-water parameters overwrote water parameters: ParmEd/ParmEd#1197). Keeping this in the "private" API is definitely the way to do it, but I also want to run it through a bunch of tests cases to ensure nothing funny happens since it might make its way to the public API in the future.

@pbuslaev
Copy link
Contributor Author

Thanks @mattwthompson. Let me know if you have some specific tests in mind and I can run those locally as well.

@mattwthompson
Copy link
Member

Thanks for the contribution @pbuslaev! I spent a good portion of today shuffling these changes into a new branch and running more tests. #973 is merged and should be in the next release. So far everything is looking great - impressive work!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants