Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Show more interface information in 3D and 2D graph views #135

Open
josemduarte opened this issue Jul 12, 2016 · 6 comments
Open

Show more interface information in 3D and 2D graph views #135

josemduarte opened this issue Jul 12, 2016 · 6 comments
Milestone

Comments

@josemduarte
Copy link
Contributor

Marking isologous/heterologous interfaces in the graph views would be very useful to help understanding the topology in the graph visually. In 3D we could simply use different shapes (e.g. circles for isologous, squares for heterologous). In 2D we could do something similar but flattened.

Another possibility would be to show the exact interface type: 2-fold, 2-fold screw, 3-fold etc. We have the interface character only for crystal symmetry so that wouldn't be complete, for instance it wouldn't show a dimer in AU as 2-fold.

@lafita
Copy link
Member

lafita commented Aug 30, 2016

I thought we had an issue about computing the exact interface type (character), but I could not found it.

The idea we discussed was to superpose the two chains if they are identical (same cluster) and obtain the transformation matrix. From the rotational and translational components of the matrix the interface character can be defined (2 fold: 180 degrees, 3-fold: 120 degrees, etc and screw if translation is present).

@josemduarte
Copy link
Contributor Author

That would be great to have, it would definitely help in the graphical representation to understand the relationship between chains. But also it would be useful for analysis and many other things.

@sbliven
Copy link
Member

sbliven commented Aug 31, 2016

Transformation matrices shouldn't be needed. Just looking at the order of the cycle induced by engaging that interface should be enough. I'm assuming homomeric complexes here; I'm not sure how this would apply to hetermers.

@josemduarte
Copy link
Contributor Author

The matrices would be needed if doing the order identification before having the graph (e.g. to do some database mining). Also for some cases the graph would not be able to tell the order, e.g. one of those open heterologous interfaces that don't continue throughout the crystal because some other crystal contact caps them. In those cases the matrix would tell us the order (where the cycle couldn't).

True that for the original issue described above (show more info in graph views) cycles are enough to identify the order.

In any case I see this feature as low priority, I'd leave it for 3.1 or later.

@josemduarte josemduarte added this to the 3.1 milestone Aug 31, 2016
@lafita
Copy link
Member

lafita commented Sep 1, 2016

Transformation matrices shouldn't be needed. Just looking at the order of the cycle induced by engaging that interface should be enough.

Screw axis operators require the transformation matrix to determine the pitch (translation).

However, obtaining the order with transformation matrices might have some numerical instability if the chains have different conformations or the tertiary fold is not entirely conserved.

I'm not sure how this would apply to heteromers.

@sbliven for heteromers this property is undefined (or identity), because the two partners cannot be aligned. It might be still possible to calculate with pseudostoichiometry (like alpha and beta subunits of hemoglobin).

@sbliven
Copy link
Member

sbliven commented Sep 1, 2016

for some cases the graph would not be able to tell the order, e.g. one of those open heterologous interfaces that don't continue throughout the crystal

Excellent point.

Screw axis operators require the transformation matrix to determine the pitch (translation).

This is true if they don't continue through the crystal. If they do span the crystal then you can determine the pitch based on the xtalTrans annotations.

for heteromers this property is undefined

That's probably the easiest solution. Interestingly, after performing edge reduction it becomes well defined again.

@josemduarte josemduarte modified the milestones: 3.2, 3.3 Feb 3, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants