Add additional edges in Dijkstra initialization round

[fdsteffen]

Hi Thomas and Mykola,
I would like to propose a small change to the grid search of LabelLib to avoid empty AVs due to the linker getting blocked close to the attachment point on the biomolecule.
In the initialization round of the Dijkstra algorithm, I suggest to search all grid within a radius linkerDiameterPlusgridSize (i.e linker width + grid spacing) instead of just essentialNeighbours (as in all subsequent rounds).
This prevents the algorithm from terminating prematurely when no grid points are within the 74 essential neighbors edges (i.e. for residues which are slightly less surface-accessible).
Since the extended neighbor list only affects the very first round of the Dijkstra algorithm, the time cost is negligible.
I believe a somewhat similar adjustment for the initialization round was originally proposed in Kalinin, Nat. Methods. (2012).
Let me know what you think.
Kind regards,
Fabio

[mdimura]

Dear Fabio,
Thank you very much for mentioning this and especially for the fix. We should definitely handle and document the issue of the blocked linker better.
Indeed, additional long connections from the attachment node were implemented in the 2012 version of the algorithm. This approach has, however, some caveats. For a linker diameter of 3A, we would effectively punch a hole in the molecule, which is 6A in diameter, which can cause weird AVs, and there would be no way to prevent this for the user of the library. We also use (weighted) AV for fluorescent proteins with peptide linkers, so the linker diameter is ~7A or more.
However, we often have the problem of the blocked C5-type linkers too. We could try to tune the radius of this "hole" around the attachment atom to find the balance between bad (too large) and no AVs.
Another approach that we use is to strip atoms, that are on the way of the linker. A simple version can be found in our pymol script. In this script all atoms in close proximity to the attachment atom are removed before AV generation, which has an effect very similar to what you suggest.

I also had some success stripping sidechain atoms in the attachment residue. In some cases additionally stripping sidechains of neighbors can help too. Also, I use a smaller linker diameter of 2-3A instead of 4.5, which helps with blocking but does not affect good AVs in most cases.

I'm not sure that stripping of the blocking atoms is sufficient though. Do you think we should do both atom stripping and the hole around the attachment atom?

[fdsteffen]

Dear Mykola,
Thanks for your quick reply. I see your approach with stripping sidechain atoms in proximity of the attachment site which I believe is a reasonable strategy if a residue is buried.
Concerning the "hole punching": If I interpret these lines correctly, the Dijkstra algorithm omits all grid points which were previously assigned to belong to the biomolecule (i.e. fillSpheres assigns -1 to all grid points which are within the VdW radius plus some additional padding defined by linkerDiameter*0.5. This padding is not affected by the fix).
Thus, extending the neighbor list should only make the algorithm "reach out" further into the open space without affecting the blocked grid points of the biomolecule. This works out quite well in my experience.
I agree that one still needs to tweak the linker width and smallest radius of the dye a bit sometimes but these parameters are accessible to the user.
Therefore, I think extending the linker list for the attachment point, along with stripping atoms using PyMOL is a viable solution.
Kind regards,
Fabio

[mdimura]

only make the algorithm "reach out" further into the open space

Yes, the linker will "tunnel" through the nearby obstacles and continue propagation. Since obstacles are ignored, it is equivalent to punching a hole, as far as I understand. For example, if we have two sheets of atoms (2-3 layers of graphene), and attach the linker to one side, it would "tunnel" to the other and the AV would be a sphere, not a hemisphere. It's not a realistic example, of course, I only use it for illustration here.
If I understand your suggestion correctly, you effectively set the hole radius to linkerDiameter+ds. The implementation of the hole punching is different compared to the pymol script, but it might be, that the important part is the larger radius.
What if you set the hole radius to linkerDiameter+ds using "pymol" approach, without additional edges, do you get a similar improvement?
Alternatively, we could probably achieve similar results if we add this after line 446:

punch = sourceXyz;
punch[3] = linkerDiameter+ds;
fillSphere(punch, punch[3]);