-
Notifications
You must be signed in to change notification settings - Fork 92
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
Refactor virtual site handler #1252
Conversation
* Attempts to make virtual site handler more resilient through code simplification. * Virtual sites are now associated with a particular 'parent' atom, rather than with a set of atoms. In particular, when checking if a v-site has been assigned we now only check the main 'parent' atom associated with the v-site, rather than all additional orientation atoms. As an example, if a force field contained a bond-charge v-site that matches [O:1]=[C:2] and a monovalent lone pair that matches [O:1]=[C:2]-[*:3] in that order, then only the monovalent lone pair will be assigned to formaldehyde as the oxygen is the main atom that would be associated with both v-sites, and the monovalent lone pair appears later in the hierarchy. This constitutes a behaviour change over previous versions. * all v-site exclusion policies have been removed except for 'parents' which has been updated to match OFF-EP 0006. * checks have been added to enforce that the 'match' keyword complies with the SMIRNOFF spec. * Molecule virtual site classes no longer store FF data such as epsilon and sigma. * Sanity checks have been added when matching chemical environments for v-sites that ensure the environment looks like one of our expected test cases. * Fixes di(try)talent lone pairs mixing the :1 and :2 indices. * Fixes trivalent v-site positioning. * Correctly splits `TopologyVirtualSite` and `TopologyVirtualParticle` so that virtual particles no longer have attributes such as `particles`, and ensure that indexing methods now work correctly.
This pull request introduces 5 alerts when merging c20a19f into 0aff82e - view on LGTM.com new alerts:
|
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.
@j-wags I'm not sure if it's helpful but I've added these comments to try and add context for the larger deletions / changes outside of parameters
in order to try and make it a bit easier to review.
This pull request introduces 5 alerts when merging 61279e7 into 0aff82e - view on LGTM.com new alerts:
|
This pull request introduces 5 alerts when merging 53a93de into 0aff82e - view on LGTM.com new alerts:
|
The distinction between a virtual site and virtual particle is due to be removed in a future | ||
version of the toolkit, and a 'virtual site' will simply refer to one massless particle placed | ||
on a parent atom rather than to a collection of massless particles. |
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 means that in the future, an API will offer access to VSites, and never make mention of VParticles. If two VSites (new definition) are actually based on the same FF parameter, the user can tell this by seeing that they have the same name and parent atom.
… error text even wordier
This pull request introduces 5 alerts when merging 5da978a into fa80730 - view on LGTM.com new alerts:
|
This pull request introduces 5 alerts when merging 0fb3c3f into fa80730 - view on LGTM.com new alerts:
|
Thanks, Matt! For the record, 4/5 of the the LGTM alerts are complaining about the VirtualSite classes that attach to Molecules. Since we're planning to remove the VirtualSite classes in 0.11.0 I'm not too concerned about the alerts. |
This pull request introduces 5 alerts when merging 112c801 into fa80730 - view on LGTM.com new alerts:
|
This pull request introduces 5 alerts when merging 9b319c0 into fa80730 - view on LGTM.com new alerts:
|
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 is totally awesome. Thanks so much for the brilliant work, @SimonBoothroyd - This knocks out a whole swath of issues and cuts down on a lot of complexity. I haven't kept up with much of your other work, but this refactor is a real programming tour de force, so now I'm excited to read the other code you've made.
I'm not certain that this fixes #1223 - Visual observation still makes it seem like something is a bit off geometrically. So I'm leaving that off the list of issues that this PR closes so we can double check it later.
This is good to merge once tests pass, and then we can move on to 0.10.5, @mattwthompson :-)
* Refactor virtual site handler * Attempts to make virtual site handler more resilient through code simplification. * Virtual sites are now associated with a particular 'parent' atom, rather than with a set of atoms. In particular, when checking if a v-site has been assigned we now only check the main 'parent' atom associated with the v-site, rather than all additional orientation atoms. As an example, if a force field contained a bond-charge v-site that matches [O:1]=[C:2] and a monovalent lone pair that matches [O:1]=[C:2]-[*:3] in that order, then only the monovalent lone pair will be assigned to formaldehyde as the oxygen is the main atom that would be associated with both v-sites, and the monovalent lone pair appears later in the hierarchy. This constitutes a behaviour change over previous versions. * checks have been added to enforce that the 'match' keyword complies with the SMIRNOFF spec. * Molecule virtual site classes have been removed * Sanity checks have been added when matching chemical environments for v-sites that ensure the environment looks like one of our expected test cases. * Fixes di(try)talent lone pairs mixing the :1 and :2 indices. * Fixes trivalent v-site positioning.
* Cherry-pick 'Refactor virtual site handler' (#1252) * Refactor virtual site handler * Attempts to make virtual site handler more resilient through code simplification. * Virtual sites are now associated with a particular 'parent' atom, rather than with a set of atoms. In particular, when checking if a v-site has been assigned we now only check the main 'parent' atom associated with the v-site, rather than all additional orientation atoms. As an example, if a force field contained a bond-charge v-site that matches [O:1]=[C:2] and a monovalent lone pair that matches [O:1]=[C:2]-[*:3] in that order, then only the monovalent lone pair will be assigned to formaldehyde as the oxygen is the main atom that would be associated with both v-sites, and the monovalent lone pair appears later in the hierarchy. This constitutes a behaviour change over previous versions. * checks have been added to enforce that the 'match' keyword complies with the SMIRNOFF spec. * Molecule virtual site classes have been removed * Sanity checks have been added when matching chemical environments for v-sites that ensure the environment looks like one of our expected test cases. * Fixes di(try)talent lone pairs mixing the :1 and :2 indices. * Fixes trivalent v-site positioning. * [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci * Fix tests * Fix mypy * [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci * finish up serialization test * [pre-commit.ci] auto fixes from pre-commit.com hooks for more information, see https://pre-commit.ci * disable vsite example notebook test * fix typo Co-authored-by: pre-commit-ci[bot] <66853113+pre-commit-ci[bot]@users.noreply.github.com> Co-authored-by: Matthew W. Thompson <mattwthompson@protonmail.com> Co-authored-by: Jeff Wagner <jwagnerjpl@gmail.com>
I'm a bit confused why this logic in |
Description
TopologyVirtualSite
andTopologyVirtualParticle
so that virtual particles no longer have attributes such asparticles
, and ensure that indexing methods now work correctly.TrivalentLonePairVirtualSite
possibly out of order #1235