Prolif class implementation

[talagayev]

First draft of the ProLIF implementation into OpenFE Analysis.

Changes made:

• creation of ProLIFAnalysis class for calculation of interactions using ProLIF
• Addition of first tests in test_prolif.py, which mainly look into if interactions were calculated sucessfully and protein/ligand conversion from MDAnalysis into ProLIF worked sucessfully.

Currently that is the first draft and PR is to see that the tests work etc.

Some notes:

• Currently this is just calculating and returning the results in pd.DataFrame format, since that is easy to see if it worked. We can see what the best way is to present the results, be it 2D visualization of the interactions, dataframes or some other format.
• As was mentioned by Irfan, the recognition and conversion of protein in MDAnalysis is sometimes tricky, which is the case here. So the code currently needs to guess bonds, which it does here:
  universe.select_atoms("protein").guess_bonds(vdwradii=vdwradii)
  But for the vdwradii it wants some values for Cl, Br etc. that we need to provide, so we need to see what defaults we select there.
• For interactions we need to check what the default option should be, if default == all interactions or some interactions etc. and if the water-bridge interactions are default and if so, what water-bridge interaction order we make default. the current one is 3, which means it can be something like:
  Ligand -- Water -- Water -- Water -- Protein
• Same goes with ProLIFAnalysis.run() there we can also look into what the defaults have to be, how many cores and if the interactions should be atom based (Ligand with Protein atom) or residue based (Ligand with Protein residue).

This is the first draft, will be updated during further development :)

PS. A small thing I also noticed, since I tested it on different PCs with one being with Windows currently somehow python 3.14 has module loading Issues with rdkit and thus I had to downgrade there to python 3.13.

[codecov]

Codecov Report

❌ Patch coverage is 78.08219% with 16 lines in your changes missing coverage. Please review.
✅ Project coverage is 92.87%. Comparing base (5260e3b) to head (47060fb).
⚠️ Report is 12 commits behind head on main.

Files with missing lines	Patch %	Lines
src/openfe_analysis/prolif.py	78.08%	16 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main      #88      +/-   ##
==========================================
+ Coverage   88.16%   92.87%   +4.70%     
==========================================
  Files           7        7              
  Lines         338      407      +69     
==========================================
+ Hits          298      378      +80     
+ Misses         40       29      -11     

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

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[IAlibay]

Can you subclass AnalysisBase here?

[talagayev]

Yup should be doable, will look into it :)

Wanted to wait and see how RMSD will look like to use an identical structure and have this initial PR to have bulletpoints to discuss tomorrow during the meeting and also have an easier overview on what was changed etc. :)

[jthorton]

I am not sure if this should be handled in the analysis class or in a protocol before running this class but there is an issue when doing this kind of analysis on trajectories from our hybrid topology protocol, where the connectivity of the end state ligands and identities of the atoms can get confused see this example on end stateB when looking at torsions. Should we add an option to provide and rdkit molecule for the ligand and use this to correct the ligand atom group automatically or should we have users fix this beforehand? This will be needed in the torsion analysis as well so a general function which could fix an atom group might be a good idea?

[hannahbaumann]

Yes, I agree I think it would be great to have these (also for water below) as args.

[hannahbaumann]

Maybe instead raise a warning, or what would happen if there are individual frames that don't have water molecules?

[talagayev]

Yes warining would be better in that case, since that is quite a possible scenario, best approach would be truly warning + remove the water_bridge interaction so that it doesn't run when there are no waters, since I would need to check, but I think currently it would possibly still try to run it 🤔