Resolution of "rigid" reconstruction after 3D-flex does not match input refinement

3D Flexible Refinement
1

Hi,

We are testing 3D-flex, and finding that the resolution of the output rigid volume after flex-reconstruct (3.1 Å) does not match the resolution of the input refinement (2.7Å), even when using the same mask (the fsc_auto mask from the input refinement, recropped to match the particles used for 3D-flex).

Is this expected? I guess it could be due to cropping the particles too tightly? Are there any other differences expected? E.g. does 3D-flex read beam tilt and other higher order CTF params?

If it is due to cropping, is it possible to somehow run flex-reconstruct on uncropped particles, using a flex-train model trained using cropped particles?

EDIT:
It doesn’t seem to be due to cropping, as running a homogeneous reconstruction on the 3d-flex prepared particles gives a resolution of 2.76, just slightly worse than the original refinement (2.73). So what is different between the “rigid” volume generated by 3D-flex reconstruct and a reconstruction from the input particles?

Cheers
Oli

1 Like
2

Hi @olibclarke thanks for reporting this as well.
Reconstruct-only uses Fourier backprojection (like all other refinement in CryoSPARC except 3DFlex). The Flex-reconstruct job uses a new L-BFGS-based real-space optimization to do the reconstruction. This is powerful since we not longer have to make assumptions about the Fourier-slice theorem so can actually deal with deformations, but also has cons like it’s much more computationally intensive and is iterative instead of having a closed-form solution (like backprojection). The “rigid” baseline from flex-reconstruct is computed using L-BFGS (without deformation model) to enable comparisons and sanity checks just as you’re doing.

The expected differences between reconstruct-only and flex-reconstruction:

  • cropping can have an impact depending on CTF aliasing but doesnt seem to be the cause in your case as you mentioned
  • the iterative L-BFGS solver is limited to a number of iterations (default 20) but for some particles/datasets it might need more. You can try to increase this to eg. 40 (taking double the time) and that may slightly improve the real-space reconstruction
  • CTF is most likely the culprit. Flex-reconstruct uses a real-only CTF. So this will account for per-particle defocus refinements that were done upstream but not tilt/trefoil/etc. This should be possible to change soon (i.e. no fundamental reason we can’t use complex CTFs in flex-reconstruct).
6 Likes
3

Thanks Ali this was very helpful!!

I suspect you are on the money - resolution for this sample was limited to ~3.1 prior to refining beam tilt and per particle defocus, so the difference tracks.

I suspect some of these params (particularly thinking of anisotropic magnification) might also cause problems for the flexibility analysis if left uncorrected, no?

Cheers
Oli

2 Likes
4

@olibclarke glad it helps! Definitely lots of improvements to be made in 3DFlex yet.
You’re also right about anisotropic magnification being particularly important. We found on a couple of datasets that 3DFlex will just learn to stretch/shear the density overall if there’s anisomag present. For this reason anisomag is actually already handled by 3DFlex training and reconstruct. As long as the input particles have already had their anisomag refined, it will be used by both jobs. In real-space anisomag is treated very differently than in Fourier space so this was separate in implementation from higher order CTF.

5 Likes
5

Ah, good to know!

Thank you for all of your efforts. I’m already pleasantly surprised by the results of my flex generator results my first go around and hope things will only improve with some more optimization.