Ability to override the number of asymmetric units to search during helical refinement

[msleutel]

We’ve found that for cases with an extremely small rise (e.g. smaller than 0.5Å) that convergence to find the global minimum of the error landscape can be challenging. For these cases, there can be degeneracy in the rise. I’m pasting the error landscape result from a symmetry search job below where the function is searching over 32 asymmetric units (rises).

Changing the rise search range to 200 rises ‘sharpens‘ the error plot:

It would be interesting to see if this would also translate into improved helical refinement results when one would be able to tweak this parameter during Helix Refine.

[egelman]

It appears that in Helix Refine the number of subunits used for the symmetry search is not properly determined and is not an adjustable parameter. Here is our own example where there is a very small helical rise:

If the search was done over many more subunits, then one would see a clear minimum in this plot, rather than all values of the rise (from 0.62 to 0.76 Å) giving the same mean squared error.

[mmclean]

Dear all,
Thanks for the info and suggestions. To clarify how the number of ASUs are determined for symmetry searching, the protocol outlined below is used.

When enforcing or searching helical symmetry in real space, CryoSPARC operates only over a central band of z-slices in the volume rather than the full box. Two things degrade signal near the box edges: the spherical window mask attenuates density near the corners, and applying too many symmetry-related shifts during backprojection can cause data to “wrap around” and hence add noise to upper and lower z-limits of the box. The algorithm determines the largest central z-band free of both effects, converts that to a number of helical rises, and clips the result between a minimum of 3 and a maximum of 32. An override exists internally but is not currently exposed in the helical refinement job interface (only in the Symmetry Search job, as @msleutel pointed out).

We have observed that the twist value often seems to be more clearly determined (stronger valley in the MSE plot) compared to the rise. Thanks @msleutel for showing how increasing the number of ASUs to search over can sharpen the plot significantly.

---

To help us address this, a few questions:

• Would direct control over the number of rises searched be preferrable? If so, what value would you have used in your case?
• Should the 32-rise cap be raised or removed entirely? (It was set conservatively for performance-related reasons, but this is clearly restrictive for small-rise helices.)
• Do you observe this indeterminacy in the MSE plot most severely in small-rise situations, or have similar situations arose with larger rises >> 1 A?

Thanks,
Michael

[msleutel]

Thanks for your detailed response.

The degeneracy in rise appears to be specific to very small rises. Here’s another example:

-default output of the symmetry search:

-Searching over 800 asymmetric units (rises).

The sharpening of the error landscapes in the examples that I shared was achieved by increasing the “Override the number of asymmetric units to search” to a value greater than 100. In the example shown above, it was set to 800. What we and perhaps also @Egelman have found, is that cryosparc can have a lot of difficulties to find and refine the correct helical symmetry parameters for these cases with an extremely low rise. One needs to provide highly accurate (0.1-0.05Å precision for the rise) initial estimates of the rise and twist (based on Fourier-Bessel indexing). We were wondering if the ability to override the number of asymmetric units to search over during helical refinement could make the process more robust to inaccuracies of the input rise and twist.

Would direct control over the number of rises searched be preferrable?
For testing purposes, it would be great to see if direct control over this parameter would make a real difference. I’m not really convinced yet that it will, as cryosparc identifies the same rise/twist values in Symmetry search jobs using either the default number of rises to search over, or when it is set to a far higher value. In that regard, it could simply be that changing the number of rises to search over simply leads to cosmetic changes in the energy landscape. But this needs to be formally rested.

If so, what value would you have used in your case?
As mentioned above, between 100-1000 for extreme cases.

Should the 32-rise cap be raised or removed entirely? (It was set conservatively for performance-related reasons, but this is clearly restrictive for small-rise helices.)
Perhaps the cap could be dependent on the box size and the input rise ? For performance-related reasons we agree that it is probably best to keep the default number of rises to a moderate value, leaving the option open to change it if needed.

Do you observe this indeterminacy in the MSE plot most severely in small-rise situations, or have similar situations arose with larger rises >> 1 A?

No, it seems to be limited to small-rise situations. Here’s an example for a rise of 9.5Å.

We have experienced the inverse case where the twist seems to be less well defined. We’ve seen this with fibers with a small diameter (<20Å). Here are some examples:

[egelman]

When I originally wrote the IHRSR programs, the helical search was done over the central 2/3 of the volume. That approach seems more reasonable than putting a cap of 32 times the rise. With a small rise as in the examples above, the 32 cap might mean that the search is only done over the central 1/20 of the volume.

Regards,

Ed

[mmclean]

Dear @msleutel and @egelman ,

Thank you both very much for the helpful examples and discussion. I’ve recorded the following action items from this thread:

We will look into exposing the existing internal override for the number of asymmetric units/rises searched directly in Helix Refine, analogous to the option currently available in Symmetry Search.

We’ll also revisit the current hard cap of 32 rises, either removing it or making it more liberal, and instead search over a greater fraction of the usable z-extent. Though it was there for performance reasons, both examples show that it is insufficient for small-rise helices.

Best,
Michael