Particle subtraction error (v2.2)

Hi,

I just tried particle subtraction on a project for which it has worked well in Relion, and I got the attached error. Normally this would indicate that it couldn’t find an input, but all the inputs are there. I input particles from a non uniform refinement job, a volume from the same job, and a refinement mask from another job (which was run using the particles that had been signal subtracted in relion, so it is masking the correct region. Thoughts?

Cheers
Oli

Also, using a refinement mask from another job also doesn’t work for local refinement - is it not possible to use masks from the mask “blob” of another refinement job? Do they need to be imported or directly made in the mask creation tool of cryosparc?

Cheers
Oli

Hmmm - particle subtraction also gives the same error if I use a mask created separately in cryosparc using the volume tools job - am I doing something wrong?

Thanks for reporting! I’m looking into it, will let you know what I find.

Best,
Ali H.

Thanks @ali.h! I get the same error starting from particles out of a “regular” homogeneous refinement job, so that’s not what’s causing the issue, and it happens with either a refinement mask input from another refinement job, or with a mask created using volume tools - puzzling

Cheers
Oli

Hi Oli,

For the error with the mask from Volume Tools - could you confirm that you indicated the volume type as ‘mask’ in the params for the Volume Tools job?

No I didn’t - that option is labeled “type of volume being changed”. The type of volume being changed is a map, from which I want to create a mask. So I selected map, along with threshold, dilation, filling holes etc. It seemed to create a mask, or at least to allow me to drag the mask “blob” onto the input lane of the particle subtraction job… I will try again. I would suggest maybe relabelling this button “type of volume to generate” rather than “type of volume being changed” - I think this would be less ambiguous

Cheers
Oli

When I re-run that same volume tools job with “type of volume being changed” as “mask”, I get the attached error:

So the mask “blob” of a refinement job says it contains a mask_refine object, but I’m not sure it actually does - @ali.h could you confirm? Also why are there two volume “blobs” for each refinement job now, one of which seems empty?

You’re right - that parameter does indicate the type of volume that is inputted into the Volume Tools job. We will have to rework the way Volume Tools handles different types of inputs and outputs - seems like something might be going wrong when inputting a map and outputting a mask.

For now, as a workaround, you can import the .mrc files directly from disk with the Import Volumes job (as a mask), and then feed them into a particle subtraction or local refinement job.

The mask_refine slot of a Refinement job outputs the dynamic mask used during the refinement (assuming the dynamic masking parameter is set). It seems like the Non-uniform Refinement job is missing this output, which is likely what caused the issue in the first place. So, I think the problem was a combination of (1) Vol. Tools map-to-mask conversion not working (2) missing mask output in NU-Refinement. We’ve made a note of both, and will fix them in upcoming releases!

@olibclarke please let me know if the suggested workaround (importing .mrc file as a mask using Import Volumes) works for now.

As always, thanks for your feedback and support!

Best,
Ali H.

By the way, connecting a mask output from a Homogeneous Refinement should work - the mask_refine output there should be working OK.

Ali H.

Thanks @ali.h! Yep, both jobs seem to start when using a mask imported directly, testing now! And yep, I think both mask creation and the way mask “blobs” from refinement jobs are handled need a look - it looks like for the mask is created by the volume tools job, but the mask “blob” doesn’t have a thumbnail of the mask and seems to contain zero objects. I wonder if the mask ism being created but not connected up somehow.

I actually used the mask_refine output of a regular refinement job, not a non-uniform refinement job, which caused the initial problem - both give the same issue.

Cheers
Oli

Also the output volume created by volume tools looks correct (in chimera/relion_display) - it is just being categorized as a volume, rather than a mask

Cheers
Oli

Also, “enforce non-negativity” defaults to true in local refinement, but false in non uniform and homogeneous refinement - is this intentional? The tooltip suggests it should be false

Hi @olibclarke,

That is intentional - we saw improvements in results with it enforced. We’re looking further into it!

Best,
Ali

OK good to hear - I have seen better results myself sometimes with it on for non-uniform and homogeneous refinement

I am trying out the particle subtraction now, but it does not seem to be effectively subtracting the residual density (whereas signal subtraction in relion does, for the same set of particles). Is cryosparc expecting a regular mask or an inverse mask, for signal subtraction?

For troubleshooting, it would be useful if cryosparc output the volume the projections of which it will subtract from the particles, so that the user can inspect.

Cheers
Oli

cryoSPARC expects an inverse mask for the subtraction. Are the particles and the volume from the same job? If so, can you confirm that the windowing parameters are identical in the subtraction job as they were in the refinement job?

That would be the issue - I assumed cryosparc would take a normal mask and invert it on the fly, as there is no way (I think?) to create an inverted mask directly in cryosparc

trying again now with an inverted mask!

Cheers
Oli

Hmm - tried again with an inverted mask and the subtraction results are still not great, as judged by an ab initio reconstruction of them… I can still clearly see then nanodisc which I am trying to subtract, which is not the case for signal subtracted particles generated from the same inputs in relion.

I’ve loaded up the input volume and mask in chimera, and they match as expected, and the same windowing parameters were used for both runs - is there anything else I could tweak?