Re: [ccp4bb] EDS server - R-value

[Tim Gruene]

Dear Alastair,

I really like the feature of shelxl which writes the cif-file (required
for deposition to the CCSD) including all restraints, constraints, the
data, and the coordinates. The program shredcif extracts the ins-file
and the hkl-file, which are checksum protected against manual editing.
With this and the backward compatibility of shelxl it is actually not
impossible to reconstruct what was available at deposition time. For the
RNA polymerase I, both data and ins-file only cover 4.5MB of data, i.e.
not too much to handle by a data base.

I don't mean to promote shelxl here, but rather the method of providing
a (checksum protected) means to repeat the last refinement cycle totally
independent from outer resources.

Cheers,
Tim

On 04/04/2014 06:36 PM, Alastair Fyfe wrote:
> [...]
> bypassing the impossible task of recording/reconstructing  the program
> version and options used.
> 
>  On 04/04/2014 09:13 AM, Gerard Bricogne wrote:
>> I replied in too great a rush - it is the Rfree, or the Rfree-Rwork gap,
>> that would go up a lot if a structure originally refined at low
>> resolution
>> with targeting to an external high-resolution one was re-refined without
>> that targeting.
>>
>> Gerard.
>>
>> -- 
>> On Fri, Apr 04, 2014 at 04:55:03PM +0100, Gerard Bricogne wrote:
>>> Dear Nat and Tim,
>>>
>>> On Fri, Apr 04, 2014 at 08:18:06AM -0700, Nat Echols wrote:
 On Fri, Apr 4, 2014 at 1:57 AM, Tim Gruene 
 wrote:

> A more up-to-date reason is that programs calculate R values very
> differently. If you take a PDB file refined with program X and put it
> into program Y you easily get discrepancies greater than 5%.
>
 This is actually pretty rare - usually it's only 1-2% at most.
 Discrepancies like 16.5% versus 30.9% usually indicate that there's
 something wrong or misleading in the annotation of the entry, and often
 mean that you can't even reproduce the R-factor with the specified
 program.

 -Nat
>>>   It could also be that such a structure is the result of a
>>> refinement
>>> against low-ish resolution data that was restrained by "targeting" it to
>>> another similar structure that was refined against higher-resolution
>>> data,
>>> so as to retain the good local geometry of the latter in spite of the
>>> shortage of data at low resolution. This is perfectly legitimate, and
>>> was
>>> first done by Oliver Smart in BUSTER under the acronym of "LSSR",
>>> outlined
>>> in an ACA 2008 Abstract then fully described in Acta Cryst. D68, 368-380
>>> (2012). A similar feature has also become available in REFMAC and
>>> PHENIX.
>>>
>>>   The problem is that the deposition process is very likely to
>>> have lost
>>> track of the recourse to that method, so that the outcome of the
>>> refinement
>>> cannot be reproduced from the deposited data in an automated environment
>>> such as the EDS server.
>>>
>>>   This may not be the case with the structure Tim was mentioning,
>>> but it
>>> provides an opportunity to point out that the use of some recent
>>> approaches
>>> to improving refinement at low resolution may need further attention
>>> at the
>>> deposition stage to ensure reproducibility of the results from the
>>> deposited
>>> information.
>>>
>>>
>>>   With best wishes,
>>>  Gerard.
> 

-- 
Dr Tim Gruene
Institut fuer anorganische Chemie
Tammannstr. 4
D-37077 Goettingen

GPG Key ID = A46BEE1A



signature.asc
Description: OpenPGP digital signature

[ccp4bb] Create Links in PDB

[Remie Fawaz-Touma]

Hi all, 

I need help creating links between units of sugar (ligands) in the PDB file 
before refining so that CCP4 recognizes the sugars are attached.

I tried the one suggestion I got before Extension > Make a Link,  but I get 
discontinued bonds instead of full bonds.

Thanks so much for all your help in advance.

Remie

Re: [ccp4bb] Tenure track junior Group Leader Positions in Milan, Italy

[Jim Pflugrath]

Thanks for the clarification.  I thought at first this position might be 
related to Dance Your PhD.
http://news.sciencemag.org/scientific-community/2013/11/dance-your-ph.d.-and-winner-…


Jim


From: CCP4 bulletin board [CCP4BB@JISCMAIL.AC.UK] on behalf of Sebastiano 
Pasqualato [sebastiano.pasqual...@gmail.com]
Sent: Friday, April 04, 2014 11:20 AM
To: CCP4BB@JISCMAIL.AC.UK
Subject: Re: [ccp4bb] Tenure track junior Group Leader Positions in Milan, Italy


Ooopsss!!!
Of course it should read "experimental and computational cancer biology" but 
with this invasive automatic correctors, one typo can lead to very interesting 
fields of study, I guess…

Ciao,
S

On Apr 4, 2014, at 6:10 PM, "Oganesyan, Vaheh" 
mailto:oganesy...@medimmune.com>> wrote:

It sounds very interesting: “experimental and computational dance biology”. Any 
type of computational dance or there are style limitations?

Regards,

Vaheh Oganesyan
www.medimmune.com


From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of 
Sebastiano Pasqualato
Sent: Friday, April 04, 2014 12:01 PM
To: CCP4BB@JISCMAIL.AC.UK
Subject: [ccp4bb] Tenure track junior Group Leader Positions in Milan, Italy


Dear all,
there are open positions for junior Group Leaders in the field of experimental 
and computational dance biology at the European Institute of Oncology in milan, 
Italy.
Please, find enclosed the details.

To the extent this electronic communication or any of its attachments contain 
information that is not in the public domain, such information is considered by 
MedImmune to be confidential and proprietary. This communication is expected to 
be read and/or used only by the individual(s) for whom it is intended. If you 
have received this electronic communication in error, please reply to the 
sender advising of the error in transmission and delete the original message 
and any accompanying documents from your system immediately, without copying, 
reviewing or otherwise using them for any purpose. Thank you for your 
cooperation. To the extent this electronic communication or any of its 
attachments contain information that is not in the public domain, such 
information is considered by MedImmune to be confidential and proprietary. This 
communication is expected to be read and/or used only by the individual(s) for 
whom it is intended. If you have received this electronic communication in 
error, please reply to the sender advising of the error in transmission and 
delete the original message and any accompanying documents from your system 
immediately, without copying, reviewing or otherwise using them for any 
purpose. Thank you for your cooperation.

--
Sebastiano Pasqualato, PhD
Crystallography Unit
Department of Experimental Oncology
European Institute of Oncology
IFOM-IEO Campus
via Adamello, 16
20139 - Milano
Italy

tel +39 02 9437 5167
fax +39 02 9437 5990
web http://is.gd/IEO_XtalUnit

Re: [ccp4bb] EDS server - R-value

[Ethan A Merritt]

On Friday, 04 April, 2014 10:44:18 Nat Echols wrote:
> On Fri, Apr 4, 2014 at 10:39 AM, Alastair Fyfe  wrote:
> 
> > Reconstructing the refinement may be necessary in some cases but  there
> > are other applications (pdb-wide map statistics, development of map
> > analysis tools, quick model vs map checks) where access to the depositor's
> > final map would be sufficient.
> 
> I think these kinds of bulk analyses will be less effective if the maps are
> not calculated consistently.  For instance, the question of how to handle
> missing reflections can make a big difference.
> 
> Perhaps the coefficients are in fact included in many of the available
> > mmCIF  files? I should check..
> >
> 
> No, because most of those mmCIF files were probably converted from MTZ
> format by the deposition server(s).

I think depositing map coefficients is the wrong way to go.

Better to deposit the Fcalc along with the Fobs (or Iobs as you prefer)
and people can make maps using whatever set of coefficients they want.

Last time I checked a random sample of PDB entries, about half of
them provided Fcalc.   I think it should be added to the "mandatory" 
category of deposition information.

Ethan

Re: [ccp4bb] EDS server - R-value

[Nat Echols]

On Fri, Apr 4, 2014 at 10:39 AM, Alastair Fyfe  wrote:

> Reconstructing the refinement may be necessary in some cases but  there
> are other applications (pdb-wide map statistics, development of map
> analysis tools, quick model vs map checks) where access to the depositor's
> final map would be sufficient.


I think these kinds of bulk analyses will be less effective if the maps are
not calculated consistently.  For instance, the question of how to handle
missing reflections can make a big difference.

Perhaps the coefficients are in fact included in many of the available
> mmCIF  files? I should check..
>

No, because most of those mmCIF files were probably converted from MTZ
format by the deposition server(s).

-Nat

Re: [ccp4bb] EDS server - R-value

[Alastair Fyfe]

Reconstructing the refinement may be necessary in some cases but  there 
are other applications (pdb-wide map statistics, development of map 
analysis tools, quick model vs map checks) where access to the 
depositor's final map would be sufficient. Perhaps the coefficients are 
in fact included in many of the available mmCIF  files? I should check..

thanks,
Alastair

On 04/04/2014 09:52 AM, Nat Echols wrote:

On Fri, Apr 4, 2014 at 9:36 AM, Alastair Fyfe  wrote:


The topic brings up a question that I've been wondering about for some
time, perhaps someone can enlighten me. Why is it not standard practice to
deposit  map coefficients along with structure factors ? Unlike image
deposition there are no significant storage or file format issues. This
would  preserve a record of the "final" refinement used for publication,
bypassing the impossible task of recording/reconstructing  the program
version and options used.


There *are* file format issues, they're just very silly.  I think the
problem is that the PDB deposition service ignores most columns in MTZ
files, even with standard labels that have not changed for years.  If you
deposit the reflections as mmCIF instead, and use the designated mmCIF
dictionary items for your map coefficients (or Fcalc, phases, etc.), it
will preserve them.  For instance:

http://www.rcsb.org/pdb/download/downloadFile.do?fileFormat=structfact&structureId=4OW3

I still don't think this solves the problem of faithfully recording the
refinement protocol - how do you know what method was used to calculate the
maps?

-Nat

Re: [ccp4bb] EDS server - R-value

[Nat Echols]

On Fri, Apr 4, 2014 at 9:36 AM, Alastair Fyfe  wrote:

