Re: [ccp4bb] How to determine Quaternary symmetry

[Jose Duarte]

You can try http://www.eppic-web.org. It will give you a full enumeration
of all symmetric assemblies present in the crystal. If the assembly you are
looking at is not symmetric (within a certain approximation) it will not be
listed in the results.

Hope it helps

Jose


On Mon, Jul 10, 2017 at 12:18 PM, Vands  wrote:

> Hi ,
>I have a protein which has A4 stoichiometry. I am trying to
> find symmetry component which should be D2 but one axis looks like
> translated which does not make it perfect D2. I am wondering if there is
> any tool which I can use to determine Quaternary symmetry.
> thanks
>
>
>
>
>
>
>
>
>
> --
> Vandna Kukshal
> Senior Scientist
> Dept. oncology
> Washington University School of Medicine
> 660 S. Euclid, Campus Box 8231
> St. Louis, MO 63110
>

Re: [ccp4bb] How to determine Quaternary symmetry

[Eleanor Dodson]

Hard to comment without more detail.
What is your cell and point group symmetry? Do you know space group?
What is likely asymmetric unit content?
Is there a non-crystallographic translation and if so what is it?

All this information given in GUI2 data processing report.

 Eleanor

On 10 July 2017 at 20:18, Vands  wrote:

> Hi ,
>I have a protein which has A4 stoichiometry. I am trying to
> find symmetry component which should be D2 but one axis looks like
> translated which does not make it perfect D2. I am wondering if there is
> any tool which I can use to determine Quaternary symmetry.
> thanks
>
>
>
>
>
>
>
>
>
> --
> Vandna Kukshal
> Senior Scientist
> Dept. oncology
> Washington University School of Medicine
> 660 S. Euclid, Campus Box 8231
> St. Louis, MO 63110
>

[ccp4bb] How to determine Quaternary symmetry

[Vands]

Hi ,
   I have a protein which has A4 stoichiometry. I am trying to find
symmetry component which should be D2 but one axis looks like translated
which does not make it perfect D2. I am wondering if there is any tool
which I can use to determine Quaternary symmetry.
thanks









-- 
Vandna Kukshal
Senior Scientist
Dept. oncology
Washington University School of Medicine
660 S. Euclid, Campus Box 8231
St. Louis, MO 63110

Re: [ccp4bb] crystallization optimization

[Patrick Shaw Stewart]

Microseed them into two or three random screens.

Search for MMS and rMMS online.

Good luck

Patrick




On 10 July 2017 at 15:47, Liuqing Chen <519198...@163.com> wrote:

> hello everyone!
> I get a condition (10% w/v PEG 6000, 100mm HEPES PH7.0) in which my
> protein grow small  needle like crystals, how can i optimize it to get
> bigger crystals?  the attach is the crystals  figure.
> thanks in advance
> sincerely
> Liuqing Chen
>



-- 
 patr...@douglas.co.ukDouglas Instruments Ltd.
 Douglas House, East Garston, Hungerford, Berkshire, RG17 7HD, UK
 Directors: Peter Baldock, Patrick Shaw Stewart

 http://www.douglas.co.uk
 Tel: 44 (0) 148-864-9090US toll-free 1-877-225-2034
 Regd. England 2177994, VAT Reg. GB 480 7371 36

Re: [ccp4bb] [ccp4bb] Rmergicide Through Programming

[Phil Evans]

> 

> (2) Rsym has just:
> 
>> R sym value in percent.
> 
> see 
> .
>  To be honest, if that is the official definition it does make me wonder what 
> it is doing in the dictionary at all.
> 
> Regards,
> Peter.
> 


Indeed

Re: [ccp4bb] AW: [ccp4bb] Rmergicide Through Programming

[Peter Keller]

On 10/07/17 16:42, Phil Evans wrote:

What is the difference between Rmerge and Rsym - I thought they were the same?
Rrim == Rmeas I think


The descriptions and formulae for most of these R values as used by the 
PDB can be found in the pdbx exchange dictionary, in the REFLNS_SHELL 
category.


(1) Rrim has:

 The redundancy-independent merging R factor value Rrim, also denoted Rmeas, for merging all intensities in a given shell. 


see 
) 
so Phil is right and they are the same.


(2) Rsym has just:


R sym value in percent.


see 
. 
To be honest, if that is the official definition it does make me wonder 
what it is doing in the dictionary at all.


Regards,
Peter.



Phil




On 10 Jul 2017, at 15:18, John Berrisford  wrote:

Dear Herman

The new PDB deposition system (OneDep) allows you to enter values for Rmerge, 
Rsym, Rpim, Rrim and / or CC half. If, during deposition, you do not provide a 
value for any of these metrics then we will ask you for a value for one of them.

Also, PDB format is a legacy format for the PDB. In 2014 mmCIF became the 
archive format for the PDB and some large entries are no longer distributed in 
PDB format. mmCIF is not limited by the constraints of punch cards.

Please see https://www.wwpdb.org/documentation/file-formats-and-the-pdb

Regards

John

PDBe



On 10/07/2017 09:26, herman.schreu...@sanofi.com wrote:

Dear All,

