Konnektor integration

[RiesBen]

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

• replace code with Konnektor implementations

  • MST
  • Maximal Network
  • Star Map
  • Redundant MST
  • Explicit networks

• Test we are getting the same results

  • pytest suit - depends on adapting the Konnektor behavior to openfe. konnektor#84

Developers certificate of origin

• I certify that this contribution is covered by the MIT License here and the Developer Certificate of Origin at https://developercertificate.org/.

[pep8speaks]

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]

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.

[jameseastwood]

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

[jameseastwood]

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

[IAlibay]

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.

[atravitz]

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

[RiesBen]

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

[atravitz]

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

[IAlibay]

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]

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.