Subparticle extraction after symmetry expansion

Utilities
#1

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

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

#3

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.

#4

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?

#5

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

#6

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?

#7

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?

#8

@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
#9

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
#10

@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).

#11

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.

#12

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.

#13

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.