For me this whole discussion is an example of a large number of people barking 
at the wrong tree. The real issue is not whether data processing programs print 
amongst many quality indicators an Rmerge as well, but the fact that the PDB 
and many journals still insist on using the Rmerge as primary quality 
indicator. As long as this is true, novice scientist might be led to believe 
that Rmerge is the most important quality indicator. As soon as the PDB and the 
journals request some other indicator, this will be over. So that is where we 
should direct our efforts to.

I don't understand at all, why the PDB still insists on an obsolete quality 
indicator. However, the PDB format for the coordinates also dates back to the 
1960's to be used with punch cards.

My 2 cents.
Herman



-Ursprüngliche Nachricht-
Von: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] Im Auftrag von Edward 
A. Berry
Gesendet: Samstag, 8. Juli 2017 22:31
An: CCP4BB@JISCMAIL.AC.UK
Betreff: Re: [ccp4bb] Rmergicide Through Programming

But R-merge is not really narrower as a fraction of the mean value- it just 
gets smaller proportionantly as all the numbers get smaller:
RMSD of .0043 for R-meas multiplied by factor of 0.022/.027 gives 0.0035 which 
is the RMSD for Rmerge. The same was true in the previous example. You could 
multiply R-meas by .5 or .2 and get a sharper distribution yet! And that factor 
would be constant, where this only applies for super-low redundancy.

On 07/08/2017 03:23 PM, James Holton wrote:

The expected distribution of Rmeas values is still wider than that of Rmerge 
for data with I/sigma=30 and average multiplicity=2.0. Graph attached.

I expect that anytime you incorporate more than one source of information you 
run the risk of a noisier statistic because every source of information can 
contain noise.  That is, Rmeas combines information about multiplicity with the 
absolute deviates in the data to form a statistic that is more accurate that 
Rmerge, but also (potentially) less precise.

Perhaps that is what we are debating here?  Which is better? accuracy or 
precision?  Personally, I prefer to know both.

-James Holton
MAD Scientist

On 7/8/2017 11:02 AM, Frank von Delft wrote:

It is quite easy to end up with low multiplicities in the low resolution shell, 
especially for low symmetry and fast-decaying crystals.

It is this scenario where Rmerge (lowres) is more misleading than Reas.

phx


On 08/07/2017 17:31, James Holton wrote:

What does Rmeas tell us that Rmerge doesn't?  Given that we know the 
multiplicity?

-James Holton
MAD Scientist

On 7/8/2017 9:15 AM, Frank von Delft wrote:

Anyway, back to reality:  does anybody still use R statistics to evaluate anything other than 
/strong/ data?  Certainly I never look at it except for the low-resolution bin (or strongest 
reflections). Specifically, a "2%-dataset" in that bin is probably healthy, while a 
"9%-dataset" probably Has Issues.

In which case, back to Jacob's question:  what does Rmerge tell us that Rmeas 
doesn't.

phx




On 08/07/2017 17:02, James Holton wrote:

Sorry for the confusion.  I was going for brevity!  And failed.

I know that the multiplicity correction is applied on a per-hkl basis in the 
calculation of Rmeas.  However, the average multiplicity over the whole 
calculation is most likely not an integer. Some hkls may be observed twice 
while 

[ccp4bb] SHELXE: peptide occupancy refined to negative value

[Andreas Förster]

Dear all,

since SHELX is now part of CCP4, this question is not entirely off-topic.

I'm trying to solve structures by S-SAD.  Substructure looks weak but ok if
the right resolution cutoff is picked in SHELXD.

SHELXE is happy to do its thing for a while but then gives up with a
"Peptide occupancy has refined to negative value" error in one hand.  The
other hand is quite obviously (CC for partial structure, number of residues
built) wrong, but the PDB obtained with the antimatter peptides looks like
protein, is 80% complete and quite obviously the right solution.

Because of the error, SHELXE doesn't write phases.  How do I get these?  (I
could do MR, but there must be a more elegant way...)  Better yet, what
might cause the "negative occupancy" error and how do I avoid it?

Thanks and all best.


Andreas



-- 

Andreas Förster, Ph.D.
MX Application Scientist, Scientific Sales
Phone: +41 56 500 2100 | Direct: +41 56 500 21 76 | Email:
andreas.foers...@dectris.com
DECTRIS Ltd. | Taefernweg 1 | 5405 Baden-Daettwil | Switzerland |
www.dectris.com

[image: LinkedIn] 
 [image: facebook]







Confidentiality Note: This message is intended only for the use of the
named
recipient(s) and may contain confidential and/or privileged information. If
you
are not the intended recipient, please contact the sender and delete the
message.
Any unauthorized use of the information contained in this message is
prohibited.

Re: [ccp4bb] AW: [ccp4bb] Rmergicide Through Programming

[Phil Evans]

What is the difference between Rmerge and Rsym - I thought they were the same?
Rrim == Rmeas I think

Phil



