When attempting to refine a set of particles merged from multiple refinements that included on the fly global CTF refinements, I ran into the appended error.
Basically cryosparc doesn’t know how to deal with a situation where multiple particles in the same optics group have slightly different Cs values, and so the refinement crashes once it reaches the stage where global CTF parameters are refined.
Would it be possible to either deal with this more gracefully (perhaps checking and if necessary resetting CTF params at load time?) or allow us to reset Cs within cryoSPARC?
In the standalone Global CTF job, there are options to reset tilt, trefoil and tetrafoil, but no option to reset Cs (and in any case if I input this set of particles it crashes before it does anything).
Bumping this - would be good for consistency to have a way to reset Cs in Global CTF (as is the case for all other higher order params) - this would be useful in cases where Cs has refined to a physically unreasonable value.
In CryoSPARC v4.1 a parameter was added to Global CTF Refinement to allow resetting the spherical aberration to any custom value. (This is the same for all exposure groups, so if you need to reset the spherical aberration in each exposure group to independent values, you will have to run separate CTF Refinement jobs).
For jobs which are toggled to refine spherical aberration, could it also be standard (or enabled with a toggle) to reset all to a constant value at the onset of the job. Refinements of particles from varying locations frequently fail at last stages due to them having previously refined cs values. Frustrating and non-obvious.
Just to understand exactly what’s causing the job to fail: when these CTF Refinement jobs fail, is it with an error message of the form Field ctf/cs_mm is not constant in group X with Y items, or does the failure happen somewhere else with a different error message?
It’s actually non-uniform refinement jobtype with higher-order aberration correction, when the particle inputs are from distinct non-uniform refinements with higher-order aberration correction. And yes, it is that message I think. Effectively, correcting for cs in any job makes those particles an independent stack which cannot be combined with others or another refinement of cs will fail. I know the workaround. I’m just wondering if it would be possible for the jobtype(s) to recognize the multi cs (which they already do) and then 1) error at the beginning or warn 2) set them back to 2.7 and refine from there 3) refine them from independent start points and treat them as groups. Thanks!
