Z-Score set to -1 in Particle Sorting

[ninthpower]

Version: Relion 2.0.3

When using particle sorting, the new column _rlnParticleSelectZScore is added to the star file for particles picked through a previous autopicking step. However, every particle's metadata lists the z-score as -1. Example:

As well, just by looking at the particles in the display after sorting by the zscore column, there doesn't seems to be any sorting at all.

I'm not sure if the z-score isn't being calculated, the sorter is looking in the wrong place, or what. We have confirmed this same "-1 z-score" behavior in 2 different data sets sorted through Relion 2.0.3, and a colleague has confirmed his data is the same after we asked him to check on a previous data set.

[ninthpower]

It's been a long time and still haven't heard anything about this :( We are unable to sort using particle sorting and would love some insight on this...

[ninthpower]

So, did a little digging and here's where I'm at: sorting only assigns a z-score to particles that have been picked through autopicking (based on references). It checks to see if a particle in the particles.star file has a reference index in the third column (this value is the specific reference from the file you passed to the autopicker for which there was enough merit to pick it as a particle).

My particles in particles.star all have valid values in the class number column, but somehow the sorter is still thinking that it's -999 (as set by line 1326 in displayer.cpp). That's why line 501 of particle_sorter.cpp is setting the z-score to -1 because it's somehow missing that value.

I am properly passing the references file from which the particles were autopicked. This is correct in my GUI and in run.job... So what gives? We would LOVE to be able to resolve this so we can get some beautiful structures ;)

Thanks -Austin

[bforsbe]

Apologies for the delay,

You have a valid class number in the screenshot you show, so I'm guessing relion is actually calculating the features and the subsequent z-score, rather than avoiding to do so. The -1 probably comes from 524 in particle_sorter.cpp. That could happenis if relion actually calculated features, but that all those features were found to be 0. Looking at the code, there's a few ways for this to happen, but I'm not sure if it is down to settings, use, or unforseen combinations of settings. I'm guessing something like a strange ctf-correction, pixel size, or other. Are you using ctf-correction for the particle sorting? In fact, the entire command would help.

[ninthpower]

Thank you so MUCH for getting back to me. You're right the -1 is assigned on 524, I guess I was just referencing the whole code block. CTF-correction is set to "Yes" in the 2D Classification step where the references came from.

Sort command: which relion_particle_sort_mpi --i ./Extract/job043/particles.star --ref ./Select/job030/class_averages.star --o Sort/job044/particles_sort.star --ctf

Here's run.job for the sorting:

job_type == 6 is_continue == false Input particles to be sorted: == ./Extract/job043/particles.star Are these from an Extract job? == Yes Autopicking references: == ./Select/job030/class_averages.star Pixel size in references (A) == -1 Are References CTF corrected? == Yes Ignore CTFs until first peak? == No Number of MPI procs: == 4 [omitted queue info - run locally]

Thank you!

[bforsbe]

What happens if you

1. run without MPI?
2. specify the --angpix size?
3. turn off ctf-correction?

[ninthpower]

particles_sort.star still shows -1 for z-scores.

Here's the command:

which relion_particle_sort --i ./Extract/job043/particles.star --angpix_ref 2.12 --ref ./Select/job030/class_averages.star --o Sort/job061/particles_sort.star

output:

• Using pixel size calculated from magnification and detector pixel size in the input STAR file: 2.12 Automatically set the background radius to 50044.5 pixels in the references You can override this by providing --particlediameter (in Angstroms) Calculating sorting features for all input particles... 2.05/2.05 min ............................................................~~(,,"> Written out Sort/job061/particles_sort.star

Since the calculating isn't automatic, it seems like your theory of it actually calculating features is true. There are only 35639 particles in this sorting so I imagine it wouldn't be too long. Is there a --verbose option on this command?

[bforsbe]

--verb

By the way, are the input image binned?

[ninthpower]

These micrographs were not binned.

[bforsbe]

And when you say micrographs, you mean extracted particles?

[ninthpower]

I'm sorry I thought you meant the binning factor during motion-correction. What other step would the particles have been binned? Do you mean the pooling that can happen during 2D classification?

[ninthpower]

I know for sure we haven't binned anything in this set.

[bforsbe]

Any new runs with the settings I suggested?

To clarify about the binning; you extract particles from micrographs. At that stage you can scale or re-size your particles to a smaller size (called binning, which is actually a misnomer in this case). If you do this during extraction ("rescale particles?" in the relion GUI), then you particles and micrographs have different pixel-sizes, which can be a culprit unless you specify both --angpix X and --ref_angpix Y

[ninthpower]

Thanks for your help. No there was never any binning between any steps, and Rescale Particles? was set to 'No' for the extraction.

Referring to your parameters, my response after yours was the command I ran with those specifications. No z-score still.

[ninthpower]

Any new thoughts on this?

[bforsbe]

Looking it over again, isn't this kind of suspicious?

Automatically set the background radius to 50044.5 pixels in the references

In the code this seems to be a square at first glance, which would make actual radius ~220 pixels, i.e. ~500Å. Does that make sense to you given your data?

If I were you I'd start specifying everything, all kinds of flag combos, until something sane shows up, then narrow down what makes this happen. Specifying a really small particle diameter is a good start. Then specifying both angpixes, and lowpass, and invert. If something starts coming up as not -1, that's clues.

[ninthpower]

OK! I added --particle_diameter as an "additional argument" and that seemed to do the trick. The only funny thing is that it looks like the metadata for the particles whose z-score get sufficiently small show a z-score of -1.00000. I'm guess this is a result of rounding?

[ninthpower]

I have tried this on other data sets, and that seemed to be the culprit. We really appreciate the help Bjorn, thank you.

[bforsbe]

Good stuff, what did you set the diameter to?

[ninthpower]

I set the diameter to 250. Same as the references.