GCTF: Bug with per-particle ctf estimation

issue_recorded

#1

Hi!

I’m trying to estimate local per-particle ctfs using the gctf wrapper and a set of micrographs with associated particles (either extracted directly or with local motion correction). Whereas it seems to work for a couple of micrographs and the program runs for a while, the ctf fit and defocus values reported seem to be stuck at what I imagine are one of the parameter extremes.The issue seems to persist even when I input global ctf values.

I’m attaching snaphsots of my input parameters and of the output. Notice how most ctf fit values are stuck at 1.84A and the average defocus at 89800A.

Please let me know if there is any other information I can provide towards identifying the issue.

Cheers,
Stefan


#2

I saw a different but also anomalous error (Strange results from local ctf refinement in Gctf wrapper [Bug]) when trying to refine CTF values for particles that had been downsampled - could that be the case here too?

Cheers
Oli


#3

Perhaps – why do you think that the downsampling matters in your case?
I’ve also heard - though I cannot find a bug report - that the standalone gctf used to have a similar issue, which could be circumvented by looping over runs on individual micrographs.


#4

Oh, yes, I encountered that issue too! I think I posted it on ccpem… yep here it is (well this is actually someone else reporting the same issue but the same fix worked):

https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ind1705&L=CCPEM&F=&S=&P=39009

No idea re why downsampling makes a difference, it shouldn’t do

Cheers
Oli


#5

Indeed, per-particle ctf estimation does not work in batch, at least with any of the gctf versions I tried. The process always starts fine, running through ~35 mrc files, after which is begins failing to determine defoci, printing one value for all micrographs and for each particle. The only solution is to loop it over the micrograph list submiting them to gctf one by one (from a shell script for example). Furthermore, in my hands, star_replace_UVA.com did not work as intended either. I do not remember exactly what the issue was, but I think star_replace_UVA.com was looking for something in the local_ctf.star that gctf did not write. My solution was to re-write the script matching micrograph names and particle locations in local_ctf.star and particles.star.

(above relates to “standalone” gctf, which cryosparc wraps. I do not think you will be able to use it inside cryosparc in that way. The only solution would be to modify your metadata outside of the cryosparc system and then re-import them back).


#6

Thank you for your suggestions, Oli and Peter!

What seems to work, without straying from the cryosparc workflow too much, is using the _automatch.star boxfiles that gctf outputs even upon failing to run gctf “manually” on a loop as Oli suggested. Then, I re-“import the particle stack”, associating the original micrograph import cryosparc job (e.g. after “motion correction”) and the .star output from gctf.


#7

thank you, good to know!


#8

I wrote an alternative script to star_replace_UVA.com for exactly that reason - never did figure out the issue, it seemed to work on Kai’s system but not on other linux distros: https://www.jiscmail.ac.uk/cgi-bin/webadmin?A2=ccpem;e173f271.1703


#9

Hi Everyone,

Our team will be addressing these issues in the next re-write of the GCTF wrapper. Hopefully we’ll be able to circumvent the current issues by calling GCTF on a loop.