Experimental support for Relion's Bayesian polishing in csparc2star.py

Hi @DanielAsarnow

I am trying to run Bayesian Polishing and finding the same error:
ERROR:
There is no movie metadata STAR file for any micrographs!

This must come from the .cs files from per-movie star files. I tried to use different types of jobs such as curate exposures, Patch CTF,… I could not find those exact files and always was returning an error. As discussed above I created a exposure group job and was able to successfully create the files. But likely the information is not there. Can you please clarify which .cs files I need and from which job?

Many thanks.

Pedro.

1 Like

First, look inside your metadata files and check the paths. The error message is telling you that the paths are wrong. (If the movie .star files have really been created).

All the files have been generated and the paths look good. All the star files have been generated too.

There’s something wrong or different about the file names or the paths given in the micrograph star file, such that Relion isn’t finding the movie metadata files.

If you are in the Relion project directory, if you open the micrographs file it should have rlnMicrographName and rlnMicrographMetadata, and if you copy those paths and ls them they should exist.

Then, if you copy the metadata path and open it should have the movie name and the gain name, and again those should be correct relative paths from the Relion project directory.

Thanks @DanielAsarnow. It is running. Fingers crossed. If I wanted to return the polished particles back to CryoSPARC, what is the best way to proceed? Thanks!

You have to import the particle stacks output from polishing (_shiny.mrcs) via the shiny.star. Exposure groups are hopefully preserved. Particle locations are only useful for duplicate removal as re-extracting would create regular (not polished) particles, but they can probably be restored if you have the right exposures to link during import.

I recommend you run a 2D classification on these particles as it is usual for a small number of them to become badly off-center or be corrupted by hot pixels that were masked during regular motion correction.

Hi Dan,

Apologies if this has already been covered in this (excellent and extremely helpful!) thread:

Does csparc2star.py account for the change in the angle of the astigmatism axis when inverting the coordinates? That is, the change in defocusU & defocusV due to the change in orientation of the mics?

The reason I ask is that we encountered a puzzling situation recently, as follows:

  • Initial processing performed using MC2 corrected mics (+Patch CTF), final resolution 2.2 Å. Some beam tilt, minimal tetrafoil aberrations noted.
  • We then performed patch motion, Patch CTF on the patch motion mics, and re-extracted after applying using csparc2star.py --inverty on the refined particle set. These particles retain the defocus values from the prior refinement by default.
  • Refinement of these particles gives a reconstruction at 2.9Å, with apparent strong tetrafoil aberrations.
  • If instead, I force-extract the CTFs from the new patch CTF job, refinement proceeds to 2.2Å, as expected, with no tetrafoil aberrations evident.
  • I think this indicates that some transformation ought to be applied to defocusU & defocusV when inverting Y; Of course this will only make much of a dfifference at high resolution, and/or in the presence of strong astigmatism.

Cheers
Oli

Hmm, good point. That would certainly (at least partially) explain why converted motion tracks aren’t working as well.

Adding 90˚ to the angle is the same thing as flipping U and V, right? Can you check what happens if you just manually change the U and V field names before importing?

I’m not sure, but can check that easily, will do

So comparing identical particles before and after force re-extracting CTFs, defocusU & defocusV are unchanged, but the sign of the defocusAngle changes (e.g. -29 becomes 29). I think this works out to the same thing though as swapping U & V while keeping the angle unchanged…?

I also converted the CS particle stack data to a .star file using csparc2star.py and tried to use it for Bayesian polishing in RELION. But it gave me “There is no movie metadata STAR file! for any micrographs!” error and have not been able to proceed. Is this a problem with the .star file not having rlnMicrographMetadata? please tell me how exactly you solved this problem.

I just want to do Bayesian polishing with RELION using CS particle data, but this thread is so complex and difficult to understand for me. If someone could summarize the specific steps, I think it would help a lot of people like me.

Best regards.

Yas

Hi @DanielAsarnow,

I want to do Bayesian polishing in RELION with particle stack after NU refinement in CS. I followed Method 2 in the csparc2star.py instruction (Using cryoSPARC output for Bayesian Polishing · asarnow/pyem Wiki · GitHub), but I received the error message “ERROR: There is no movie metadata STAR file for any micrographs!” in RELION GUI. I have read several related threads but am struggling to find a concrete solution for long time…
Please help me.

You have to look at your text files and fix the paths.

@DanielAsarnow

I checked the paths in .star files and fixed the problem. Thanks!

Hey Oli, did you ever check if just swapping U and V in the imported star header fixes the problem? I don’t think it matters which of the few identical operations are performed, the calculated CTFs will be the same and this one is the easiest to do manually. We can automate it in csparc2star.py if it works like this.

Following this with interest. Apologies, wouldn’t swapping defocusU and defocusV values amount to a 90°-rotation transformation rather than the mirror-in-x-axis that the sign change implies? I thought the defocus angle, by CtfFind convention, was taken to be the angle between the larger of the two defoci and the x-axis.

Cheers,
Yang

1 Like

That’s right, I was thinking about it wrong. It’s either negative sign or (360 - x).

@olibclarke This is a --flipy case correct? I will add negating the defocus angle to the block that is flipping the Y origin and transforming the angles. In the pure --inverty case, all the images have the same orientation, it’s just changing coordinates.

1 Like

Yep it’s a flipY case! Thanks Dan

Cheers
Oli

I pushed the change to negate the defocus angle in the --flipy block. Could you give it a test and see if that gives approximately the same behavior as the patch CTF extract?

Actually just double checked and it was actually --inverty, not --flipY - sorry!

The orientation of the particle images in this case didn’t matter, as we were re-refining - will check with --flipY now