> The topic brings up a question that I've been wondering about for some
> time, perhaps someone can enlighten me. Why is it not standard practice to
> deposit  map coefficients along with structure factors ? Unlike image
> deposition there are no significant storage or file format issues. This
> would  preserve a record of the "final" refinement used for publication,
> bypassing the impossible task of recording/reconstructing  the program
> version and options used.
>

There *are* file format issues, they're just very silly.  I think the
problem is that the PDB deposition service ignores most columns in MTZ
files, even with standard labels that have not changed for years.  If you
deposit the reflections as mmCIF instead, and use the designated mmCIF
dictionary items for your map coefficients (or Fcalc, phases, etc.), it
will preserve them.  For instance:

http://www.rcsb.org/pdb/download/downloadFile.do?fileFormat=structfact&structureId=4OW3

I still don't think this solves the problem of faithfully recording the
refinement protocol - how do you know what method was used to calculate the
maps?

-Nat

Re: [ccp4bb] EDS server - R-value

[Alastair Fyfe]

The topic brings up a question that I've been wondering about for some 
time, perhaps someone can enlighten me. Why is it not standard practice 
to deposit  map coefficients along with structure factors ? Unlike image 
deposition there are no significant storage or file format issues. This 
would  preserve a record of the "final" refinement used for publication, 
bypassing the impossible task of recording/reconstructing  the program 
version and options used.


 On 04/04/2014 09:13 AM, Gerard Bricogne wrote:

I replied in too great a rush - it is the Rfree, or the Rfree-Rwork gap,
that would go up a lot if a structure originally refined at low resolution
with targeting to an external high-resolution one was re-refined without
that targeting.

Gerard.

--
On Fri, Apr 04, 2014 at 04:55:03PM +0100, Gerard Bricogne wrote:

Dear Nat and Tim,

On Fri, Apr 04, 2014 at 08:18:06AM -0700, Nat Echols wrote:

On Fri, Apr 4, 2014 at 1:57 AM, Tim Gruene  wrote:


A more up-to-date reason is that programs calculate R values very
differently. If you take a PDB file refined with program X and put it
into program Y you easily get discrepancies greater than 5%.


This is actually pretty rare - usually it's only 1-2% at most.
Discrepancies like 16.5% versus 30.9% usually indicate that there's
something wrong or misleading in the annotation of the entry, and often
mean that you can't even reproduce the R-factor with the specified program.

-Nat

  It could also be that such a structure is the result of a refinement
against low-ish resolution data that was restrained by "targeting" it to
another similar structure that was refined against higher-resolution data,
so as to retain the good local geometry of the latter in spite of the
shortage of data at low resolution. This is perfectly legitimate, and was
first done by Oliver Smart in BUSTER under the acronym of "LSSR", outlined
in an ACA 2008 Abstract then fully described in Acta Cryst. D68, 368-380
(2012). A similar feature has also become available in REFMAC and PHENIX.

  The problem is that the deposition process is very likely to have lost
track of the recourse to that method, so that the outcome of the refinement
cannot be reproduced from the deposited data in an automated environment
such as the EDS server.

  This may not be the case with the structure Tim was mentioning, but it
provides an opportunity to point out that the use of some recent approaches
to improving refinement at low resolution may need further attention at the
deposition stage to ensure reproducibility of the results from the deposited
information.


  With best wishes,
  
   Gerard.

Re: [ccp4bb] EDS server - R-value

[Zachary Wood]

Hi Jai,

I had the same thing happen when I pulled up one of my lab's structures. It was 
twinned, and at least in the past the EDS did not handle twinning.

Best regards,

Z

***
Zachary A. Wood, Ph.D.
Assistant Professor  
Department of Biochemistry & Molecular Biology
University of Georgia
Life Sciences Building, Rm A426B
120 Green Street
Athens, GA  30602-7229
Office: 706-583-0304
Lab:706-583-0303
FAX: 706-542-1738
***






On Apr 4, 2014, at 4:07 AM, jai mohan wrote:

> Dear all,
> Sorry for the off-topic Question.
> I just tried to extract files *.* from EDS server for a PDB entry.
> The page tells us that
> 
> There is no map available for this entry (),
> because our automatic script failed to produce an electron density map
> with an R-value (0.309) within 5 percentage points of the published one 
> (0.165).
> If you are the author of this entry and wish to help us remedy this
> situation, please contact us.
> Back to EDS home page
> 
> The reported R-value for the () PDB entry is 0.16 than how 0.309? 
> could anyone please explain about this!
> Sincerely,
> S.M. Jaimohan, Ph. D

[ccp4bb] feedback on diffuse diffraction pattern

[lbetts0508 .]

All - This crystal gave a hexagonal space group when the single reflections
are auto processed by xds.  The streaks are very prevalent - can I get
suggestions what they are caused by?  Thanks Laurie

https://drive.google.com/file/d/0Bx8-qQA_HKegUmliSkUxQ3JtYU1qci1LXzNnWlpxalJHaDBj/edit?usp=sharing

Re: [ccp4bb] Tenure track junior Group Leader Positions in Milan, Italy

[Sebastiano Pasqualato]

Ooopsss!!!
Of course it should read "experimental and computational cancer biology" but 
with this invasive automatic correctors, one typo can lead to very interesting 
fields of study, I guess…

