Symmetry detection fails for long twisted assemblies

[biocryst]

For examples look at 6CL5, 6GAO, 5JXC.

The problem, I believe, is in the following:

1. Subunits are represented via their centers:
   

   biojava/biojava-structure/src/main/java/org/biojava/nbio/structure/symmetry/core/RotationSolver.java

   Line 459 in 2bb0857

   originalCoords[i] = centers.get(i);

2. Permutation of the centers is used to derive transformations:
   

   biojava/biojava-structure/src/main/java/org/biojava/nbio/structure/symmetry/core/RotationSolver.java

   Lines 232 to 233 in 2bb0857

   	Quat4d quat = UnitQuaternions.relativeOrientation(
   	originalCoords, transformedCoords);

   ...
   

   biojava/biojava-structure/src/main/java/org/biojava/nbio/structure/symmetry/core/RotationSolver.java

   Line 237 in 2bb0857

   transformation.set(quat);

3. The transformations are applied to the whole subunits
   

   biojava/biojava-structure/src/main/java/org/biojava/nbio/structure/symmetry/core/RotationSolver.java

   Line 260 in 2bb0857

   QuatSymmetryScores scores = QuatSuperpositionScorer.calcScores(subunits, transformation, permutation);

4. The centers of long twisted chains are not representative well enough. E.g., in 6CL5 the centers are within ~1A of each other. Since the chains are not perfectly symmetrical, the transformations derived from the centers are essentially random.

There may also a potential problem in generating permutations for such structures. The "closest neighbor" center would not necessarily represent the chain that's being superposed, which may affect validity of the permutations. Although at the moment I do not fully understand how this part of the code works, it's around here:

biojava/biojava-structure/src/main/java/org/biojava/nbio/structure/symmetry/core/RotationSolver.java

Line 401 in 2bb0857

private List<Integer> getPermutation() {

If we replace the centers with the full list coordinates, it will fix the problem, but obviously affect the performance by quite a bit. So I suggest doing something in-between, i.e., splitting the chains into several segments of consecutive residues and calculating centers for those segments. The number of segments can be a parameter in the QuatSymmetryParameters class.

Any thoughts, suggestions? Thank you!

[pwrose]

Interesting case! How about checking if the centers of mass of the subunits are too close (based on a threshold) and if they are below a threshold, switch to the all-atom comparison?

…

On Fri, Aug 24, 2018 at 6:02 PM Dmytro Guzenko ***@***.***> wrote: For examples look at 6CL5, 6GAO, 5JXC. The problem, I believe, is in the following: 1. Subunits are represented via their centers: https://github.com/biojava/biojava/blob/2bb08570f8a79e27e958b5c136207e2192868aa7/biojava-structure/src/main/java/org/biojava/nbio/structure/symmetry/core/RotationSolver.java#L459 2. Permutation of the centers is used to derive transformations: https://github.com/biojava/biojava/blob/2bb08570f8a79e27e958b5c136207e2192868aa7/biojava-structure/src/main/java/org/biojava/nbio/structure/symmetry/core/RotationSolver.java#L232-L233 ... https://github.com/biojava/biojava/blob/2bb08570f8a79e27e958b5c136207e2192868aa7/biojava-structure/src/main/java/org/biojava/nbio/structure/symmetry/core/RotationSolver.java#L237 3. The transformations are applied to the whole subunits https://github.com/biojava/biojava/blob/2bb08570f8a79e27e958b5c136207e2192868aa7/biojava-structure/src/main/java/org/biojava/nbio/structure/symmetry/core/RotationSolver.java#L260 4. The centers of long twisted chains are not representative well enough. E.g., in 6CL5 the centers are within ~1A of each other. Because the chains are not perfectly symmetrical, the transformations derived from the centers are essentially random. There may also a potential problem in generating permutations for such structures. The "closest neighbor" center would not necessarily represent the chain that's being superposed, which may affect validity of the permutations. Although at the moment I do not fully understand how this part of the code works, it's around here: https://github.com/biojava/biojava/blob/2bb08570f8a79e27e958b5c136207e2192868aa7/biojava-structure/src/main/java/org/biojava/nbio/structure/symmetry/core/RotationSolver.java#L401 If we replace the centers with the full list coordinates, it will fix the problem, but obviously affect the performance by quite a bit. So I suggest doing something in-between, i.e., splitting the chains into several segments of consecutive residues and calculating centers for those segments. The number of segments can be a parameter in the QuatSymmetryParameters class. Any thoughts, suggestions? Thank you! — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#795>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADuwEOxkA539d3LO0l-cuL4cb8c2DPE-ks5uUKIPgaJpZM4WMLMg> .

-- Peter Rose, Ph.D. Director, Structural Bioinformatics Laboratory San Diego Supercomputer Center UC San Diego +1-858-822-5497

[lafita]

These assemblies have very elongated subunits and large interfaces, so this might be another property to identify them and switch to the all-atom comparison.

[sbliven]

All-atom is probably overkill if we're worried about performance. We could get by with some small set of atoms that preserves the orientation. The principal axes might work, or even a small random sample (say, 10 atoms).

The centroid method fails to account for orientation, so it would also fail for globular asymmetric complexes if their centroids happened to fall on a circle. We've been fortunate so far in that the vast majority of homooligomers really do have symmetry so the centroid heuristic works well.

[sbliven]

This might improve helix visualization too (#306)