-
Notifications
You must be signed in to change notification settings - Fork 132
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
Periodic improper support #1662
Periodic improper support #1662
Conversation
One thing to note about this PR is that the support for periodic impropers is important for running GAFF forcefields in HOOMD, which is recently supported in other engines via MoSDeF. One thing to note while @kierannp and I were working on this is the naming in HOOMD, which can be a bit confusing. There already is a HarmonicImproperForceCompute.cc that computes a true a hoomd.md.improper.Harmonic functional form, and we are adding a hoomd.md.improper.Periodic. So we will call the cpp files PeriodicImproperForceCompute.cc. We may benefit at this time to rename the HarmonicDihedralForceCompute.cc (and like files) to PeriodicDihedralForceCompute.cc to reduce future confusion and potentially open the door for a true HarmonicDihedral force, which should look like any other harmonic force with an (a-a0)**2 type syntax, despite how LAMMPS notates it with a cosine function, and uses the term |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks like a good start! Here are some suggestions for improvement.
assert(improper.tag[3] <= m_pdata->getMaximumTag()); | ||
|
||
// transform a, b, and c into indices into the particle data arrays | ||
// MEM TRANSFER: 6 ints |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// MEM TRANSFER: 6 ints |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reminder to remove this line.
@@ -110,3 +110,46 @@ def __init__(self): | |||
chi0=hoomd.data.typeconverter.nonnegative_real, | |||
len_keys=1)) | |||
self._add_typeparam(params) | |||
|
|||
class Periodic(Improper): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Add this class name to the list in module-md-improper.rst
so the documentation appears.
Yes, feel free to rename |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good so far.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good, I think there are two more of Josh's edits still to get at. Also add your name to this file as well, should we add a note to the changelog?
assert(improper.tag[3] <= m_pdata->getMaximumTag()); | ||
|
||
// transform a, b, and c into indices into the particle data arrays | ||
// MEM TRANSFER: 6 ints |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Reminder to remove this line.
Please don't. HOOMD has so many PRs that all the change log entries would conflict. I build the change log at release time from the drafts in each of the PR descriptions. |
… periodic improper; made modification for suggestions; altered test case in documentation to not produce error
…throws error/warning
Co-authored-by: Tim Moore <[email protected]>
Also complete misc cleanup to bring the code up to modern HOOMD coding standards.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the complete PR and extensive tests.
I pushed a commit that moves the parameters into a GPUArray to reduce code duplication and the chances for errors in that duplication. I also made a few other changes to bring error messages up to modern HOOMD coding standards.
Could you double check my changes and let me know if they are correct? I got a little lost with the parameters. It seems that "d" and "sign" are the same parameter. It also seems that "n", "multi", and "m" are also all the same. You might consider modifying the code to keep the same names throughout to avoid confusion.
The changes you made appear correct. I tried to use the same naming conventions as in similar scripts in HOOMD for calculating forces. I will look into making these variables names more consistent and explicit. |
To clarify a bit more, d is named sign because d is always +-1. n is the multiplicity of the cos function. I would second the fact that we should stick to one value within hoomd. I believe these were derived from this line. When I pull a PR to rename the HarmonicDihedralForce to PeriodicDihedralForce, we can make the same consistent name changes to those files as well. |
Description
Add support for a periodic improper force for 4 atoms bonded as an improper https://manual.gromacs.org/current/reference-manual/functions/bonded-interactions.html#proper-dihedrals-periodic-type
Motivation and context
This is a common functional form in CHARMM-like forcefield and is an easy extension of the periodic dihedral already supported.
How has this been tested?
Created python functions for calculating the force and energy resulting from this functional formal, see hoomd.md.pytest.test_improper.py for detailed test cases and functions to recreate test results.
Change log
Checklist:
sphinx-doc/credits.rst
) in the pull request source branch.