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

Refactor virtual site handler #1252

Merged
merged 16 commits into from
Apr 19, 2022
Merged

Refactor virtual site handler #1252

merged 16 commits into from
Apr 19, 2022

Conversation

SimonBoothroyd
Copy link
Contributor

@SimonBoothroyd SimonBoothroyd commented Apr 7, 2022

Description

  • 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.

* 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.
@lgtm-com
Copy link

lgtm-com bot commented Apr 7, 2022

This pull request introduces 5 alerts when merging c20a19f into 0aff82e - view on LGTM.com

new alerts:

  • 4 for `__eq__` not overridden when adding attributes
  • 1 for Module is imported with 'import' and 'import from'

@codecov
Copy link

codecov bot commented Apr 7, 2022

Codecov Report

Merging #1252 (9b319c0) into master (fa80730) will decrease coverage by 0.55%.
The diff coverage is 91.36%.

Copy link
Contributor Author

@SimonBoothroyd SimonBoothroyd left a 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.

openff/toolkit/tests/test_forcefield.py Show resolved Hide resolved
openff/toolkit/tests/test_forcefield.py Show resolved Hide resolved
openff/toolkit/tests/test_forcefield.py Show resolved Hide resolved
openff/toolkit/tests/test_forcefield.py Show resolved Hide resolved
openff/toolkit/tests/test_molecule.py Show resolved Hide resolved
openff/toolkit/topology/molecule.py Show resolved Hide resolved
openff/toolkit/topology/molecule.py Show resolved Hide resolved
openff/toolkit/topology/topology.py Show resolved Hide resolved
openff/toolkit/topology/topology.py Show resolved Hide resolved
@lgtm-com
Copy link

lgtm-com bot commented Apr 10, 2022

This pull request introduces 5 alerts when merging 61279e7 into 0aff82e - view on LGTM.com

new alerts:

  • 4 for `__eq__` not overridden when adding attributes
  • 1 for Module is imported with 'import' and 'import from'

@lgtm-com
Copy link

lgtm-com bot commented Apr 11, 2022

This pull request introduces 5 alerts when merging 53a93de into 0aff82e - view on LGTM.com

new alerts:

  • 4 for `__eq__` not overridden when adding attributes
  • 1 for Module is imported with 'import' and 'import from'

@mattwthompson mattwthompson added this to the 0.10.5 milestone Apr 12, 2022
Comment on lines +140 to +142
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.
Copy link
Member

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.

@lgtm-com
Copy link

lgtm-com bot commented Apr 19, 2022

This pull request introduces 5 alerts when merging 5da978a into fa80730 - view on LGTM.com

new alerts:

  • 4 for `__eq__` not overridden when adding attributes
  • 1 for Module is imported with 'import' and 'import from'

@lgtm-com
Copy link

lgtm-com bot commented Apr 19, 2022

This pull request introduces 5 alerts when merging 0fb3c3f into fa80730 - view on LGTM.com

new alerts:

  • 4 for `__eq__` not overridden when adding attributes
  • 1 for Module is imported with 'import' and 'import from'

@j-wags
Copy link
Member

j-wags commented Apr 19, 2022

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.

@lgtm-com
Copy link

lgtm-com bot commented Apr 19, 2022

This pull request introduces 5 alerts when merging 112c801 into fa80730 - view on LGTM.com

new alerts:

  • 4 for `__eq__` not overridden when adding attributes
  • 1 for Module is imported with 'import' and 'import from'

@lgtm-com
Copy link

lgtm-com bot commented Apr 19, 2022

This pull request introduces 5 alerts when merging 9b319c0 into fa80730 - view on LGTM.com

new alerts:

  • 4 for `__eq__` not overridden when adding attributes
  • 1 for Module is imported with 'import' and 'import from'

Copy link
Member

@j-wags j-wags left a 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 :-)

@j-wags j-wags merged commit cba4ae3 into master Apr 19, 2022
@j-wags j-wags deleted the refactor-v-sites branch April 19, 2022 05:28
SimonBoothroyd added a commit that referenced this pull request Apr 25, 2022
* 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.
j-wags added a commit that referenced this pull request May 6, 2022
* 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>
@mattwthompson
Copy link
Member

I'm a bit confused why this logic in VirtualSiteHandler._create_openff_virtual_sites is not found a few lines above when creating the OpenMM particles. Should the same attempts be made to ensure identical particles don't sit on top of each other in OpenMM, or is that handled somewhere I missed?

@mattwthompson mattwthompson mentioned this pull request Jun 21, 2022
1 task
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment