I have a question regarding symmetry expansion followed with re-extracting (sub)particles.
I am refining a helical filament that consists of one type of asymmetric unit. Now, I first used helical refinement and subsequently, then a symmetry expansion job, followed up with a local refinement, where I enter only the mask of the asymmetric unit to get a good resolution on the asymmetric unit.
However, now I would like to re-extract (sub)particles, where the asymmetric unit is in the center of the particle (toggle: re-extract aligned coordinates = on) , with a smaller box size then in my original particle stack. Basically so that I can turn my helical structure in a single particle approach.
When I re-extract, it looks like it re-extracts particles n times my asymmetric unit (as expected from the sym. expansion job) - but the locations seems incorrect. I expected the extracted particles to encircle the filament, instead they seem be located n x at the same spot.
Is this a valid workflow or did I misinterpret the function of the symmetry expansion?
I apologize about the late reply, and thanks for the post. What you described is exactly how the symmetry expansion/re-extraction workflow is intended to be used. Iâm just testing this out right now on an example dataset (EMPIAR-10267) where each particle initially had symmetry order of 5. In the initial extraction, the particles are extracted like this:
Then, after helical refinement --> symmetry expansion --> re-extraction, they look like:
So there are 5 particles for each single particle in the first image (itâs hard to see the separation between the circles, as the asymmetric unit is pretty small so they overlap). Note though that cryoSPARC has no knowledge of the actual location of the asymmetric unit within the box â only its vertical extent is known through the rise. So in particular, you wonât see the extracted boxes âcircleâ around the filament â itâd only be possible to do this if cryoSPARC knew the position of the center of the asymmetric unit in the box, and it would be a bit complicated to handle in general for all of the symmetry types.
Where this wouldnât make a difference is if n=1 (then of course expansion does nothing). Also, if you have a very small helical rise, youâll end up with very densely-packed picks, and it might be difficult to see any differences between them. Would that explain the behaviour that youâre observing?
In any case, you can still use these particles in local refinement downstream, you just need to keep in mind that the initial volume you got from the first helical refinement defines the âobject frameâ, so all masks should be defined in the reference frame of that volume. If youâre using chimera to make a mask around the ASU, just make sure to save the mask on the same grid as the initial volume.
Thanks so much for testing this out! This indeed exactly the behavior I meant. However, I added one extra step to this:
I did a helical refinement --> symmetry expansion --> a local refinement --> and then re-extracted. So therefore I expected the re-extration job type to âknowâ, not only the rise/twist, but also the relative location in the initial box.
However, my particle picks look similar to the image you show here, closely overlapping boxes; but no circling around the helix at the location of the asymmetric unit.
If the algorithm works as how I understand it to work, then that combination of jobs should have shifted the centers of my expanded particles to the locations of the asymmetric unit (twist/rise + from COM of filament to COM of asymmetric unit)
Maybe you could help me understand why this should (or not?) work?
I see â so this would be the behaviour if local refinement re-centered the volume to coincide with the centre of mass of the mask for example. Right now this isnât done â the volume is kept in the same frame as the original inputs, so the small change in alignments computed by the local refinement donât have a noticeable effect on the particle positions. In our upcoming cryoSPARC release, there will be a utility allowing one to manually shift the centre of a volume to any arbitrary location and then do subsequent refinements while keeping the alignments in agreement; I believe this would allow you to do exactly what you are looking for, but I havenât personally tested this workflow just yet.
