JISCMail - CCPEM Archives

From: Axel Brilot <[log in to unmask]>
Sent: Friday, October 7, 2016 6:21 PM
To: Reza Khayat
Cc: [log in to unmask]
Subject: Re: [ccpem] RELION 2.0.1 tutorial discrepency with MotionCorr

The patch size is automatically increased if there is not enough signal to hit the accuracy threshold.
We have had good results here with 5 5 patches.

HTH

Axel

On Fri, Oct 7, 2016 at 3:19 PM, Reza Khayat <[log in to unmask]> wrote:

Any suggestions on what patch sizes to try?

Reza Khayat, PhD
Assistant Professor
City College of New York
Department of Chemistry
New York, NY 10031

________________________________________
From: Collaborative Computational Project in Electron cryo-Microscopy <[log in to unmask]> on behalf of Sjors Scheres <[log in to unmask]>
Sent: Friday, October 7, 2016 5:33 PM

To: [log in to unmask]
Subject: Re: [ccpem] RELION 2.0.1 tutorial discrepency with MotionCorr

We also have had great results with Motioncor2. We haven't tried yet to do
polishing after Motioncor2, but did compare unblur+polishing versus only
motioncor2 on the 2.2A betagal data set from Sriram (EMPIAR-10061).
Unblur+polishing gave a few resolution shells more information (2.2 vs
2.3A), but does come at an important computational costs compared to only
doing motioncor2. Therefore, at LMB, I'm now recommending people to first
do MotionCor2 (with patches and dose-weighting) and then do all your
classifications etc. Then, at the very end, if you did get your
almost-final high-resolution map, and do want to see whether you can
squeeze out a bit more information, do try polishing as well. As many data
sets never go to very high resolution and it thus wouldn't be worth to do
polishing anyway, this should save quite a bit of computational resources
(CPU time and disk space).
HTH,
Sjors

PS: one note of warning: in order to get the dose-weighting correct you
need to know the correct dose per frame. This sounds logical, but many
errors are being made with this. Especially with non-counting detectors.

> Motioncorr2 can also do dose weighting and it allows motion correction of
> patches (not only whole frame).
> In our hands motioncorr2 seems to always perform as good or better than
> driftcorr.
> This also means that using motioncorr2 we do not get any benefit anymore
> of doing particle-polishing at the end of the relion process (Using K2
> camera and ribosomes) and therefore skip this step.
>
> Cheers
> Marcus
>
>
> Marcus Fislage, PhD
>
> Howard Hughes Medical Institute (HHMI)
> Columbia University
> Department of Biochemistry and Biophysics
> Lab of Joachim Frank
> New York, NY
>
> email address: [log in to unmask]
> Phone: 212.305.9524
> Fax: 212.305.9500
>
>
> ________________________________________
> From: Collaborative Computational Project in Electron cryo-Microscopy
> [[log in to unmask]] on behalf of Hoover , David (NIH/CIT) [E]
> [[log in to unmask]]
> Sent: Friday, October 07, 2016 12:47 PM
> To: [log in to unmask]
> Subject: Re: [ccpem] RELION 2.0.1 tutorial discrepency with MotionCorr
>
> Is there any great benefit to one version or the other?
>
>> On Oct 7, 2016, at 12:33 PM, Sjors Scheres <[log in to unmask]>
>> wrote:
>>
>> Hi David,
>>
>> There are 2 different programs with very similar names:
>>
>> 1) Motioncorr, developed by Xueming Li, apparentloy now has a version
>> 2.1. This is also called driftcorr (and many other names), and is the
>> program you refer to below. This is the standard MotionCorr to which
>> RELION-1.4 wrapped, and RELION-2.0 also wraps.
>>
>> 2) Then there is Shawn Zheng and David Agard's new MotionCor2 program,
>> which you can find here: http://msg.ucsf.edu/em/software/motioncor2.html
>>
>> RELION-2.0 wraps to both programs. To distinguish it has an additional
>> question on the GUI: "Is this MOTIONCOR2"? Say NO if you use the program
>> under 1). Say YES if you use 2)
>>
>> HTH,
>> Sjors
>>
>>
>> On 10/07/2016 05:26 PM, Hoover , David (NIH/CIT) [E] wrote:
>>> Please, be more direct.
>>>
>>> What version of MotionCorr is the correct version?
>>>
>>> The webpage at http://cryoem.ucsf.edu/software/driftcorr.html only
>>> shows v2.1. What other versions are available and from where?
>>>
>>> David Hoover
>>> HPC @ NIH
>>>
>>>> On Oct 7, 2016, at 10:26 AM, Sjors Scheres <[log in to unmask]>
>>>> wrote:
>>>>
>>>> Ahhh! This is confusing, I didn't even know there was a version 2.1 of
>>>> motiocorr1.....
>>>> Yes, Wolfgang is correct: I mean David Agard's MotionCor2. If you use
>>>> Motioncorr1, then say No to that question on the GUI.
>>>> S
>>>>
>>>> On 10/07/2016 03:12 PM, Wolfgang Lugmayr wrote:
>>>>> hi,
>>>>>
>>>>> you are not using MotionCor2, you are are using motioncorr (dosef)
>>>>> 2.1.
>>>>> So say NO in the files "Is this MOTIONCOR2?"
>>>>>
>>>>> MotionCor2: http://msg.ucsf.edu/em/software/index.html
>>>>>
>>>>> cheers,
>>>>> wolfgang
>>>>>
>>>>>
>>>>> On 10/07/2016 03:57 PM, Hoover , David (NIH/CIT) [E] wrote:
>>>>>> What version of MotionCorr should be used with RELION 2.0.1? I am
>>>>>> following the tutorial and I'm getting the following errors:
>>>>>>
>>>>>> WARNING: there was an error executing:
>>>>>> /usr/local/apps/RELION2.0/motioncorr_v2.1/bin/dosefgpu_driftcorr
>>>>>> -InMrc Micrographs/Falcon_2012_06_12-14_33_35_0_movie.mrcs -OutMrc
>>>>>> MotionCorr/job002/Micrographs/Falcon_2012_06_12-14_33_35_0.mrc
>>>>>> -OutStack 1 -Patch 1 1 -Gpu 0 >>
>>>>>> MotionCorr/job002/Micrographs/Falcon_2012_06_12-14_33_35_0.out 2>>
>>>>>> MotionCorr/job002/Micrographs/Falcon_2012_06_12-14_33_35_0.err
>>>>>>
>>>>>> In the .out file,
>>>>>>
>>>>>> $ cat MotionCorr/job002/Micrographs/Falcon_2012_06_12-16_55_40_0.out
>>>>>> Undefined option:
>>>>>> Micrographs/Falcon_2012_06_12-16_55_40_0_movie.mrcs .Abort.
>>>>>> Error: Failed to read parameters. Abort!
>>>>>>
>>>>>> I have v2.1 of MotionCorr. The options -InMrc, -OutMrc, -OutStack,
>>>>>> -Patch, don't exist:
>>>>>>
>>>>>> $ /usr/local/apps/RELION2.0/motioncorr_v2.1/bin/dosefgpu_driftcorr
>>>>>> Dose Fractionation Tool:
>>>>>> Drift correction v2.1 (Nov 21, 2013)
>>>>>>
>>>>>> Input: InputStack.mrc [OPTION VALUE] ...
>>>>>> *Note: If OPTION isn't specified, the default value will
>>>>>> be used.
>>>>>>
>>>>>> OPTION VALUE(Default) Introduction
>>>>>> -crx 0 Image crop offset X
>>>>>> -cry 0 Image crop offset Y
>>>>>> -cdx 0 Image crop dimension X. 0:
>>>>>> Use maximum size.
>>>>>> -cdy 0 Image crop dimension Y. 0:
>>>>>> Use maximum size.
>>>>>> -bin 1 1 or 2. Bin stack before
>>>>>> processing, only 1x and 2x binning
>>>>>> -nst 0 First frame (0-base) used in
>>>>>> alignment.
>>>>>> -ned 0 Last frame (0-base) used in
>>>>>> alignment. 0: Use maximum value.
>>>>>> -nss 0 First frame (0-base) used
>>>>>> for final sum.
>>>>>> -nes 0 Last frame (0-base) used for
>>>>>> final sum. 0: Use maximum value.
>>>>>> -gpu 0 GPU device ID.
>>>>>> -bft 150 BFactor in pix^2.
>>>>>> -pbx 96 Box dimension for searching
>>>>>> CC peak.
>>>>>> -fod 2 Number of frame offset for
>>>>>> frame comparision.
>>>>>> -nps 0 Radius of noise peak.
>>>>>> -kit 1.0 Threshold of alignment error
>>>>>> in pixel.
>>>>>> -hgr 1 1: Use gain reference in MRC
>>>>>> header(MRC mode 5 only). 0: No.
>>>>>> -fgr FileName.mrc Gain reference. Applied when
>>>>>> specified.
>>>>>> -fdr FileName.mrc Dark reference. Applied when
>>>>>> specified.
>>>>>> -srs 0 1: Save uncorrected sum. 0:
>>>>>> No.
>>>>>> -ssr 0 1: Save uncorrected stack.
>>>>>> 0: No.
>>>>>> -ssc 0 1: Save corrected stack. 0:
>>>>>> No.
>>>>>> -scc 0 1: Save CC Map. 0: No.
>>>>>> -slg 1 1: Save Log. 0: No.
>>>>>> -atm 1 1: Align to middle frame
>>>>>> N/2+1. 0: No. <0: to |VALUE|.
>>>>>> -dsp 1 1: Save quick results. 0:
>>>>>> No.
>>>>>> -fsc 0 1: Calculate FSC. 0: No.
>>>>>> -frs FileName.mrc Uncorrected sum
>>>>>> -frt FileName.mrc Uncorrected stack
>>>>>> -fcs FileName.mrc Corrected sum
>>>>>> -fct FileName.mrc Corrected stack
>>>>>> -fcm FileName.mrc CC map
>>>>>> -flg FileName.txt Log file
>>>>>>
>>>>>> Additional Notes:
>>>>>> 1) MRC mode 5 was defined based on standard MRC format as
>>>>>> following:
>>>>>> a) A 32-bit-float Gain Reference is stored in the end of MRC
>>>>>> extended header(Symmetry Data).
>>>>>> b) Dark-subtracted frames is in format of unsigned 8-bit
>>>>>> integer (unsigned char).
>>>>>> 2) If both -hgr and -fgr are enabled, -fgr will be disabled.
>>>>>>
>>>>>> Wrote by Xueming Li @ Yifan Cheng Lab, UCSF
>>>>>>
>>>>>> Any hints would be helpful.
>>>>>>
>>>>>> Cheers,
>>>>>> David Hoover
>>>>>> HPC @ NIH
>>>>>
>>>> --
>>>> Sjors Scheres
>>>> MRC Laboratory of Molecular Biology
>>>> Francis Crick Avenue, Cambridge Biomedical Campus
>>>> Cambridge CB2 0QH, U.K.
>>>> tel: +44 (0)1223 267061
>>>> http://www2.mrc-lmb.cam.ac.uk/groups/scheres
>>
>> --
>> Sjors Scheres
>> MRC Laboratory of Molecular Biology
>> Francis Crick Avenue, Cambridge Biomedical Campus
>> Cambridge CB2 0QH, U.K.
>> tel: +44 (0)1223 267061
>> http://www2.mrc-lmb.cam.ac.uk/groups/scheres
>

--
Sjors Scheres
MRC Laboratory of Molecular Biology
Francis Crick Avenue, Cambridge Biomedical Campus
Cambridge CB2 0QH, U.K.
tel: +44 (0)1223 267061
http://www2.mrc-lmb.cam.ac.uk/groups/scheres