Ciao,
S

On Apr 4, 2014, at 6:10 PM, "Oganesyan, Vaheh"  wrote:

> It sounds very interesting: “experimental and computational dance biology”. 
> Any type of computational dance or there are style limitations?
>  
> Regards,
>  
> Vaheh Oganesyan
> www.medimmune.com
> 
>  
> From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of 
> Sebastiano Pasqualato
> Sent: Friday, April 04, 2014 12:01 PM
> To: CCP4BB@JISCMAIL.AC.UK
> Subject: [ccp4bb] Tenure track junior Group Leader Positions in Milan, Italy
>  
>  
> Dear all,
> there are open positions for junior Group Leaders in the field of 
> experimental and computational dance biology at the European Institute of 
> Oncology in milan, Italy.
> Please, find enclosed the details.
>  
> To the extent this electronic communication or any of its attachments contain 
> information that is not in the public domain, such information is considered 
> by MedImmune to be confidential and proprietary. This communication is 
> expected to be read and/or used only by the individual(s) for whom it is 
> intended. If you have received this electronic communication in error, please 
> reply to the sender advising of the error in transmission and delete the 
> original message and any accompanying documents from your system immediately, 
> without copying, reviewing or otherwise using them for any purpose. Thank you 
> for your cooperation. To the extent this electronic communication or any of 
> its attachments contain information that is not in the public domain, such 
> information is considered by MedImmune to be confidential and proprietary. 
> This communication is expected to be read and/or used only by the 
> individual(s) for whom it is intended. If you have received this electronic 
> communication in error, please reply to the sender advising of the error in 
> transmission and delete the original message and any accompanying documents 
> from your system immediately, without copying, reviewing or otherwise using 
> them for any purpose. Thank you for your cooperation.

-- 
Sebastiano Pasqualato, PhD
Crystallography Unit
Department of Experimental Oncology
European Institute of Oncology
IFOM-IEO Campus
via Adamello, 16
20139 - Milano
Italy

tel +39 02 9437 5167
fax +39 02 9437 5990
web http://is.gd/IEO_XtalUnit

Re: [ccp4bb] EDS server - R-value

[Gerard Bricogne]

I replied in too great a rush - it is the Rfree, or the Rfree-Rwork gap,
that would go up a lot if a structure originally refined at low resolution
with targeting to an external high-resolution one was re-refined without
that targeting.

Gerard.

--
On Fri, Apr 04, 2014 at 04:55:03PM +0100, Gerard Bricogne wrote:
> Dear Nat and Tim,
> 
> On Fri, Apr 04, 2014 at 08:18:06AM -0700, Nat Echols wrote:
> > On Fri, Apr 4, 2014 at 1:57 AM, Tim Gruene  
> > wrote:
> > 
> > > A more up-to-date reason is that programs calculate R values very
> > > differently. If you take a PDB file refined with program X and put it
> > > into program Y you easily get discrepancies greater than 5%.
> > >
> > 
> > This is actually pretty rare - usually it's only 1-2% at most.
> > Discrepancies like 16.5% versus 30.9% usually indicate that there's
> > something wrong or misleading in the annotation of the entry, and often
> > mean that you can't even reproduce the R-factor with the specified program.
> > 
> > -Nat
> 
>  It could also be that such a structure is the result of a refinement
> against low-ish resolution data that was restrained by "targeting" it to
> another similar structure that was refined against higher-resolution data,
> so as to retain the good local geometry of the latter in spite of the
> shortage of data at low resolution. This is perfectly legitimate, and was
> first done by Oliver Smart in BUSTER under the acronym of "LSSR", outlined
> in an ACA 2008 Abstract then fully described in Acta Cryst. D68, 368-380
> (2012). A similar feature has also become available in REFMAC and PHENIX.
> 
>  The problem is that the deposition process is very likely to have lost
> track of the recourse to that method, so that the outcome of the refinement
> cannot be reproduced from the deposited data in an automated environment
> such as the EDS server.
> 
>  This may not be the case with the structure Tim was mentioning, but it
> provides an opportunity to point out that the use of some recent approaches
> to improving refinement at low resolution may need further attention at the
> deposition stage to ensure reproducibility of the results from the deposited
> information.
> 
> 
>  With best wishes,
>  
>   Gerard.

Re: [ccp4bb] Tenure track junior Group Leader Positions in Milan, Italy

[Oganesyan, Vaheh]

It sounds very interesting: "experimental and computational dance biology". Any 
type of computational dance or there are style limitations?

Regards,

Vaheh Oganesyan
www.medimmune.com
[MedI Logo Sig]

From: CCP4 bulletin board [mailto:CCP4BB@JISCMAIL.AC.UK] On Behalf Of 
Sebastiano Pasqualato
Sent: Friday, April 04, 2014 12:01 PM
To: CCP4BB@JISCMAIL.AC.UK
Subject: [ccp4bb] Tenure track junior Group Leader Positions in Milan, Italy


Dear all,
there are open positions for junior Group Leaders in the field of experimental 
and computational dance biology at the European Institute of Oncology in milan, 
Italy.
Please, find enclosed the details.

To the extent this electronic communication or any of its attachments contain 
information that is not in the public domain, such information is considered by 
MedImmune to be confidential and proprietary. This communication is expected to 
be read and/or used only by the individual(s) for whom it is intended. If you 
have received this electronic communication in error, please reply to the 
sender advising of the error in transmission and delete the original message 
and any accompanying documents from your system immediately, without copying, 
reviewing or otherwise using them for any purpose. Thank you for your 
cooperation. To the extent this electronic communication or any of its 
attachments contain information that is not in the public domain, such 
information is considered by MedImmune to be confidential and proprietary. This 
communication is expected to be read and/or used only by the individual(s) for 
whom it is intended. If you have received this electronic communication in 
error, please reply to the sender advising of the error in transmission and 
delete the original message and any accompanying documents from your system 
immediately, without copying, reviewing or otherwise using them for any 
purpose. Thank you for your cooperation.
<>

Re: [ccp4bb] EDS server - R-value

[Robbie Joosten]

Hi,

Did you look at the same structure in the PDB_REDO databank 
(www.cmbi.ru.nl/pdb_redo)? If the problem can be solved, the structure and maps 
should be there. If it cannot, you might get a slightly more informative error 
message from the WHY_NOT server.

Cheers,
Robbie

Sent from my Windows Phone

Van: jai mohan
Verzonden: 4-4-2014 10:08
Aan: CCP4BB@JISCMAIL.AC.UK
Onderwerp: [ccp4bb] EDS server - R-value

Dear all,
Sorry for the off-topic Question.
I just tried to extract files *.* from EDS server for a PDB entry.
The page tells us that

There is no map available for this entry (),
because our automatic script failed to produce an electron density map
with an R-value (0.309) within 5 percentage points of the published one (0.165).
If you are the author of this entry and wish to help us remedy this
situation, please contact us.
Back to EDS home page


The reported R-value for the () PDB entry is 0.16 than how 0.309?
could anyone please explain about this!

Sincerely,
S.M. Jaimohan, Ph. D

Re: [ccp4bb] EDS server - R-value

[Gerard Bricogne]

Dear Nat and Tim,

On Fri, Apr 04, 2014 at 08:18:06AM -0700, Nat Echols wrote:
> On Fri, Apr 4, 2014 at 1:57 AM, Tim Gruene  wrote:
> 
> > A more up-to-date reason is that programs calculate R values very
> > differently. If you take a PDB file refined with program X and put it
> > into program Y you easily get discrepancies greater than 5%.
> >
> 
> This is actually pretty rare - usually it's only 1-2% at most.
> Discrepancies like 16.5% versus 30.9% usually indicate that there's
> something wrong or misleading in the annotation of the entry, and often
> mean that you can't even reproduce the R-factor with the specified program.
> 
> -Nat

 It could also be that such a structure is the result of a refinement
against low-ish resolution data that was restrained by "targeting" it to
another similar structure that was refined against higher-resolution data,
so as to retain the good local geometry of the latter in spite of the
shortage of data at low resolution. This is perfectly legitimate, and was
first done by Oliver Smart in BUSTER under the acronym of "LSSR", outlined
in an ACA 2008 Abstract then fully described in Acta Cryst. D68, 368-380
(2012). A similar feature has also become available in REFMAC and PHENIX.

 The problem is that the deposition process is very likely to have lost
track of the recourse to that method, so that the outcome of the refinement
cannot be reproduced from the deposited data in an automated environment
such as the EDS server.

 This may not be the case with the structure Tim was mentioning, but it
provides an opportunity to point out that the use of some recent approaches
to improving refinement at low resolution may need further attention at the
deposition stage to ensure reproducibility of the results from the deposited
information.


 With best wishes,
 
  Gerard.

-- 

 ===
 * *
 * Gerard Bricogne g...@globalphasing.com  *
 * *
 * Global Phasing Ltd. *
 * Sheraton House, Castle Park Tel: +44-(0)1223-353033 *
 * Cambridge CB3 0AX, UK   Fax: +44-(0)1223-366889 *
 * *
 ===

Re: [ccp4bb] EDS server - R-value

[Pavel Afonine]

Here you can find a list of reasons for R-factor discrepancy and how much
each of them affects the R-factor:
http://phenix-online.org/papers/he5476_reprint.pdf

Pavel


On Fri, Apr 4, 2014 at 8:18 AM, Nat Echols wrote:

> On Fri, Apr 4, 2014 at 1:57 AM, Tim Gruene wrote:
>
>> A more up-to-date reason is that programs calculate R values very
>> differently. If you take a PDB file refined with program X and put it
>> into program Y you easily get discrepancies greater than 5%.
>>
>
> This is actually pretty rare - usually it's only 1-2% at most.
> Discrepancies like 16.5% versus 30.9% usually indicate that there's
> something wrong or misleading in the annotation of the entry, and often
> mean that you can't even reproduce the R-factor with the specified program.
>
> -Nat
>

Re: [ccp4bb] EDS server - R-value

[Nat Echols]

On Fri, Apr 4, 2014 at 1:57 AM, Tim Gruene  wrote:

> A more up-to-date reason is that programs calculate R values very
> differently. If you take a PDB file refined with program X and put it
> into program Y you easily get discrepancies greater than 5%.
>

This is actually pretty rare - usually it's only 1-2% at most.
Discrepancies like 16.5% versus 30.9% usually indicate that there's
something wrong or misleading in the annotation of the entry, and often
mean that you can't even reproduce the R-factor with the specified program.

-Nat

[ccp4bb] Postdoc position - Birkbeck ISMB London

[Gabriel Waksman]

Postdoctoral Research Assistant – Ref: 11234

Biophysics and Structural Biology of Complex Nanomachines

INSTITUTE OF STRUCTURAL AND MOLECULAR BIOLOGY

 

Full time, fixed term appointment for up to four years

 

The Institute of Structural and Molecular Biology is seeking a Post-doctoral 
Research Assistant to carry out biophysical and structural analysis (ensemble 
biophysics, single molecular biophysics including smFRET and optical tweezers, 
and x-ray crystallography) of complexes formed during pilus biogenesis. The 
group is led by Professor Gabriel Waksman and has over the years produced 
numerous high profile publications in the highest impact journals.  The 
research programme is funded by a grant from the MRC to Prof Gabriel Waksman. 
Further details on the research group can be found at 
http://people.cryst.bbk.ac.uk/~ubcg54a/.

 

Applicants should have a PhD in Structural Molecular Biology, Biophysics or a 
related area, postdoctoral research experience and relevant research 
publications.

 

Salary:

 

Researcher Level 2: Grade 7, £31,644 per annum plus the London Allowance of 
£3,006 per annum.

 

Researcher Level 3: Grade 3 £37,756 per annum plus the London Allowance of 
£3,006 per annum.

 

Closing date for completed applications: Sunday 4 May 2014 at midnight

 

To apply for this position please go to www.bbk.ac.uk/jobs and search using 
reference number 11234

[ccp4bb] PhD Position in Noroviruses

[Balu A]

A full scholarship for a PhD student to study noroviruses is available 
immediately in the lab of Dr. Grant Hansman at the German Cancer Research 
Center (DKFZ), Heidelberg, Germany. The scholarship will be awarded for a span 
of four years and is jointly sponsored by DKFZ and the Wiezmann Institute in 
Israel. 

The project will focus on molecular targets important for the development of 
antivirals and offer the PhD student an opportunity to learn and carry out 
experiments to determine the full-length genome sequences from norovirus 
isolates; express the variant capsid genes in insect cells and determine the 
antigenic changes amongst variant viruses; express and crystallize the variant 
RNA dependent RNA polymerase (RdRp) and capsid P domains in E.coli and 
determine their X-ray crystal structures; compare the histo-blood group antigen 
(HBGA) binding profiles among the variant P domains using X-ray 
crystallography; investigate the enzymatic activities among the variant RdRps; 
develop a virus-tracking system and observe differences between variant VLPs 
and their attachment/ entry to culture cells.

The potential candidate must be interested in understanding structure and 
pathogenicity of noroviruses. Prior experience in X-ray crystallography or 
viruses is a plus but is not a requirement. Interested candidates should 
forward their applications (a brief description of research interests and a CV) 
to Dr. Grant Hansman (g.hans...@dkfz-heidelberg.de) at the German Cancer 
Research Center.

[ccp4bb] PhD position in structure-based drug design in Germany

[Ruth Brenk]

Dear all,


The structure-based design research group of Ruth Brenk at the Johannes 
Gutenberg Universität Mainz (Germany) in the Institute for Pharmacy and 
Biochemistry has got the following job opening:


PhD student, paid according to EGr. 13 TV-L (50%)


Responsibilities:
Structure-based design of inhibitors of 
β-ketoacyl-(acyl-carrier-protein) synthase II (FabF), a target for 
antibiotics. In the course of the project, starting from the crystal 
structure of FabF new inhibitors shall be designed. Further, for testing 
potential inhibitors an assay system based on the “MicroScale 
Thermophoresis“ technology shall be developed. The binding modes of new 
inhibitors shall be determined using X-ray crystallography.


Prerequisites:
University degree (master or equivalent) in pharmacy, medical chemistry, 
biochemistry or a related subject.

Very good or excellent study results
Interest in working on a challenging research project in the area of 
structure-based drug design

Independent, aim oriented and thorough working attitude
Knowledge in the area of structure-based design, X-ray crystallography 
or recombinant protein expression are advantageous.


Further information are available from Ruth Brenk, br...@uni-mainz.de, + 
44 (6131) 39-25726. Please send your application with a CV, name of two 
references, university certificates and a motivation letter to the same 
address.



--
Jun.-Prof. Dr. Ruth Brenk
Johannes Gutenberg-Universität Mainz
Institut für Pharmazie und Biochemie
Staudinger Weg 5
D-55128 Mainz

Phone:  +49 (6131) 39-25726
Fax:  +49 (6131) 39-25670
http://www.pharmazie.uni-mainz.de/AK-Brenk

Re: [ccp4bb] loggraph not popping up after refmac5 ccp4-6.4

[hari jayaram]

Hi Ingo,
I tried replacing the loggraph script and also running the old ccp4 in its
entirety on the same machine
Both of them popup the blank graph window and then promptly crash with the
message we had posted.
Can anyone confirm if they are using Redhat 6.5 and blt with loggraph

Thanks for your suggestion

Hari

On Friday, April 4, 2014, Ingo P. Korndoerfer 
wrote:

>  hi,
>
> i belive i have for quite a while simply copied loggraph from the last
> working installation into the active version of ccp4.
>
> might be worth a shot ...
>
> ingo
>
>
> hari jayaram wrote:
>
> Hi all ..
> loggraph seems to be broken on Redhat 6.5 . It may be a "blt"  error. Can
> someone confirm that they can get loggraph to work on Redhat Enterprise 6.5
> with the ccp4 provided binaries.
>
>  Sadly Redhat nor Activestate provide "blt" replacements
>
>  In all cases the loggraph starts a blank window ready to plot a graph
> and then fails with the error
>
>  "Error in startup script: syntax error in expression "10 11 12 + 12":
> extra tokens at end of expression
> while executing
> "expr [string trim $ele] + $data(NCOLUMNS) "
> (procedure "extract_tables_from_GRAPH" line 44)
> invoked from within
> "extract_tables_from_$filetype $input $arrayname"
> (procedure "extract_tables_from_file" line 31)
> invoked from within
> "extract_tables_from_file $system(SCRIPT) $system(FORMAT) data"
> invoked from within
> "if { $system(SCRIPT) != "" } {
>   if { ![ElementExists system FORMAT] || $system(FORMAT) == "" } {
>  set system(FORMAT) [GetFileFormat $system(SCRI..."
> (file
> "/home/yong.tang/ccp4_root/ccp4-6.4.0/share/ccp4i/loggraph/loggraph.tcl"
> line 2324)
> invoked from within
>  "source [file join $env(CCP4I_TOP) loggraph loggraph.tcl]"
> (file
> "/home/yong.tang/ccp4_root/ccp4-6.4.0/share/ccp4i/bin/loggraph.tcl" line 83)
> "
>
>  Sadly We cannot go back to using Ubuntu where this was working.
>
>  The CCP4 provided  blt, bltsh and wish binaries seem to work fine ..its
> only loggraph that fails .
>
>  We are using the current ccp4 installed yesterday.
>
>  I also tried using Activestate wish and combining it with ccp4 provided
> bltsh ..but in that case I get the error :
>
>  package require blt
>
>  Thanks
>
>  Hari ( and Yong)
>
>
>
>
> On Wed, Apr 2, 2014 at 2:33 PM, Yong Tang  wrote:
>
>  Hello All,
>
> Further to my earlier email..I am running ccp4 6.4 , on 64 bit Redhat
> Linux 6.5
>
>  I cannot see loggraphs with View-Files-From-Job - View Log Graphs--
>
>  That throws an error in the shell. This is the same error  I see when
> coot finishes refmac5 as well.
> It seems that the loggraph tcl script is broken somehow.
>
>  Any ideas on how to fix.
>  Thank you for your help
>
>
>  Yong
>
>
> Top level CCP4 directory is /home/yong/ccp4_root/ccp4-6.4.0
> Using CCP4 programs from /home/yong/ccp4_root/ccp4-6.4.0/bin
> Error in startup script: syntax error in expression "10 11 12 + 12": extra
> tokens at end of expression
> while executing
> "expr [string trim $ele] + $data(NCOLUMNS) "
> (procedure "extract_tables_from_GRAPH" line 44)
> invoked from within
> "extract_tables_from_$filetype $input $arrayname"
> (procedure "extract_tables_from_file" line 31)
> invoked from within
>
> --
> CRELUX GmbH
>
> Dr. Ingo Korndoerfer
> Head of Crystallography
>
> Am Klopferspitz 19a
> 82152 Martinsried
> Germany
>
> Phone: +49 89 700760210
> Fax: +49 89 700760222 korndoer...@crelux.com 
> www.crelux.com
>
> Amtsgericht München HRB 165552 - Managing Directors: Dr. Michael Schäffer, 
> Dr. Ismail Moarefi
>
> This e-mail may contain confidential and/or privileged information. If you 
> are not the intended recipient (or have received this e-mail in error) please 
> notify the sender immediately and destroy this e-mail. Any unauthorized 
> copying, disclosure or distribution of the material in this e-mail is 
> strictly forbidden.
> Diese E-Mail enthält vertrauliche und/oder rechtlich geschützte 
> Informationen. Wenn Sie nicht der richtige Adressat sind oder diese E-Mail 
> irrtümlich erhalten haben, informieren Sie bitte sofort den Absender und 
> vernichten Sie diese Mail. Das unerlaubte Kopieren sowie die unbefugte 
> Weitergabe dieser Mail ist nicht gestattet.
>
>
>
>

Re: [ccp4bb] How to install XDS on iMac

[Tim Gruene]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear Saleem,

the file you download from Wolfgang Kabsch's page is a gzipped
tar-Archive.

You can look into its content with the command
tar tfz XDS-OSX10.5.8_Darwin9.8.0.tar.gz

This tells you that upon extraction (see below) you will have a
subdirectory XDS-OSX10.5.8_Darwin9.8.0

I recommend you open a terminal, change into the directory /usr/local
and copy the archive there. Then you can extract the archive with
tar xfz XDS-OSX10.5.8_Darwin9.8.0.tar.gz

Once this is done, you have to make sure the directory is part of your
PATH variable so that you can run xds. This is best ensured by editing
the file ~/.bashrc and append the line
export PATH=$PATH:/usr/local/XDS-OSX10.5.8_Darwin9.8.0

The next time you open a terminal, the xds-binaries should be found,
i.e. if you type 'xds_par' you are ready to go.

Best,
Tim

On 04/04/2014 11:49 AM, saleem raza wrote:
> Hi, I was wondering if anyone can help me with the installation of
> xds on iMac? regardsSaleem
> 

- -- 
- --
Dr Tim Gruene
Institut fuer anorganische Chemie
Tammannstr. 4
D-37077 Goettingen

GPG Key ID = A46BEE1A

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iD8DBQFTPpAFUxlJ7aRr7hoRAlpmAKCv2K5UrOhVEGJq52NVqUavnVRKQwCfekjK
gdfaS2Dc2fPd/ZJ7UsNZWbA=
=/hjG
-END PGP SIGNATURE-

[ccp4bb] How to install XDS on iMac

[saleem raza]

Hi,
I was wondering if anyone can help me with the installation of xds on iMac?
regardsSaleem 

Re: [ccp4bb] EDS server - R-value

[Tim Gruene]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear S. M. Jaimohan,

one reason such a discrepancy is often the presence of TLS, which may
be present in the PDB-header but is not found in the PDB coordinates.
Another reason might be that during deposition |F| and I got confused
- - this is not too uncommon for elderly entries.

A more up-to-date reason is that programs calculate R values very
differently. If you take a PDB file refined with program X and put it
into program Y you easily get discrepancies greater than 5%. At the
DGK meeting two weeks ago some structures were presented solved at
3'ish A resolution with R/Rfree near 14%/16%, which I would be very
suspicious about...

That's why I think that R-values are becoming meaningless. They are
useful guides for the refinement of one particular structure with one
particular program, but any deviation from this and you cannot compare
R-values. Other validation tools like those implemented in Coot or the
Molprobity server are much more reliable. Maybe that's a good thing
because this makes people move away from using a single number to
judge about 10,000s of parameters.

Best,
Tim

On 04/04/2014 10:07 AM, jai mohan wrote:
> Dear all, Sorry for the off-topic Question. I just tried to extract
> files *.* from EDS server for a PDB entry. The page tells us that
> 
> There is no map available for this entry (), because our
> automatic script failed to produce an electron density map with an
> R-value (0.309) within 5 percentage points of the published one
> (0.165). If you are the author of this entry and wish to help us
> remedy this situation, please contact us. Back to EDS home page
> 
> 
> The reported R-value for the () PDB entry is 0.16 than how
> 0.309? could anyone please explain about this!
> 
> Sincerely, S.M. Jaimohan, Ph. D
> 

- -- 
- --
Dr Tim Gruene
Institut fuer anorganische Chemie
Tammannstr. 4
D-37077 Goettingen

GPG Key ID = A46BE
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.12 (GNU/Linux)
Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iD8DBQFTPnQBUxlJ7aRr7hoRAoNVAJ9eSKs+Zq5dz1cryZB/8qC+FtnleQCfamDY
UPpJZTTMIRPqGrS+YpDVq+0=
=DuKK
-END PGP SIGNATURE-

Re: [ccp4bb] EDS server - R-value

[Jon Agirre]

Dear Jai,

you can find lots of possible explanations in that very same website:
http://eds.bmc.uu.se/eds/eds_help.html#PROB_RFAC


On 4 April 2014 09:07, jai mohan  wrote:

> Dear all,
> Sorry for the off-topic Question.
> I just tried to extract files *.* from EDS server for a PDB entry.
> The page tells us that
>
> There is no map available for this entry (),
> because our automatic script failed to produce an electron density map
> with an *R-value (0.309)* within 5 percentage points of the published one
> (*0.165*).
> If you are the author of this entry and wish to help us remedy this
> situation, please contact us
> .
> Back to EDS home page 
>
> The reported R-value for the () PDB entry is 0.16 than how 0.309?
> could anyone please explain about this!
> Sincerely,
> S.M. Jaimohan, Ph. D
>



-- 
Dr Jon Agirre
York Structural Biology Laboratory / Department of Chemistry
University of York, Heslington, YO10 5DD, York, England
http://www.york.ac.uk/chemistry/research/ysbl/people/research/jagirre/
+44 (0) 1904 32 8253

[ccp4bb] EDS server - R-value

[jai mohan]

Dear all,
Sorry for the off-topic Question.
I just tried to extract files *.* from EDS server for a PDB entry.
The page tells us that

There is no map available for this entry (),
because our automatic script failed to produce an electron density map
with an R-value (0.309) within 5 percentage points of the published one (0.165).
If you are the author of this entry and wish to help us remedy this
situation, please contact us.
Back to EDS home page


The reported R-value for the () PDB entry is 0.16 than how 0.309? 
could anyone please explain about this!

Sincerely,
S.M. Jaimohan, Ph. D