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

Enable PersesAtomMapper #929

Closed
wants to merge 5 commits into from
Closed

Conversation

jthorton
Copy link
Collaborator

@jthorton jthorton commented Sep 3, 2024

Add the missing abstract methods for the PersesAtomMapper and turn on the tests.
Checklist

  • Added a news entry

Developers certificate of origin

@pep8speaks
Copy link

pep8speaks commented Sep 3, 2024

Hello @jthorton! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

There are currently no PEP 8 issues detected in this Pull Request. Cheers! 🍻

Comment last updated at 2024-09-10 14:00:03 UTC

Copy link
Contributor

@RiesBen RiesBen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just have minor comments, appart from those looks good to me :)

openfe/tests/setup/atom_mapping/test_perses_atommapper.py Outdated Show resolved Hide resolved
openfe/tests/setup/atom_mapping/test_perses_atommapper.py Outdated Show resolved Hide resolved
openfe/tests/setup/atom_mapping/test_perses_atommapper.py Outdated Show resolved Hide resolved
Copy link

codecov bot commented Sep 5, 2024

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 92.85%. Comparing base (733908d) to head (79de2e8).

Additional details and impacted files
@@            Coverage Diff             @@
##             main     #929      +/-   ##
==========================================
- Coverage   94.32%   92.85%   -1.48%     
==========================================
  Files         134      134              
  Lines        9917     9932      +15     
==========================================
- Hits         9354     9222     -132     
- Misses        563      710     +147     
Flag Coverage Δ
fast-tests 92.85% <100.00%> (?)
slow-tests ?

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

Copy link
Member

@IAlibay IAlibay left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just the one thing from me

openfe/setup/atom_mapping/perses_mapper.py Show resolved Hide resolved
openfe/setup/atom_mapping/perses_mapper.py Outdated Show resolved Hide resolved
@jthorton
Copy link
Collaborator Author

jthorton commented Sep 5, 2024

I noticed that the type hint for coordinate_tolerance was float which I have updated, I am not sure if this will cause issues in some JSON schema files. Are the atom mapper settings ever saved to file and should I just leave this as float for now and look at this in a PR later?

@IAlibay
Copy link
Member

IAlibay commented Sep 5, 2024

I noticed that the type hint for coordinate_tolerance was float which I have updated, I am not sure if this will cause issues in some JSON schema files. Are the atom mapper settings ever saved to file and should I just leave this as float for now and look at this in a PR later?

Sorry I don't fully understand what you mean here, could you elaborate? As far as I know we haven't ever gotten around to serializing AtomMappers (@RiesBen please correct me!).

Regarding the float -> unit.Quantity, this looks like a legitimate bug being fixed, i.e. if you passed a float it should have been failed, since AtomMapper expects a quantity. I'm happy going with this unless your JSON question highlights something I've completely unware/forgotten about.

Copy link
Member

@IAlibay IAlibay left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me thanks!

openfe/setup/atom_mapping/perses_mapper.py Show resolved Hide resolved
@RiesBen
Copy link
Contributor

RiesBen commented Sep 5, 2024

I noticed that the type hint for coordinate_tolerance was float which I have updated, I am not sure if this will cause issues in some JSON schema files. Are the atom mapper settings ever saved to file and should I just leave this as float for now and look at this in a PR later?

Sorry I don't fully understand what you mean here, could you elaborate? As far as I know we haven't ever gotten around to serializing AtomMappers (@RiesBen please correct me!).

Regarding the float -> unit.Quantity, this looks like a legitimate bug being fixed, i.e. if you passed a float it should have been failed, since AtomMapper expects a quantity. I'm happy going with this unless your JSON question highlights something I've completely unware/forgotten about.

oooooooh wait, we do serialize atom mappers!
This is actually very important, that they are serializable, as Konnektor will bring parallelization of Network generation (and mappings) . If they are not serializable, you will not be able to go parallel. :)

@jthorton
Copy link
Collaborator Author

jthorton commented Sep 5, 2024

If they are not serializable, you will not be able to go parallel. :)

We might be getting two different cases confused, Konnector needs them to work with pickle right for the processpool? which quantities should work with. I meant JSON serialisation as I am unsure it will know what to do with a quantity but maybe that's what the to_dict method is for to work around this?

@IAlibay
Copy link
Member

IAlibay commented Sep 5, 2024

If they are not serializable, you will not be able to go parallel. :)

We might be getting two different cases confused, Konnector needs them to work with pickle right for the processpool? which quantities should work with. I meant JSON serialisation as I am unsure it will know what to do with a quantity but maybe that's what the to_dict method is for to work around this?

Ah ok yes, if your concern is "will X in a gufe serializable go to JSON", in openfe/gufe we use custom codecs to do this: https://github.com/OpenFreeEnergy/gufe/blob/main/gufe/custom_codecs.py

We do not have a specific codec for openmm units/quantities. In this case, the answer is to switch over to openff-units.

@IAlibay
Copy link
Member

IAlibay commented Sep 5, 2024

This is to say @jthorton we should just do the switch to openff units now. It's an API break but I'm happy to label this as a bugfix.

@@ -43,7 +67,7 @@ def __init__(self, allow_ring_breaking: bool = True,
if mappings must strictly preserve chirality, default: True
use_positions: bool, optional
this option defines, if the
coordinate_tolerance: float, optional
coordinate_tolerance: openmm.unit.Quantity, optional
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A note, we say "optional" but none of the type hints say Optional[...].. maybe that's something we should also remember to fix.

Copy link
Member

@IAlibay IAlibay left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's switch to openff units and add a news entry to make it clear we've changed the behaviour (as a bug fix).

@RiesBen RiesBen self-requested a review September 7, 2024 21:39
Copy link
Contributor

@RiesBen RiesBen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one looks cool to me, after @IAlibay comments done and he agrees. :)
Cool addition @jthorton :)

@jthorton
Copy link
Collaborator Author

Thanks @RiesBen and @IAlibay for the review changes done in 79de2e8. The perses tests are still not running though as most depend on openeye shall I just try and include the dict round trip one which shouldn't need openeye?

@IAlibay
Copy link
Member

IAlibay commented Sep 10, 2024

We should have an openeye runner - will need to look into what's happening

@jthorton
Copy link
Collaborator Author

It looks like openeye is not enabled in the testing CI from what I can follow here.

@mikemhenry
Copy link
Contributor

The openeye tests are not running since this is from a fork, which won't have access to the OE license we have for CI, we can either give @jthorton write access to our repo OR I can push this branch to the repo which will then allow the tests to run.

@jthorton
Copy link
Collaborator Author

Thanks @mikemhenry either is fine for me!

@IAlibay
Copy link
Member

IAlibay commented Sep 11, 2024

Let's give him write access.

@mikemhenry
Copy link
Contributor

@jthorton you should have write access, go here: https://github.com/OpenFreeEnergy/openfe to accept the invite if it doesn't show up. Then you should be able to push this branch directly to our repository.

@jthorton jthorton mentioned this pull request Sep 12, 2024
2 tasks
@jthorton jthorton closed this Sep 12, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants