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

Konnektor integration #927

Open
wants to merge 19 commits into
base: main
Choose a base branch
from
Open

Konnektor integration #927

wants to merge 19 commits into from

Conversation

RiesBen
Copy link
Contributor

@RiesBen RiesBen commented Sep 3, 2024

This PR is integrating Konnektor to openFE which will offer in the future a default parallelization for all Network building and more different network tools.
In this PR there is one paradigm change currently present, leading to only being able to pass one Atom mapper to the functions.

Checklist

Developers certificate of origin

@pep8speaks
Copy link

pep8speaks commented Sep 3, 2024

Hello @RiesBen! 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-18 21:06:49 UTC

@RiesBen
Copy link
Contributor Author

RiesBen commented Oct 22, 2024

This PR should be ready for review to merge after this merge happened:
OpenFreeEnergy/konnektor#84

need to look into further other unit test failures.

@RiesBen RiesBen changed the title [WIP] - Konnektor integration Konnektor integration Oct 22, 2024
@jameseastwood
Copy link
Contributor

Please discuss with @atravitz and @hannahbaumann as part of the Konnektor handover plans.

@jameseastwood
Copy link
Contributor

Needs follow-up discussion in a meeting planned for Oct. 28

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.

Mostly blocking on API breaks - I agree that the name change may make sense in some cases, but these are very much user facing methods and we cannot break the API for 1.x, especially without some kind of deprecation cycle.

openfe/setup/ligand_network_planning.py Outdated Show resolved Hide resolved
@@ -160,7 +167,7 @@ def generate_maximal_network(
----------
ligands : Iterable[SmallMoleculeComponent]
the ligands to include in the LigandNetwork
mappers : AtomMapper or Iterable[AtomMapper]
mapper : AtomMapper or Iterable[AtomMapper]
Copy link
Member

Choose a reason for hiding this comment

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

This docstring rename doesn't match the current signature (note that we can't rename from mappers to mapper without causing an API break).

Copy link
Member

Choose a reason for hiding this comment

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

@atravitz you marked this as resolved but the docstring still doesn't match - was this intentional?

openfe/setup/ligand_network_planning.py Outdated Show resolved Hide resolved
openfe/setup/ligand_network_planning.py Show resolved Hide resolved
openfe/setup/ligand_network_planning.py Show resolved Hide resolved
openfe/setup/ligand_network_planning.py Outdated Show resolved Hide resolved
openfe/setup/ligand_network_planning.py Outdated Show resolved Hide resolved
openfe/setup/ligand_network_planning.py Outdated Show resolved Hide resolved
openfe/setup/ligand_network_planning.py Outdated Show resolved Hide resolved
@@ -4,6 +4,7 @@ channels:
dependencies:
- duecredit<0.10
- kartograf>=1.0.0
- konnektor
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we need to make a Konnektor v0.2.0 release with this change, then pin this with konnektor>=v0.2.0.

openfe/setup/ligand_network_planning.py Outdated Show resolved Hide resolved
openfe/setup/ligand_network_planning.py Outdated Show resolved Hide resolved
openfe/setup/ligand_network_planning.py Show resolved Hide resolved
openfe/setup/ligand_network_planning.py Show resolved Hide resolved
@@ -130,21 +130,7 @@ def test_radial_network_index_error(toluene_vs_others, lomap_old_mapper):
ligands=ligands, central_ligand=2077,
mappers=lomap_old_mapper, scorer=None,
)


def test_radial_network_self_central(toluene_vs_others, lomap_old_mapper):
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This can not happen anymore with the current Konnektor and OpenFE implementation.
I propose removing the test.

Copy link
Contributor

Choose a reason for hiding this comment

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

@IAlibay is there a concern about breaking backwards compatibility here?

Copy link
Member

Choose a reason for hiding this comment

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

By "this cannot happen" do we mean that Konnektor just gracefully handles things such that the network cannot end up with a self edge?

If so, then my suggestion is to keep the code that throws a warning?

If it's more "if you try to do that Konnektor will error", then we should retain the behaviour that pops the ligand out and throws the warning, with a deprecation warning that this behaviour will go away in 2.0.

@RiesBen
Copy link
Contributor Author

RiesBen commented Oct 29, 2024

I went further through the current CI problems and hope I caught all problems for this PR (@atravitz):

  • *unreachable unit tests: there a error messages missing. -> We need to check why this error is not appearing. This should be thrown at the Konnektor level.
  • generate maximal network: the unitest behavior expects each edge direction leading to 56 edges. I assume it is either due to directionality of edges or number of possible mappings? However, Konnektor considers edges as non-directed at the current time point and allows only on possible mapper solution == one edge. Therefore it returns 28 edges. Other approaches might lead to problems with the graph algorithms. -> I would propose to adjust the edge number to 28. After verifying the behavior reason.
  • redundant mst: generates one edge to less then expected? (expected 14 (2*(n-1)), got 13) -> need to look into why this is.
  • explicit networks: The problem here is image you get a list of 8 ligands and 2 defined edges. Currently only the connected part is returned as a ligand network, so two edges with 3 nodes. That clashes with the current unit tests, expecting 3 edges and 8 nodes. This translates to the expectation of getting back a disconnected network as a default. I'm not sure why here it was allowed to generate disconnected networks. -> I would propose to throw an error in these cases in order to avoid user confusion.

@atravitz atravitz force-pushed the KonnektorIntegration branch 3 times, most recently from 1205c63 to 46986af Compare November 6, 2024 20:01
RiesBen and others added 10 commits November 15, 2024 09:46
- fix removing the central ligand from list.
remove test for testing if a central component is part of the other component list. This can not happen anymore with the current Konnektor implementation, therefore I propose removing the test.
@atravitz atravitz force-pushed the KonnektorIntegration branch from 24a7abd to 6d3e59a Compare November 15, 2024 17:46
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.

partial review

mappers: Union[AtomMapper, Iterable[AtomMapper]],
central_ligand: Union[SmallMoleculeComponent, str, int, None],
Copy link
Member

Choose a reason for hiding this comment

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

I wouldn't change the order unless we really have to - i.e. it's technically API breaking in the case that someone just passes arguments without specifying them?

@@ -160,7 +167,7 @@ def generate_maximal_network(
----------
ligands : Iterable[SmallMoleculeComponent]
the ligands to include in the LigandNetwork
mappers : AtomMapper or Iterable[AtomMapper]
mapper : AtomMapper or Iterable[AtomMapper]
Copy link
Member

Choose a reason for hiding this comment

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

@atravitz you marked this as resolved but the docstring still doesn't match - was this intentional?

edges = []

for ligand in ligands:
if ligand == central_ligand:
Copy link
Member

Choose a reason for hiding this comment

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

What happens in the new code if you pass in multiple copies of the same central ligand in the ligand list?

@@ -160,7 +171,7 @@ def generate_maximal_network(
----------
ligands : Iterable[SmallMoleculeComponent]
the ligands to include in the LigandNetwork
mappers : AtomMapper or Iterable[AtomMapper]
mapper : AtomMapper or Iterable[AtomMapper]
Copy link
Member

Choose a reason for hiding this comment

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

revert to mappers?

Copy link

github-actions bot commented Dec 9, 2024

🚨 API breaking changes detected! 🚨

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants