D3 Symmetry Conventions

[donaldb]

I am currently working on a molecule with D3 symmetry and in the process I have noticed that cryosparc seems to have a different convention for the location of the dihedral axis from RELION and cisTEM in ‘Dn’ pointgroup symmetries.

The other two programmes place the dihedral 2-fold axis along the x-axis, whereas cryosparc puts it along the y-axis. This may not have been noticed previously, as it is only noticeable if the cyclic symmetry is an odd number.

Would it be possible to change this in cryosparc to make it fit the convention of the field and make the models more easily transferrable?

[DanielAsarnow]

Some of us actually noticed this conventions issue a ways back (one of the classic EM test
samples, the T20S proteasome, has D7 symmetry), but I thought it had been fixed already. Seems like I am mistaken…

Dn symmetry definition diferent as relion/xmipp and maybe others

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…

Conflicting D symmetry conventions

[apunjani]

Hi @DanielAsarnow, @donaldb,

Thanks for bringing this up again, you are correct. The last post in this thread explains the current status correctly: Dn symmetry definition diferent as relion/xmipp and maybe others

Unfortunately this becomes non-trivial to change because of all the existing cryoSPARC projects that would have trouble if we switch the Dn symmetry definition.
What would you think of adding a different symmetry definition “Dnx” (so eg D7x) that uses the C2-along-x convention? This would have the drawback that by default, cryoSPARC projects would still have a different symmetry than other programs unless the user knew to enter D7x instead of D7.
Changing the actual definition though would make existing projects break unless the user now enters D7y instead of D7.

Thoughts?

[olibclarke]

how much trouble would this actually cause in practice? I would advocate increased compatibility, with the option of having a D7_legacy or whatever for re-running old refinements.

If a user has a project using the old sym definition, and want to continue with a new one, it should just be a matter of rerunning refinement with “align to symmetry” on, right?

So long as it is very prominently flagged in the release notes (and maybe in the GUI when Dx sym is entered?) I don’t see a big issue

Oli

[donaldb]

I would be more in favour of switching the default to the standard ‘RELION’ convention. As @olibclarke points out you can add a legacy option for preexisting projects. The axis location in cryoSPARC is usually something of a triviality because of the excellent symmetry alignment, which I imagine many people never turn off, even when their model is already aligned.

[olibclarke]

actually there is still a long standing bug in symmetry alignment - if the model is already aligned, cryosparc frequently messes it up if symmetry alignment is switched on… if it is not pre aligned it does work well though!