When running 3D class in any mode, the first (and lengthy) step is to compute consensus reconstruction from ALL particles. 1) if solvent mask is provided, shouldn’t this be skipped when using “input” mode with volumes? 2) can we provide single volume to skip this step, while still benefitting from “simple” or “PCA” mode? 3) can there be a hard limit, or can we set a limit, on number of particles used for this?
We’ve also notice that some NU-refine particles from <V4.1 are failing at this step for V4.1, hung up at a specific particle count. check corrupt particles reveals nothing. redo GS-FSC split does nothing. we will have to do a new extraction of those particles to get fresh ID. The Class3D job is new, not cloned from old.
Hey @CryoEM2! Thanks for the suggestions / feedback. Please see below:
if solvent mask is provided, shouldn’t this be skipped when using “input” mode with volumes?
You’re right that if the user provides a solvent mask without a focus mask, the main classification loop does not need the consensus. However, we also use the consensus volume to compute optimal particle scales, and to compute the noise model.
can we provide single volume to skip this step, while still benefitting from “simple” or “PCA” mode? 3) can there be a hard limit, or can we set a limit, on number of particles used for this?
We’ve noted the suggestion in 3) – thanks! Hopefully that will speed up things for larger datasets.
We’ve also notice that some NU-refine particles from <V4.1 are failing at this step for V4.1, hung up at a specific particle count.
Can you please post the exact error you’re seeing (if there is one?)? I’ve tried to replicate this with a v4.0 NU-refine job with no luck (all runs as expected). Thanks!
sorry, no error message, just runs completely through half-set 1 and then gets stuck (for at least 24h) in half-set 2 at a certain particle (always the same, many attempts):
[2023-12-13 9:35:10.13]
[CPU: 813.2 MB Avail: 330.90 GB]
Split sizes (A | B) : 120574 | 120028
no corrupt particles (this job took 2min), also none with NaN (this job took 5h), but that job type generated an output (of all input particles) that failed again for “simple” initialization mode, but worked for “input” mode which was desired route. So we’ve past the problem and never really got a fix, but I will let you know if it happens again and we can dig further to the root of the issue. our prior version was 4.0 workflows beta, so might be isolated.