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.

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.

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.

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.