> On 10 Jul 2017, at 15:18, John Berrisford  wrote:
> 
> Dear Herman
> 
> The new PDB deposition system (OneDep) allows you to enter values for Rmerge, 
> Rsym, Rpim, Rrim and / or CC half. If, during deposition, you do not provide 
> a value for any of these metrics then we will ask you for a value for one of 
> them.
> 
> Also, PDB format is a legacy format for the PDB. In 2014 mmCIF became the 
> archive format for the PDB and some large entries are no longer distributed 
> in PDB format. mmCIF is not limited by the constraints of punch cards.
> 
> Please see https://www.wwpdb.org/documentation/file-formats-and-the-pdb
> 
> Regards
> 
> John
> 
> PDBe
> 
> 
> 
> On 10/07/2017 09:26, herman.schreu...@sanofi.com wrote:
>> Dear All,
>> 
>> For me this whole discussion is an example of a large number of people 
>> barking at the wrong tree. The real issue is not whether data processing 
>> programs print amongst many quality indicators an Rmerge as well, but the 
>> fact that the PDB and many journals still insist on using the Rmerge as 
>> primary quality indicator. As long as this is true, novice scientist might 
>> be led to believe that Rmerge is the most important quality indicator. As 
>> soon as the PDB and the journals request some other indicator, this will be 
>> over. So that is where we should direct our efforts to.
>> 
>> I don't understand at all, why the PDB still insists on an obsolete quality 
>> indicator. However, the PDB format for the coordinates also dates back to 
>> the 1960's to be used with punch cards.
>> 
>> My 2 cents.
>> Herman
>> 
>> 
>> 
>> -Ursprüngliche Nachricht-
>> Von: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] Im Auftrag von 
>> Edward A. Berry
>> Gesendet: Samstag, 8. Juli 2017 22:31
>> An: CCP4BB@JISCMAIL.AC.UK
>> Betreff: Re: [ccp4bb] Rmergicide Through Programming
>> 
>> But R-merge is not really narrower as a fraction of the mean value- it just 
>> gets smaller proportionantly as all the numbers get smaller:
>> RMSD of .0043 for R-meas multiplied by factor of 0.022/.027 gives 0.0035 
>> which is the RMSD for Rmerge. The same was true in the previous example. You 
>> could multiply R-meas by .5 or .2 and get a sharper distribution yet! And 
>> that factor would be constant, where this only applies for super-low 
>> redundancy.
>> 
>> On 07/08/2017 03:23 PM, James Holton wrote:
>>> The expected distribution of Rmeas values is still wider than that of 
>>> Rmerge for data with I/sigma=30 and average multiplicity=2.0. Graph 
>>> attached.
>>> 
>>> I expect that anytime you incorporate more than one source of information 
>>> you run the risk of a noisier statistic because every source of information 
>>> can contain noise.  That is, Rmeas combines information about multiplicity 
>>> with the absolute deviates in the data to form a statistic that is more 
>>> accurate that Rmerge, but also (potentially) less precise.
>>> 
>>> Perhaps that is what we are debating here?  Which is better? accuracy or 
>>> precision?  Personally, I prefer to know both.
>>> 
>>> -James Holton
>>> MAD Scientist
>>> 
>>> On 7/8/2017 11:02 AM, Frank von Delft wrote:
 It is quite easy to end up with low multiplicities in the low resolution 
 shell, especially for low symmetry and fast-decaying crystals.
 
 It is this scenario where Rmerge (lowres) is more misleading than Reas.
 
 phx
 
 
 On 08/07/2017 17:31, James Holton wrote:
> What does Rmeas tell us that Rmerge doesn't?  Given that we know the 
> multiplicity?
> 
> -James Holton
> MAD Scientist
> 
> On 7/8/2017 9:15 AM, Frank von Delft wrote:
>> Anyway, back to reality:  does anybody still use R statistics to 
>> evaluate anything other than /strong/ data?  Certainly I never look at 
>> it except for the low-resolution bin (or strongest reflections). 
>> Specifically, a "2%-dataset" in that bin is probably healthy, while a 
>> "9%-dataset" probably Has Issues.
>> 
>> In which case, back to Jacob's question:  what does Rmerge tell us that 
>> Rmeas doesn't.
>> 
>> phx
>> 
>> 
>> 
>> 
>> On 08/07/2017 17:02, James Holton wrote:
>>> Sorry for the confusion.  I was going for brevity!  And failed.
>>> 
>>> I know that the multiplicity correction is applied on a per-hkl basis 
>>> in the calculation of Rmeas.  However, the average multiplicity over 
>>> the whole calculation is most likely not an integer. Some hkls may be 
>>> observed twice while others only once, or perhaps 3-4 times in the same 
>>> scaling run.
>>> 
>>> Allow me to do the error propagation properly.  Consider the scenario:
>>> 
>>> Your outer resolution bin has a true I/sigma = 1.00 and average 
>>> multiplicity of 2.0. Let's say there are 100 hkl indices in this 

Re: [ccp4bb] Ramachandran oultliers increase upon restrained refinement

[Phoebe A. Rice]

4% outliers at < 3A seems a little high to me.
A trick that often works for me is to truncate the side chains surrounding the 
offending peptide to Ala or Gly, optimize the backbone, and then put the side 
chains back on.  Often that makes it clear that a different rotamer would work 
better.


++

Phoebe A. Rice
Dept. of Biochemistry & Molecular Biology
The University of Chicago

pr...@uchicago.edu
Mobile DNA III: mobile elements are everywhere!  
http://www.asmscience.org/content/book/10.1128/9781555819217


From: CCP4 bulletin board [CCP4BB@JISCMAIL.AC.UK] on behalf of Vipul Panchal 
[panchal.vi...@igib.in]
Sent: Sunday, July 02, 2017 12:31 PM
To: CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] Ramachandran oultliers increase upon restrained refinement

I do agree with Eleanor. When I was solving structure at 2.16A resolution, 
outlier residues were having stearic clash or required side chain flipping.

At 2.76A resolution, hydrogen bonds would be difficult to visulize.

I found phenix.refine more user friendly. You may too find it useful.

Vipul Panchal,
Ph.D. student
CSIR-IGIB
(M)- 091 7678617949

On 02-Jul-2017 9:14 PM, "Eleanor Dodson" 
> wrote:
Just remember - most Ramachandran outliers are due to errors in the environment 
- eg: maybe some side chains clash hence refinement tries to move things to 
accommodate that bad feature, etc etc etc...
At that resolution it is inevitable you will have some level of 
mis-interpretation ..
4% outliers does not surprise me.

EDSTATS is a useful tool to find things such as pep flips - you can access it 
most simply from CCP4 GUI2 .

But unless the outliers are in a important part of the structure I would 
suggest checking, then living with them.

Eleanor






On 2 July 2017 at 16:31, Rajesh Kumar 
> wrote:
Dear Meytal,

PHENIX-REFINE has an option for Ramachandran outlier refine. If you check this 
on, it will do the work. But after this refinement, you must check every 
residues to make sure residues are in the density.

Thank you
Rajesh


 ---x
With regards
Rajesh K. Harijan, Ph.D.
Schramm Laboratory
Albert Einstein College of Medicine
1300 Morris Park Ave., Bronx, NY 10461
Tel: 718.430.2777  |  Fax: 
718.430.8565



On Sun, Jul 2, 2017 at 7:26 AM, Meytal Galilee 
> wrote:
Dear all,
I am refining a 2.76A structure using refmac5.
I keep fixing the Ramachandran outliers down to 18 (1.9%), however, upon 
restrained refinement, the outliers increase back to 35.
Do you have any suggestions how can I fix my structure?
Thanks,
Meytal Galilee

[ccp4bb] crystallization optimization

[Liuqing Chen]

hello everyone!
I get a condition (10% w/v PEG 6000, 100mm HEPES PH7.0) in which my protein 
grow small  needle like crystals, how can i optimize it to get bigger crystals? 
 the attach is the crystals  figure.
thanks in advance
sincerely
Liuqing Chen

Re: [ccp4bb] AW: [ccp4bb] Rmergicide Through Programming

[John Berrisford]

Dear Herman

The new PDB deposition system (OneDep) allows you to enter values for 
Rmerge, Rsym, Rpim, Rrim and / or CC half. If, during deposition, you do 
not provide a value for any of these metrics then we will ask you for a 
value for one of them.


Also, PDB format is a legacy format for the PDB. In 2014 mmCIF became 
the archive format for the PDB and some large entries are no longer 
distributed in PDB format. mmCIF is not limited by the constraints of 
punch cards.


Please see https://www.wwpdb.org/documentation/file-formats-and-the-pdb

Regards

John

PDBe



On 10/07/2017 09:26, herman.schreu...@sanofi.com wrote:

Dear All,

For me this whole discussion is an example of a large number of people barking 
at the wrong tree. The real issue is not whether data processing programs print 
amongst many quality indicators an Rmerge as well, but the fact that the PDB 
and many journals still insist on using the Rmerge as primary quality 
indicator. As long as this is true, novice scientist might be led to believe 
that Rmerge is the most important quality indicator. As soon as the PDB and the 
journals request some other indicator, this will be over. So that is where we 
should direct our efforts to.

I don't understand at all, why the PDB still insists on an obsolete quality 
indicator. However, the PDB format for the coordinates also dates back to the 
1960's to be used with punch cards.

My 2 cents.
Herman



-Ursprüngliche Nachricht-
Von: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] Im Auftrag von Edward 
A. Berry
Gesendet: Samstag, 8. Juli 2017 22:31
An: CCP4BB@JISCMAIL.AC.UK
Betreff: Re: [ccp4bb] Rmergicide Through Programming

But R-merge is not really narrower as a fraction of the mean value- it just 
gets smaller proportionantly as all the numbers get smaller:
RMSD of .0043 for R-meas multiplied by factor of 0.022/.027 gives 0.0035 which 
is the RMSD for Rmerge. The same was true in the previous example. You could 
multiply R-meas by .5 or .2 and get a sharper distribution yet! And that factor 
would be constant, where this only applies for super-low redundancy.

On 07/08/2017 03:23 PM, James Holton wrote:

The expected distribution of Rmeas values is still wider than that of Rmerge 
for data with I/sigma=30 and average multiplicity=2.0. Graph attached.

I expect that anytime you incorporate more than one source of information you 
run the risk of a noisier statistic because every source of information can 
contain noise.  That is, Rmeas combines information about multiplicity with the 
absolute deviates in the data to form a statistic that is more accurate that 
Rmerge, but also (potentially) less precise.

