Subparticle extraction after symmetry expansion

Hello,

I’m working on an icosahedral reconstruction and would like to extract subparticles at asymmetric units. I’ve seen people do this in relion using the following workflow:

  1. icosahedral reconstruction
  2. identify coordinate at center of asymmetric unit
  3. symmetry expansion
  4. re-extraction of symmetry expanded particles re-centered on asymmetric unit

The result is 60 subparticles per icosahedron, each centered on a different asymmetric unit with orientations intact.

I’ve tried something similar in cryosparc with the following workflow:

  1. icosahedral reconstruction
  2. identify coordinate at center of asymmetric unit
  3. symmetry expansion
  4. Volume alignment tools → re-centering on asymmetric unit

When I inspect the output of this, though, it seems that all 60 particles for a given icosahedron share the same center (they haven’t been shifted according to their expanded orientations). Is there something wrong with my protocol here? Has anyone accomplished this kind of symmetric subparticle exctraction in cryosparc?

Thanks,
Lucas

2 Likes

Hi Lucas

I would first do symmetry expansion, then volume alignment tools (to recenter ASUs at center of box), then re-extract - this works fine for us at least in lower symmetries. Is this what you are doing? I don’t see an extraction step in your workflow?

Cheers
Oli

Thanks for the response Oli!

Right, the next step would be extraction. I just took the output of the Volume Alignment job into Inspect Particle Picks first to see if the centers looked appropriately dispersed on each icosahedron. The Inspect job notes the correct number of (expanded) particles per micrograph, but it only displays a single circle at the center of each icosahedron, so I thought all of the subparticles must be overlapping and not centered on distinct asymmetric units.

EDIT: Also when I use csparc2star on the Volume Alignment output to inspect my particle metadata, the 60 centers for a given icosahedron all match.

hmm - I haven’t tried that, it is possible that inspect particle picks has an issue - I know that for us extraction correctly extracts at the sub-particle centers, so maybe try a test-extraction and see?

Also you want to symmetry expand first, then volume alignment tools - in your workflow it looks like you are doing the other way around?

I’ve been expanding then aligning. I’ll try the test extraction and report back. Thanks!

Can confirm - same issue on my end. Extraction gives correct centers, but coordinates after vol alignment tools are displayed incorrectly in Inspect Particle Picks and Manual Picker (overlapping on center of particle). @team I think this is a bug?

Taking the Volume Alignments output into Extraction gives me the correct subparticles! Thank you Oli!

Seems it may have been a bug in Inspect, but also using csparc2star to convert the Volume Alignments output gave me a .star with incorrect centers.

Is it that the Volume Alignments tool just applies shifts, but the particle origin is still unchanged until re-extraction?

@olibclarke @lucas.adams Highlight of a single particle center (the previous center of extraction) even after symmetry expansion, but before re-extraction (with recentering enabled), is currently the expected behavior of interactive particle inspection. We are considering visualization of “pre-re-extraction” shift information (relative to the center of previous extraction) for a future cryoSPARC release.

2 Likes

This is correct. The volume alignment tools updates alignments3D/shift only, and not the location of the particle on the micrograph (location/center_x_frac and location/center_y_frac). The alignment shift is the residual shift required to centre a particle after it has been extracted and written to disk in the first extraction; so in cryoSPARC, the alignments3D/shift is effectively what defines the “particle origin” you mention. The geometric information needed by cryoSPARC to reconstruct a particle stack must be contained entirely in alignments3D, and since we can’t always assume that the original micrographs exist or have location information, we don’t attempt to do this (until the point of re-extraction with re-centering, if done).

The information displayed in inspect picks is location/center_{x,y}_frac, which is the pick location on the micrograph.

Re-extraction with re-centering updates location and alignments3D such that location stores the updated location of the particle on the micrograph, and the alignments3D/shift stores the small residual (<1px) shift value. E.g. in your example, this would cause the location field to now store the coordinates of the ASU on the micrograph, rather than the centre of each icosahedral particle.

In either case, re-extraction with re-centering is obviously preferred (especially if the new centre is an appreciable distance away from the original centre, as centered particles suffer less from the effects of CTF delocalization), but it is technically optional in this workflow. For small changes to the centre, you can run volume alignment tools with a new centre, and proceed immediately to local refinement and the geometry should be correct. The issue of inspect picks not showing the updated location is merely an artefact of this subtlety, and doesn’t affect anything else internal. Thus, the workflow you outlined in your first post (quoted below) should work.

Best,
Michael

2 Likes

@lucas.adams In what way do you notice the .star files to be incorrect when omitting the re-extraction step? I believe the rlnOrigin{X,Y}Angstrom should correspond 1-to-1 with our alignments3D/shift field. In this case, you won’t observe rlnCoordinateX being updated unless you re-extract, of course, since rlnCoordinateX stores the coordinate of the particle in the micrograph (and this is fixed after extraction).

Thanks for taking the time to clarify everything!

Misunderstanding what the volume alignment tool was doing (adjusting shifts, not coordinates), I noted the unchanged coordinates in the .star file but did not notice the updated shifts/Origin[X,Y]Angst. Looking now, the .star file is correct and re-extracts the way you’d expect.

Maybe just to clarify the reason to perform this workflow, would this theoretically give a better reconstruction of the ASU than performing symmetry expansion and then local refinement with a mask of one ASU. Just asking because I usually use symmetry expansion for helical refinements and then local refinement of the ASU, and I thought that was the “best” way.

In theory local refinement on symmetry expanded particles should give the same results as local refinement on the extracted subparticles (though I’ve never tested this head-to-head). We just encounter memory/computational bottlenecks when using the full particles, especially after expansion increases our particle count 60x.

Hi Lucas,

I am very new in processing Isocahedral protein now.

I am wondering how do you recenter your ASUs? My box size is 648, do we just recenter at 0, 0, 0 in Volume Alignment Tools?

Thank you.

Best regards,
YK

Hi Oli,

May I know how do you recenter your ASUs at the center of the box?

My particle is also in icosahedral symmetery with box size of 648.
Do I just use 0, 0, 0 to recenter?

Thank you.

Best regards,
YK

Hi YK,

You can find the appropriate position to recenter using Chimera. Navigate to the center of the ASU that you want to recenter on, place a marker there (ac mc), then select the yellow marker sphere and get the coordinates (measure center sel). You can then enter these x,y,z values into Volume alignment tools.

Cheers
Oli

Hi Oli,

Thank you.
I managed to get the x,y,z values.

When you doing the particle shift in Volume alignment tools, do you input any static mask?
The mask is the ASU mask or the whole protein?
There is also an option for symmetry alignment, I guess we don’t need this for particle shifting?

Thank you for clearing my doubt.
YK

Hi YK,

I would input a mask covering the ASU (which will then be recentered along with the particles and volume). You can then use the recentered mask for refinement or classification.

Correct, you don’t need symmetry alignment unless the ASU itself has local symmetry.

Cheers
Oli

Hi Oli,

Thank you.

When I tried to recenter another part of the molecule, it gives a value greater than my box size, do you know how to overcome this issue?

YK

Double check that the values you input are in the correct format - I think Volume Alignment Tools wants it in pixels (not sure, check the tooltip), maybe you input the value in Angstroms?