Thanks Sjors.
Then we are doing it similarly to what you suggested. We have been
limiting one thread per core in Relion, and the refinement process we have
been running is using 20 processors from 5 computer, where each processor
has 32GB RAM and each computer has 128 GB RAM and 32 processors. We found
that 16GB per processor is the minimum so that the last step of the
refinement would not quit due to insufficient memory. A test process we
ran in 5 machines with 8 processors per machine (16GB per processor) was
found to scale down and become slower per iteration. It appears that the
RAM per processor is a key factor.
Another question is that when the refinement quits in the last step due to
insufficient memory, is it possible to redo memory distribution and
reassign processors by MPI and let relion continue from the last iteration
instead of from the beginning?
Thanks for the clarification of the parameter T in classification. We
probably donıt need to do it.
Best,
Qiu-Xing
On 10/6/14, 2:19 AM, "Sjors Scheres" <[log in to unmask]> wrote:
>Dear Qiu-Xing,
>The more cores the faster relion will run, but it does matter how you
>divide these cores among MPI and threads. Up to say 50-100 MPI processes,
>MPI scales much better than threads in relion-1.3 (this will probably
>change in relion-1.4). This means it may be worth to run more MPIs and
>fewer threads, but that would be provided your reconstructions fit in RAM.
>If you mean to day you have 20-core nodes with only 32Gb of RAM each, then
>running 20 threads may be necessary with that image size, as otherwise you
>run out of RAM.
>
>About the angular accuracy: yes this is normal in the beginning but it
>should go away in a few iterations. The parameter T is explained in
>Scheres JMB 2012, it is a user-controlled parameter to prevent overfitting
>in classification runs, where gold-standard FSCs are not possible. This
>remark of using T and 3D-classification with a single reference is only
>true for VERY difficult data sets, in general you should not have to worry
>about this. From the box size I infer your particle is rather big, so if
>you've collected good data, it should refine fine. (If you use a very
>small pixel size and stay well below half Nyquist, you may also consider
>to downscale the particles upon extraction, so your runs will go faster.)
>
>HTH,
>S
>
>
>
>> Dear all,
>> We have been running a refinement process for a dataset that is about
>> 50,000 particles and each image 384x384. We found that the refinement
>> speed has been fairly slow. For a 20 core parallel run, each core was
>> assigned 32 GB RAM, each iteration takes about 12 Hrs. The question is
>> whether adding more processors will make it run faster and whether the
>> RAM
>> assignment needs to follow certain rule of thumb.
>> Also at the beginning of the runs, the accuracy angles > 10 degrees and
>> Relion complained about poor accuracy. Is this usual? Also Relion
>> suggests
>> that " Sometimes it is better to tune resolution yourself by adjusting T
>> in a 3D-classification with a single classİ÷. What is the reasoning
>> behind
>> tuning resolution by adjusting T in 3D classification?
>>
>> Thanks.
>> Qiu-Xing
>>
>>
>>
>> On 10/3/14, 6:31 AM, "Sjors Scheres" <[log in to unmask]> wrote:
>>
>>>Hi Joel,
>>>As explained in the eLife paper, we used MOTIONCORR first and then did
>>>the polishing in RELION for gamma-secretase. Polishing still improved
>>>resolution from 4.9 to 4.5A. We now often take this approach, also for
>>>larger complexes.
>>>HTH,
>>>S
>>>
>>>On 10/02/2014 10:31 PM, Joel Meyerson wrote:
>>>> Hi Sjors,
>>>> Can you comment on whether particle polishing should be used on data
>>>> that was pre-aligned using a routine such as UCSF motioncorr? My
>>>> concern is that using pre-aligned data would later perturb the motion
>>>> modeling done for particle polishing.
>>>>
>>>> Thanks,
>>>> Joel
>>>
>>>--
>>>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
>>
>>
>> ________________________________
>>
>> UT Southwestern Medical Center
>> The future of medicine, today.
>>
>
>
>--
>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
>
|
