-
Notifications
You must be signed in to change notification settings - Fork 18
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
Add support for Foyer forcefields #517
Conversation
for more information, see https://pre-commit.ci
Wow, this is a nice surprise! Make sure you add Don't worry about the OpenEye parts of the matrix, but you can force the tests to run in those cases by adding |
@mattwthompson with the current code the tests run fine
but when I run a delta H vaporization simulation using my production script I get
Would you know off hand why that is? |
The traceback looks like it's not coming from a development/editable install - does |
Yes, I pip installed it to test it with the production script |
for more information, see https://pre-commit.ci
Co-authored-by: Matt Thompson <matt.thompson@openforcefield.org>
for more information, see https://pre-commit.ci
… other mixing rules
The error I'm seeing in tests:
usually stems from the periodicity not being set. If |
<HarmonicBondForce> | ||
<Bond class1="OW_tip3p" class2="HW_tip3p" length="0.09572" k="1884.06"/> | ||
</HarmonicBondForce> | ||
<HarmonicAngleForce> | ||
<Angle class1="HW_tip3p" class2="OW_tip3p" class3="HW_tip3p" angle="1.82421813" k="230.274"/> | ||
</HarmonicAngleForce> |
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.
TIP3P is supposed to be a fixed model, but I don't think Foyer support constraints in its force field schema? We always did that at simulation runtime, I think
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.
The test builds a rigid tip3p model HOWEVER this seems due to a short circuit in TemplateBuildSystem._execute
that forces all water to be rigid tip3p with TemplateBuildSystem._build_tip3p_system
. Is the intent to always override any water with tip3p in evaluator?
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.
I don't think that's the intent
interchange = Interchange.from_foyer(topology=topology, force_field=force_field) | ||
|
||
openmm_pdb_file = app.PDBFile(self.coordinate_file_path) | ||
if openmm_pdb_file.topology.getPeriodicBoxVectors() is not None: | ||
interchange.box = openmm_pdb_file.topology.getPeriodicBoxVectors() | ||
|
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.
Does this mean Interchange.from_foyer
isn't parsing the box vectors on the topology
argument? If so, I think that's a bug
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.
topology
is not an argument to _parameterize_molecule
, just the molecule
itself which contains no box information, the better fix would be to pass the topology to _parameterize_molecule
but I'm trying to make the smallest changes I can
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.
the topology
being passed to interchange is from molecule.to_topology()
not from TemplateBuildSystem._execute.topology
(which isn't passed as an argument to _parameterize_molecule
)
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.
That makes sense, I was misreading the code then
…e to _append_system
for more information, see https://pre-commit.ci
for more information, see https://pre-commit.ci
@aehogan I think this is ready to go? Is there anything more you were looking to do, and have you been able to use this in your studies? If there aren't issues you've ran into, I think I'll give this another review and look to merge it into a release soon. How does that sound to you? The changeset is smaller than I originally anticipated, but thinking through it again, it shouldn't be a surprise that it doesn't need to do much more than swap out the force field source. |
@mattwthompson There are still one or two more issues with running a full delta H vaporization simulation I need to iron out. Besides that I was going to change out the xml test with a methane so that part of the code is actually tested. |
Sounds good, let me know when you think it's ready - no rush |
…hane, add energy minimization to oplsaa test to ensure openmm successfully runs
…tem is built correctly
@mattwthompson should be good now |
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.
I once again trust this is working for simulations in your research; the code looks great but it's hard to say much comprehensively without battle-testing it since Evaluator relies so much on things that take a long time to test.
Could you also merge the main
branch back in add a one-liner to the "Current development" section? Copying the name of the PR is plenty.
Merge openforcefield/main
Awesome work! |
Thanks! Delta H vaporization, delta H mixing and densities have all run successfully now. |
Description
Add support for Foyer forcefields
Todos
Questions
Status