Perhaps that is what we are debating here?  Which is better? accuracy or 
precision?  Personally, I prefer to know both.

-James Holton
MAD Scientist

On 7/8/2017 11:02 AM, Frank von Delft wrote:

It is quite easy to end up with low multiplicities in the low resolution shell, 
especially for low symmetry and fast-decaying crystals.

It is this scenario where Rmerge (lowres) is more misleading than Reas.

phx


On 08/07/2017 17:31, James Holton wrote:

What does Rmeas tell us that Rmerge doesn't?  Given that we know the 
multiplicity?

-James Holton
MAD Scientist

On 7/8/2017 9:15 AM, Frank von Delft wrote:

Anyway, back to reality:  does anybody still use R statistics to evaluate anything other than 
/strong/ data?  Certainly I never look at it except for the low-resolution bin (or strongest 
reflections). Specifically, a "2%-dataset" in that bin is probably healthy, while a 
"9%-dataset" probably Has Issues.

In which case, back to Jacob's question:  what does Rmerge tell us that Rmeas 
doesn't.

phx




On 08/07/2017 17:02, James Holton wrote:

Sorry for the confusion.  I was going for brevity!  And failed.

I know that the multiplicity correction is applied on a per-hkl basis in the 
calculation of Rmeas.  However, the average multiplicity over the whole 
calculation is most likely not an integer. Some hkls may be observed twice 
while others only once, or perhaps 3-4 times in the same scaling run.

Allow me to do the error propagation properly.  Consider the scenario:

Your outer resolution bin has a true I/sigma = 1.00 and average multiplicity of 2.0. 
Let's say there are 100 hkl indices in this bin.  I choose the "true" 
intensities of each hkl from an exponential (aka Wilson) distribution. Further assume the 
background is high, so the error in each observation after background subtraction may be 
taken from a Gaussian distribution. Let's further choose the per-hkl multiplicity from a 
Poisson distribution with expectation value 2.0, so 0 is possible, but the long-term 
average multiplicity is 2.0. For R calculation, when multiplicity of any given hkl is 
less than 2 it is skipped. What I end up with after 120,000 trials is a distribution of 
values for each R factor.  See attached graph.

What I hope is readily apparent is that the distribution of Rmerge
values is 

[ccp4bb] [SOLVED] Re: [ccp4bb] latest XDS only using a single thread

[Florian Sauer]

Dear all,

after looking through my input file, Kay found that the problem was the 
option


SECONDS=600

which limits XDS to run in a single thread.
Deleting the line allowed running on all available cores.

Florian



please send me your XDS.INP and .LP files by email.

thanks,

Kay

On 2017-07-10 13:24, Florian Sauer wrote:

Hi Kay,

thanks for your quick response!

a) I am using BUILT=20170615 on Ubuntu 14.04.
b) xds_par
c) My machine has 2 cores (4 threads possible). The dataset contains
3600 frames. On a different machine (Opensuse) running an older built
(20170215), xds_par uses all available cores (12) when using the same
XDS.INP / data.
d) The input file (non modified as automatically generated at ESRF)
contains the line: MAXIMUM_NUMBER_OF_PROCESSORS= 16. However when
running xds_par the output says:

   * COLSPOT * (VERSION Jun 1, 2017  BUILT=20170615)  10-Jul-2017

   INPUT PARAMETER VALUES
   --
   MAXIMUM_NUMBER_OF_PROCESSORS=   1  (0: automatic choice of OpenMP
threads)
   number of OpenMP threads used   1
   MAXIMUM_NUMBER_OF_JOBS=   1  (0:automatic choice of forked main tasks)

Everything else runs correctly.

Cheers,

Florian

P.S.: I just checked the auto-processed files from ESRF who are using
the same XDS version. Also here:

MAXIMUM_NUMBER_OF_PROCESSORS=   1  (0: automatic choice of OpenMP
threads)
   number of OpenMP threads used   1



On 10.07.2017 11:46, Kay Diederichs wrote:

Hi Florian,

difficult to say without knowing more details.

a) you should be using the XDS version that identifies itself with
BUILT=20170615
b) are you using xds or xds_par? Only xds_par is parallelized, xds
is single-threaded
c) I assume your machine has >1 core, and a DELPHI-sized batch of
frames has >1 frames
d) xds_par will not use more threads (specified as
MAXIMUM_NUMBER_OF_PROCESSES) than your machine has cores

AFAICT you are the only person with this problem, so there must be
something special about your input or setup.

best,
Kay



On Mon, 10 Jul 2017 11:25:07 +0200, Florian Sauer
 wrote:


Dear all,

I have recently installed the latest version of XDS (Linux 64 bit) and
found that xds_par is only using a single thread despite having
MAXIMUM_NUMBER_OF_PROCESSORS= 16
In the latest version (licensed till Sep 2017) XDS is using the full
number of threads with the same XDS.INP / data.

Does anything have to be specified differently in the new version?

Best wishes,

Florian

--
Dr. Florian Sauer
Rudolf Virchow Zentrum für Experimentelle Biomedizin
Josef-Schneider-Str. 2, Haus D15
97080 Würzburg

--
Dr. Florian Sauer
Rudolf Virchow Zentrum für Experimentelle Biomedizin
Josef-Schneider-Str. 2, Haus D15
97080 Würzburg





--
Dr. Florian Sauer
Rudolf Virchow Zentrum für Experimentelle Biomedizin
Josef-Schneider-Str. 2, Haus D15
97080 Würzburg

Re: [ccp4bb] latest XDS only using a single thread

[Kay Diederichs]

Hi Florian,

please send me your XDS.INP and .LP files by email.

thanks,

Kay

On 2017-07-10 13:24, Florian Sauer wrote:
> Hi Kay,
> 
> thanks for your quick response!
> 
> a) I am using BUILT=20170615 on Ubuntu 14.04.
> b) xds_par
> c) My machine has 2 cores (4 threads possible). The dataset contains
> 3600 frames. On a different machine (Opensuse) running an older built
> (20170215), xds_par uses all available cores (12) when using the same
> XDS.INP / data.
> d) The input file (non modified as automatically generated at ESRF)
> contains the line: MAXIMUM_NUMBER_OF_PROCESSORS= 16. However when
> running xds_par the output says: 
> 
>  * COLSPOT * (VERSION Jun 1, 2017  BUILT=20170615)  10-Jul-2017
> 
>  INPUT PARAMETER VALUES
>  --
>  MAXIMUM_NUMBER_OF_PROCESSORS=   1  (0: automatic choice of OpenMP threads)
>  number of OpenMP threads used   1
>  MAXIMUM_NUMBER_OF_JOBS=   1  (0:automatic choice of forked main tasks)
> 
> Everything else runs correctly.
> 
> Cheers,
> 
> Florian
> 
> P.S.: I just checked the auto-processed files from ESRF who are using
> the same XDS version. Also here:
> 
> MAXIMUM_NUMBER_OF_PROCESSORS=   1  (0: automatic choice of OpenMP threads)
>  number of OpenMP threads used   1
> 
> 
> 
> On 10.07.2017 11:46, Kay Diederichs wrote:
>> Hi Florian,
>>
>> difficult to say without knowing more details.
>>
>> a) you should be using the XDS version that identifies itself with 
>> BUILT=20170615
>> b) are you using xds or xds_par? Only xds_par is parallelized, xds is 
>> single-threaded
>> c) I assume your machine has >1 core, and a DELPHI-sized batch of frames has 
>> >1 frames
>> d) xds_par will not use more threads (specified as 
>> MAXIMUM_NUMBER_OF_PROCESSES) than your machine has cores
>>
>> AFAICT you are the only person with this problem, so there must be something 
>> special about your input or setup. 
>>
>> best,
>> Kay
>>
>>
>>
>> On Mon, 10 Jul 2017 11:25:07 +0200, Florian Sauer 
>>  wrote:
>>
>>> Dear all,
>>>
>>> I have recently installed the latest version of XDS (Linux 64 bit) and 
>>> found that xds_par is only using a single thread despite having  
>>> MAXIMUM_NUMBER_OF_PROCESSORS= 16
>>> In the latest version (licensed till Sep 2017) XDS is using the full 
>>> number of threads with the same XDS.INP / data.
>>>
>>> Does anything have to be specified differently in the new version?
>>>
>>> Best wishes,
>>>
>>> Florian
>>>
>>> -- 
>>> Dr. Florian Sauer
>>> Rudolf Virchow Zentrum für Experimentelle Biomedizin
>>> Josef-Schneider-Str. 2, Haus D15
>>> 97080 Würzburg
> 
> 
> -- 
> Dr. Florian Sauer
> Rudolf Virchow Zentrum für Experimentelle Biomedizin
> Josef-Schneider-Str. 2, Haus D15
> 97080 Würzburg
> 


-- 
Kay Diederichshttp://strucbio.biologie.uni-konstanz.de
email: kay.diederi...@uni-konstanz.deTel +49 7531 88 4049 Fax 3183
Fachbereich Biologie, Universität Konstanz, Box M647, D-78457 Konstanz

This e-mail is digitally signed. If your e-mail client does not have the
necessary capabilities, just ignore the attached signature "smime.p7s".



smime.p7s
Description: S/MIME Cryptographic Signature

[ccp4bb] Two PhD positions at the Interfaculty Institute of Biochemistry - Prof. Thilo Stehle

[Georg Zocher]

Dear CCP4BB-Users,

On behalf of Prof. Thilo Stehle I would like to post a job offer for two 
PhD positions (see below) at the Interfaculty Institute of Biochemistry.


Best Regards,

Georg


*Two PhD positions at the Interfaculty Institute of Biochemistry**
*
We  offer  two  PhD  positions  in  the  group  of  Professor Stehle  
at  the  Interfaculty  Institute  of  Biochemistry  in Tübingen. Our 
group is interested in the atomic details of interactions between 
pathogens and hosts in order to  describe the  mechanisms  of  pathogen  
engagement of  target  cells  and to  provide  a  basis  for  vaccine  
and drug design.


The  successful  candidates  will  work  on  the  structural  and 
functional  characterization  of  virus-glycan interactions  and on  
the  structural  and  functional  analysis  of  enzymes involved  in  
cell  wall  synthesis  and degradation in pathogenic bacteria, 
respectively. We are searching for highly motivated individuals with a 
Master degree in a relevant field (e. g. biochemistry or chemistry). The 
ideal candidates will have profound practical and theoretical knowledge 
in construct design and optimization, protein production and 
purification. Experience in crystallization, structure determination and 
other biophysical methods is an advantage. We expect excellent 
communication skills, willingness to work in a team,  a strong  
dedication  and motivation and  the  ability  to  design,  plan  and  
interpret experiments  in  an independent manner. Fluency in English is 
expected and a good working knowledge of German is a plus but not mandatory.


The  salary  will  be  based  on  German  federal  TV-L  13 (65%).  The  
positions  are  fully  funded  and  available immediately.  
Applications  will  be  considered  until  18th August  2017. The  
University  of  Tübingen  is  an equal-opportunity employer. 
Applications of women are explicitly encouraged. Applications  
including  contact  information (E-mail,  phone,  or  Skype),  CV,  
research  experience,  copy of  the Master degree certificate, and 
contact information of two persons for references should be send as 
single pdf document (max. size 3 MB) to thilo.stehle[at]uni-tuebingen.de.


--
Universität Tübingen
Interfakultäres Institut für Biochemie
Dr. Georg Zocher
Hoppe-Seyler-Str. 4
72076 Tuebingen
Germany
 
Fon: +49(0)-7071-2975359

Mail: georg.zoc...@uni-tuebingen.de
http://www.ifib.uni-tuebingen.de

[ccp4bb] Joint PhD studentship Oxford/Diamond - entry 2017

[Kamel El Omari]

Dear all,

The Oxford Interdisciplinary Bioscience (http://www.biodtp.ox.ac.uk) is funding 
a joint PhD studentship between Diamond and the Division of Structural Biology 
(STRUBI, Oxford).
The aim of the project is to unravel the mechanism of viral fusion of 
pestiviruses using crystallographic and/or electron microscopy techniques. For 
further details see: 
http://www.biodtp.ox.ac.uk/wp-content/uploads/2017/07/iCASE-Advert_ElOmari-Stuart.pdf

This project is funded for four years by the Biotechnology and Biological 
Sciences Research Council BBSRC and Diamond Light Source. BBSRC eligibility 
criteria for studentship funding applies 
(http://www.bbsrc.ac.uk/documents/studentship-eligibility-pdf/).
Further particulars, including details on how to apply can be accessed online: 
http://www.biodtp.ox.ac.uk/diamond-light-source-studentship/index.html

Regards,
Kamel

-- 
This e-mail and any attachments may contain confidential, copyright and or 
privileged material, and are for the use of the intended addressee only. If you 
are not the intended addressee or an authorised recipient of the addressee 
please notify us of receipt by returning the e-mail and do not use, copy, 
retain, distribute or disclose the information in or attached to the e-mail.
Any opinions expressed within this e-mail are those of the individual and not 
necessarily of Diamond Light Source Ltd. 
Diamond Light Source Ltd. cannot guarantee that this e-mail or any attachments 
are free from viruses and we cannot accept liability for any damage which you 
may sustain as a result of software viruses which may be transmitted in or with 
the message.
Diamond Light Source Limited (company no. 4375679). Registered in England and 
Wales with its registered office at Diamond House, Harwell Science and 
Innovation Campus, Didcot, Oxfordshire, OX11 0DE, United Kingdom

Re: [ccp4bb] latest XDS only using a single thread

[Kay Diederichs]

Hi Florian,

difficult to say without knowing more details.

a) you should be using the XDS version that identifies itself with 
BUILT=20170615
b) are you using xds or xds_par? Only xds_par is parallelized, xds is 
single-threaded
c) I assume your machine has >1 core, and a DELPHI-sized batch of frames has >1 
frames
d) xds_par will not use more threads (specified as MAXIMUM_NUMBER_OF_PROCESSES) 
than your machine has cores

AFAICT you are the only person with this problem, so there must be something 
special about your input or setup. 

best,
Kay



On Mon, 10 Jul 2017 11:25:07 +0200, Florian Sauer 
 wrote:

>Dear all,
>
>I have recently installed the latest version of XDS (Linux 64 bit) and 
>found that xds_par is only using a single thread despite having  
>MAXIMUM_NUMBER_OF_PROCESSORS= 16
>In the latest version (licensed till Sep 2017) XDS is using the full 
>number of threads with the same XDS.INP / data.
>
>Does anything have to be specified differently in the new version?
>
>Best wishes,
>
>Florian
>
>-- 
>Dr. Florian Sauer
>Rudolf Virchow Zentrum für Experimentelle Biomedizin
>Josef-Schneider-Str. 2, Haus D15
>97080 Würzburg

[ccp4bb] latest XDS only using a single thread

[Florian Sauer]

Dear all,

I have recently installed the latest version of XDS (Linux 64 bit) and 
found that xds_par is only using a single thread despite having  
MAXIMUM_NUMBER_OF_PROCESSORS= 16
In the latest version (licensed till Sep 2017) XDS is using the full 
number of threads with the same XDS.INP / data.


Does anything have to be specified differently in the new version?

Best wishes,

Florian

--
Dr. Florian Sauer
Rudolf Virchow Zentrum für Experimentelle Biomedizin
Josef-Schneider-Str. 2, Haus D15
97080 Würzburg

[ccp4bb] AW: [ccp4bb] Rmergicide Through Programming

[Herman . Schreuder]

Dear All,

For me this whole discussion is an example of a large number of people barking 
at the wrong tree. The real issue is not whether data processing programs print 
amongst many quality indicators an Rmerge as well, but the fact that the PDB 
and many journals still insist on using the Rmerge as primary quality 
indicator. As long as this is true, novice scientist might be led to believe 
that Rmerge is the most important quality indicator. As soon as the PDB and the 
journals request some other indicator, this will be over. So that is where we 
should direct our efforts to.

I don't understand at all, why the PDB still insists on an obsolete quality 
indicator. However, the PDB format for the coordinates also dates back to the 
1960's to be used with punch cards.

My 2 cents.
Herman



-Ursprüngliche Nachricht-
Von: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] Im Auftrag von Edward 
A. Berry
Gesendet: Samstag, 8. Juli 2017 22:31
An: CCP4BB@JISCMAIL.AC.UK
Betreff: Re: [ccp4bb] Rmergicide Through Programming

But R-merge is not really narrower as a fraction of the mean value- it just 
gets smaller proportionantly as all the numbers get smaller:
RMSD of .0043 for R-meas multiplied by factor of 0.022/.027 gives 0.0035 which 
is the RMSD for Rmerge. The same was true in the previous example. You could 
multiply R-meas by .5 or .2 and get a sharper distribution yet! And that factor 
would be constant, where this only applies for super-low redundancy.

On 07/08/2017 03:23 PM, James Holton wrote:
>
> The expected distribution of Rmeas values is still wider than that of Rmerge 
> for data with I/sigma=30 and average multiplicity=2.0. Graph attached.
>
> I expect that anytime you incorporate more than one source of information you 
> run the risk of a noisier statistic because every source of information can 
> contain noise.  That is, Rmeas combines information about multiplicity with 
> the absolute deviates in the data to form a statistic that is more accurate 
> that Rmerge, but also (potentially) less precise.
>
> Perhaps that is what we are debating here?  Which is better? accuracy or 
> precision?  Personally, I prefer to know both.
>
> -James Holton
> MAD Scientist
>
> On 7/8/2017 11:02 AM, Frank von Delft wrote:
>>
>> It is quite easy to end up with low multiplicities in the low resolution 
>> shell, especially for low symmetry and fast-decaying crystals.
>>
>> It is this scenario where Rmerge (lowres) is more misleading than Reas.
>>
>> phx
>>
>>
>> On 08/07/2017 17:31, James Holton wrote:
>>> What does Rmeas tell us that Rmerge doesn't?  Given that we know the 
>>> multiplicity?
>>>
>>> -James Holton
>>> MAD Scientist
>>>
>>> On 7/8/2017 9:15 AM, Frank von Delft wrote:

 Anyway, back to reality:  does anybody still use R statistics to evaluate 
 anything other than /strong/ data?  Certainly I never look at it except 
 for the low-resolution bin (or strongest reflections). Specifically, a 
 "2%-dataset" in that bin is probably healthy, while a "9%-dataset" 
 probably Has Issues.

 In which case, back to Jacob's question:  what does Rmerge tell us that 
 Rmeas doesn't.

 phx




 On 08/07/2017 17:02, James Holton wrote:
> Sorry for the confusion.  I was going for brevity!  And failed.
>
> I know that the multiplicity correction is applied on a per-hkl basis in 
> the calculation of Rmeas.  However, the average multiplicity over the 
> whole calculation is most likely not an integer. Some hkls may be 
> observed twice while others only once, or perhaps 3-4 times in the same 
> scaling run.
>
> Allow me to do the error propagation properly.  Consider the scenario:
>
> Your outer resolution bin has a true I/sigma = 1.00 and average 
> multiplicity of 2.0. Let's say there are 100 hkl indices in this bin.  I 
> choose the "true" intensities of each hkl from an exponential (aka 
> Wilson) distribution. Further assume the background is high, so the error 
> in each observation after background subtraction may be taken from a 
> Gaussian distribution. Let's further choose the per-hkl multiplicity from 
> a Poisson distribution with expectation value 2.0, so 0 is possible, but 
> the long-term average multiplicity is 2.0. For R calculation, when 
> multiplicity of any given hkl is less than 2 it is skipped. What I end up 
> with after 120,000 trials is a distribution of values for each R factor.  
> See attached graph.
>
> What I hope is readily apparent is that the distribution of Rmerge 
> values is taller and sharper than that of the Rmeas values.  The most 
> likely Rmeas is 80% and that of Rmerge is 64.6%.  This is expected, of 
> course.  But what I hope to impress upon you is that the most likely 
> value is not generally the one that you will get! The distribution has a 
> width.  Specifically, Rmeas could be as