In the second (No re-centering) workflow I described, the input map to local refinement is kept in the same position and orientation as that out of the upstream global refinement job. In other words, there are no spatial transformations of the particles or volume at all. It’s only in the first (Re-centering) workflow where the particles and volumes are transformed.
Let me know if I understood you correctly!
Best,
Michael
Isn’t that what having a fulcrum other than the center of the box does?
The default is the CoM of the mask, so my understanding was the two workflows should actually be extremely similar except for potentially the order of operations.
Recentering a local refinement is expected to be helpful because the error will be lower for a given angular sampling, and (in Relion) because it restores the assumption that origins are normally distributed around 0,0.
Yes - that was why it was surprising at the time
I was pretty sure about it because after I implemented the ideas from Sjors’ 2016 book chapter (which later became Relion Multi-Body) into pyem, I recall having a conversation with Ali about how local refinement in cryoSPARC ought to abstract all those steps for the user. The cumbersome pyem workflow producing the best local resolutions (for the two reasons I mentioned) looked like this:
subparticles.py --target=x,y,z ptcl.star ptcl_xyz.star
map.py --target=x,y,z vol.mrc vol_xyz.mrc
# Generate or transform ROI mask
# Projection subtraction using relion_project or pyem
# Validation of subtraction/transformation using relion_reconstruct
relion_refine ... # local searches only
subparticles.py --invert --transform=x,y,z run_data.star run_data_xyz_inv.star
map.py --invert --target=x,y,z run_class001.mrc run_class001_xyz_inv.mrc
One of the main issues with the pipeline is that it’s quite prone to user error, one needed to validate all the transformations or subtractions with reconstructions (of a subset, for speed). For a while back then it was the only way to crop smaller images after high-symmetry expansion, though. I wrote it for a friend working with a large D24 complex, without cropping his symmetry-expanded, subtracted stacks were several TB in size.
Yes exactly – the only difference is the codepath/implementation that is followed within local refinement. Internally local refinement does pose/shift composition with the supplied fulcrum to achieve this. So any discrepancies between these two workflows is surprising/unintended – we’re trying to figure out why this may be. We do have datasets now that show the discrepancy, so we are able to go ahead and interrogate this example
Best,
Michael
Hi, I am working on the same workflow as you described above, but I encountered a different problem. My workflow is NU-Refine → VAT (Set a new center) → NU-Refine → Local refinement. But the fulcrum in local refinement doesn’t have the same coordinate as the new center. Instead, its coordinates are the same as those of the old center before VAT. Is there anything wrong with the workflow? Thanks in advance.
Hi @yan,
This is a good question! The only modification to this workflow I would make is changing it to NU-Refine → VAT (Set a new center) → Local refinement. (I.e., cut out the second NU-refine). This is because NU-refine ignores the changes in initial particle alignments which VAT modifies, and it isn’t intended to be used as a next step after VAT. Could you try this modified workflow, and see if you obtain your expected result?
If this change doesn’t resolve things, could you confirm that the VAT job is supplied all three inputs (volume, mask, and particles), and check what mask are you using as input to the final local refinement, as well as the fulcrum parameters for the job?
Many thanks,
Michael
Hi, @mmclean,
Thank you very much for the suggestion! I will check this out today and see if it makes a difference.
Regards,
Yan