We came across a novel error message in RBMC (Falcon4 EER data).
DIE: Bug: caller must get rid of particles that are too close to movie frame edges
Any suggestions on triaging?
This occurred during the motion-correction step of a complete RBMC workflow, where the hyperparameters determined led to no trajectory activity.
The user is going back to interrogate the hyperparameter search step, so the point may end up being moot, but I’m curious what the potential solutions/workarounds may be; or if RBMC could be made to fail more gracefully in this situation, e.g. instead of crashing, implement a padarray treatment in mild cases, as previously suggested, or discard the particle in more severe cases.
Cheers,
Yang
EDIT:
We’ve since repeated by applying parameters from an earlier search iteration, to allow for some trajectory activity, and the motion-correction step is failing with the same message, but on an earlier moviestack.
Hi @leetleyang, thanks for reporting this. This is probably a bug; reference motion is supposed to automatically exclude particles which are too close to the edges earlier in the job - that error message shouldn’t ever be seen.
Could you let me know what the EER import parameters were (specifically the upsampling factor)? And then also, could you describe the job chain which the reference volume and particle stacks went through before encountering RBMC? Any resampling of either of the two?
Thanks for following up. From what I can see in the job logs…
In CryoSPARC Live, import was performed with EER upsampling of 1, fractionating 60 e/Å^2 into 42 fractions. There was some curation of the exposures before they were exported to CryoSPARC. This created output groups including one designated accepted exposures.
The workflow combined particles from two curation branches (2D classification)–repeat passes through the same micrographs with different picking strategies. It may be worth noting that in both branches the initial picking and extraction operations were performed in CS Live. As such, the filenames themselves lack visual UID-prefixes, although the particles.cs files maintain micrograph_uid records when interrogated.
Particles that survived their respective 2D curation workflows were re-extracted in CryoSPARC (resampling 478p@0.732Å/p > 286p@1.2234Å/p), and combined for pruning in a duplicate removal job using the default separation distance (20 Å)–perhaps insufficiently discriminative in this case.
The output from duplicate removal was fed into a NU-Refinement job with dynamic masking and no user-supplied mask. I notice an initial mismatch in dimensions between the images (286p@1.2234Å/p) and an imported reference volume (360p@0.66 Å/p). CryoSPARC dealt with this internally with resampling prior to lowpass filtering. The dimensions of the resulting volumes appear, by eye, to be fine.
The NU-refinement output groups–particles, volumes, and mask–were combined with the accepted exposures for RBMC.
Hi @leetleyang, thank you for taking the time to write a detailed description of the workflow. I think the bug is exposed by some combination of resampling and combining inputs, but I’m still not able to immediately see where the problem lies… The RBMC job performs this check twice, and it should never be the case that the second check actually triggers.
When you run the job do you see a warning message near the top of the stream log that says “Removing N particles too close to micrograph edges”, or no?
When you say you connected the “accepted exposures” from curation, were there multiple groups connected, or just a single group? Is there any possibility that the input movies had different import parameters?
Looking in the stream log, I don’t see said message. The job had motion-corrected particles from four movies before crashing, so I don’t think I’ve missed it.
Along those lines, I was considering suggesting to the user to perform a mock-reextraction job once more but with an even larger box size in order to trigger automatic removal of particles that are currently closest to the micrograph edges. The idea would be to try RBMC on the particle intersect subset.
Just the single group from the initial Live Exposure Export job. This is also the same input given for the re-extraction steps following curation. I believe the import parameters were set once at the start of the Live session and remained untouched throughout the processing.
If it’s more likely an unfortunate combination of resampling parameters, would you recommend slightly changing the extraction and output box-size values and trying again? Or perhaps initiate a new Live Exposure Export job, Reassign Particles to Micrographs and then repeating the workflow, in case something got garbled along the way the first time?
Cheers,
Yang
EDIT:
Hypothetically, could the presence of a subset of junk particles contribute to this error? For instance, if they are judged to be sufficiently far from an edge initially, but due to chaotic trajectories find themselves too close or even tracking off a movie frame completely over the course of motion correction? Or should the two checks you mentioned address this?
We also encountered the error DIE: Bug: caller must get rid of particles that are too close to movie frame edges. As @leetleyang suggested, re-extraction can indeed mitigate the problem, as some particles near edge are rejected probably due to shift after refinement. In our case, we just keep box size the same as before and redo extraction.
“Removing N particles too close to micrograph edges” message also did not appear in this particular job, but in other jobs this message was shown and did not encounter the above bug.