Dn symmetry definition diferent as relion/xmipp and maybe others

3D Reconstruction
1

We have been converting refinement cs files to star files (using pyem). Our particle has D7 symmetry and in our later reconstructions (using relion or xmipp) were rendering a D14 symmetry. We have looked into this in more detail and we believe that cryosparc defines Dn as Cn around z + C2 around Y, while relion and xmipp, and maybe others, define it as Cn around z + C2 around X.

Therefore, pyem 3d angles conversion is not a straightforward conversion, at least for Dn symmetries.

We think the best, simplest solution to allow packages interoperability, would be to have the same symmetry conventions. Is this something cs can easily change in future versions, or should users/developers be aware of this fact and make the maths to change the angles.

1 Like
2

Just wanted to comment that I experienced something similar with my D6 complex. And to get proper symmetry averaging, I had to apply D6 symmetry during ab initio.

If I tried using a d6 symmetry-averaged reference from Relion to “bootstrap” the symmetry averaging, the output maps always came out looking like crap.

Only could get proper symmetry averaging by applying symmetry de novo during the cryosparc ab initio job type.

3

I believe the original D symmetry convention issue was fixed by changing the convention in cryoSPARC to match Heymann et al. 2005. Are you sure this isn’t a symmetry alignment issue? The main symmetry axis needs to be the Z axis of the map, and the secondary one should be the Y axis.

4

The Heymann, Chagoyen and Belnap (2005) standard lists the Dn symmetry with z-axis being the main symmetry axis and the 2-fold on x-axis. While there is some deviation for the orientations of T and I symmetries, RELION, xmipp, and cisTEM adhere to the Heymann, Chagoyen and Belnap (2005) standard for Dn symmetry.

The following command using star.py from @DanielAsarnow, et al.'s pyem seemed to work for me to move the Dn 2-fold to x-axis from the y-axis:

star.py --transform “[[0,-1,0],[1,0,0],[0,0,1]]” input.star output.star

or alternatively,

star.py --transform “[[0,1,0],[-1,0,0],[0,0,1]]” input.star output.star

depending on your desired direction of rotation.

1 Like
5

I guess there was a regression? Or maybe the fix wasn’t pushed?

Thanks for posting your work around. FYI whenever you give one of my programs a --sym argument it gets the matrices from Relion.

6

Hi all,

Just confirming that dihedral symmetry in cryoSPARC uses y as the dyad axis, rather than x as done in the Heymann reference and in RELION. Thus, as of now, one would need to run symmetry alignment for any Dn structures to re-align any imported volumes from RELION, or use the command from pyem that @thomaspv kindly provided.

For anyone curious, I believe this inconsistency happened sometime in 2018, when we changed the definition of the x and y axes in terms of how we computed actual 3D array indices. In v0 (and perhaps very early versions of v2), y was the “fast” axis of our 3D arrays, whereas x was the second-fastest axis, and z was the slowest index. In v2, we made x the fastest index, y second fastest, and z slowest… but that had the effect of swapping the x and y axes for the previously defined dihedral symmetry operator.

Best,
Michael

3 Likes