-
Notifications
You must be signed in to change notification settings - Fork 22
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
Interchange.to_gromacs() creates a topology with far too many atomtypes, which influences GROMACS performance #961
Comments
Will look at this and your changes more closely later but you're probably running into the long-standing problem of using SMIRNOFF in "conventional" atom-typed infrastructure, namely the atom type explosion problem. It's the sort of problem that seems like it should be easy to wrangle but doesn't always work out like that - with some differences in how engines handle each. I forget (but hope I can pull up!) some of the more antagonistic cases that prevented me from going all the way with atom type de-duplication in the past. This is all to say your issue is surely valid, I'm not surprised you're running into some performance issues, and I've even tagged this as something to better document (#607). |
Following the discussion in #606 the behaviour suggested in #962 can be made optional, by adding a flag to |
With #973, there's now a good-looking solution for this. I might keep this open while it gets some testing out in the wild, though. |
Description$n^2$ dependence on the number of atom types. For me, a system of around 55,000 atoms led to memory usage over 32 GB at both
When dumping the interchange to GROMACS format, too many atom types are created. This is completely fine in terms of compatibility with GROMACS, but it is causing huge memory pressure on GROMACS. The issue is that GROMACS is creating and keeping in memory the matrix of all non-bonded interactions. So the more atom types you have, the larger the table is. The table size (and the memory requirements) has
grompp
andmdrun
stages.To demonstrate the issue, I used the
102L
structure. I removed all the waters manually with vmd and added hydrogens withgmx pdb2gmx
:When I ran
grompp
with the topology and structure created by GROMACS withamber99sb-ildn
force field using the following basic.mdp
file:I got:
The memory usage during the execution, obtained with
looks like this:
When I created the system using interchange:
and used
grompp
with the same.mdp
file as before, I got the following output:The memory usage during the execution tracked the same way as for
gmx
looks like this:Note, that for the system created with
interchange
the size of non-bonded parameter combinations generated is 3611328 instead of 2145, and execution time is 3 seconds, instead of 0.2 seconds.I propose the solution (the draft is in MR #962 ) which is merging similar (or identical) atom types into a single entry. With this solution, I was able to reduce the number of atom types combinations to 105 and execution time to 0.1 seconds.
The text was updated successfully, but these errors were encountered: