Improving LigNetwork Visualization in ProLIF: Automating Residue Placement & Expanding 2D Interaction Maps | Project #7, GSoC 2025 | Aarya Pandey

[geeky33]

Hi @cbouy, @talagayev and team! I'm Aarya.

I've been looking at Project 7 of improving the LigNetwork plot in ProLIF. I thought it would be nice if I could share my thoughts and gather your feedback to ensure alignment with the project’s vision and that my thoughts are not very off.

I've tried to split the project into 4 major parts, and have elaborated my thoughts on each of them later.

1. Automated Residue Placement in LigNetwork
2. Heatmap Visualisation for Ligand Atoms
3. Interaction Drawer Compatibility
4. Flareplot Integration

DETAILED OVERVIEW

1. Automated Residue Placement in LigNetwork

From reviewing the code, I can see that the LigNetwork class creates an interactive network diagram using the vis.js library. It displays the ligand molecule with appropriate atom and bond representations, protein residues as nodes and interactions between ligand atoms and protein residues as edges. Currently, the placement of residues appears to be handled by vis.js's physics engine, which is turned off after stabilization occurs (network.setOptions({ physics: false })). This explains why users need to manually drag residues to make the visualisation more readable.

(a) Ligand-at-the-center Visualisation

The first idea was to simply use the ligand’s 2D coordinates (from RDKit) as the central reference. For each residue, calculate the centroid of its interacting ligand atoms and then position residues radially around this centroid at a fixed distance (e.g., 1.5*ligand size). I suspect there will be a great overlap of residues, and this issue must be handled separately, as this will recur irrespective of the visualisation technique chosen (mostly).

(b) Interaction-strength-based Visualisation

We can position the residues at a distance from the ligand proportional to their interaction strength, with stronger interactions placed closer.

Upon googling and GPTing more about this idea, I did come across something called Edge-crossing Minimisation Visualisation, where the idea is to implement a force-directed algorithm specifically designed to minimize edge crossings, possibly using techniques from graph drawing like the Sugiyama algorithm. However, I am not yet aware of the details of this algorithm and am not specifically sure how this will be utilised. But it is surely something on my cards as of now.

2. Heatmap Visualisation for Ligand Atoms.

In the current implementation of the LigNetwork class, the focus is on nodes/edges (ligand atoms and residues) and does not track interaction weights spatially. The from_fingerprint method aggregates interaction data but does not expose per-atom metrics. I went through the paper attached https://jcheminf.biomedcentral.com/articles/10.1186/1758-2946-5-43 and understood that we have to add a heatmap parameter to overlay 2D Gaussian blobs on ligand atoms.

Since this would be a newer implementation, I have yet to spend some more time figuring out how we can compute the interaction weight/strength distances to be visualised on the heatmap.

3. Interaction Drawer Compatibility

The current LigNetwork generates a custom HTML/JS output tailored for vis.js. Hence, there is no existing code map ProLIF metadata to InteractionDrawer’s schema. I inspected the https://github.com/rareylab/InteractionDrawer library, and in my current understanding, we have to add a new method like LigNetwork.to_interaction_drawer() to serialize interactions into InteractionDrawer’s JSON format.

I saw _get_records method extracts interaction metadata. The thought is to reuse this for the above-mentioned JSON serialization.

4. Flareplot Integration

Currently, I didn't see any code to generate residue-level interaction networks (required for Flareplot).

My initial thought is to create a new class, ResidueNetwork, to aggregate residue-residue interactions (e.g., hydrogen bonds, salt bridges). But again, need to think more on this.

TECHNICAL/IMPLEMENTATION QUESTIONS (as of now)

(a) I noticed that the current implementation uses vis.js for rendering. Would it be okay to consider alternatives like D3.js as it is the library I've previously worked extensively for creating data visualisations?

(b) Can we modify the existing API a little bit? I'm thinking we could add a layout parameter to the constructor to allow users to choose between automatic placement strategies.

At this point, I saw some plotting-related open issues in ProLIF and would be diving deep into the plotting section of the codebase to work on them. Maybe I am thinking of starting with a prototype of the automated residue placement algorithm and exploring minimizing edge crossings and overlap. Once we have a basic implementation, we can refine it based on feedback.

What are your thoughts on this approach? Are there any specific use cases or examples where you would want me to focus on?

Looking forward to your feedback and insights! And thank you very much for your time (and for reading this long discussion)!

Best regards,
Aarya Pandey.

---

[cbouysset]

Hi Aarya and thank you for considering contributing to ProLIF through a GSoC!

I'll only answer to the two questions at the bottom of your post to keep the replies going quickly, but I'd say you can go ahead and put this in a pre-proposal already.

(a) I noticed that the current implementation uses vis.js for rendering. Would it be okay to consider alternatives like D3.js as it is the library I've previously worked extensively for creating data visualisations?

I don't have a strong attachment to vis.js, it did the job I wanted at the time, however if we were to switch to D3 there are a few things to consider:

• first we'd need to implement all the features that are already present in the current LigNetwork, i.e. labelling with percentages of occurrence of each interaction with the recent (unreleased) show_interaction_data=True parameter, showing the distance of the interaction on hover, hiding interaction types and residues types from the visualisation by clicking on the legend.
• next there's the question on maintainability: I've never used D3 (but it's used everywhere so it sounds like a good upgrade to have) which means if things break I might struggle to implement a fix, and during the implementation you wouldn't be able to receive help from me or @talagayev.

So not saying this is a bad idea, just that there would be quite a lot of responsibility on your shoulders, which may not put you up to success for the GSoC project.

(b) Can we modify the existing API a little bit? I'm thinking we could add a layout parameter to the constructor to allow users to choose between automatic placement strategies.

Adding new optional parameters is fine, it's only modifying existing parameters/methods that can be a bit tricky, but I don't think that's going to be the case here.

At this point, I saw some plotting-related open issues in ProLIF and would be diving deep into the plotting section of the codebase to work on them.

So the issues that have the visualisation label are either essentially what this GSoC project is about, or there's one issue around saving the plots which is actually already solved, I just need to close it once I make a release.

Maybe I am thinking of starting with a prototype of the automated residue placement algorithm and exploring minimizing edge crossings and overlap. Once we have a basic implementation, we can refine it based on feedback.

Yes starting with a simple prototype and iterating over it would be the preferred option.

---

But anyway I'd say you can put this in a pre-proposal already, we can polish it later 👍